Forums

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

Started by gnua...@gmail.com November 24, 2020
Whether tis nobler to suffer the slings and arrows of outrageous judgement =
or just add the pointless, incorrectly working async reset that every frigg=
in' text book and every training example shows. =20

I'm on a project where we have no strong guidance and one member of the tea=
m is the type who *knows* how to work a project and so has zero interest in=
 considering what others are doing. =20

This design will power up very infrequently.  When it does power up there i=
s little to no need for the circuit to hit the ground running so to speak. =
 If your circuit takes a millisecond to wind through a homing sequence and =
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...=20

My thoughts are to have the configuration process serve as the only reset. =
 We are using a Gowin FPGA and I checked with support who said initializati=
on will be picked up as the starting state from configuration.  So make sur=
e your circuits won't have a lock state and you are done.  This may require=
 a bit of attention, but it

Some wish to focus intently on what happens when the async global reset sig=
nal is released.  The concern is that with slow routing some parts of the d=
esign may not see the release of the reset until a clock cycle later than o=
thers.  In fact, I suppose it may take more than one clock cycle for the gl=
obal reset signal to be seen as released in every FF on the chip. =20

My thinking is that with such minimal constraints on the start up of the ch=
ip (many sections have a 5 millisecond clock enable) very little of the chi=
p cares exactly when it is released.  Rather than add local reset circuits =
to manage each section of the design with an async reset, it just seems sim=
pler to design the section to reset itself through homing. =20

Anyway, this is a much longer post than I intended.  Any thoughts?=20

--=20

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
On 24/11/2020 05:25, gnuarm.del...@gmail.com wrote:
> Whether tis nobler to suffer the slings and arrows of outrageous judgement or just add the pointless, incorrectly working async reset that every friggin' text book and every training example shows. > > I'm on a project where we have no strong guidance and one member of the team is the type who *knows* how to work a project and so has zero interest in considering what others are doing. > > This design will power up very infrequently. When it does power up there is little to no need for the circuit to hit the ground running so to speak. If your circuit takes a millisecond to wind through a homing sequence and 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 state and join the band rather than everyone starting at the same time... and a one, and a two and a three... > > My thoughts are to have the configuration process serve as the only reset. We are using a Gowin FPGA and I checked with support who said initialization will be picked up as the starting state from configuration. So make sure your circuits won't have a lock state and you are done. This may require a bit of attention, but it > > Some wish to focus intently on what happens when the async global reset signal is released. The concern is that with slow routing some parts of the design may not see the release of the reset until a clock cycle later than 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. > > My thinking is that with such minimal constraints on the start up of the 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 circuits to manage each section of the design with an async reset, it just seems simpler to design the section to reset itself through homing. > > Anyway, this is a much longer post than I intended. Any thoughts? >
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
On Tuesday, November 24, 2020 at 5:22:43 PM UTC-5, Michael Kellett wrote:
> On 24/11/2020 05:25, gnuarm.del...@gmail.com wrote:=20 > > Whether tis nobler to suffer the slings and arrows of outrageous judgem=
ent or just add the pointless, incorrectly working async reset that every f= riggin' text book and every training example shows.=20
> >=20 > > I'm on a project where we have no strong guidance and one member of the=
team is the type who *knows* how to work a project and so has zero interes= t in considering what others are doing.=20
> >=20 > > This design will power up very infrequently. When it does power up ther=
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...=20
> >=20 > > My thoughts are to have the configuration process serve as the only res=
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=20
> >=20 > > Some wish to focus intently on what happens when the async global reset=
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.=20
> >=20 > > My thinking is that with such minimal constraints on the start up of th=
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.=20
> >=20 > > Anyway, this is a much longer post than I intended. Any thoughts?=20 > > > I like to have a reset input so that the micro (or human) in charge can=
=20
> reset the FPGA "code" without reconf or power cycle.=20 > Since doing a big project with Xilinx Viavado and Artix I've massively=20 > cut down on what I reset (to only things that need it) and use=20 > synchronous resets.=20 > On Lattice stuff for years and years I just used the asynchronous reset=
=20
> on everything and that always seemed to work as well.=20 >=20 > MK
Why a reset rather than a reconfig? =20 --=20 Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209
On 25/11/2020 02:54, gnuarm.del...@gmail.com wrote:
> On Tuesday, November 24, 2020 at 5:22:43 PM UTC-5, Michael Kellett wrote: >> On 24/11/2020 05:25, gnuarm.del...@gmail.com wrote: >>> Whether tis nobler to suffer the slings and arrows of outrageous judgement or just add the pointless, incorrectly working async reset that every friggin' text book and every training example shows. >>> >>> I'm on a project where we have no strong guidance and one member of the team is the type who *knows* how to work a project and so has zero interest in considering what others are doing. >>> >>> This design will power up very infrequently. When it does power up there is little to no need for the circuit to hit the ground running so to speak. If your circuit takes a millisecond to wind through a homing sequence and 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 state and join the band rather than everyone starting at the same time... and a one, and a two and a three... >>> >>> My thoughts are to have the configuration process serve as the only reset. We are using a Gowin FPGA and I checked with support who said initialization will be picked up as the starting state from configuration. So make sure your circuits won't have a lock state and you are done. This may require a bit of attention, but it >>> >>> Some wish to focus intently on what happens when the async global reset signal is released. The concern is that with slow routing some parts of the design may not see the release of the reset until a clock cycle later than 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. >>> >>> My thinking is that with such minimal constraints on the start up of the 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 circuits to manage each section of the design with an async reset, it just seems simpler to design the section to reset itself through homing. >>> >>> Anyway, this is a much longer post than I intended. Any thoughts? >>> >> 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 > > 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
On 24/11/2020 05:25:23, gnuarm.del...@gmail.com wrote:
> Whether tis nobler to suffer the slings and arrows of outrageous > judgement or just add the pointless, incorrectly working async reset > that every friggin' text book and every training example shows. > > I'm on a project where we have no strong guidance and one member of > the team is the type who *knows* how to work a project and so has > zero interest in considering what others are doing. > > This design will power up very infrequently. When it does power up > there is little to no need for the circuit to hit the ground running > so to speak. If your circuit takes a millisecond to wind through a > homing sequence and 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 state and join the band rather > than everyone starting at the same time... and a one, and a two and a > three... > > My thoughts are to have the configuration process serve as the only > reset. We are using a Gowin FPGA and I checked with support who said > initialization will be picked up as the starting state from > configuration. So make sure your circuits won't have a lock state > and you are done. This may require a bit of attention, but it > > Some wish to focus intently on what happens when the async global > reset signal is released. The concern is that with slow routing some > parts of the design may not see the release of the reset until a > clock cycle later than 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. > > My thinking is that with such minimal constraints on the start up of > the 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 circuits to manage each section of the design with an > async reset, it just seems simpler to design the section to reset > itself through homing. > > Anyway, this is a much longer post than I intended. Any thoughts?
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. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk