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

Add a new BoringUtils.drive API for boring to drive a sink. #3960

Merged
merged 3 commits into from
Apr 3, 2024

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 API allows users to bore to a sink they plan to drive, which complements the existing API to bore from a source to read.

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 Apr 1, 2024
@mikeurbach mikeurbach added this to the 7.0 milestone Apr 1, 2024
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.

LGTM

src/test/scala/chiselTests/BoringUtilsSpec.scala Outdated Show resolved Hide resolved
src/main/scala/chisel3/util/experimental/BoringUtils.scala Outdated Show resolved Hide resolved
mikeurbach and others added 2 commits April 2, 2024 07:02
Co-authored-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
@mikeurbach
Copy link
Contributor Author

What I have here is the simplest change to the private boreOrTap implementation to be able to bore "into" something rather than "out of" something. I think it's working for my use case and shouldn't be breaking any existing uses, but the implementation is getting a little convoluted. E.g., the rhs variable isn't always on the right hand side of connects any more. I wanted to keep this change small so I haven't done any renaming/refactoring. Are we good to merge this as-is and think about refactoring later?

@mikeurbach mikeurbach merged commit 5cd8ad0 into main Apr 3, 2024
14 checks passed
@mikeurbach mikeurbach deleted the mikeurbach/boring-drive-api branch April 3, 2024 00:58
SpriteOvO added a commit that referenced this pull request Apr 6, 2024
* Specify right convention for modules

* Specify `desiredName` as `defname` for `extmodule`

Removed FixedPoint in muxes-and-input-selection.md (#3956)

Make SRAMs directly emit FIRRTL memories (#3955)

Add a new BoringUtils.drive API for boring to drive a sink. (#3960)

This API allows users to bore to a sink they plan to drive, which complements the existing API to bore from a source to read.

Support literals in DataView (#3964)

Add requireIsAnnotatable for better errors when annotating literals (#3968)
SpriteOvO pushed a commit that referenced this pull request Apr 8, 2024
This API allows users to bore to a sink they plan to drive, which complements the existing API to bore from a source to read.
mikeurbach added a commit that referenced this pull request Apr 15, 2024
This follows up on #3960
to address the behavior at the final module for the sink being
driven. We already have special handling for boring out from the
original source, and we need the inverse here. When we reach the final
sink, if it is an input port, we should return it, rather than boring
into the module and connecting to it.
mikeurbach added a commit that referenced this pull request Apr 15, 2024
…3998)

This follows up on #3960
to address the behavior at the final module for the sink being
driven. We already have special handling for boring out from the
original source, and we need the inverse here. When we reach the final
sink, if it is an input port, we should use it, rather than boring
into the module and connecting to it.
SpriteOvO pushed a commit that referenced this pull request Apr 20, 2024
This API allows users to bore to a sink they plan to drive, which complements the existing API to bore from a source to read.
SpriteOvO pushed a commit that referenced this pull request Apr 20, 2024
This API allows users to bore to a sink they plan to drive, which complements the existing API to bore from a source to read.
SpriteOvO pushed a commit that referenced this pull request Apr 20, 2024
…3998)

This follows up on #3960
to address the behavior at the final module for the sink being
driven. We already have special handling for boring out from the
original source, and we need the inverse here. When we reach the final
sink, if it is an input port, we should use it, rather than boring
into the module and connecting to it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New feature, will be included in release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants