[Proposal] Stronger and more complete reset types #161
Conversation
spec.md
Outdated
| The reset signal must be a `Reset`{.firrtl}, `UInt<1>`{.firrtl}, or `AsyncReset`{.firrtl}, and the type of initialization value must be equivalent to the declared type of the register (see [@sec:type-equivalence] for details). | ||
| If the reset signal is an `AsyncReset`{.firrtl}, then the reset value must be a constant type. | ||
| The reset signal must be a `Reset`{.firrtl} or `Reset<_,_>`{.firrtl}, and the type of initialization value must be equivalent to the declared type of the register (see [@sec:type-equivalence] for details). | ||
| If the reset signal is an `Reset<async,_>`{.firrtl} or an `Reset<asyncsync,_>`{.firrtl}, then the reset value must be a constant type. |
There was a problem hiding this comment.
It would be good to include a one-sentence justification for why this is required.
|
I love this. I added a few comments, mostly in terms of the presentation. |
There was a problem hiding this comment.
This looks great!
It would be really useful to have an example or two of generic reset handling code. In particular we need ways to invert and do some simple boolean operations (eg. OR) resets generically where inverting a reset should change the Active while keeping the kind--I'd just like to understand how to build these operations using the existing primitives. In particular, if I have a Reset<_, _> I need to invert it and get back effectively Reset<_, !_> in a way that reset inference can still fill in the holes.
Make all resets use a uniform type. Expand that type to cover asynchronous set, synchronous release resets. Expand that type to handle both active-high and active-low resets.
Provide a couple of ops that allow writing generic code on uninferred reset signals.
Tighten type conversion to make UInt<1> not equivalent to synchronous reset.