[FIRRTL] Add lower-to-core lowering mode

[uenoku]

This PR introduces an option (--lower-to-core) to force lowering to pure core dialects (generally verif/sim) by ignoring legacy lowering.

I think the unfortunate fact is that it's unrealistic to emit core dialects from LowerToHW without contaminating them with a bunch of ugly macro lowerings (e.g., STOP_COND, PRINTF_COND, PRINTF_COND_FRAGMENT, ASSERT_VERBOSE_COND, and __circt_lib_logging::FileDescriptor::get). These are highly specific to Chisel (or internal SiFive use cases), and this technical debt should not block circt-bmc or arcilator workflows.

The new option allows us to incrementally replace each lowering where possible. For instance, maybe printf could be handled if we had a way to replace STOP_COND with an external function call defined by the FIRRTL ABI, for which firtool could provide an interpretable default.

While I hope --lower-to-core eventually becomes the default, I'm a bit pessimistic about that transition.

As we discussed in ODM we might want to put core dialect representation to a different region, but I feel just providing option feels very pragmatic (and changes needed for LowerToHW look more manageable than what I originally imagined).

Let me know what you think! @fzi-hielscher @dobios @nanjo712

AI-assisted-by: GPT-5.4

[uenoku]

I'm happy to drop this function as I realized this is subsumed by #10153.

[nanjo712]

I agree there is overlap with the helper in #10153.
Given that #10153 currently depends on the larger #10146 stack and is harder to disentangle, I think keeping the simpler implementation local to #10162 is reasonable for now, especially since --lower-to-core is meant to be a pragmatic transitional path.

[uenoku]

Ok that sounds good.

[nanjo712]

Thanks, this makes a lot of sense to me.
I agree that --lower-to-core is a pragmatic way to unblock non-SV backends while we still have legacy macro lowerings in LowerToHW.
I see this as complementary to the cleanup direction: the option gives us an immediate escape hatch, while follow-up work can incrementally replace individual legacy lowerings with core-dialect representations where feasible.

[dobios]

Looks great! Just a little question about your choice of always lowering to a clockedassertlikes even when the clock is frivolous

[dobios]

Are clocked assertions always the best way to go? I'm not quite sure they have full support in all of the backends yet?

[dobios]

Wouldn't it be easier to just emit a regular assertion if the predicate is an i1. That would at least make it immediately usable for most cases.

[dobios]

Or is there already a canonicalization that handles that?

[uenoku]

I think FIRRTL only has clocked assert. I'm not familiar with this area, what do you think the most reasonable lowering here? (or I can keep this blank so that you can take over).

[dobios]

hmm ok i guess this should be fine for now, I think it might be a good idea to push all of the backends to support this anyways

[dobios]

I think this is a good start, we might want to revisit some of this later if it starts conflicting with the verification backends too much.

[dobios]

@uenoku

I think the unfortunate fact is that it's unrealistic to emit core dialects from LowerToHW without contaminating them with a bunch of ugly macro lowerings (e.g., STOP_COND, PRINTF_COND, PRINTF_COND_FRAGMENT, ASSERT_VERBOSE_COND, and __circt_lib_logging::FileDescriptor::get). These are highly specific to Chisel (or internal SiFive use cases), and this technical debt should not block circt-bmc or arcilator workflows.

Ideally those can simply be ignored in the verification backends, but it would be nice if there was an option to simply not emit them.

The new option allows us to incrementally replace each lowering where possible. For instance, maybe printf could be handled if we had a way to replace STOP_COND with an external function call defined by the FIRRTL ABI, for which firtool could provide an interpretable default.

While I hope --lower-to-core eventually becomes the default, I'm a bit pessimistic about that transition.

This will at least make going from chisel directly to the verification backends much cleaner, thanks!

As we discussed in ODM we might want to put core dialect representation to a different region, but I feel just providing option feels very pragmatic (and changes needed for LowerToHW look more manageable than what I originally imagined).

I prefer the idea of having an option define which type of lowering we want rather than just emitting both in separate regions as the latter will require some annoying edge case handling downstream which i don't think should be necessary.

[fabianschuiki]

This is an excellent idea! Having two lowering modes would give us a way to switch between status quo and the where we want to go, and then we can close the gap iteratively. LGTM!