D/I Question -- contextual information for Instances

Definition/Instance API allows us to specify a Module once then stamp down copies of it. This works well from Chisel -> FIRRTL, but it’s unclear what the mental model is as it goes through FIRRTL. Currently FIRRTL (specifically SFC) can modify Modules/Instances in the following ways:

• [A] Reset Inference – change the types of flops inside based on what the reset of an instance is connected to
• [B] Constant Propagation – eliminate certain inputs, outputs, or internal logic based on what is connected to the instance
• [C] Width inference – decide the width of internal signals, registers, I/Os based on what is connected to the instance
• [D] Arbitrary annotations – change pretty much anything based on what annotations are applied to the Instance

For D/I API to be useful, we need to clearly define what is allowed/expected behavior for each of these cases.

My observations are:

[A] Reset Inference

SFC seems to check that all of the Instances of the Definition will have the same inferred reset type: https://scastie.scala-lang.org/O1QxHS4nQ8aITDFCB7suhA

The Definition’s reset type is ignored.

https://scastie.scala-lang.org/ORaed9rCRRORAapWYiq3wg and https://scastie.scala-lang.org/kvx1kLUBS5aHtPHIrmVyQA

[B] Constant Prop

I think that constant prop will happen if it can be constant-propped for all instances, and will not happen otherwise. TODO Scastie example

[C] Width Inference

Seems to take the maximum width? https://scastie.scala-lang.org/5Bzl0WCDQ2ewUJ65Z8Hv0Q

[D] Arbitrary Instance Annotations

Not sure yet

Type of issue: feature request

Impact: unknown

Development Phase: request

Other information

If the current behavior is a bug, please provide the steps to reproduce the problem: See Scasties Above

What is the current behavior? See above

What is the expected behavior?

Not sure. My request is that we make sure we are clear on what the expected behavior is.

Please tell us about your environment: - version: 3.5.1

What is the use case for changing the behavior?

More useful Definition/Instance API

[seldridge]

The weirdness in A is just a bug, this is a known issue (although looks like I never filed it), that Chisel defaults to Bool for the top module and that D/I is treating Definitions as top modules, rather, Chisel should change to allow inferring even the top-level reset.

Note: this isn’t quite right. The CHIRRTL produced has an abstract reset for the child. The problem is that Definitions are unaffected by withReset because this is an API that connects resets (and there is nothing to connect for a definition).

[mwachs5]

After discussing it some, it seems like the thoughts are:

• [B] and [C] should be documented for users along the lines of “creating Instances of a Definition where constant prop/DCE/width inference will happen across the interfaces should be seen as a constraint solving problem – the Definition will resolve to something that satisfies the constraints of all Instances. Therefore adding a new Instance in a different context can result in changes to the Definition for all instances”. In theory there could be places where no solution is possible, in practice I can’t think of any today. But if there hypothetically were some (“I want a width < 10 for io.in” and “I want a width > 20 for io.in”) then this would fail during width inference/constant prop/dce with an error message to user.
• Users who don’t like the above can prevent constant prop across their Definition (with DontTouch) and width inference (by not using any inferred width signals).
• [A] is basically the same as [B] and [C] except there is no solution to the constraint “I want a sync reset” and “I want an async reset” so we fail, as we would in the hypothetical case above. Users who don’t like this can make their Reset type explicit by using RequiresSyncReset/RequiresAsyncReset/only using specific reset types for their module interfaces.