[circt-bmc] Preserve signal names before lowering

[ankit-cybertron]

This patch adds dbg.scope and dbg.variable ops in LowerToBMC to preserve hardware signal names before
hwModule->erase() discards them.

This is needed to support counter-example generation -- without preserving names here, there is no way to produce human-readable waveform output when the solver finds a violation.

[TaoBi22]

Thanks for looking at this! Could we add a test or two in test/Tools/circt-bmc/ to make sure this is working properly?

[ankit-cybertron]

Thanks for looking at this! Could we add a test or two in test/Tools/circt-bmc/ to make sure this is working properly?

Thanks for the review! Added 2 tests in test/Tools/circt-bmc/lower-to-bmc-debug.mlir -- one for a simple passthrough module and one for a module with a computed output -- to verify that dbg.scope and dbg.variable ops are correctly emitted for all ports. But I'm not sure if these tests cover everything we have here

[TaoBi22]

Thanks! This is looking good modulo some comments below.

While I think landing this makes sense for now as a first step, I wonder if the best way to handle module hierarchy would actually be to add another pass to the circt-bmc pipeline that adds the dbg.variable ops to every module. Then these changes in LowerToBMC could just be to make sure those ops get carried across (not even sure that wouldn't just happen automatically). Not a blocker on this, just a thought!

[ankit-cybertron]

Thanks! This is looking good modulo some comments below.

While I think landing this makes sense for now as a first step, I wonder if the best way to handle module hierarchy would actually be to add another pass to the circt-bmc pipeline that adds the dbg.variable ops to every module. Then these changes in LowerToBMC could just be to make sure those ops get carried across (not even sure that wouldn't just happen automatically). Not a blocker on this, just a thought!

That sounds like a really interesting direction -- I can definitely try exploring that as well. Not sure if something like this will work for circt-bmc at this stage, but happy to look into it

[TaoBi22]

Thanks! LGTM modulo a couple of nits - let me know if you need me to hit merge once these are addressed.

[TaoBi22]

nit: unrelated change

[TaoBi22]

Can we check this is actually using the right value, as opposed to just matching anything for VAL? Also is there a reason for not matching the specific scope?

[TaoBi22]

Ah looks like the CI is failing on this - we probably need some kind of placeholder to discard dbg ops for now further down the pipeline.