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

API for probing internal signals #3088

Merged
merged 37 commits into from
Apr 26, 2023
Merged

Conversation

debs-sifive
Copy link
Contributor

@debs-sifive debs-sifive commented Mar 14, 2023

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 state the API impact?
  • Did you specify the code generation impact?
  • Did you request a desired merge strategy?
  • Did you add text to be included in the Release Notes for this change?

Type of Improvement

  • backend code generation
  • new feature/API

API Impact

Creates a new API for probes.

Backend Code Generation Impact

Generates probe-related FIRRTL statements.

Desired Merge Strategy

  • Squash: The PR will be squashed and merged (choose this if you have no preference.

Release Notes

Adds an API for probing internal signals.

Reviewer Checklist (only modified by reviewer)

  • Did you add the appropriate labels?
  • Did you mark the proper milestone (Bug fix: 3.5.x or 3.6.x depending on impact, API modification or big change: 5.0.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.

@debs-sifive debs-sifive changed the title adding probes to ir/serializer Support and create API for probes Mar 14, 2023
Copy link
Member

@dtzSiFive dtzSiFive left a 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.

@sequencer
Copy link
Member

Wondering if there is any user-level example of the prove API?

@debs-sifive
Copy link
Contributor Author

@sequencer I am working on the user-facing API! I will add it to this PR before i un-draft it :)

@jackkoenig
Copy link
Contributor

jackkoenig commented Mar 16, 2023

Wondering if there is any user-level example of the prove API?

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).

@sequencer
Copy link
Member

Thanks @debs-sifive and @jackkoenig, we are waiting this feature for a long time!

@dtzSiFive
Copy link
Member

dtzSiFive commented Mar 20, 2023

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 .

@azidar azidar marked this pull request as ready for review March 28, 2023 00:17
Copy link
Contributor

@azidar azidar left a 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?)

@azidar azidar changed the title Support and create API for probes Support and create internal command for probes Mar 28, 2023
@davidbiancolin
Copy link
Contributor

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.

@debs-sifive debs-sifive changed the title Support and create internal command for probes Support and create user API for probes Apr 5, 2023
@seldridge
Copy link
Member

@davidbiancolin wrote:

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.

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.

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

This looks both very clean and consistent with the existing way that Chisel works. Very, very terse tests. That helps immensely with maintainability.

Comment on lines +10 to +12
// Strip SourceInfos and split into lines
private def processChirrtl(chirrtl: String): Array[String] =
chirrtl.split('\n').map(line => line.takeWhile(_ != '@').trim())
Copy link
Member

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.

Comment on lines +15 to +25
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)")
Copy link
Member

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
}
Copy link
Member

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. 💯

Copy link
Member

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!

@debs-sifive debs-sifive merged commit e8026fe into chipsalliance:main Apr 26, 2023
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.

8 participants