Bug 268

Summary:	nmigen does not seem to support write-through SRAM
Product:	Libre-SOC's first SoC	Reporter:	Luke Kenneth Casson Leighton <lkcl>
Component:	Source Code	Assignee:	Jacob Lifshay <programmerjake>
Status:	CONFIRMED ---
Severity:	enhancement	CC:	libre-soc-bugs, programmerjake, staf
Priority:	---
Version:	unspecified
Hardware:	PC
OS:	Linux
NLnet milestone:	---	total budget (EUR) for completion of task and all subtasks:	0
budget (EUR) for this task, excluding subtasks' budget:	0	parent task for budget allocation:
child tasks for budget allocation:		The table of payments (in EUR) for this task; TOML format:

Description Luke Kenneth Casson Leighton 2020-03-27 09:50:48 GMT

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).

Comment 1 Staf Verhaegen 2020-03-27 10:44:30 GMT

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).

Comment 2 Luke Kenneth Casson Leighton 2020-03-27 10:55:40 GMT

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?

Comment 3 Jacob Lifshay 2020-03-27 13:45:23 GMT

(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

Comment 4 Luke Kenneth Casson Leighton 2020-03-27 16:05:39 GMT

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?