Fix OTP splicing with updatemem #15162
Comments
|
I ran Vivado with a modified TCL script where I don't make modification to I opened the Vivado GUI and searched for cells of type BMEM.BRAM, and it's now very clear why the placement values have that strange prefix. For example, the OTP cell rom.mmi<?xml version="1.0" encoding="UTF-8"?>
<MemInfo Version="1" Minor="0">
<Processor Endianness="Little" InstPath="dummy">
<AddressSpace Name="rom" Begin="0" End="39935">
<BusBlock>
<BitLane MemType="RAMB32" Placement="X7Y35">
<DataWidth MSB="3" LSB="0"/>
<AddressRange Begin="0" End="8191"/>
<Parity ON="false" NumBits="0"/>
</BitLane>
<BitLane MemType="RAMB32" Placement="X6Y37">
<DataWidth MSB="7" LSB="4"/>
<AddressRange Begin="0" End="8191"/>
<Parity ON="false" NumBits="0"/>
</BitLane>
<BitLane MemType="RAMB32" Placement="X7Y39">
<DataWidth MSB="11" LSB="8"/>
<AddressRange Begin="0" End="8191"/>
<Parity ON="false" NumBits="0"/>
</BitLane>otp.mmi<?xml version="1.0" encoding="UTF-8"?>
<MemInfo Version="1" Minor="0">
<Processor Endianness="Little" InstPath="dummy">
<AddressSpace Name="rom" Begin="0" End="2815">
<BusBlock>
<BitLane MemType="RAMB32" Placement="18_X8Y127">
<DataWidth MSB="0" LSB="0"/>
<AddressRange Begin="0" End="1023"/>
<Parity ON="false" NumBits="0"/>
</BitLane>
<BitLane MemType="RAMB32" Placement="18_X7Y125">
<DataWidth MSB="1" LSB="1"/>
<AddressRange Begin="0" End="1023"/>
<Parity ON="false" NumBits="0"/>
</BitLane>
<BitLane MemType="RAMB32" Placement="18_X7Y123">
<DataWidth MSB="2" LSB="2"/>
<AddressRange Begin="0" End="1023"/>
<Parity ON="false" NumBits="0"/>
</BitLane> |
dmcardle
added a commit
to dmcardle/opentitan
that referenced
this issue
Sep 27, 2022
Signed-off-by: Dan McArdle <dmcardle@google.com>
This was referenced Sep 28, 2022
|
To summarize, I think the root of this issue is that the MMI file(s) we generate are probably incorrect, causing Ideally, I would just call I do wonder whether I was running I have a few things to try:
|
|
One thing I don't quite understand is that the BRAMs for ROM appear to be "RAMB36", yet we write "RAMB32" into the MMI file. Our OTP BRAMs are "RAMB18", so it's not clear what memory type to claim in the MMI file. Some folks on a forum 5 years ago say that updatemem does not support RAMB18, but it's not a conclusive answer from Xilinx. I briefly tried enabling RAMB18 support with the effectively undocumented UPDATEMEM_ALLOW_RAMB18 environment variable but it didn't have the desired effect (sorry to be vague, I should have taken better notes.) |
|
As suspected, the file from The file from Filtering just the relevant stuff: I think the first 22 lines of output correspond to the 22 BRAM cells, but I'm not exactly sure what to do with the |
|
If you change the minor version of the file to 1, it looks like updatemem accepts the RAMB18: <?xml version="1.0" encoding="UTF-8"?>
-<MemInfo Version="1" Minor="0">
+<MemInfo Version="1" Minor="1">
<Processor Endianness="Little" InstPath="dummy"> |
dmcardle
added a commit
to dmcardle/opentitan
that referenced
this issue
Oct 10, 2022
Signed-off-by: Dan McArdle <dmcardle@google.com>
dmcardle
added a commit
to dmcardle/opentitan
that referenced
this issue
Oct 14, 2022
Signed-off-by: Dan McArdle <dmcardle@google.com>
dmcardle
added a commit
to dmcardle/opentitan
that referenced
this issue
Oct 15, 2022
Signed-off-by: Dan McArdle <dmcardle@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think OTP splicing might not be working properly. I changed the value of
CREATOR_SW_CFG_ROM_EXEC_ENand modified the SRAM execution test to (1) use an OTP-spliced bitstream and (2) print the OTP value at the expected address. Bazel definitely ran the commands to splice the OTP image in, but when the GDB script ran, it printed the default value forCREATOR_SW_CFG_ROM_EXEC_ENrather than the value I chose.I believe these local changes are sufficient to reproduce the result when running
./bazelisk.sh test --define bitstream=gcp_splice //sw/device/examples/sram_program:sram_program_fpga_cw310_test. (The SRAM program test was just handy, but it should be irrelevant because GDB is printing the value before loading the SRAM program into memory.)Let's peek at the MMI files that we generated with vivado_hook_write_bitstream_pre.tcl.
I noticed a few things:
The DataWidth values in
rom.mmido not overlap, but the ones inotp.mmido overlap. I think this is forbidden per the Xilinxupdatememmanual:I wonder whether this has something to do with the TCL condition that adds 3 to the
slice_endvariable. vivado_hook_write_bitstream_pre.tcl:66The Placement values in
rom.mmiare of the form "X{}Y{}" like theupdatememmanual examples, but the values inotp.mmiare prefixed with18_.I have a suspicion that we're not trimming the right string from the left of the LOC property for OTP images. vivado_hook_write_bitstream_pre.tcl:60
rom.mmi
otp.mmi
The text was updated successfully, but these errors were encountered: