Is Auto-Punching IO's a feature worth supporting?

[azidar]

There has been great discussion about this topic on #75 , but it is a separate idea so I thought we'd move the conversation to a dedicated issue.

Background

Chisel, SFC and MFC support a BoringUtils API which enables users to tell the compiler to drill ports between two marked signals to physically connect them in the generated hardware design.

This feature has been used for many use-cases, one of which was for forcing/reading internal signals when testing a component. Unfortunately, it was a slight mismatch in intent versus impact because an unfortunate side-effect is that the test harness now influenced the compilation of the DUT (design-under-test), which is non-desirable as the Verilog validated is not the Verilog in the final design which instantiated that component. For this reason (among others), FIRRTL is introducing reference types to enable more side-channel simulation features to accomplish this task (#75).

Motivation

Now that this test-harness/DUT use-case has a different solution and implementation, is there still an important use-case for this auto-punching IO feature?

Off the top of my head, there are some indications that this still may be useful. For one, diplomacy itself does auto-punching (via a different mechanism), which we can look into to understand what use-cases it services. Secondly, some conceptual hardware features have a spooky-action-at-a-distance feel to them, one example being BIST for memories.

If auto-punching isn't the desired solution, I do feel it will often be the solution users will ask for us, so a discussion about the pros/cons that represent our historical decision behind this will be useful to document.

[ekiwi]

Some prior art: https://github.com/ucb-bar/chiseltest/pull/407

[azidar]

My thoughts:

A FIRRTL Compiler should not be responsible for doing wiring.

I think it's too preliminary to have a strong statement about this one way or the other. However, I personally feel that in general, auto-port-punching-and-wiring is extremely useful for users because plumbing IO's is extremely boilerplate-heavy for often little gain. Conversely, the central downside is it makes the interfaces of the intermediate modules it impacts not independent of their context.

In these circumstances, I feel that good IR design can enable users to explicitly declare when this behavior is acceptable to them, and when it isn't. As a strawman, a public module cannot have auto-punched ports, but a private module can. What public and private mean will be part of the IR design discussion, but the key takeaway for me is that the mechanism for users to define where auto-punching is acceptable and where it isn't is where they define their interface so they themselves can answer the question: is this a flexible interface or a rigid one?

[seldridge]

Auto-port punching is totally useful as a Chisel API across a non-separately compiled boundary. I'm not arguing against this in any way. We should support an auto-port punching API like BoringUtils in Chisel.

However, it is a non-sequitur to assume that BoringUtils needs FIRRTL support. It's doing pretty trivial things like adding ports and connections. This is hard today because Chisel has restrictions on module modifications after module close. We should look at removing those restrictions before adding non-dataflow dataflow that a FIRRTL Compiler has to reason about.

[azidar]

it is a non-sequitor to assume that BoringUtils needs FIRRTL support

We aren't assuming anything, we are just brainstorming and talking about it. Non-sequitur is a strong statement...

One relevant reason to consider IR support would be to support the composition of box-types around module definitions in Chisel (Definition[MyModule]) with auto-punching. Chisel cannot be the one to auto-punch ports because the transform is based on the instance context, which is only known after the Definition has been built.

Regardless, this is an excellent place to discuss relevant use-cases, and then we can come to the decision of how best to support them in our stack (Chisel library, Chisel front-end feature, FIRRTL spec feature, etc.).