You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Following #1718, verification IRs are guarded by the reset. However, currently this reset is injected during Chisel elaboration and not captured by the verification IR.
Due to the lack of reset, it becomes difficult for the transform to grab the reset. For example, I'm currently trying to extract all assertion conditions (with ~reset). However, since ~reset exists only in the Conditionally IR and it is sometimes a local node within another Conditionally, it becomes quite difficult or sophisticated to get this ~reset.
If the Verification IR contains the reset (like how the clock works), it would be useful for transforms.
Describe the solution you'd like
Basically, adding the reset to the IR without changing anything else is good. I'm assuming I can handle this if chisel dev agrees to accept this feature request.
Furthermore, should consider the FIRRTL IR? If the firrtl does not require this reset, then during emitting firrtl we should emit the ~reset manually.
What is the use case for implementing this feature?
Extract full information of the assert, cover, etc during transforms
The text was updated successfully, but these errors were encountered:
I'm not sure whether this issue is still applicable for the master branch of Chisel (I'm currently using v6.5.0). Is it still possible to capture the IRs before emitting FIRRTL? Look like the intrinsic is replacing the Verification IR.
Type of issue: Feature Request
Is your feature request related to a problem? Please describe.
Following #1718, verification IRs are guarded by the reset. However, currently this reset is injected during Chisel elaboration and not captured by the verification IR.
Due to the lack of reset, it becomes difficult for the transform to grab the reset. For example, I'm currently trying to extract all assertion conditions (with
~reset
). However, since~reset
exists only in theConditionally
IR and it is sometimes a local node within anotherConditionally
, it becomes quite difficult or sophisticated to get this~reset
.If the Verification IR contains the reset (like how the clock works), it would be useful for transforms.
Describe the solution you'd like
Basically, adding the reset to the IR without changing anything else is good. I'm assuming I can handle this if chisel dev agrees to accept this feature request.
Furthermore, should consider the FIRRTL IR? If the firrtl does not require this reset, then during emitting firrtl we should emit the
~reset
manually.What is the use case for implementing this feature?
Extract full information of the
assert
,cover
, etc during transformsThe text was updated successfully, but these errors were encountered: