quark17
commented
1 year ago I've also run into this. It's why BSC globally turns off BLKSEQ warnings when it runs Verilator (if you give bsc -vsim verilator) -- see src/Verilator/verilator_config.vlt.
I think that Verilator could do a better job of analyzing the always block, and know not to warn in this case. Or at least notice that the block is wrapped in translate_off. (Does changing synopsys to synthesis make it any more visible to Verilator?) (In any case, it was suggested in #118 to remove these.)
If we can't expect Verilator to improve and need to workaround it, then adding a targeted comment like you suggest could be better than globally turning it off, if the user has non-BSC-generated Verilog that might need the warning. If went this route, we'd have to decide if BSC should always include the comment, for all users, or if it can be controlled by a flag (and whether it's on or off by default). At the moment, BSC doesn't output different Verilog for different targets. But Verilator may even warrant having its own backend, since we might want to implement multiple-clock designs differently for Verilator (by constructing a top-level C++ that generates the clocks, to get the best performance from Verilator, rather than having it fall back to a timed model necessary to implement clock generators/dividers/etc).
Generating verilog from a $display statement using $time produce an
always@(negedge CLK)block containing a blocking assignment, which triggers a BLKSEQ verilator warning. Should that block be wrapped with/* verilator lint_off/on BLKSEQ */?