Electronics > FPGA

Reset - Sync, Async or None At All

(1/3) > >>

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:

--- Quote from: rstofer on December 24, 2019, 02:45:50 am --- It doesn't matter what you define as an initial value, it is getting copied in at startup.

--- End quote ---
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:

--- Quote from: Berni on December 24, 2019, 08:45:02 am ---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.

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page