Coverage port width mismatches number of mux in design

[TobiasKovats]

Hi!

I am currently working on reimplementing the rfuzz passes in yosys to make it compatible with some other tools I am working with. I have realised that the width of the coverage port does not match the total number of multiplexers in the design (after converting processes to multiplexers and registers but skipping the SparseMem transform). Are there any optimisations in the FIRRTL passes reducing the number of multiplexers that I might be missing? Or does the ProfilingTransform skip certain multiplexers if they cannot be toggled?

Thanks a lot for your help,

Tobias

[ekiwi]

I am currently working on reimplementing the rfuzz passes in yosys to make it compatible with some other tools I am working with.

That sounds exciting. Let me know when you have it working, I would be curious to try it out.

Are there any optimisations in the FIRRTL passes reducing the number of multiplexers that I might be missing? Or does the ProfilingTransform skip certain multiplexers if they cannot be toggled?

When emitting the mux information at the end of the instrumentation passes, we are skipping any mux conditions that are (1) reset or (2) that are the exact same condition already used by another mux. To check for the same condition, we just do a shallow structural equivalence check, i.e., if the condition serializes to the exact same expression, we know they are the same. That is happening here: https://github.com/ekiwi/rfuzz/blob/651f28f1583e14a4aa9d8dfc624b700e6da3a143/instrumentation/src/rfuzz/TomlGenerator.scala#L236

The harness generator than only wires up the mux conditions that were included in the TOML.

Hope this helps!

[TobiasKovats]

Yes that helps a lot, thank you so much!

[ekiwi]

One thing I have learned over the last 6 years that I want to make sure you are aware of before you implement all of rfuzz in yosys: rfuzz wires out the conditions we want to cover to the toplevel. This is useful for fuzzing on a FPGA as well as in software with the exact same RTL. However, it is also a big performance problem, especially for software (i.e. RTL simulation) fuzzing. A better approach would be to wire the signals you are interested in directly to cover cells in yosys which should result in a Verilog cover statement which Verilator can use to efficiently count how often a signal was covered. The only remaining issue here is that getting the coverage data out of Verilator can be inefficient: https://github.com/verilator/verilator/issues/3090

• My paper on how to better implement custom coverage for a wider range of simulator: https://kevinlaeufer.com/papers/simulator_independent_coverage_asplos2023.html
• The paper that first complained about rfuzz coverage being a large performance overhead: https://compsec.snu.ac.kr/papers/hur-difuzzrtl.pdf I think they are correct in that it is slow, but I think it is not fundamental to mux toggle coverage, more of a problem with how I implemented it for rfuzz.

[TobiasKovats]

Great, thanks a lot for all your help, I appreciate it! I will look into the papers that you have mentioned.