[RFC] More Consistent Notion of "Infinite Width" Values

[jackkoenig]

Discussion originated in #857. The motivating example is bit extraction for literals of unspecified width. For example:

for (i <- 0 until 4) {
  io.out(i) := io.in(i) && 5.U(i)
}

Here I'm using the literal 5.U as a numerical value, I don't care about the width. However, without the special-case support in #857 this would result in an out-of-bounds indexing error. A more consistent notion would be helpful because the existing implementation that works for literals does not work for other Chisel values like Wires, Registers, nor Ports.

Sketch of Proposal

As discussed in the Chisel developers meeting on July 27th, we could create a new Chisel API (and corresponding FIRRTL primop) that does something like padToInfinity or padUnbounded. The full implications of such an operation are not clear, but at least in the case of bit select, the argument would be treated as if it were zero- or sign-extended to infinity. I imagine we need to think through exactly how this influences width inference (if at all).

PR Template

Type of issue: feature request

Impact: API modification*

It's hard for me to see how we do this in a principled way without some sort of API modification. The extend of it remains to be seen.

Development Phase: request

[ducky64]

This issue has been around for a while now, with no real resolution, and keeps popping up at the dev meetings. I'm going to try to summarize all the positions here so we can try to make some progress on this.

There are several possible resolutions:

• Leave as-is, and codify the hotpatch in Revert removal of bit extraction const prop for literals #857. This makes literals behavior inconsistent with non-literal behavior: specifically chisel frontend const-props literal bit extracts in a way that's slightly different from firrtl, in that it won't error out when attempting to index an out-of-bounds bit. I don't think this is a good idea because it introduces edge cases and blows holes in peoples' conceptual models in order to (bluntly speaking) save a few characters in an uncommon use case. 🗑️🔥
• Revert Revert removal of bit extraction const prop for literals #857 (so making the chisel behavior match the firrtl behavior) with no additional changes. Basically, users will need to add special case logic in their code for handling out-of-bound extracts, such as padding their data to the position they want to extract from. Main disadvantage is some localized duplication of code, both the pad and extract need to have the same argument passed in. Argument for this would be in the absence of the special case const-prop in chisel frontend (which is arguably a bug), would anyone really have pushed for special support for this use case? There could be a runtime deprecation phase. 🤔
• Add an operator for an out of bounds bit extraction like in Add infinite-width bit extract operator #869. Eliminates the disadvantage of duplicating the bit position to extract across pad and extract by combining both into one operator, but creates another operator that may not see a whole lot of use (or will it?). Meeting minutes indicate agreement on this, though a name is still required. Suggestions included padExtract, i (probably a bad idea), extract, adding a pad keyword-argument to the existing extract operator, and iPad ("infinity pad"). This would break existing code (like the above option, and we could also have runtime deprecations), but offers a cleaner alternative. 🤔
• Add a pad-to-infinity operator, which can be composed with bit extract. Elegant, but turns out to be an implementation nightmare. 😔

@jackkoenig @albert-magyar

[ducky64]

Resolution: add padExtract operator, preserve existing behavior with deprecation warning until at least 3.3.