Flash status synchronisation tb fix #21977
Conversation
|
This PR takes care of issue #21111 |
antmarzam
force-pushed
the
flash_status_and_addr_mode_synchronisation_tb_fix
branch
from
b263980
to
dd07f33
Compare
antmarzam
force-pushed
the
flash_status_and_addr_mode_synchronisation_tb_fix
branch
from
dd07f33
to
acd4bf3
Compare
antmarzam
force-pushed
the
flash_status_and_addr_mode_synchronisation_tb_fix
branch
3 times, most recently
from
e4c9841
to
8ef0cef
Compare
antmarzam
force-pushed
the
flash_status_and_addr_mode_synchronisation_tb_fix
branch
2 times, most recently
from
9dda7a7
to
426da15
Compare
Flash status checks have been reworked and upgraded (including READ_STATUS commands no longer wrap around the flash_status value) There's a new Analysis Port in the monitor which sends the SPI seq_item on CSB being active, and then whichever component is hooked to that AP could get notified on each sampled byte going through the SPI-bus and on CSB going inactive via SV events in the sequence item. SPI sequence item now was 2 SV events which are triggered by the monitor each time a byte is sampled and when the CSB goes inactive. Status bits towards the host-side are committed on each SPI-byte, whereas the TL-UL side is updated on each CSB assertion (CSB===1) The TB uses several SV queues to model the view at each side of the CDC, including fuzzy queues where temporary values are held until they're known to have travel towards each of the CDC domains Signed-off-by: Antonio Martinez Zambrana <[email protected]>
antmarzam
force-pushed
the
flash_status_and_addr_mode_synchronisation_tb_fix
branch
from
426da15
to
48a4443
Compare
The intercept sequence now also randomly drives: - concurrent TL-UL and SPI side transactions - sequential TL-UL (on CSB inactive) and SPI-TXn - Double TL-UL flash status write in parallel with SPI txn. This double write is sent when the busy bit is set and it comprises of the first write setting the upper bits of the status register and the second write clearing the busy/wel bits. The intr_state task now rather than making a read every X random clk_cycles reads the intr_state every cycle through the backdoor and if there are interrupts, then it does a front-door read to update the predicted values in SCB. Otherwise, it may happen the TB doesn't repopulate either half of the read buffer "early enough" leading to memory mismatches. Signed-off-by: Antonio Martinez Zambrana <[email protected]>
antmarzam
force-pushed
the
flash_status_and_addr_mode_synchronisation_tb_fix
branch
from
48a4443
to
ee997eb
Compare
There was a problem hiding this comment.
This looks good, thanks. As a minor nit, I think you addressed some of my style comments in the second commit, so we sometimes get a sequence of "... mess up style; fix style ...". But amending exactly the right commit is a pain!
On the plus side, magit has a reasonably nice way of doing this: either @hcallahan-lowrisc or I can probably show you in person at some point. Another win for Emacs :-)
But it's definitely not worth re-doing everything for. Thank you very much for tidying things up.
|
Was a significant subset of tests run on this? It looks like regression results have taken a big dive between before this change (https://reports.opentitan.org/hw/ip/spi_device_2p/dv/2024.03.29_04.21.20/report.html) and after (https://reports.opentitan.org/hw/ip/spi_device_2p/dv/2024.04.01_04.52.26/report.html). Are those real failures? |
I run quite a bunch of tests for the flash_status changes. I had some spurious failures of tests timing out which passed once I rerun them. |
TB has been updated to check for flash_status bits correctness.
SPI-monitor now triggers SV events on each byte sampled on the SPI bus as well as when the CSB is deasserted.
The intercept VSEQ has been updated so reads/writes to flash_status won't occur just sequentially before/after a SPI-txn but also concurrently, as well as sending two flash_status writes in a row (less likely) where the first writes the upper bits of the flash_status register, and the second would clear the busy/wel bits.
The Scoreboard has been updated to be in sync with the latest flash_status behaviour changes in the RTL: