Before this commit, memory_map (which is always a part of a synth
script) would always pick up any $mem cell that was not processed
by a preceding pass and lower it down to $dff/$mux cells.
This is undesirable for two reasons:
* If there is an explicit inference attribute set on a $mem cell,
e.g. (* ram_block *), then it is arguably incorrect to map such
a memory to $dff/$mux cells.
* If memory_map tries to lower a memory that was intended to
be mapped to a large BRAM, it often takes extraordinarily long
time to finish, produces an extremely large log file, and outputs
an unusable design.
After this commit, properly invoked memory_map will not map any
memory that has an explicit inference attribute specified, solving
the first issue, and alleviating the second. The default behavior
is not changed.
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.