[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.

[uenoku]

Sorry for the late reply. I might be more comfortable if this was model was global variable (c.f. llhd.global_signal), not as config. Lowering them to some arc runtime function (for arcilator) or some ABI-defined macro (SV) is certainly ok. WDYT?

[fzi-hielscher]

I like your idea of providing global registers/variables for simulation that are not tied to a specific simulator mechanism. But the first thing we need to determine is when and how we want to be able to change their value. I can think of three variants:

1. The values are provided from outside of the simulation and never change
2. The values can be set from within the simulation (either directly in the MLIR model or by a testbench) but changes only apply at the next time step.
3. The values can be set from within the model and change immediately.
   Each of these variants may merit its own set of operations in the core dialects. SV macros can be used for all of that, but that's also what makes them such a pain to deal with.

The way I'm interpreting the operations you have described here, you have been targeting variant (1), right? But apparently the SiFive use-case for the STOP_COND/PRINTF_COND macros requires (2). (3) would require us to make both the get (load) and set (store) operations procedural, otherwise we couldn't reason about their order.

In the case of (2), I agree with @uenoku that it would be even more useful if we had something like probes, allowing us to manipulate generic signals and not only simulation specific ones.