[MooreToCore] Observe class-backed event waits

[AmurG]

When getValuesToObserve finds no out-of-region operands for a moore.wait_event — which happens when the awaited storage is class-backed or reached through a virtual interface handle, invisible to observer analysis — the lowered llhd.wait observes nothing and the process can never wake up.

In that case, materialize the pre-wait sampled detect values to HW value types and use them as the wait's observed values, so the process wakes on changes to the very values the event detection compares. Behavior is unchanged when observer analysis does find values to observe.

Includes a regression test with a class-allocated event source (previously lowered to an observer-less llhd.wait that hangs forever) and a dynamic-ref posedge wait.

Part of a series upstreaming SystemVerilog/UVM simulation support validated against the sv-tests suite.

🤖 Generated with Claude Code

[circt-bot]

Results of circt-tests run for afab026 compared to results for 23609cf: no change to test results.

[fabianschuiki]

Hmmm looking at this, not having any observable values actually seems like the correct behavior: all the class-related things are constructed entirely within the moore.wait_event region, so nothing on the outside can ever change them. Might be an artifact of the test though.

Do you have any SV examples that exhibit this? I remember discussing with @Scheremo in the past that SV has very limited signal-like behavior for classes and class variables. I wonder how much of the wakeup semantics we do need for classes. And if we do, we probably need a mechanism to detect accesses to class-typed SSA values and insert a potentially new wake-up mechanism there. It would be great to have some examples to look at.

[AmurG]

Fair — the test as written is artificial in exactly the way you describe (everything constructed inside the region), and I agree empty-observe is arguably correct for that shape in isolation. The real-world case we keep hitting in sv-tests UVM rows is a virtual interface reached through class storage:

class driver_t;
  virtual dut_if vif;   // set externally, e.g. via uvm_config_db
  task run();
    forever begin
      @(posedge vif.clk);  // the wait reads vif through a class field
      drive_one_txn();
    end
  endtask
endclass

The detect input is a load through the class handle, so observer analysis finds no out-of-region operands, the lowered llhd.wait observes nothing, and the process never wakes — this is what hangs the uvm_*_vif_config_db family in sv-tests at runtime (the handle is written by another process via config_db before run_phase). Sampling the pre-wait values as observed values is admittedly a conservative stopgap: it wakes on changes to the values the event detection actually compares, at the cost of some spurious wakeups.

I agree the right long-term shape is a mechanism that detects accesses to class-typed SSA values and inserts an explicit wake-up — happy to write that up as a proposal (and loop in @Scheremo's earlier discussion). Would you prefer this stopgap land gated to the empty-observe case as-is while that design is worked out, or hold this PR for the mechanism? Meanwhile I can also rework the test to the vif-through-class-field shape above so it documents the real pattern rather than the artificial one.