-
Notifications
You must be signed in to change notification settings - Fork 651
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 diplomatic IOBinders #699
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.
Looks reasonable to me. I like that we can still have non-lazy iobinders.
208a96e
to
7a55c55
Compare
|
||
abstract trait HasIOBinders { this: LazyModule => | ||
val lazySystem: LazyModule | ||
private val iobinders = p(IOBinders) |
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.
There is no "ApplyIOBinders" function right. So where do the IOBinder functions (both lazy and non-lazy) get called? I'm not exactly sure here.
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.
The evaluation of lzy
and imp
below evaluates the IOBinders, or wraps them in InModuleBody
if they are not lazyiobinders. The implementation is a bit hairy because I wanted to avoid having to modify all of the existing concrete iobinders,
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.
Other than the questions I have this LGTM. This (from an initial port) works with my FPGA work (can generate Verilog and a proper DTS).
I hope this doesn't sound too pushy, but do you guys have an ETA on this being merged? I would like to try out some of these new features. Thanks! |
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.
Cool! It'd be nice to see the boring utils stuff ripped out given we can use diplomacy to plumb out the clock now.
}) | ||
) | ||
}) | ||
class OverrideHarnessBinder[T, S <: HasHarnessSignalReferences, U <: Data](fn: => (T, S, Seq[U]) => Seq[Any]) |
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.
I see we're approaching diplomacy-level type genericization.
case system: T => composer(upfn)(system, th, pts) | ||
case _ => | ||
} | ||
case _ => |
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.
@jerryz123 I'm bumping to start using this code. Can you help me understand why you need the empty default matching cases on lines 55 and 57 of the new file here (i.e. the case _ =>
lines)?
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.
I believe this was done to avoid MatchErrors. In the case where the type of the actual elaborated TestHarness does not match the expected Harness type, or in the case where type of the actual elaborated System does not match the expected System type, this expression just becomes a no-op.
This is useful because it lets us build up a collection of default HarnessBinders through Configs without thinking about exactly what hardware design is being requested.
Related issue:
OverrideLazyIOBinder
andComposeLazyIOBinder
APIs to write IOBinders which modify diplomatic parametersmake TOP=DigitalTop
and adds regression testType of change: new feature
Impact: software change
Release Notes