Firstly, I'm worried that this question may be off-topic or irrelevant to the lesson and I'm worried that this question is quite open so it's hard to answer definitely and it may bother you.

RTL Verification

According to the lecture note(https://docs.google.com/document/d/1VddAsurGBaMQRDUtRzxSSitqBwzwy6uKHVh0ZlJUI60/edit?tab=t.0#heading=h.ezw0to49lua8), I've been taking a look at RTL design fuzzing.

And I become curious that a new hdl (hazardflow) can contribute to more effective way of RTL design fuzzing.

Existing works

RFUZZ (ICCAD '18)

https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8587711
The core idea is that signal of multiplexer leads to a state transition so guiding the fuzzing based on mux's select signal would lead to exploring more FSM states.
However, mux-coverage metric is clock-insensitive because clock-by-clock measurement of mux-coverage is infeasible due to performance and scalability issues.

DIFUZZRTL (S&P '21)

https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9519470
Pointing the limitation of RFUZZ above, it measures the control register value every cycle instead.
The number of control register is far less than the number of wires connected to mux's signals. So it can capture clock-sensitive FSM state transition.

DIFUZZRTL coverage instrumentation

In DIFUZZRTL fuzzing framework, the paper implements RTL compiler pass for control register coverage instrumentation. (And the paper said that it modified two different HDL processing tools, Pyverilog and FIRRTL compiler)

And such control-register coverage instrumentation includes the process of identifying control registers in RTL through a static analysis. Process of identifying control-register is simplified as below. 1) Build a graph representing the connections between elements (regs, wires, muxes) in the module 2) Perform backward data-flow analysis for each mux's control signal 3) If backward data-flow tracing reaches a register, then conclude such a register is the control register since its value will be directly/indirectly used to control the mux's behavior. 4) If the backward tracing either goes beyond the module boundary or reaches the already traced point, the analysis stops.

In other words, it requires the static process of identifying targets to be monitored which are expected to contribute to state transition before monitoring the target control register dynamically.

Programming Language Support of Hazardflow for Monitoring and Coverage of Fuzzing & Verification

At this point, in my personal opinion, fuzzing targeting hazardflow hdl has relative benefits if appropriate compiler pass for fuzzing framework is implemented on above current hazardflow compiler.

The main advantage will be that programmer's intent or programming semantics are more visible in high-level languages like hazardflow rather than verilog.
Specific data (state, payload, resolver, etc) influencing state transition is able to be directly identified within primitive fsm module in hazardflow design. So, we might be able to simplify or improve the process of identifying targets to be monitored efficiently.
Some important data (e.x. fsm state) written in hazardflow can be compiled to verilog with covergroup, coverpoint automatically without programmer's annotation.
If we can leverage some semantics remaining in hazardflow design, then I wonder whether we can apply other fuzzing techniques to RTL verification such as symbolic(concolic) execution-based fuzzing.

So, it would be really thankful if I can get your any opinion or feedback.

kaist-cp / cs492-uarch