The techmap rules for this target do not work in the first place (note
lack of >2-input LUT mappings), and if proper support is ever added,
it'd be better placed in the synth_intel_alm backend.
This pass is a proper subset of opt_rmdff, which is called by opt, which
is called by every synth flow in the coarse part. Thus, it never
actually does anything and can be safely removed.
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
This regresses Cyclone V and Cyclone 10 substantially, but these
numbers were artificial, targeting a BRAM that they did not contain.
Amusingly, synth_intel still does better when synthesizing PicoSoC
than Quartus when neither are inferring block RAM.
cyclonev has been a "supported" family since the initial commit. The old
commit message suggested to use a10gx which is incorrect.
Aside from the obvious lack of functional change due to this just being
a help message, users who were previously using "a10gx" for "cyclonev" will
also have no functional change by using "cyclonev" instead.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
The help and code default to MAX10 for the family, however the couple of
if ladders defaulted to cycloneive. Fix this inconsistency and the next
patch will clean it up.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
o Not all derived methods were marked 'override', but it is a great
feature of C++11 that we should make use of.
o While at it: touched header files got a -*- c++ -*- for emacs to
provide support for that language.
o use YS_OVERRIDE for all override keywords (though we should probably
use the plain keyword going forward now that C++11 is established)
Claire Xenia Wolf
gatecat
Marcelina Kościelnicka
Dan Ravensloft
whitequark
Claire Wolf
Eddie Hung
David Shah
Ben Widawsky
Miodrag Milanovic
Henner Zeller
c60k28
dh73
Larry Doolittle