This change set contains a number of bug fixes and improvements related to
scoping and resolution in generate and procedural blocks. While many of the
frontend changes are interdependent, it may be possible bring the techmap
changes in under a separate PR.
Declarations within unnamed generate blocks previously encountered issues
because the data declarations were left un-prefixed, breaking proper scoping.
The LRM outlines behavior for generating names for unnamed generate blocks. The
original goal was to add this implicit labelling, but doing so exposed a number
of issues downstream. Additional testing highlighted other closely related scope
resolution issues, which have been fixed. This change also adds support for
block item declarations within unnamed blocks in SystemVerilog mode.
1. Unlabled generate blocks are now implicitly named according to the LRM in
`label_genblks`, which is invoked at the beginning of module elaboration
2. The Verilog parser no longer wraps explicitly named generate blocks in a
synthetic unnamed generate block to avoid creating extra hierarchy levels
where they should not exist
3. The techmap phase now allows special control identifiers to be used outside
of the topmost scope, which is necessary because such wires and cells often
appear in unlabeled generate blocks, which now prefix the declarations within
4. Some techlibs required modifications because they relied on the previous
invalid scope resolution behavior
5. `expand_genblock` has been simplified, now only expanding the outermost
scope, completely deferring the inspection and elaboration of nested scopes;
names are now resolved by looking in the innermost scope and stepping outward
6. Loop variables now always become localparams during unrolling, allowing them
to be resolved and shadowed like any other identifier
7. Identifiers in synthetic function call scopes are now prefixed and resolved
in largely the same manner as other blocks
before: `$func$\func_01$tests/simple/scopes.blk.v:60$5$\blk\x`
after: `\func_01$func$tests/simple/scopes.v:60$5.blk.x`
8. Support identifiers referencing a local generate scope nested more
than 1 level deep, i.e. `B.C.x` while within generate scope `A`, or using a
prefix of a current or parent scope, i.e. `B.C.D.x` while in `A.B`, `A.B.C`,
or `A.B.C.D`
9. Variables can now be declared within unnamed blocks in SystemVerilog mode
Addresses the following issues: 656, 2423, 2493
The presence of IS_*_INVERTED on FD* cells follows Vivado, which
apparently has been decided by a dice roll. Just assume false if the
parameter doesn't exist.
Fixes#2559.
* xilinx: eliminate SCCs from DSP48E1 model
* xilinx: add SCC test for DSP48E1
* Update techlibs/xilinx/cells_sim.v
* xilinx: Gate DSP48E1 being a whitebox behind ALLOW_WHITEBOX_DSP48E1
Have a test that checks it works through ABC9 when enabled
Quartus assumes unsigned multiplication by default, breaking signed
multiplies, so add an input signedness parameter to the MISTRAL_MUL*
cells to propagate to Quartus' <family>_mac cells.
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.
Our techmap rules for $shift and $shiftx cells contained a special path
that aimed to decompose the shift LSB-first instead of MSB-first in
select cases that come up in pmux lowering. This path was needlessly
overcomplicated and contained bugs.
Instead of doing that, just switch over the main path to iterate
LSB-first (except for the specially-handled MSB for signed shifts
and overflow handling). This also makes the code consistent with
shl/shr/sshl/sshr cells, which are already decomposed LSB-first.
Fixes#2346.
The main part is converting ice40_dsp to recognize the new FF types
created in opt_dff instead of trying to recognize the mux patterns on
its own.
The fsm call has been moved upwards because the passes cannot deal with
$dffe/$sdff*, and other optimizations don't help it much anyway.
The main part is converting xilinx_dsp to recognize the new FF types
created in opt_dff instead of trying to recognize the patterns on its
own.
The fsm call has been moved upwards because the passes cannot deal with
$dffe/$sdff*, and other optimizations don't help it much anyway.
The symbiflow-arch-defs tool chain no longer needs the EXPLICIT_CARRY
within yosys itself.
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
gatecat
Zachary Snow
Marcelina Kościelnicka
Tom Verbeure
whitequark
David Shah
Pepijn de Vos
Miodrag Milanović
Konrad Beckmann
clairexen
Jeff Goeders
Eddie Hung
Dan Ravensloft
Xiretza
Keith Rothman