Missing INIT string data in FASM for selected BRAM sites #1285
Comments
|
If you run $XRAY_BIT2FASM --verbose, and grep the output for "unknown", do you find anything? |
|
Yes, lots of such messages. I just dumped everything it output to a file, it is attached. |
|
This issue (#1285) suggests that there are some holes in the prjxray bitstream db as it relates to BRAMs. Interestingly, it only occurs for some BRAMs in one column of the device - the bitstream is correct for others. Would like to track down and propose a fix for this, and have some new students coming on-line soon to help. A bit of direction from the experts out there could be helpful to jump start this. |
|
@nelsobe Have you confirmed that the |
|
To be clear, BRAM36's are exposed in FASM as 2 BRAM18's. If you repeat the design using only BRAM18's, do you observe the same error? How confident is your mapping between the BRAM36 and 2x BRAM18's? |
|
Yes, we have verified that the INIT in Vivado is different from the INIT in the resulting FASM (and that it gives a bunch of "unknown" messagses when it creates the FASM). Here is some background info so maybe you can help us zero in on where in the code base things are going wrong. The relevant files are above in the initial comment for this issue up above if you want to reproduce. The design consists of a single memory written in behavioral Verilog. Vivado synthesizes that to a bitstream (device is Artix-7 50T part). That is the entire processing chain, nothing unusual about it that I can see. When $XRAY_BIT2FASM --verbose is run on the resulting bitstream it ends with errors about unknown bits and unknown segments. 100's of tests have been run with various sizes and shapes of memories. The result shows that the bit2fasm errors only occur for BRAMs in specific locations on the chip - they are always for BRAMs in the same couple of locations. For memories that are mapped to different locations there are never any errors. An error in the bitstream database for this part could be an explanation but I would assume there may be other explanations. We are new enough to the system that I don't know where to point my students. Any suggestions appreciated. However, I assume it is a bug that ought to be found and fixed in the tools and we are happy to dive in. Here are the errors at the bottom of the fasm file when --verbose is included : In frame 0x0040129b 8 bits were not converted.{ unknown_bit = "0040129b_76_19", unknown_segment = "0x00401280", unknown_segbit = "27_2451" } In frame 0x0040031b 40 bits were not converted.{ unknown_bit = "0040031b_56_19", unknown_segment = "0x00400300", unknown_segbit = "27_1811" } In frame 0x00000f1b 16 bits were not converted.{ unknown_bit = "00000f1b_5_19", unknown_segment = "0x00000f00", unknown_segbit = "27_179" } In frame 0x0000129b 8 bits were not converted.{ unknown_bit = "0000129b_5_19", unknown_segment = "0x00001280", unknown_segbit = "27_179" } In frame 0x00400f1b 24 bits were not converted.{ unknown_bit = "00400f1b_76_19", unknown_segment = "0x00400f00", unknown_segbit = "27_2451" } In frame 0x0000031b 32 bits were not converted.{ unknown_bit = "0000031b_5_19", unknown_segment = "0x00000300", unknown_segbit = "27_179" } |
|
I need the DCP from your replication, or your exact TCL script and Vivado version used. |
|
Tile |
|
I assume |
|
Yes, the 47 was a typo, they are both in X37. Files attached, including .tcl file which generates .bit file (also included). I am running Vivado 2017.2 on Ubuntu 16.04. |
|
The problems appears to soley about all BRAM_R tiles. BRAM_L tiles operate per the database. As a short term solution, you can set prohibit on sites located within BRAM_R tiles, something akin: |
|
Thanks. So, are you saying the BRAM_R are not supported yet? Or, that there is a bug in their handling? A curious thing, however, is that from our experiments it is clear that the brams at BRAM_R_X37Y50 and BRAM_R_X37Y55 work just fine. That is, the resulting FASM file has exactly the same INIT contents as Vivado does. This goes for random data as well as all 1's data. That may be due to luck in how the frames line up or something else in the code, but it is true nonetheless. That is why I only originally reported it for just two of the locations. I haven't done an exhaustive test for all BRAM_R locations on the chip, but I do know that some work (X37Y50 and X37Y55) and some do not (X37Y35 and X37Y40). |
|
At a minimum, the top 128 bits INIT_3F of BRAM_R (and the top bits of the high INITP) appear to have problems. If I had to guess, the problem lies in bitread, but I don't have hard data yet. |
If you can avoid needing to set INIT_3F[255:128] or INITP_07[255:128], then I expect things work as expected. |
|
That is exactly what we noticed - always the top half of INIT_3F was all 0's. |
|
@tmichalak I believe that bitread is missing some bits at the end of the bitstream. Replication, using Vivado's rbt output (with the So the RBT version of the bitstream shows two differences. The first change in the high bit of However the Is this a latent bug in bitread or an error in the |
|
The |
|
@litghost Has this bug been resolved now? |
When generating a large memory in Verilog, in some cases, parts of the BRAM INIT information is missing when the .bit file is converted to FASM.
Here is an example (memory was initialized to all 1's in Verilog, BRAM INIT string should be 256 1's but some get left off):
BRAM_R_X37Y35.RAMB18_Y0.INIT_3F[127:0] = 128'b11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
There are 3 other such INIT strings in this design out of many that have this issue. This is for the xc7a50 part.
The common thread is the location of the particular BRAM cells -
X37Y35 and X37Y40 are the only locations identified thus far where the information drops occur. Have run 100's of other test cases which map BRAMs to other locations without problems (cannot say have tried every other single site, however).
Additional info:
To re-create:
Generate a bitstream for the attached .sv code for the Artix-7 50T part.
Run $XRAY_BIT2FASM on the resulting .bit file.
Here is the test code:
128kb8.zip
The text was updated successfully, but these errors were encountered: