http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-March/005453.html we would like to have write-through capability in nmigen Memory. when one write-port writes, a read-port *in the same major cycle* is capable of receiving that same data. Staf mentions that the SRAM that he is doing makes that data available on the *falling* edge (not on the exact same cycle).
I may have overlooked something and write-through may actually be implemented. I think the trick is to have both a read and a write port; have these port share the same address signal and also do a read when you do a write (e.g. have transparent read port which make the read port always enabled).
i think this was the basis of a unit test that jacob wrote, and he found that there was a definite bug in the nmigen Simulation. i believe however it was a 2R1W arrangement. jacob can you remember?
(In reply to Luke Kenneth Casson Leighton from comment #2) > i think this was the basis of a unit test that jacob wrote, and he found that > there was a definite bug in the nmigen Simulation. i believe however it > was a 2R1W arrangement. jacob can you remember? Found it: https://salsa.debian.org/Kazan-team/simple-barrel-processor/-/blob/391d95f30bd99e37236af8fb95565809b7230e29/test/test_mem.py nmigen bug: https://github.com/m-labs/nmigen/issues/47 Turned out that write conflicts weren't implemented as advertised, the buggy feature (write port priority) was later removed: https://github.com/m-labs/nmigen/commit/a02e3750bfeba44bcaad4c5de8d9eb0ef055d9c6
okaaay so that's write-port *priority*, not the same thing as write-*through* capability. you've got a (similar?) unit test kicking around, would you be ok writing a similar one that checks if what is written can be read on the same clock cycle?