m-labs
Memory port transparency model is flawed
Investigating #172, it appears that there are two major issues with the way port transparency is handled.
- Transparent read ports should not be the default, since it is expensive. On many platforms (e.g. iCE40), fabric logic will need to be inserted. On other platforms (e.g. Xilinx), non-transparent ports have a much larger set of configurations with well-defined behavior. Transparency between different clock domains is impossible with BRAMs and will result in a (silent) failure during synthesis.
- Transparency should not be requested in general, but rather for a specific write port (in the same domain). It does not make sense to request a "fully" transparent read port for a true dual-port RAM with write ports in different domains. It does make sense to request a read port transparent only wrt one specific write port for a true dual-port RAM with write ports in the same domain (this is implementable in Xilinx) and a read port transparent wrt both write ports for a true dual-port RAM with write ports in the same domain (this is not directly implementable in any FPGA arch I know, but is useful for e.g. superscalar CPU register files).
I propose to remove transparent completely, replacing it with a transparent_for=[write_ports] argument. The default (when this argument is not specified) would be "transparent for no write ports" for synchronous read ports, and "transparent for all ports" for asynchronous read ports. It would not be possible to specify a non-default value for an asynchronous read port.
The lowering to RTLIL would be the same as today, with the selected write port ignored (beyond checking that the domain is compatible),
According to Clifford, the TRANSPARENT parameter of $memrd only applies to the ports in the same domain, so point (2) does not necessarily apply. (It would be still be necessary to clearly document the semantics of transparent read ports.)
According to UG473, WRITE_FIRST (i.e. transparent) ports are recommended for TDP, and READ_FIRST ports would, confusingly, result in an undefined value being read. This doesn't seem to make any sense to me, so I'm looking further.
According to @nakengelhardt, a read/write collision between asynchronous ports always results in undefined data being read. Apparently, using the WRITE_FIRST is recommended because it results in lower power consumption.
Based on this and https://github.com/m-labs/nmigen/issues/216#issuecomment-533660474, the current semantics actually seems fine (if confusing), and so #172 is likely caused by something else.
Reopening per discussion in https://github.com/YosysHQ/yosys/issues/1390.
After careful consideration, it is my opinion that transparent_for should be used as soon as possible, even if it means desugaring to \TRANSPARENT=1 in Yosys at first. Including in 0.1.
After discussion with Yosys maintainers, the most likely way this will be solved upstream is by (a) keeping \TRANSPARENT working as it currently is, (b) splitting ports into groups (which are most of the time identical to clock domains), (c) making \TRANSPARENT and \PRIORITY act per-group, not per-memory.
This is a less invasive solution than the transparent_for one I have suggested above (and is therefore a better one). Moreover, we do not need a radical change in the API, and there is no need to change anything for 0.1; we can add a new API and a warning at any point in the future without breaking existing code. Denominating from 0.1.