According to the official simulation model, and also cross-checked
on real hardware, the data output of the SPRAM when chipselect is
low is kept stable. It doesn't go undefined.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This commit tries to carefully follow the documented behavior of LSE
and Synplify. It will use `syn_ramstyle` attribute if there are any
write ports, and `syn_romstyle` attribute otherwise.
* LSE supports both `syn_ramstyle` and `syn_romstyle`.
* Synplify only supports `syn_ramstyle`, with same values as LSE.
* Synplify also supports `syn_rw_conflict_logic`, which is not
documented as supported for LSE.
Limitations of the Yosys implementation:
* LSE/Synplify appear to interpret attribute values insensitive
to case. There is currently no way to do this in Yosys (attrmap
can only change case of attribute names).
* LSE/Synplify support `syn_ramstyle="block_ram,no_rw_check"`
syntax to turn off insertion of transparency logic. There is
currently no way to support multiple valued attributes in
memory_bram. It is also not clear if that is a good idea, since
it can cause sim/synth mismatches.
* LSE/Synplify/1364.1 support block ROM inference from full case
statements. Yosys does not currently perform this transformation.
* LSE/Synplify propagate `syn_ramstyle`/`syn_romstyle` attributes
from the module to the inner memories. There is currently no way
to do this in Yosys (attrmvcp only works on cells and wires).
On some architectures, notably on Windows, the official name for the
Python binary from python.org is `python`. The build system assumes
that python is called `python3`, which breaks under this architecture.
There is already infrastructure in place to determine the name of the
Python binary when building PYOSYS. Since Python is now always required
to build Yosys, enable this check universally which sets the
`PYTHON_EXECUTABLE` variable.
Then, reuse this variable in other Makefiles as necessary, rather than
hardcoding `python3` everywhere.
Signed-off-by: Sean Cross <sean@xobs.io>
