Async reset in generated Verilog always blocks

[Alexander Funkner]

How to make Chisel to generate async reset in always blocks instead of sync. 

E.g. this:

always @(posedge clk or negedge rstn) begin

if (!rstn) begin

   reset ops

end else

if (smt) begin

    main ops

end

end

instead of this:

always @(posedge clk) begin

if (reset) begin

reset ops

end

if (smt) begin

main ops

end

end

In fact many RTL developers and IP vendors (in ASIC world - majority) use asynchronous reset strategy instead of synchronous.

In our company it is design rule. Std. cell libraries from certain fabs/tech nodes don't even have flip-flops for synchronous reset.

[Martin Schoeberl]

Hi Alexander,

I agree with you that an option to support asynchronous reset would be nice.

However, you do not need “flip-flops with synchronous reset” to implement
asynchronous reset. It is just a multiplexer in the input connecting a 0 on one input
and the synchronous reset at the select input. Or even simpler and AND gate
between the data input and the flip-flop with the inverted reset on the second
input.

An asynchronous reset might save a few gates (or logic cells in an FPGA).
And one can reset the chip even when the clock is not yet running.

Cheers,
Martin

> --
> You received this message because you are subscribed to the Google Groups "chisel-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users...@googlegroups.com.
> To post to this group, send email to chisel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/b9300a11-abe7-4c17-8213-2d38ae17a379%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Stephan]

Hi,

I would also like to see an option for async resets. Also defining the reset polarity would be nice. In our company the design rule is to use active low async resets.

Regards,
Stephan

[chig...@gmail.com]

Greetings,

Since you're in complete control of the generated Verilog, could I suggest abstracting away sync/async and polarity of resets with macros?  I wrote a blog post describing this technique here: http://potential.ventures/reset_roulette.html

It's handy because it allows you to generate (or write) code that is portable across architectures.

Thanks,

Chris

[Stephan]

Hi Chris,

This is indeed an interesting solution. This implies adapting the Verilog backend accordingly of course (also true for the chisel tester related code).

Unfortunately VHDL does not provide macros as suggested in the blog. For my VHDL backend I’d need to use generate statements or better pass a backend specific parameter to the code generator.

Anyway, I think it would make sense to have a solution compatible to all backend if the feature is of common interest.

Regards,

Stephan

[Stephen Twigg]

We have shied away from implementing asynchronous reset for a few reasons. The main one is that, with asynchronous reset, the reset signal must be treated as a clock (since glitches on an asynchronous signal are simply unacceptable). Because we do not implement logic on clock signals within Chisel, you then would not be able to override reset with arbitrary logic for registers that require an asynchronous reset.

[Martin Schoeberl]

I agree that one should not be able to overwrite reset with arbitrary logic. I think the idea here is to have the reset signal not visible at Chisel level (as currently), but having a global setting if you want to generate synchronous or asynchronous reset. You shall probably not mix those two.

BTW, even when the reset is an asynchronous signal for the flip-flop, the reset itself must be synchronous to the system clock. Is you use an external asynchronous reset signal it will go thought two flip-flops for metastability issues. However, I would consider this detail out of the Chisel world that needs to be dealt with in a Verilog or VHDL top level.

Cheers,
Martin

> --
> You received this message because you are subscribed to the Google Groups "chisel-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users...@googlegroups.com.
> To post to this group, send email to chisel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/65c5ed94-b93d-4654-9198-7e1f87f60d52%40googlegroups.com.

[Alexander Funkner]

Again there are many pros and cons in implementing either asynchronous or synchronous reset. Yes you should treat reset as a clock and use the logic on reset is forbidden (not always), but async reset is mush simpler on the backend stage. Discussion which reset scheme is better is pointless. The fact is many developers and vendors just use asynchronous reset and they are not free to choose.

We've tested Chisel for a few months, and the lack of asynchonous reset and the lack of some degree of freedom with clock (you don't even able to make clock the output of module!) are the main reasons why we refrain from implement Chisel into our main development flow. Yes it has many many cool features, but is very raw.

суббота, 14 марта 2015 г., 0:51:41 UTC+3 пользователь Stephen Twigg написал:

[Stephan]

I absolutely agree! Even so one might personally prefer asynchronous to synchronous resets or vice versa there is usually I very simple acceptance criteria within companies: Design rule! It is obvious that such an option can break things when used on arbitrary chisel based designs! Since I am currently working on a VHDL backend I tend to add a global option to the code generator as it seems easier to me than having custom scripts for conversion.