f4pga / f4pga-arch-defs

FOSS architecture definitions of FPGA hardware useful for doing PnR device generation.
https://f4pga.org
ISC License
270 stars 113 forks source link

Errors in implement a Verilog design involving in uart485 and rom #2103

Open zjenny09 opened 3 years ago

zjenny09 commented 3 years ago

Hi, I tried to implement a Verilog design based on the bram_init_test_18 . I found the following errors:

  1. Because I do not have a development board with RS232, I modified the design from RS232 to RS485. Besides, I added a controller module to enable or disable the bram test function. However, the controller didn't work. Yet, the controller implemented by vivado can work well.

  2. In addition, the output data was "E"...."0D" "0A", which indicated that the BRAM initial data was not correct. To ensure the BRAM data, I further modified the Rom_test and ERROR_OUTPUT_LOGIC into ROM_READ module in top.v. The output data did not correct either. According to my design, the output data should include rom_data and rom_address. Since the BRAM was initiated to data equal to address, the output data should be someting like "... 01 B1 01 B1 01 B2 01 B2 01 B3 01 B3 01 B4 01 B4 01 B5 01 B5 01 B6 01 B6 01 B7 01 B7..."(the output data was correct while implemented by vivado again). However, the output data was actually someting like "...01 B1 01 B2 01 B3 01 B4 01 B5 01 B6 01 B7...". In order to locate the fault, I tried to simulate it. That's how I found the third error.

  3. During Post_implement function simulation, the state-jump of the FSM in ROM_READ module is faulty. The wave should be: image1 However, the wave actually was: image2 State became a five-bit reg, which should be a four-bit reg. And Sub_state became a three-bit reg, which should be a two-bit reg.

I wondow whether you have tried the bram init test. Could you tell my your test process and your result? Would you give me some advice in how to debug/implement my design? @mithro

litghost commented 3 years ago

Based on your debugging where do you believe the error arose? If you use yosys + Vivado, does the design work? If you run the bitstream through xc-bit2fasm and simulate the output, can you see where the error arose?

zjenny09 commented 3 years ago

Based on your debugging where do you believe the error arose? If you use yosys + Vivado, does the design work? If you run the bitstream through xc-bit2fasm and simulate the output, can you see where the error arose?

I did not try yosys + Vivado, but I tried behavioral simulation of top_synth.v. The wave was similiar to image2. State was also a five-bit reg. Sub_state was a three-bit reg too.

I don't know how to use yosys + Vivado.

litghost commented 3 years ago

If behavior simulation of top_synth.v is failing, this likely points to synthesis issue. Does the same issue exist with top_synth.premap.v?

the-centry commented 3 years ago

If behavior simulation of top_synth.v is failing, this likely points to synthesis issue. Does the same issue exist with top_synth.premap.v?

Tried these test exmples and I founed that the behavior simulation of top_post_synthesis is different from on board,whether it means that the genfasm has bug! Had someone thought to use yosys+vpr+vivado to generate bit and then compare with the bit generated by symbiflow such as v2b? Thanks so much!

zjenny09 commented 3 years ago

If behavior simulation of top_synth.v is failing, this likely points to synthesis issue. Does the same issue exist with top_synth.premap.v?

Yes, the same issue ocures. Maybe there are someting wrong with yosys in bram initializing. I found when bram initialization data-width is 16-bit, (difined by reg [15:0] ram[0:1023];), the initial data of RAMB18E1 in top_synth.premap.v is someting like .INIT_00(256'bx000000000001111x000000000001110x000000000001101x000000000001100x000000000001011x000000000001010x000000000001001x000000000001000x000000000000111x000000000000110x000000000000101x000000000000100x000000000000011x000000000000010x000000000000001x000000000000000). However I guess it should be someting like .INIT_00(256'b0000000000001111000000000000111000000000000011010000000000001100000000000000101100000000000010100000000000001001000000000000100000000000000001110000000000000110000000000000010100000000000001000000000000000011000000000000001000000000000000010000000000000000).

litghost commented 3 years ago

However I guess it should be something like (x -> 0)

We specifically handle x in INIT strings with the following lines in the synthesis TCL script: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/7ab78089e229ff74f2280b879b5128dfcb109abc/xc/xc7/yosys/synth.tcl#L177

zjenny09 commented 3 years ago

However I guess it should be something like (x -> 0)

We specifically handle x in INIT strings with the following lines in the synthesis TCL script: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/7ab78089e229ff74f2280b879b5128dfcb109abc/xc/xc7/yosys/synth.tcl#L177

This command makes (x -> 0). But there should not be any x in _topsynth.premap.v, since the initialization data-width is 16-bit. When BRAM initialization data-width is 15-bit, the initial data of RAMB18E1 in _topsynth.premap.v should be .INIT_00(256'bx000000000001111x000000000001110x000000000001101x000000000001100x000000000001011x000000000001010x000000000001001x000000000001000x000000000000111x000000000000110x000000000000101x000000000000100x000000000000011x000000000000010x000000000000001x000000000000000). And then "x"s are modified to 0 in _topsynth.v by the command you mentioned . However, since the initialization data-width is 16-bit, it should be .INIT_00(256'b0000000000001111000000000000111000000000000011010000000000001100000000000000101100000000000010100000000000001001000000000000100000000000000001110000000000000110000000000000010100000000000001000000000000000011000000000000001000000000000000010000000000000000) already in _top_synth.premap.v_. While the initialization data-width is 16-bit, "x"s in the initialization data make effect data lose. For example, if init data is 03FF, it turned into 01FF owing to the "x"s of the initialization data.

litghost commented 3 years ago

So you are assuming a specific data pattern that may not be true based on the Yosys BRAM mapping. Please review https://github.com/YosysHQ/yosys/blob/master/techlibs/xilinx/brams_init.py and https://github.com/YosysHQ/yosys/blob/master/techlibs/xilinx/xc7_brams_map.v and double check your assumptions.

GitHub
YosysHQ/yosys
Yosys Open SYnthesis Suite. Contribute to YosysHQ/yosys development by creating an account on GitHub.
GitHub
YosysHQ/yosys
Yosys Open SYnthesis Suite. Contribute to YosysHQ/yosys development by creating an account on GitHub.