genvar declaration cannot take an initial value when declared as a module_or_generate_item_declaration.
Correct this test so that it doesn't fail unexpectedly if Yosys aligns with the standard.
When assigning values to input ports of nested modules in cosimulation,
sim needs to find the actual driver of the signal to perform the
assignment. The existing code didn't handle unconnected inputs in that
scenario.
While not setting the smtoffset here was clearly a bug, I think using
`chunk.offset` only worked incidentally. The `smtoffset` is an offset
into the `smtname, smtid` pair (here `"", idcounter`) which corresponds
to the smt bitvector `stringf("%s#%d", get_id(module), idcounter)` which
contains all the chunks this loop is iterating over.
Thus using an incrementing `smtoffset` (like the `$ff`/`$dff` case above
already does) should be the correct fix.
Wires weren't being assigned an smtoffset value so when generating a yosys witness trace it would also use an offset of 0.
Not sure if this has any other effects, but it fixes the bug I was having.
@jix could you take a look at this?
Allow Liberty canonical identifier including double quotes in if-body and pass-through for Synopsys-style unquoted identifiers issue#3498
Co-authored-by: Aki <201479+lethalbit@users.noreply.github.com>
Writeback of simulation state into initial state was only working for `run()` and `run_cosim_fst()`.
This change moves the writeback into the `write_output_files()` function so that all simulation modes work with the writeback option.
(* nowrshmsk *) on a struct / union variable now affects dynamic
bit slice assignments to members of the struct / union.
(* nowrshmsk *) can in some cases yield significant resource savings; the
combination of pipeline shifting and indexed writes is an example of this.
Constructs similar to the one below can benefit from (* nowrshmsk *), and
in addition it is no longer necessary to split out the shift assignments
on separate lines in order to avoid the error message "ERROR: incompatible
mix of lookahead and non-lookahead IDs in LHS expression."
always_ff @(posedge clk) begin
if (rotate) begin
{ v5, v4, v3, v2, v1, v0 } <= { v4, v3, v2, v1, v0, v5 };
if (res) begin
v0.bytes <= '0;
end else if (w) begin
v0.bytes[addr] <= data;
end
end
end
This was renaming cells while iterating over them which would always
cause an assertion failure. Apparently having to rename cells to make
all witness signals public is rarely required, so this slipped through.
When the verilog frontend perfomed constant evaluation of unbased
unsized constants in a context-determined expression it did not properly
extend them by repeating the bit value. This only affected constant
evaluation and not constants that made it through unchanged to RTLIL.
The latter case was already covered by tests and working before.
This fixes the const-eval issue by checking the `is_unsized` flag in
bitsAsConst and extending the value accordingly.
The newly added test also tests the already working non-const-eval case
to highlight that both cases should behave the same.
Jannis Harder
N. Engelhardt
github-actions[bot]
CORRADI Quentin
Krystine Sherwin
Miodrag Milanovic
Muthiah Annamalai (முத்து அண்ணாமலை)
Muthu Annamalai
Kamil Rakoczy
YRabbit
Muthu Annamalai
Dag Lem
Aki Van Ness
Ralf Fuest
Benjamin Barzen
AdamHillier