-
Notifications
You must be signed in to change notification settings - Fork 597
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Co-authored-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
aa22f99
to
7a5c251
Compare
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 |
* 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)
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.
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.
…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.
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.
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.
…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.
Contributor Checklist
docs/src
?Type of Improvement
Desired Merge Strategy
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)
3.6.x
,5.x
, or6.x
depending on impact, API modification or big change:7.0
)?Enable auto-merge (squash)
, clean up the commit message, and label withPlease Merge
.Create a merge commit
.