Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Property in BoringUtils. #3784

Merged
merged 1 commit into from
Jan 30, 2024
Merged

Conversation

mikeurbach
Copy link
Contributor

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 adds support for BoringUtils.bore to bore and connect Property ports.

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 mikeurbach added the Feature New feature, will be included in release notes label Jan 30, 2024
@mikeurbach
Copy link
Contributor Author

Note that this PR is currently stacked on top of #3783.

Copy link
Member

@sequencer sequencer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small nitpick

case (false, false) =>
(left, right) match {
case (_: Property[_], _: Property[_]) => PropAssign(si, left.lref, Node(right))
case (_, _) => Connect(si, left.lref, Node(right))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if left: Property[_] and right: _? this should be forbidden explicitly and throw it at elaboration time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. Maybe I can delegate to MonoConnect which checks these things. Or just add the runtime check here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my comment on the other thread--this would only happen if there was a bug in the implementation of BoringUtils, so I think it is reasonable to just deal with the two cases we care about.

Copy link
Member

@seldridge seldridge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Question about errors on property/data connections.

case (false, false) =>
(left, right) match {
case (_: Property[_], _: Property[_]) => PropAssign(si, left.lref, Node(right))
case (_, _) => Connect(si, left.lref, Node(right))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What should happen for boring from property to data and when/what error will show up? I assume this will blow up later. Is the error message reasonable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep Jiuyang had a similar question. I will add an error test and make sure the error is reasonable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, so this logic is only ever used to connect ports/wires created by BoringUtils itself. If the user bores from a Property to a Data, the Property ports will be bored and secret connections from Property to Property made here, but then when the bored output is connected to a non-Property data, you'll get the usual error:

Connection between sink (Foo.a: IO[Bool]) and source (chisel3.properties.Property$$anon$9@371acd0e) failed @: Sink (Bool) and Source (chisel3.properties.Property$$anon$9@66435227) have different types.

Base automatically changed from mikeurbach/property-datamirror to main January 30, 2024 19:07
@mikeurbach mikeurbach added this to the 6.x milestone Jan 30, 2024
This adds support for BoringUtils.bore to bore and connect Property
ports.
@mikeurbach mikeurbach force-pushed the mikeurbach/property-boring-utils branch from 45dec73 to 16cb7f3 Compare January 30, 2024 19:16
@mikeurbach mikeurbach merged commit 178d8f0 into main Jan 30, 2024
14 checks passed
@mikeurbach mikeurbach deleted the mikeurbach/property-boring-utils branch January 30, 2024 19:32
@mergify mergify bot added the Backported This PR has been backported label Jan 30, 2024
mergify bot pushed a commit that referenced this pull request Jan 30, 2024
This adds support for BoringUtils.bore to bore and connect Property
ports.

(cherry picked from commit 178d8f0)
chiselbot pushed a commit that referenced this pull request Jan 30, 2024
This adds support for BoringUtils.bore to bore and connect Property
ports.

(cherry picked from commit 178d8f0)

Co-authored-by: Mike Urbach <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backported This PR has been backported Feature New feature, will be included in release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants