This is @KrystalDelusion's suggestion in PR #5141 to verify
sensible implementation of all 4 possible full_case/parallel_case
combinations.
(Also including two similar tests to check the Verilog frontend
applies the correct attributes when given SystemVerilog
priority/unique case and if statements.)
There are two elements involved:
1) Apply the relevant full_case and/or parallel_case attribute(s) to
the generated AST_CASE node(s), so that the existing AST frontend and
subsequent passes will generate RTLIL with appropriate behaviour.
(This is handled in the parser "if_attr" non-terminal.)
2) Rearrange the AST_CASE structure when necessary. For "priority if"
(i.e., full_case), this requires only ensuring that directly nested
"else if" branches also inherit the full_case attribute. For
"unique if" and "unique0 if" (i.e., parallel_case+full_case and
parallel_case alone), there are two steps:
a) Flatten the AST_CASE structure such that any direct "else if"
branches are mapped to additional AST_CONDs in the parent;
b) Reverse the "direction" of the test: the constant 1 (true)
is provided in the AST_CASE node, and the expression(s) in the
if statement(s) are given in each AST_COND. This is necessary
because the constant 1, being the common factor, must occupy the
shared AST_CASE position.
(This is handled in the parser "TOK_IF" expansion of behavioral_stmt.)
Observe that:
* The generated AST has not been changed for bare "if"s (those
without unique/priority). This should minimise the risk of
unexpected regressions.
* It is possible that the flattening described in 2) a) above might
affect the behaviour of expressions with side effects in "unique if"
statements (consider "unique if( a ) ...; else if( b++ ) ...": if
a is true, is b incremented?). While it might be possible to provide
precise semantics here, IEEE 1800-2012 12.4.2 seems to be deliberately
vague ("In unique-if and unique0-if, the conditions may be evaluated
and compared in any order[...] The presence of side effects in
conditions may cause nondeterministic results.") and so it seems
doubtful that there is benefit in Yosys providing stronger promises
on the interpretation of questionable code.
The tests/verilog/*_if_enc.ys scripts instantiate simple encoder
modules, both with and without the SystemVerilog priority/unique/unique0
keywords, and check for consistency between the two for the subset
of inputs where the priority/unique/unique0 "if" result is
well-defined.
These tests vacuously succeed at the moment, since priority/unique
keywords are silently ignored and therefore the generated logic is
trivially identical. But the test cases will be capable of detecting
certain types of unsound optimisation if priority/unique handling is
introduced later.
Add support to the "read_verilog -sv" parser to validate the
"unique", "unique0", and "priority" keywords in contexts where
they're legal according to 1800-2012 12.4.2.
This affects only the grammar accepted; the behaviour of conditionals
is not changed. (But accepting this syntax will provide scope for
possible optimisations as future work.)
Three test cases ("unique_if", "unique_if_else", and
"unique_if_else_begin") verify that the keywords are accepted where
legal and rejected where illegal, as described in the final paragraph
of 12.4.2.
Calling `throw dst_end_of_data_exception()` when the desired number of cycles has been reached means that the fst reader can't tidy up after itself and leads to memory leaks.
This doesn't happen when the `-stop` flag is used because the `Yosys::FstData` struct tracks the end time and skips the outer callback if the simulation has gone past the desired end time.
Move cycle checking into the inner callback along with the time checking means that the outer callback no longer needs to throw an exception in order to stop checking further values, while still allowing the fst reader to finish reading and deallocate memory.
libfst is no longer included in gtkwave and instead has its own repo. There has also been some refactoring, so the patches need to update to match, as does sim.cc.
