Distinguish identity views from single-target views

[jackkoenig]

This is a minor overhaul of DataViews internals that make the various use cases of what were previously referred to as "1-1 views" more clear. This incidentally fixes an issue with bulk connections and views.

While for users this is just a bug fix, this has larger implications for developers. This replaces reifySingleData with two more precise functions:

• reifyIdentityView - Fast, used for things like Probe legality (which by having pointer semantics, only really works with identity views).
• reifySingleTarget - Slow, used for legacy annotation support which was, and remains, iffy for views.

A subtle but critical aspect of this PR is that reifyIdentityView works in cases when the reifySingleData did not. It is properly hierarchical: e.g. if you have an Aggregate that is a child of a non-identity view parent yet the child itself is an identity view, it will return the target for that child. This is critical for use cases like FlatIO where the parent Bundle isn't an identity but every single child is.

One negative of this PR is that it makes the awkward "unnamed rename map" logic slower. I benchmarked this on a large design (that uses lots of views) and it's such a small piece of the overall runtime that it's okay (~1%). Regardless that logic is ludicrously slow and is a complete waste. I am thinking about ways to get rid of it but this PR has scope creeped enough. I think we just have to change the annotation API so it's really about coming up with the best way to do it.

This PR actually fixes several bugs, I will file them separately as they illustrate all of the weird corner cases this PR cleans up.

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 request a desired merge strategy?
• Did you add text to be included in the Release Notes for this change?

Type of Improvement

• Bugfix

Desired Merge Strategy

• Squash

Release Notes

Fixes #4185, Fixes #4187

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]

This is pretty far into dark corners of Chisel that I don't have cached context to comment on well. I gave the code a once over and it seemed fine. I'm approving this to keep things going here as I'm confident that you will deal with any impacts of this.

High level comments:

There seems like there is a lot of complexity that is stemming from reifySingleTarget. Do we actually need to have the ability annotate a view? Would things be clearer/cleaner if this support was instead removed as opposed to making this a failable operation?

The concerns with performance are brought up a couple of times in the PR. Are there expectations that reifySingleTarget has internal users which could see a performance degradation from this? Restating the first high-level comment, the performance impact goes away if you can't do this.

Granted, I tend to think of DataView as closer to a mechanism for a user to define how two things should be connected. (You could argue that DataView is actually a connectable type class.) From that perspective, I do think that the first high-level comment is made stronger as there is less of an expectation that if you have defined how two things "connect" that you can do anything with that type class implementation other than connect them.

[jackkoenig]

Thanks for the review!

There seems like there is a lot of complexity that is stemming from reifySingleTarget. Do we actually need to have the ability annotate a view? Would things be clearer/cleaner if this support was instead removed as opposed to making this a failable operation?

I think it would be reasonable to ban annotating [non-identity] views. Targets are similar to Probes in that they are references and I do think there's just fundamentally a clash between the semantics of pointers/references and the value-semantics of views. I think annotation authors should still be able to annotate the targets of views, but we could do that by tweaking the annotation API and exposing reification via DataMirror (or some other way). The annotation author can then choose to support them or not as appropriate (e.g. obviously dontTouch can easily work on views, it's fine with being split up).

The concerns with performance are brought up a couple of times in the PR. Are there expectations that reifySingleTarget has internal users which could see a performance degradation from this? Restating the first high-level comment, the performance impact goes away if you can't do this.

Granted, I tend to think of DataView as closer to a mechanism for a user to define how two things should be connected. (You could argue that DataView is actually a connectable type class.) From that perspective, I do think that the first high-level comment is made stronger as there is less of an expectation that if you have defined how two things "connect" that you can do anything with that type class implementation other than connect them.

I measured the performance impact and it seems small in practice. Whatever we do, the unnamed views renamemap needs to go away. We can do this by tweaking the annotation API to only operate on the targets of views or banning annotating views directly but providing users the ability to do reification themselves.

I think we should go ahead and do this on main while leaving the current sketchy but functional thing going on 6.x.
I'm only backporting this because it's needed for .readOnly (next PR), and I need that on 6.x to deprecate some stuff so I can change it on main 🙂.