Chisel Linker

[Jiuyang Liu]

Splitting Definition and Instance is what we all agreed for a long time. Currently we have a D/I API for it. However there still exist shortages:

• D/I only happens in the build time, doesn't support importing Verilog or FIRRTL.
• The macro usage make IDEA unhappy(at least in Jiuyang's team, we heavily use the IDEA as our main IDE)
• Parameterization is tricky for D/I.

The essential issue here is we still lack of the most important feature: serialization and deserialization for public module:

There are some premature solutions we have tried:

• SerializableGeneartor in Chisel to serialize generator itself.(it doesn't know the IO of FIRRTL)
• firtool --scalarize-ext-modules --scalarize-public-modules(but it cannot go back to Chisel)
• firtool --chisel-interface-out-dir is a Scala codegen for a public module.(I think this is dirty)
• AutoBlackBox via slang, see #2851

There are good but tries, but is not a SOTA solution:(

Thanks to @SpriteOvO. Chisel is able to parse FIRRTL or MLIRBC via new Panama CIRCT API. which may resolve the essential problem: How do we can eat back the elaborated FIRRTL, imported as Definition.

I'm proposing a new way for linking Modules in Chisel/MLIR, here is some limiation.

• Only SerializableGeneartor can be linked, since it provides a standard way for serialize and deserialize elaboration time parameter.
• Only public and scalarized module can be linked. since it's possible to get the base type.
• SerializableParameter should be stored in a special Property, telling chisel how to elaborate again for a reproducible build.
• Besides the Module name and IO, linking should also contain: Probe, Property.

Here are my ideas:

1. a Declaration(similar to Instance[SomeModule], but manually defined by user) only provides the Interface. For the name of interface, it cannot be automatically renamed.
2. an Implementation can be a real Chisel Module, user just implement it, connect to the Interface on their own.
3. an Implementation can be a MLIR/Verilog Blackbox, Panama CIRCT should provide an API for importing corresponding files, automatically link to the Declaration.
4. Provide a reproducible build API: re-elaborate the Implementation imported from BlackBox, force importing and exporting to be strictly identical: one from Chisel Module, another one from imported MLIR.
5. At the CIRCT level, imported MLIR should live in its own namespace, For generated Verilog, it should live in a standalone compile unit.(I'm not sure if CIRCT support it, if not a prefix is another possible solution.