-
Notifications
You must be signed in to change notification settings - Fork 615
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
API for probing internal signals #3088
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.
This looks great!! Wow! Thanks! 🚀
Added a bunch of comments re:spec and missing bits, don't mean to nit but mostly lots of FYI 👍 .
I'm thinking it's more important to be able to generate the right strings in the valid-design case, not to model details of types / constraints / limitations in Chisel? If the latter is important LMK and I'll take a look pushing on this as have been for CIRCT.
Wondering if there is any user-level example of the prove API? |
@sequencer I am working on the user-facing API! I will add it to this PR before i un-draft it :) |
We're doing a bit of co-development of new features, once this works end-to-end, I will make sure we add an integration test that shows this working in a simulation (to the extent that we can with Verilator). |
Thanks @debs-sifive and @jackkoenig, we are waiting this feature for a long time! |
Probably future work, and might already work but not shown here: you can narrow a reference using sub-index and sub-field, internally to CIRCT it's presently called ref.sub but isn't given an explicitly different name in the FIRRTL spec, so if those will work with the new probe types added here, awesome! Example: https://github.com/dtzSiFive/reftype-inputs/blob/main/spec/forwarding_refs_upwards_narrow.fir -- given a reference to an aggregate, can select a sub-element and forward that reference up the hierarchy, or read only an element of the aggregate: https://github.com/dtzSiFive/reftype-inputs/blob/main/spec/read_subelement.fir . |
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 if you delete the extra tpe
field in the Expr expressions (unless I'm missing something?)
Is this eventually supposed to support FPGA implementations (say with ILAs?). If so it may be useful to have references to clocks around for Read probes, that may reduce the complexity of deducing which clock the probed value is synchronous to (assuming it is synchronous), or save having to inject clock crossings. Just a thought. |
@davidbiancolin wrote:
This is an open question and I'd like to raise this to have the clock association information captured more directly as opposed to relying on an analysis to determine the association. As an example, it is now possible to define a clock association directly in Chisel: class ClockAssociatedData[A <: Data](gen: => A) extends Bundle {
val data = gen
val associatedClock = Probe(Clock())
} Once you have something like this, it starts to become possible to make it trivial to lookup what clock is associated with something. |
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
This looks both very clean and consistent with the existing way that Chisel works. Very, very terse tests. That helps immensely with maintainability.
// Strip SourceInfos and split into lines | ||
private def processChirrtl(chirrtl: String): Array[String] = | ||
chirrtl.split('\n').map(line => line.takeWhile(_ != '@').trim()) |
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.
This would be great as a utility in a PR following this.
val chirrtl = ChiselStage.emitCHIRRTL( | ||
new RawModule { | ||
val a = IO(Output(RWProbe(Bool()))) | ||
|
||
val w = WireInit(Bool(), false.B) | ||
val w_probe = RWProbeValue(w) | ||
define(a, w_probe) | ||
}, | ||
Array("--full-stacktrace") | ||
) | ||
processChirrtl(chirrtl) should contain("define a = rwprobe(w)") |
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.
This is nice and terse! Interestingly, I've never thought to use an anonymous new RawModule
like that. Clever.
// TODO writable probes of const type should fail | ||
|
||
// TODO const of probe type should fail? --> put check in ConstSpec | ||
} |
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 are some mega-terse tests. 💯
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 tests are awesome, thank you/great work!
Contributor Checklist
docs/src
?Type of Improvement
API Impact
Creates a new API for probes.
Backend Code Generation Impact
Generates probe-related FIRRTL statements.
Desired Merge Strategy
Release Notes
Adds an API for probing internal signals.
Reviewer Checklist (only modified by reviewer)
3.5.x
or3.6.x
depending on impact, API modification or big change:5.0.0
)?Enable auto-merge (squash)
, clean up the commit message, and label withPlease Merge
.Create a merge commit
.