Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory port transparency model is flawed #216

Open
whitequark opened this issue Sep 20, 2019 · 6 comments
Open

Memory port transparency model is flawed #216

whitequark opened this issue Sep 20, 2019 · 6 comments

Comments

@whitequark
Copy link
Contributor

Investigating #172, it appears that there are two major issues with the way port transparency is handled.

  1. 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.
  2. 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),

@whitequark whitequark added the bug label Sep 20, 2019
@whitequark whitequark added this to the 0.1 milestone Sep 20, 2019
@whitequark
Copy link
Contributor Author

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

@whitequark
Copy link
Contributor Author

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.

@whitequark whitequark removed this from the 0.1 milestone Sep 20, 2019
@whitequark
Copy link
Contributor Author

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 #216 (comment), the current semantics actually seems fine (if confusing), and so #172 is likely caused by something else.

@whitequark
Copy link
Contributor Author

Reopening per discussion in YosysHQ/yosys#1390.

@whitequark whitequark reopened this Sep 20, 2019
@whitequark whitequark added this to the 0.1 milestone Sep 23, 2019
@whitequark
Copy link
Contributor Author

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.

@whitequark
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant