| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This reverts commit a3a90f6377f251d3b6c5898eb1543f8832493bb8.
|
| |
|
| |
|
| |
|
|\
| |
| | |
anlogic: Use dfflegalize.
|
| | |
|
| |
| |
| |
| | |
This reverts commit 09ecb9b2cf3ab76841d30712bf70dafc6d47ef67.
|
| |
| |
| |
| |
| |
| |
| | |
Of standard yosys cells, xilinx_srl only works on $_DFF_?_ and
$_DFFE_?P_, which get upgraded to $_SDFFE_?P?P_ by dfflegalize at the
point where xilinx_srl is called for non-abc9. Fix this by running
ff_map.v first, resulting in FDRE cells, which are handled correctly.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This adds ABC9 support for synth_gowin; drastically improving
synthesis quality.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Co-authored-by: Eddie Hung <eddie@fpgeh.com>
|
|/
|
|
|
| |
Suspect it is to do with map/set ordering in techmap; should
be fixed by #1862?
|
| |
|
|
|
|
| |
Signed-off-by: Claire Wolf <claire@symbioticeda.com>
|
|\
| |
| | |
abc9: -dff improvements
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | | |
abc9: fixes around handling combinatorial loops
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
tests: reduce test warnings
|
| | |/
| |/| |
|
| |/
|/| |
|
|/ |
|
|
|
|
| |
Fixes #2058.
|
|
|
|
|
| |
Eliminate need for abc9_{,un}map.v in xilinx
-prep_dff_{hier,unmap} -> -prep_hier
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
By instantiating the LUTRAM cell directly, we avoid a trip through
altsyncram, which speeds up Quartus synthesis time. This also gives
a little more flexibility, as Yosys can build RAMs out of individual
32x1 LUTRAM cells.
While working on this, I discovered that the mem_init0 parameter of
<family>_mlab_cell gets ignored by Quartus.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
By operating at a layer of abstraction over the rather clumsy Intel primitives,
we can avoid special hacks like `dffinit -highlow` in favour of simple techmapping.
This also makes the primitives much easier to manipulate, and more descriptive
(no more cyclonev_lcell_comb to mean anything from a LUT2 to a LUT6).
|
|\
| |
| | |
ice40/ecp5: add support for both 1364.1 and Synplify/LSE RAM/ROM attributes
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| |
| |
| |
| | |
LSE/Synplify use case insensitive matching.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| |
| |
| |
| |
| |
| | |
iCE40 does not have LUTRAM. This was erroneously added in commit
caab66111e2b5052bd26c8fd64b1324e7e4a4106, and tested for BRAM,
essentially a duplicate of the "dpram.ys" test.
|
|\ \
| | |
| | | |
opt_expr: optimise $xor/$xnor/$_XOR_/$_XNOR_ -s with constant inputs
|