Documentation error?

[donnie-j]

Caveat: I've not simulated the netlist...

Is it not the case that for 1RW1R RAM:

• In https://raw.githubusercontent.com/Cloud-V/DFFRAM/main/docs/img/ram_1rw1r_ifc.png since EN0 rises and WE=0000 in cycle 2, that Do0 should output D0 after the rising edge (and the access time) in cycle 3?

• If that is the case, then might it not be the case that to be consistent with 1RW as documented in https://raw.githubusercontent.com/Cloud-V/DFFRAM/main/docs/img/ram_1rw_ifc.png that D0 remains driven in cycle 4, because cycle 3 is a write cycle and the 1RW diagram implies that reads are not performed in a write cycle?

Again, I've not looked carefully at the model or run a simulation on the RTL or netlist, but my suspicion would be the first is true and the second is false, and the 1RW timing diagram is wrong because read happens in the same cycle as write. If I am correct about that, then the next question is, is this the written value or the previous value (is it read before or after write)?

In any case, the implied behavior seems inconsistent.
J.

[donnie-j]

my suspicion would be the first is true and the second is false, and the 1RW timing diagram is wrong because read happens in the same cycle as write.

This turns out to be correct. Here are waveforms from a simulation of the netlist RAM8.nl.v from a run of 8x8_default ram, with no options.

There is an important caveat for latch based RAM, however: During a write cycle, all signals must be stable before clock falls. If this doesn't happen, the gate for the latch cells shows up in the next clock cycle, which obviously doesn't write what and where we expect.

[donnie-j]

For completeness, here is the same test bench run against a macro with flops USE_LATCH=0 instead of latch cells. The change in size is not that significant, but I suspect clock tree skew might be more problematic in the array itself. Write timing is relaxed, but looks to me unsurprisingly read is still async, the same as with the latch implementation.

In both cases, read is async, as shown below after the cursor where Do changes immediately when A (or EN) changes, not after clock edge.

The docs are definitely in need of update, or users of the RAM modules will likely be unpleasantly surprised that data appears one cycle earlier than expected. I also suggest the model might benefit from an option to insert output flops `define SYNC_READ perhaps.