[RFC][Sim] Add declarations and reads for externally controlled configuration bits

[nanjo712]

I think we need a mechanism to replace some of the functionality of the SV macros in FIRRTLToHW. From my observation, STOP_COND and PRINTF_COND behave like configurations that allow external injection, and I want to introduce this abstraction into the Sim dialect.

I've implemented a preliminary approach to naming and designing this Op.

[circt-bot]

Results of circt-tests run for 88f6df3 compared to results for e2cbd2d: no change to test results.

[uenoku]

These STOP_COND/PRINTF_COND macros were poor replacements for $asserton/$assertoff. I would love to remove them entirely today, but I cannot because our internal setup depends on them.

However, we should avoid introducing this technical debt into the Sim dialect. I see two better alternatives:

• Introduce meta printf/assertion control operations (e.g., assertionon/off). As a compromise, I think we could also add printfoff/on even though it's not defined in SV spec

• Add proper probe support, since these macros typically point to testbench registers.

[nanjo712]

I think I understand the assertion-control direction better now, but I want to clarify one point.

In the current FIRRTLToHW lowering, STOP_COND_ is not just a static switch. It is materialized as an expression and combined with the lowered stop condition:

  %exitCond = STOP_COND_ & %cond
  sim.clocked_terminate %clock, %exitCond

So the existing mechanism allows the macro to expand to a runtime testbench signal, e.g. tb.stop_enable.
My understanding is that $asserton/$assertoff would not be a drop-in replacement for this lowering. It would only work if we changed the lowering model and represented stops as assertion-like checks, for example by lowering a non-zero-exit stop to something like:

  assert (!cond) else $fatal;

Then the external runtime control would come from the simulator's assertion control state, not from an injected i1 value.
Is that the direction you have in mind? If so, should this only apply to failure stops, or do you also expect zero-exit stops currently lowered to $finish to be modeled through assertion control?

[nanjo712]

I think there are three separate concepts here:

• assertion on/off, for assertion checking;
• printf on/off, for simulation printing;
• terminate/stop on/off, for simulation termination.

For STOP_COND_, a semantic terminate/stop control operation, possibly driven by a proper probe/testbench-value mechanism, seems closer than assertion control. Does that match what you had in mind, or do you expect STOP_COND_ to only apply to assertion-like failure stops?

Supplement: I am not sure printf on/off or terminate on/off captures the current behavior better. The existing mechanism is not a stateful operation that changes simulator mode. It is an expression-level predicate that is combined with each individual print/terminate condition.

[nanjo712]

Hi @fzi-hielscher, I'd be interested to hear your thoughts on modeling runtime configuration within the context of Sim dialects. I would greatly appreciate seeing your perspective on this matter.