Add Property expressions, starting with addition.

[mikeurbach]

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

• Feature (or new API)

Desired Merge Strategy

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

Release Notes

This allows Properties to be used to build up expressions in terms of input Properties and literals.

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.

[mikeurbach]

Opening a draft to share an early cut of this. The first commit shows the one time effort to support Property expressions, and new kinds of Property expressions can be added pretty easily similar to the second commit.

[sequencer]

Is there any firrtl spec for it? Looks like an essential feature for property propagation

[mwachs5]

Exciting! Maybe add a sentence to the Property explanations doc?

[mikeurbach]

Yes, FIRRTL spec and explanation docs are incoming.

[mikeurbach]

Ok, I have updated the implementation slightly. The APIs for creating Property expressions now immediately create a temp wire and propassign the expression into it, returning the wire for use in other Property expressions.

I think this is the output we are looking for, but I'm curious for feedback on the internal implementation. I still kept the new PropExprBinding and PropExpr as an internal data structures that we can use instead of creating Nodes internally. Does this make sense given our goals? I've looked at how DefPrim works and is converted, and I'm not sure if we want to treat property expressions like a "command", or not.

[mikeurbach]

Separately, I'll write some docs for this new feature.

[jackkoenig]

I don't like putting information that traditionally goes in _ref inside of the Binding, let's meet to chat about how we should do this.

[mikeurbach]

I'm not sure if this is exactly what you meant, but I realized what you're saying about the binding being redundant. In fe3224b I removed the binding and changed binOp to create the normal binding and immediately setRef to a fresh PropExpr. This works and emits the same.

I guess my broader question is still whether it makes sense to have a separate IR node for PropExpr, which is an Arg but doesn't ever get named. I think it makes sense if we don't want to treat Property expressions as a command that defines a Node. But I'm still kind of curious if this is the best way to factor this if we don't want to create Nodes in the textual FIRRTL for Property expressions.

[jackkoenig]

LGTM, please see comment about sealing PropertyArithmeticOps and other suggestions.