- 19 12月, 2020 1 次提交
-
-
由 Yinan Xu 提交于
-
- 13 12月, 2020 1 次提交
-
-
由 zoujr 提交于
-
- 12 12月, 2020 5 次提交
- 11 12月, 2020 1 次提交
-
-
由 zoujr 提交于
-
- 10 12月, 2020 2 次提交
- 06 12月, 2020 1 次提交
-
-
由 Yinan Xu 提交于
-
- 01 12月, 2020 2 次提交
- 30 11月, 2020 1 次提交
-
-
由 ZhangZifei 提交于
-
- 29 11月, 2020 1 次提交
-
-
由 Yinan Xu 提交于
-
- 27 11月, 2020 2 次提交
- 26 11月, 2020 1 次提交
-
-
由 zoujr 提交于
-
- 22 11月, 2020 2 次提交
- 21 11月, 2020 1 次提交
-
-
由 Yinan Xu 提交于
-
- 19 11月, 2020 1 次提交
-
-
由 Yinan Xu 提交于
-
- 04 11月, 2020 1 次提交
-
-
由 Yinan Xu 提交于
Previously, the RAM is synchronous. However, due to verilator issues, the bug is hidden by Buffer that includes FFs. The buffer works as follows (simplified): always @(posedge clk) data_out <= data_form_ram_helper; data_from_ram_helper is given by (synchronous read): always @(posedge clk) ram_helper(raddr, data_from_ram_helper); At every positive edge, data_out should be assigned with data_from_ram_helper_old, and data_from_ram_helper should then be evaluated to the new value during the next clock cycle. However, verilator evaluates data_from_ram_helper first and then assigns it to data_out, that is, data_out is incorrectly assigned by data_from_ram_helper. For example, verilator gives the following sequence: raddr data_from_ram_helper data_out 0 X X 1 data[0] data[0] 2 data[1] data[1] However, the correct values should be: raddr data_from_ram_helper data_out 0 X X 1 data[0] X 2 data[1] data[0] Previously, due to the two bugs, ram works well. However, when it comes to multi-threading, they are put to two threads and since verilator does not find the relationship between raddr and data_from_ram_helper, data_out, they don't follow any specific evaluation order. Thus, multi-threaded emu randomly produces difftest error. To prove that verilator incorrectly evaluates DPI-C functions and related signals (however, it's also possible that we were using DPI-C functions incorrectly), one can change ram.v to always @(posedge clk) begin rdata <= ram_read_helper(raddr); ram_write_helper(waddr, wdata); end This should be the same with previous version of ram.v but it will give errors on difftest. To solve the issue, this commit makes two modifications: (1) make the ram asynchronous AXIWrapper requests the RAM to be asynchronous such that after ar.fire() we have eight cycles of rdata[0-7]. (2) changes DPI-C function prototype to uint64_t ram_read_helper(uint64_t raddr) In this form, verilator detects the correct order between data_from_ram_helper and data_out evaluation.
-
- 26 10月, 2020 1 次提交
-
-
由 Yinan Xu 提交于
-
- 23 10月, 2020 1 次提交
-
-
由 William Wang 提交于
-
- 20 10月, 2020 1 次提交
-
-
由 William Wang 提交于
-
- 13 8月, 2020 1 次提交
-
-
由 ZhangZifei 提交于
-
- 09 8月, 2020 1 次提交
-
-
由 Yinan Xu 提交于
-
- 06 8月, 2020 1 次提交
-
-
由 Yinan Xu 提交于
-
- 05 8月, 2020 2 次提交
- 26 7月, 2020 2 次提交
- 25 7月, 2020 1 次提交
-
-
由 Zihao Yu 提交于
* by default, snapshot will be saved every 10s
-
- 08 3月, 2020 2 次提交
- 11 12月, 2019 1 次提交
-
-
由 Zihao Yu 提交于
* To run more programs on debian, we use 256MB memory described in dts. But if the hardware still provides 128MB memory, the memory access will wrap around when Linux allocate a physical page excceed 128MB, which causes wrong memory access.
-
- 11 11月, 2019 1 次提交
-
-
由 zhangzifei 提交于
-
- 04 11月, 2019 2 次提交
-
-
由 zhangzifei 提交于
-
由 zhangzifei 提交于
-