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

[gnuarm.del...@gmail.com]

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?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[Michael Kellett]

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

 

[gnuarm.del...@gmail.com]

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?

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

 

[Michael Kellett]

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

 

[Mike Perkins]

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