Add sv.module.verbatim op and use for firrtl.extmodule with BlackBoxInlineAnno/BlackBoxPathAnno

[tmckay-sifive]

This PR adds an sv.verbatim.module op and lowers inline black boxes (firrtl.extmodule with BlackBoxInlineAnno or BlackBoxPathAnno) to the new op.

Emitted verilog is semantically the same (there can be a difference in emission order)--so, this is mostly an IR-only change.

Before:

• BlackBoxReader
  • For each firrtl.extmodule with BlackBoxInlineAnno or BlackBoxPathAnno, create emit.file and emit.verbatim operations for the inline content
• LowerToHW pass: For each firrtl.extmodule, creates a hw.module.extern operation

After:

• BlackBoxReader
  • For each firrtl.extmodule with verbatim annotations:
    • Process each BlackBoxInlineAnno and BlackBoxPathAnno to calculate the verbatim content and determine the output file path
    • Store this information in a new annotation type designed for consumption by the LowerToHW pass
    • Remove the original BlackBoxInlineAnno/BlackBoxPathAnno annotations
• LowerToHW:
  • For each firrtl.extmodule with the new verbatim annotation:
    • On the first verbatim annotation encountered, create a sv.verbatim.module operation
    • For additional verbatim annotations on the same module, add them to the additional_files attribute of the existing sv.verbatim.module operation
    • Do not create hw.module.extern for modules with verbatim content

BlackBoxReader

It is a bit strange to partially lower the BlackBoxInlineAnno BlackBoxPathAnno. The intention here was to preserve the fragile logic around calculating output directories for black boxes.

Eventually, I think we can remove BlackBoxReader entirely and rely on AssignOutputDirs for this. Then, by the time we get to LowerToHW, we don't need to special case any of this stuff for black boxes.

Supporting multiple files

firtool currently accepts multiple instances of BlackBoxInlineAnno and BlackBoxPathAnno annotations. This is often used to include additional SV libraries, C files, or headers. In the future, we should disallow this and ensure that one module corresponds to one SV file. Before we do this however, we need to provide another mechanism for specifying external dependencies.

The addition_files attribute is a way to support the existing behavior in the meantime. Once we have addressed this tech-debt, we can just remove that attribute.

[uenoku]

The implementation direction makes sense, could you include tests for ExportVerilog, lower-to-hw, and sv dialect? It's a bit unclear to me how additional_files are used.

[tmckay-sifive]

The implementation direction makes sense, could you include tests for ExportVerilog, lower-to-hw, and sv dialect?

Yep, will do.

It's a bit unclear to me how additional_files are used.

Sorry, I meant to talk about that in the PR description. I've added it but I'll paste it here too:

firtool currently accepts multiple instances of BlackBoxInlineAnno and BlackBoxPathAnno annotations. This is often used to include additional SV libraries, C files, or headers. In the future, we should disallow this and ensure that one module corresponds to one SV file. Before we do this however, we need to provide another mechanism for specifying external dependencies.

The addition_files attribute is a way to support the existing behavior in the meantime. Once we have addressed this tech-debt, we can just remove that attribute.

[tmckay-sifive]

The implementation direction makes sense, could you include tests for ExportVerilog, lower-to-hw, and sv dialect?

I added some tests for LowerToHW and ExportVerilog. I wasn't sure what SV dialect tests should exercise that isn't covered by the LowerToHW, ExportVerilog, or BlackBox tests. If you have something in mind please let me know.

[uenoku]

Generally looks great! Could you add round-trip test for SV dialect?

[uenoku]

LGTM, mostly style comments but please fix DenseMap iteration (non-determinism) and remove getnearestSymbolTable in verifySymbolUses.