Add language to the spec that allows multiple group definitions in the same module to reference the same group declaration.
This is done as it is more straightforward to have Chisel create groups whenever a module's constructor runs as opposed to waiting until the module is "closed" before creating a group. Modules may have arbitrarily complex levels of inheritance and there's no great reason to force Chisel to have to combine groups itself. This also forces Chisel users of groups to not treat groups as arbitrary scope escape hatches where anything defined in a group is visible to anything in a later declared group. This better matches Chisel's scoping rules where it tries to align with Scala scoping rules.
This change does not disallow merging groups in a FIRRTL compiler. This is support that will be added to CIRCT 1. The ABI is intentionally silent about how this situation should be lowered as the modules that are created to implement the logic of a group are an implementation detail. E.g., in the code example in this commit, it is legal to either create two modules that will be bound in or one module that will be bound in which combines the two group definitions.
Add language to the spec that allows multiple group definitions in the same module to reference the same group declaration.
This is done as it is more straightforward to have Chisel create groups whenever a module's constructor runs as opposed to waiting until the module is "closed" before creating a group. Modules may have arbitrarily complex levels of inheritance and there's no great reason to force Chisel to have to combine groups itself. This also forces Chisel users of groups to not treat groups as arbitrary scope escape hatches where anything defined in a group is visible to anything in a later declared group. This better matches Chisel's scoping rules where it tries to align with Scala scoping rules.
This change does not disallow merging groups in a FIRRTL compiler. This is support that will be added to CIRCT 1. The ABI is intentionally silent about how this situation should be lowered as the modules that are created to implement the logic of a group are an implementation detail. E.g., in the code example in this commit, it is legal to either create two modules that will be bound in or one module that will be bound in which combines the two group definitions.