Asynchronous Reset?

[shunshou]

Is there a methodology to support asynchronous reset? Just got feedback that companies doing ASICs only use asynchronous resets for power on resets of control logic state machines. I'd also really like to be able to use it for some more mixed-signal-y things.

[mwachs5]

In rocket-chip we've created a black box for asynchronous reset flops. Looking forward to parameterized black boxes so we can at least not have to wrap every single one...

Agree that we need this. I think there were already some open threads on it. My preference is to be able to state the reset methodology on hierarchical basis, not (just) per-register.

[aswaterman]

Agreed with @mwachs5 -- which suggests that it should be part of the solution to #205.

[shunshou]

Is this not something that can be added as a FIRRTL pass right before Verilog emission? You'd be able to do it maybe @ the per-register level or module, etc. level (Transform granularity). Seems like doing it as a parameterized black box is a little overkill...

It's just adding some lines in the section of the Verilog code that deals w/ registering?

[mwachs5]

The parameterized black box is definitely a temporary workaround and not at all the desired solution.

[shunshou]

Actually, what's the reason we can't just use something like asyncinit in Chisel? You just need to bring it down to the template for registering stuff and add an if before the posedge clk stuff...

Doesn't work with C++ testing, but should be perfectly acceptable with Verilator?

[shunshou]

@aswaterman does that construct exist in Chisel3 now? I actually use enables a lot in my code... never bothered to formalize it.

[aswaterman]

Not yet... as with async reset, the main problem is finding the best API. The nuts and bolts are easy.

[mwachs5]

I'm not sure what #205 has to do with this... is that what you really meant?

[aswaterman]

Typo, I meant #206

[jackkoenig]

I revived parameterized blackbox support, it's in Firrtl now so is about ready for Chisel primetime

[ducky64]

So, how's this coming along...?

[aswaterman]

It's the next item on @jackkoenig's docket!

On Thursday, December 15, 2016, Richard Lin notifications@github.com wrote:

So, how's this coming along...?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ucb-bar/chisel3/issues/343#issuecomment-267438779, or mute the thread https://github.com/notifications/unsubscribe-auth/AA-7wv0zoNE9zl_MIu-2bPw7MpuSENuxks5rIaaIgaJpZM4KioUd .

[ducky64]

poke

[ducky64]

Resolution: make any API-level changes in 3.0.0 (like using a reset type), the actual implementation can be delayed until later.

[edysusanto]

Hi, does it mean with Chisel, we cannot have asynchronous reset FlipFlop at this moment?

[ducky64]

Async reset isn't available as a Chisel construct (yet). A workaround is to black box it: wrap an async reset flip flop in a Verilog module, and instantiate that module in your Chisel code.

[ducky64]

We discussed this at the dev meeting two weeks back.

The resolution was to add reset types (with an async reset type) to FIRRTL, where defregs would emit different based on the reset type. Casts could convert between relevant types.

Detailed discussion notes:

• Asynchronous assert, synchronous deassert reset: a deassert synchronizer could be built on top of an asynchronous reset register primitive.
  • note that some synthesis tools only recognize the synchronous deassert type (posedge rst)
• Chisel frontend options: 1) async reset type as a Reset subclass. All registers in its reset scope would be async registers. This lets the top-level control generation of all registers downstream, which is a common design style. However, it would be difficult if not impossible to determine the reset type in Chisel, since the reset object is not propagated through the module hierarchy, only connections are. 2) async reset register, where a new AsyncReg(...) (or something) would declare an async reset reg similar to how a Reg(...) declares a sync reset reg. Addresses some use cases, but does not allow top-level configuration of the global reset type.
• FIRRTL implementation options: either the reset or registers could be annotated to be async. However, there may be dedup implications with a Reset type, since a module could generate differently based on whether it is in a sync or async reset scope. Other options include an async reset reg primitive.

Next action items: someone needs to write an RFC. @jackkoenig @azidar ?

[crboth]

If someone's putting together a Reset RFC could #938 be considered in it as well?

[edwardcwang]

Front-end wise we could/should do both - for most flip-flops the reset might not explicitly matter so we can use the type approach to determine reset type, while certain circuits (e.g. async FIFO) may require AsyncReset registers regardless of the global reset type.

[jackkoenig]

For anyone reaching this page via a search engine, this has been supported since Chisel 3.2.