Add when.cond for getting the current when condition #1694
Conversation
This is useful for libraries to guard operations implemented via annotations or BlackBoxes by the current when predicate
|
Because this API is very much a "power user library writer" thing (I actually have struggled to provide useful-looking examples using it other than directly driving a blackbox or annotating the signal), @albert-magyar suggested we put it in a different package like |
|
Something similar did cross my mind: it's a bit of a reflection style API, which we've typically put (maybe a bit haphazardly) in DataMirror. I don't know if that's the right answer, though. |
|
I think putting features that are too important to exclude, but are dangerous or not useful for typical users, into something like chisel3.advanced is a sensible proposal. |
| def cond: Bool = { | ||
| implicit val compileOptions = ExplicitCompileOptions.Strict | ||
| implicit val sourceInfo = UnlocatableSourceInfo | ||
| val whens = Builder.whenStack | ||
| whens.foldRight(true.B) { | ||
| case (ctx, acc) => acc && ctx.localCond() | ||
| } | ||
| } |
There was a problem hiding this comment.
Can we get a source locator from the when conditions themselves?
|
We talked about this in dev yesterday, I'm swayed the most by @chick's argument that moving things from @seldridge asked if there's any prior art for "advanced" packages, and I don't think I know of any. Do other projects have packages for "advanced features" or do they just document things? |
This is useful for libraries to guard operations implemented via annotations or BlackBoxes by the current when predicate (cherry picked from commit cdb7bb2)
This is useful for libraries to guard operations implemented via annotations or BlackBoxes by the current when predicate (cherry picked from commit cdb7bb2) Co-authored-by: Jack Koenig <[email protected]>
This Serializer which is implemented external to the IR node definition uses a StringBuilder to achieve about a 1.7x performance improvement when serializing. Eventually, all implementations of the `serialize` methd should be replaced with a call to `Serializer.serialize`. However, for this PR we keep the old code in place in order to allow for easy regression testing with the benchmark JAR like this: > java -cp utils/bin/firrtl-benchmark.jar \ firrtl.benchmark.hot.SerializationBenchmark \ ~/benchmarks/medium.pb 2 5 test Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This is useful for libraries to guard operations implemented via
annotations or BlackBoxes by the current when predicate
@albert-magyar, remember how we discussed this like 3 years ago?
One question I have is how far we should backport this. It's a feature addition so we could just do
3.4.x, but it is a critical feature for verification libraries so it might be nice to go back to3.2.x.The main complexity in the implementation is that
elsewhenandotherwiseare actually parallel with previous conditions that must not be true (rather than being nested as they are in FIRRTL). I originally hadaltCondsas a singleOption[() => Bool], but the test caught the issue withelsewhen. Basically,altCondsis aListto keep track of the condition of the startingwhenand priorelsewhensin the same chain so they can be inverted. Nesting is handled inside ofwhen.condwhen it accesses thewhenStack.I also used
foldRightthroughout the implementation so that conditions will flow in the order of thewhensrather than being reversed.Contributor Checklist
docs/src?Type of Improvement
API Impact
This adds
when.condfor determining the current when conditionBackend Code Generation Impact
No impact
Desired Merge Strategy
Release Notes
Add
when.condfor determining the current when conditionReviewer Checklist (only modified by reviewer)
Please Merge?