This can be useful to determine whether the wire should be a part of
a design checkpoint, whether it can be used to override design state,
and whether driving it may cause a conflict.
Before this commit, the meaning of "sync def" included some flip-flop
cells but not others. There was no actual reason for this; it was
just poorly defined.
After this commit, a "sync def" means that a wire holds design state
because it is connected directly to a flip-flop output, and may never
be unbuffered. This is not affected by presence of async inputs.
This can be useful to distinguish e.g. a combinatorially driven wire
with type `CXXRTL_VALUE` from a module input with the same type, as
well as general introspection.
When an adffe is being legalized, and is not natively supported,
prioritize unmapping to adff over converting to dffsre if dffsre is not
natively supported itself.
Fixes#2361.
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 only difference between "RTLIL" and "ILANG" is that the latter is
the text representation of the former, as opposed to the in-memory
graph representation. This distinction serves no purpose but confuses
people: it is not obvious that the ILANG backend writes RTLIL graphs.
Passes `write_ilang` and `read_ilang` are provided as aliases to
`write_rtlil` and `read_rtlil` for compatibility.
For connection `assign a = b;`, `sigmap(a)` returns `b`. This is
exactly the opposite of the desired canonicalization for driven bits.
Consider the following code:
module foo(inout a, b);
assign a = b;
endmodule
module bar(output c);
foo f(c, 1'b0);
endmodule
Before this commit, the inout ports would be swapped after flattening
(and cause a crash while attempting to drive a constant value).
This issue was introduced in 9f772eb9.
Fixes#2183.
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.