To Reset or not to Reset, That is the Question!

I like to have a reset input so that the micro (or human) in charge can reset the FPGA "code" without reconf or power cycle. Since doing a big project with Xilinx Viavado and Artix I've massively cut down on what I reset (to only things that need it) and use synchronous resets. On Lattice stuff for years and years I just used the asynchronous reset on everything and that always seemed to work as well.

MK

ent or just add the pointless, incorrectly working async reset that every f riggin' text book and every training example shows.

team is the type who *knows* how to work a project and so has zero interes t in considering what others are doing.

e is little to no need for the circuit to hit the ground running so to spea k. If your circuit takes a millisecond to wind through a homing sequence an d find it's ready state, it is of no consequence. So reset requirements are as lax as can be. Each circuit simply needs to find it's way to its home s tate and join the band rather than everyone starting at the same time... an d a one, and a two and a three...

et. We are using a Gowin FPGA and I checked with support who said initializ ation will be picked up as the starting state from configuration. So make s ure your circuits won't have a lock state and you are done. This may requir e a bit of attention, but it

signal is released. The concern is that with slow routing some parts of th e design may not see the release of the reset until a clock cycle later tha n others. In fact, I suppose it may take more than one clock cycle for the global reset signal to be seen as released in every FF on the chip.

e chip (many sections have a 5 millisecond clock enable) very little of the chip cares exactly when it is released. Rather than add local reset circui ts to manage each section of the design with an async reset, it just seems simpler to design the section to reset itself through homing.

Why a reset rather than a reconfig?

Speed - on a design using a Lattice ICE40 configured by a micro bit banging the interface it can take 50ms to reconfigure , against < 1us for a reset.

It's become a habit - on a lot of stuff the saving of 50ms makes no difference to anything.

There have been a couple of designs where it does matter.

MK

Most FPGAs allow the initialisation / startup state to be specified / fixed.

I tend to use time-outs to limit stalemate conditions rather than resets per se.

Anything after that will be down to your requirements, and you then have to ask what your 'reset' needs to do.

Most people tend to steer away from asynchronous resets but they should be fine if the reset is a long duration and consideration taken of what happens when reset is de-asserted.