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 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).
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).
Before, the rules for encoding parameters in JSON were as follows:
- if the parameter is not a string:
- if it is exactly 32 bits long and there are no z or x bits, emit it
as an int
- otherwise, emit it as a string made of 0/1/x/z characters
- if the parameter is a string:
- if it contains only 0/1/x/z characters, append a space at the end
to distinguish it from a non-string
- otherwise, emit it directly
However, this caused a problem in the json11 parser used in nextpnr:
yosys emits unsigned ints, and nextpnr parses them as signed, using
the value of INT_MIN for values that overflow the signed int range.
This caused destruction of LUT5 initialization values. Since both
nextpnr and yosys parser can also accept 32-bit parameters in the
same encoding as other widths, let's just remove that special case.
The old behavior is still left behind a `-compat-int` flag, in case
someone relies on it.
whitequark
Eddie Hung
Marcelina Kościelnicka
David Shah
Gabriel Somlo
Claire Wolf
N. Engelhardt
Miodrag Milanović
Marcin Kościelnicki