I just wanted to follow up on our August 5th discussion on inputs / outputs in RTL dialect modules. To refresh everyone’s memory, a few snippets from the meeting notes:
Aug 5, 2020
- Introductions from a few new people!
- Continue discussion about directionality in MLIR type system.
[ … ]
- Should EmitVerilog.cpp support FIRRTL bundle types?
- This would be really great!
- How do we handle bidirectional bundle? Do we emit them as inout ports, do we split them into two unidirectional pieces?
- inout is problematic in many tools, so we cannot necessarily just lower to them.
- Should RTL dialect support flip?
- Stephen’s perspective: RTL is a very logically pure thing that supports synchronous circuits; doesn’t support connect.
[ … ]
- Current proposal is to have a rather generic type of ‘module’ operation that:
- has a graph region, and can be instantiated in graph regions
- primarily uses operation operands to represent module inputs and operation results to represent module outputs
- Also support ‘inout’ operands marked with an attribute that are accessed through ‘connect’-like operation
- Alternatively, the RTL dialect could have a restricted module operation that supports 1+2, but not 3. The Verilog dialect would then have a different, less restricted module.
- Open question: Does Verilog dialect module concept want a graph region, or an SSACFG region?
Did we ever finalize this decision? I would prefer the “alternative” option where rtl.module has its arguments represent inputs, its results as outputs, and no support for inout.