LSRAM corrupt RDATA in ModelSim, ref design generated using args: BFM_SIMULATION MSS_BAREMETAL

[Kian-KH]

I've generated the MPFS_ICICLE_BFM_SIMULATION.prjx using Libero 2022.3 and passed both BFM_SIMULATION and MSS_BAREMETAL arguments prior to script execution. However, opening the testbench SmartDesign interactively in ModelSim would produce the waveform below, showing that RDATA is different from WDATA written to the MSS_LSRAM:

[hughbreslin]

Hi @Kian-KH this is actually expected (a bit misleading) the LSRAM isn’t initialised for the BFM. The first write and read back is 64 bit so it looks fine, the second write and read back is 32 bit so the upper bits in that address of the LSRAM are unknown for ModelSim and it produces Xs in the upper bits and the same for the third write/read.

If you add the strobe signals you’ll see the width of the writes and reads. There is an update to be released to add in the strobe signals in BFM so it’s clearer.

I hope this clears it up :)

If you want in the design open up the configurator for the LSRAM and select initialise memory (I don’t have it in front of me, if you select initialise without adding a memory file it should initialise the memory with 0s or else there is a tick box for this) - when you’ve done this you should see 0s instead of Xs.

[Kian-KH]

Hi @hughbreslin , is the "data lingering" seen in the third and fourth writes related to the fact that we're not reading/writing in fixed address intervals (just like 1st and 2nd)? I'm saying "lingering" because LSBs seem to linger and not replaced by Xs anymore.

[hughbreslin]

Again this is related to the strobes and the width of the writes - you can see here that the 3rd write is 16 bit and the 4th is 8 bit, it will leave the existing data untouched as you aren’t writing it.

If you wanted to zeroize the existing data you should do a 64 bit write with just the data you want

[Kian-KH]

Got it, thanks a lot @hughbreslin !

[hughbreslin]

No problem :)