Reset - Sync, Async or None At All

[rstofer]

I thought I would spend a few minutes at the Xilinx site and chase down an answer to the "Asynchronous vs Synchronous Reset" question.  I wasn't expecting the most likely correct answer: No reset at all!

Well, sure, why have a reset when every flop and every bit of BlockRAM is initialized at startup.  It doesn't matter what you define as an initial value, it is getting copied in at startup.

Code is going to look weird, we're all used to doing something with 'rst' at every clocked process but it might not be necessary nor is it even guaranteed to work.

https://www.xilinx.com/support/documentation/white_papers/wp272.pdf

I have no idea how this relates to other manufacturers but it doesn't matter because I'm happy with the Xilinx world.

[BrianHG]

It doesn't matter what you define as an initial value, it is getting copied in at startup.

Same with Intel, however, it does matter what you define as the startup default for any registers as long as the compiler 'power-up don't care' flag is disabled.  You would only use the 'Power-up don't care' feature if your FPGA is 98% full and you want to recover some free space or improve FMAX.

Ram blocks are just copied in via bootprom.

I personally have only 1 reset in my designs, only synchronous, and it only effects a minimal number of registers.  However, my designs usually push the FMAX to the limit and I have little other choice.  Though doing it right does usually lead to cleaner code.

Async set/clr, if not implemented on dedicated register async controls, like usually in verilog code, may lead to an additional gate on every effected register's clk input.  I personally don't like that even though the compiler hides this from you.

[Berni]

Async vs Sync depends on the FPGA architecture and application.

Altera/Intel FPGAs have a asyncrhonus master clear input in the logic blocks of a lot of there FPGAs. In that case if you are using a async reset to set that register to 0 you get no performance penalty at all since the reset is not part of the logic feeding that register.

Xilinx often don't have this and in that case using asynchronous reset could hurt your performance, those will likely work better with synchronous reset.

No reset at all however will give the best performance every time, no matter the FPGA architecture. So if you have a design that doesn't really need a reset then don't use it. Good examples being things like clock dividing counters where they just count in a circle, doesn't matter what state they start in, they just keep counting as long as there is a clock. Only pitfall being that simulating these things is annoying as registers start as undefined X, so to simulate it correctly you might need to add a reset just in simulation, or manually set it to zero at the start.

[tggzzz]

Resets are, of course, useful in other situations, e.g. during testing, fault recovery, and in case the power-on power line behaviour isn't quite sufficient for the reset circuitry to work as intended.

I've always included a reset, but it doesn't have to be a classic reset signal on each and every flip flop.

[rstofer]

Async vs Sync depends on the FPGA architecture and application.

Altera/Intel FPGAs have a asyncrhonus master clear input in the logic blocks of a lot of there FPGAs. In that case if you are using a async reset to set that register to 0 you get no performance penalty at all since the reset is not part of the logic feeding that register.

Xilinx often don't have this and in that case using asynchronous reset could hurt your performance, those will likely work better with synchronous reset.

No reset at all however will give the best performance every time, no matter the FPGA architecture. So if you have a design that doesn't really need a reset then don't use it. Good examples being things like clock dividing counters where they just count in a circle, doesn't matter what state they start in, they just keep counting as long as there is a clock. Only pitfall being that simulating these things is annoying as registers start as undefined X, so to simulate it correctly you might need to add a reset just in simulation, or manually set it to zero at the start.

As I read the Xilinx white paper, every single flop and every bit in BlockRAM is going to be copied from the platform flash at startup.  Whether I want all my flops to default to '0' or I want to provide a different initial condition, it doesn't matter.  The platform flash will have that initial condition.

I'm going to assume that the device comes out of reset properly because it is Xilinx recommending against my coding a reset.

For my next project, I'm going to skip the reset signal and see how it works.

Fixing up the initial conditions in the test bench seems like the best approach.

OR...

Just keep on doing what I am doing and leave the heavy thinking to others.

[SiliconWizard]

The most rational answer here is like with any other non-trivial topic...: it depends.

I personally always use reset signals and have never even used signal initialization. My rationale is that, unless I'm mistaken, signal initialization is not synthesizable in general (it is with many FPGAs, but not quite all, and there's a life with HDLs beyond FPGAs.) Unless I design very very specific stuff tied to some specific FPGA, I usually write code that can be synthesized unmodified also for ASICs.

Then async vs sync, that really depends on 1/ the requirements (in some cases, sync resets are more appropriate as the behavior is 100% predictable at the clock pulse level) and/or 2/ difficulties to meet timings. If neither are a concern, I've found async resets to be fine on all FPGAs I've used and I've used them liberally. I'm certainly not in the fanatic camp of those that are against any form of async resets no matter what. Even on Xilinx FPGAs.

The "no-reset" approach, apart from the point above (of signal init. not being synthesizable in the general case - but you may not care if you're dead sure you're never ever gonna use your code on any other target than one that is fine with this, or if you don't care about initial state), has another, obvious problem: you have no way to reset outside of ROC (reset on config), which may be OK in some cases, or not in others.

Just my 2 cents.

[emece67]

.

[emece67]

.

[NorthGuy]

Xilinx has lots of stuff which must start in reset and then be released once the clock is stable - stuff like SERDES, FIFO etc. If you must you must.

Otherwise, I've never felt that I needed reset just for sake of having it. There are times when you need to put something, such as a state machine, in the initial state, but if you're going to put every flop into a known state, you will use lots of resources. And there's no benefit because typically most of the flops are "don't care". Usually, only resetting the state is sufficient.

I always try to do everything synchronous, as much as I can. This way, things are much more deterministic. As a bonus, regular FPGA resources can be used instead of dedicated RST pins.

[legacy]

I usually only have synchronous code, and my HDL simulator does explicitly need the reset signal to operate. Hence I leave it in the testbench and in the code with a macro to eventually disable it on synthesis.

[Someone]

Xilinx has lots of stuff which must start in reset and then be released once the clock is stable - stuff like SERDES, FIFO etc. If you must you must.

But the classic pitfall is thinking of these as "resets" and making large global nets. It will need to be reset at some point before using the function, but there are likely many other processes/functions which will take some time to come up. A cascade or streaming reset that triggers each local part as required/possible is usually more appropriate and easily closes timing as a synchronous process.