-
Notifications
You must be signed in to change notification settings - Fork 15
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
Instrumentation widget #53
base: master
Are you sure you want to change the base?
Conversation
Passes midas-top:
|
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.
Generally, i like the direction you're heading, and some of the readability improvements you've made.
Let's see how this evolves once you get the boring utils working.
@@ -28,7 +30,7 @@ class SimConfig extends Config((site, here, up) => { | |||
case KeepSamplesInMem => true | |||
case CtrlNastiKey => NastiParameters(32, 32, 12) | |||
case MemNastiKey => NastiParameters(64, 32, 6) | |||
case EndpointKey => EndpointMap(Seq(new SimNastiMemIO, new SimAXI4MemIO)) | |||
case EndpointKey => EndpointMap(Seq(new SimNastiMemIO, new SimAXI4MemIO, new SimInstrumentationIO)) |
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 don't think this should be added to the default.
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.
Hmm, may I inquire as to why this is the case? From what I saw it seems that if there are no InstrumentationIOs, it shouldn't cause any backwards-incompatible changes.
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.
Mainly, because it's not even clear yet that Endpoint-style matching will be the ultimate way you bind your widget to the target.
super.genHeader(base, sb) | ||
import CppGenerationUtils._ | ||
|
||
// Generate all_ready() |
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.
Can you explain why this needs to be so customized? Also, do you have to emit macros?
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.
These make it a lot easier to pull data out of the instrumentation widget and was really useful for the testcase (and perhaps also in the general case) since it helped remove a lot of boilerplate code (e.g. to mark all the widgets as ready) which depended on the exact elements of the bundle.
I tried to make these functions but then 1) something in the build system complains about duplicate definition; 2) it would depend on simif_t and including simif.h here doesn't seem like a good idea.
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.
Ok we should talk about this in person.
@@ -93,21 +93,30 @@ class FPGATop(simIoType: SimWrapperIO)(implicit p: Parameters) extends Module wi | |||
b.elements.toList foreach { case (name, wire) => | |||
loop(target.elements(name), wire) | |||
} | |||
case (target: Record, r: Record) => |
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 appreciate your efforts to better support Record.
(Don't merge until #50 is merged since this PR depends on it)