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:
* renames all remaining instances of "DRAM" (which is ambiguous)
to "LUTRAM" (which is not), finishing the work started in
the commit 698ab9be;
* renames memory rule files to brams.txt/lutrams.txt;
* adds/renames script labels map_bram/map_lutram;
* extracts where necessary script labels map_ffram and map_gates;
* adds where necessary options -nobram/-nolutram.
The end result is that BRAM/LUTRAM/FFRAM aspects of every target
are now consistent with each other.
Per architecture:
* anlogic: rename drams.txt→lutrams.txt, add -nolutram, add
:map_lutram, :map_ffram, :map_gates
* ecp5: rename bram.txt→brams.txt, lutram.txt→lutrams.txt
* efinix: rename bram.txt→brams.txt, add -nobram, add :map_ffram,
:map_gates
* gowin: rename bram.txt→brams.txt, dram.txt→lutrams.txt,
rename -nodram→-nolutram (-nodram still recognized), rename
:bram→:map_bram, :dram→:map_lutram, add :map_ffram, :map_gates
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>
