search

chipsalliance / chisel

Chisel: A Modern Hardware Design Language
https://www.chisel-lang.org/
Apache License 2.0
3.9k stars 585 forks source link

Proposal for Verification IR with reset #4282

Open poemonsense opened 1 month ago

poemonsense commented 1 month ago

Type of issue: Feature Request

Is your feature request related to a problem? Please describe.

Following https://github.com/chipsalliance/chisel/issues/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

poemonsense commented 1 month ago

Just noticed https://github.com/chipsalliance/chisel/pull/4001.

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.

poemonsense commented 1 month ago

Also wondering the boundary of Chisel/FIRRTL/CIRCT. Will there be more circt intrinsics? How does this affect the position of FIRRTL IR?