Create method for marking all ports of a `Module` with `DontTouchAnnotation`

[debs-sifive]

Contributor Checklist

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

Type of Improvement

• Feature (or new API)

Desired Merge Strategy

• Squash: The PR will be squashed and merged (choose this if you have no preference).

Release Notes

Create dontTouch.modulePorts method for marking all ports of a Module with DontTouchAnnotation.

Reviewer Checklist (only modified by reviewer)

• [ ] Did you add the appropriate labels? (Select the most appropriate one based on the "Type of Improvement")
• [ ] Did you mark the proper milestone (Bug fix: 3.6.x, 5.x, or 6.x depending on impact, API modification or big change: 7.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.

[seldridge]

Is this necessary now that Public exists?

[jackkoenig]

Is this necessary now that Public exists?

I agree with moving away from dontTouch generally but Public does impose additional constraints w.r.t. inferred resets and port widths that dontTouch doesn't.

[seldridge]

I agree with moving away from dontTouch generally but Public does impose additional constraints w.r.t. inferred resets and port widths that dontTouch doesn't.

Is not enforcing those constraints a requirement?

I'm trying to conserve concepts here and if this API is being used to create testable units, then I think those also probably want public and what it entails.

I won't hold this up as don't touch is a thing and having a utility to don't touch all the ports is generally useful. However, this is an intermediate API that I think we generally want to move off of.

[jackkoenig]

I think there are 3 main historical use cases of this API:

1. Give me these module ports "as is" in the Verilog -- as you noted this is just Public
2. Give me the ports of this module such that I can access them with Verilog XMRs -- this can be handled with Probes and RWProbes
3. I don't understand what is happening and want to debug, leave my ports alone so I can see them in the Verilog while I debug! -- I don't think we really have a great way to do this. Public sort of, but now the additional constraints are a problem when all you're trying to do is debug. Probes, again sort of, but you have to thread them to the top (BoringUtils helps but still extra boilerplate), and then of course read Probes intentionally do not block optimizations and RWProbes also are not really talking about keeping the ports themselves as much as keeping a forceable reference around.

(1) and (2) are what you should do in code that actually hits main, but (3) is still important IMO.

[seldridge]

I think that makes sense. Is there anyway that we can prevent users using (3) in situations where they should be using (1) or (2)? Annoyingly, all I could think of is not providing this API. 🙃