Implement typeName API for stable Module names

[jared-barocsi]

typeName is a new member of Data types which specifies a default, non-ambiguous name of its type. This is useful for problems like generating a descriptive name for a Chisel type, as it allows modules (e.g. Queue) to use this naming information for their own desiredName.

As a motivating use case, Queue modules now have a default name based on the depth parameter of the Queue as well as the generated typeName of the Chisel type passed to it. For example, Queue4_UInt4 describes a Queue of size 4 which takes a UInt(4.W), and would be the default desiredName of such a queue.

User-defined types like Bundles should override this feature if needed to diversify the names of Modules that use them, preventing situations like multiple Queues all sharing the same name and having unstable names as a result.

Contributor Checklist

• Did you add Scaladoc to every public function/method?
• Did you add at least one test demonstrating the PR?
• Did you delete any extraneous printlns/debugging code?
• Did you specify the type of improvement?
• Did you add appropriate documentation in docs/src?
• Did you state the API impact?
• Did you specify the code generation impact?
• Did you request a desired merge strategy?
• Did you add text to be included in the Release Notes for this change?

Type of Improvement

• new feature/API

API Impact

Adds a new public-facing feature to Data

Backend Code Generation Impact

Module names in FIRRTL will now include the parameter information of their respective Chisel modules in their names (via overriding desiredName), and consequently Verilog names will differ as well.

Desired Merge Strategy

Squash and merge

Release Notes

This gives a flexible way to generate a stable name for a Chisel type, which is useful for problems like generating stable names for Modules and Queues

Reviewer Checklist (only modified by reviewer)

• Did you add the appropriate labels?
• Did you mark the proper milestone (Bug fix: 3.5.x or 3.6.x depending on impact, API modification or big change: 5.0.0)?
• Did you review?
• Did you check whether all relevant Contributor checkboxes have been checked?
• Did you do one of the following when ready to merge:
  • Squash: You/ the contributor Enable auto-merge (squash), clean up the commit message, and label with Please Merge.
  • Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

[mwachs5]

Should you update the naming cookbook, especially https://github.com/chipsalliance/chisel/blob/main/docs/src/cookbooks/naming.md#my-module-names-are-super-unstable---i-change-one-thing-and-queue_1-becomes-queue_42-help after this change?

[jared-barocsi]

Should you update the naming cookbook, especially https://github.com/chipsalliance/chisel/blob/main/docs/src/cookbooks/naming.md#my-module-names-are-super-unstable---i-change-one-thing-and-queue_1-becomes-queue_42-help after this change?

I think I will, but also clarify that queue names will still have some measure of instability based on the specificity of the typeName that's being used, and that users should add enough relevant parameter information to a typeName as necessary.

[mwachs5]

LGTM!

[jackkoenig]

@Mergifyio backport 3.6.x

[mergify]

backport 3.6.x

✅ Backports have been created

• #4145 Implement typeName API for stable Module names (backport #3130) has been created for branch 3.6.x but encountered conflicts

[jackkoenig]

Backport requested by @jerryz123