Multiple Reset Inputs

A

Analog_Guy

Guest
I generally implement resets with asynchronous assertion and
synchronous de-assertion. With a single reset, this is simple.
However, what happens if there are multiple reset inputs but I only
want one internal reset?

I was always under the impression that one should not have any
combinational logic in the asynchronous reset path, as it could lead
to static hazards (and reset glitches). So, how do you combine two
resets into one without using combinational logic somewhere?

I was thinking of two scenarios:
1. AND the two resets coming into the FPGA, and connect to the
asynchronous reset of a synchronizer. The output of the synchronizer
is the single internal reset.
2. Individually synchronize the two resets coming into the FPGA (note
that each reset input feeds the asynchronous reset of the
synchronizer). AND the output of each of the synchronizers and feed
this single signal into the asynchronous reset of a final flip-flop.
The output of this flip-flop is the single internal reset.

In both cases we achieve asynchronous assertion and synchronous de-
assertion ... however, in both cases there is combinational logic in
the asynchronous reset path.

Any suggestions how these multiple resets should be combined?
 
In article <63d8c432-53dd-43c0-9541-e87ee1645090
@q14g2000yqe.googlegroups.com>, analog_guy@hotmail.com says...
I was thinking of two scenarios:
1. AND the two resets coming into the FPGA, and connect to the
asynchronous reset of a synchronizer. The output of the synchronizer
is the single internal reset.
You really want to OR the two resets together. Either one _or_ the other
should reset the internal logic. The sense of the logic may be H active
or L active but in any case the combinatorial logic is an OR.

Now I say this because in all my experience I cannot envision a case
where you would be saying you want to reset your internal logic when
both inputs are active at the same time.

Lastly, what is wrong with some combinatorial logic in the asynchronous
path? Since the inputs arrive at who knows what time the added delay of
the combinatorial logic only adds a small amount to that best guess
time! Now I suppose there could be special cases of the input signals
being very narrow pulses where the delay may be an impact but then they
are going to have problems being detected by the synchronizer - but you
did not mention that detail.


--

Michael Karas
Carousel Design Solutions
http://www.carousel-design.com
 
On Sat, 20 Nov 2010 06:55:28 -0800, Michael Karas wrote:

Lastly, what is wrong with some combinatorial logic in the asynchronous
path? Since the inputs arrive at who knows what time the added delay of
the combinatorial logic only adds a small amount to that best guess
time! Now I suppose there could be special cases of the input signals
being very narrow pulses where the delay may be an impact but then they
are going to have problems being detected by the synchronizer - but you
did not mention that detail.
The OP is worried about glitches in the combinatorial logic. In general,
a glitch can be generated at the output of some combinatorial logic
whenever any input changes, even if (under steady state conditions) that
input should not affect the output.

For the specific case of an AND (or OR) gate implemented in a single LUT,
glitches can not be generated and the OP needn't worry.

There's an old Xilinx appnote dating from the XC3000 days which stated
that a single LUT will not generate an glitch if only one input changes
at a time (i.e. within some brief time window). This behaviour was due
to the structure of the readback mux in the LUT. I believe I have seen a
similar statement from Altera as well, although this information never
appears in contemporary datasheets from either company.

Guaranteeing glitch free behaviour from synthesised logic with more than
a few inputs is nigh on impossible, as the synth tool will ignore any
hazard coverage you do.

Cheers,
Allan
 
On Nov 20, 7:09 pm, Allan Herriman <allanherri...@hotmail.com> wrote:
On Sat, 20 Nov 2010 06:55:28 -0800, Michael Karas wrote:
[snip]
Lastly, what is wrong with some combinatorial logic in the asynchronous
path? Since the inputs arrive at who knows what time the added delay of
the combinatorial logic only adds a small amount to that best guess
time! Now I suppose there could be special cases of the input signals
being very narrow pulses where the delay may be an impact but then they
are going to have problems being detected by the synchronizer - but you
did not mention that detail.

The OP is worried about glitches in the combinatorial logic.  In general,
a glitch can be generated at the output of some combinatorial logic
whenever any input changes, even if (under steady state conditions) that
input should not affect the output.
Actually, the OP is worried about something that does not need to be
worried about. Glitches causing resets are things that need to be
avoided when you're trying to *prevent* a false reset from occurring
(i.e. resetting when you don't want to be). What the OP describes is
two inputs which are supposed to cause a reset. A 'glitch' on one of
them would be a case of something that should cause a reset, not
something that should be prevented.

KJ
 
On Sat, 20 Nov 2010 18:11:55 -0800, KJ wrote:

On Nov 20, 7:09 pm, Allan Herriman <allanherri...@hotmail.com> wrote:
On Sat, 20 Nov 2010 06:55:28 -0800, Michael Karas wrote:
[snip]
Lastly, what is wrong with some combinatorial logic in the
asynchronous path? Since the inputs arrive at who knows what time the
added delay of the combinatorial logic only adds a small amount to
that best guess time! Now I suppose there could be special cases of
the input signals being very narrow pulses where the delay may be an
impact but then they are going to have problems being detected by the
synchronizer - but you did not mention that detail.

The OP is worried about glitches in the combinatorial logic.  In
general, a glitch can be generated at the output of some combinatorial
logic whenever any input changes, even if (under steady state
conditions) that input should not affect the output.


Actually, the OP is worried about something that does not need to be
worried about. Glitches causing resets are things that need to be
avoided when you're trying to *prevent* a false reset from occurring
(i.e. resetting when you don't want to be). What the OP describes is
two inputs which are supposed to cause a reset. A 'glitch' on one of
them would be a case of something that should cause a reset, not
something that should be prevented.
Exactly right, which is why I said:

"For the specific case of an AND ... the OP needn't worry."

Cheers,
Allan
 
On Nov 21, 4:41 am, Allan Herriman <allanherri...@hotmail.com> wrote:
On Sat, 20 Nov 2010 18:11:55 -0800, KJ wrote:
On Nov 20, 7:09 pm, Allan Herriman <allanherri...@hotmail.com> wrote:
On Sat, 20 Nov 2010 06:55:28 -0800, Michael Karas wrote:
[snip]
Lastly, what is wrong with some combinatorial logic in the
asynchronous path? Since the inputs arrive at who knows what time the
added delay of the combinatorial logic only adds a small amount to
that best guess time! Now I suppose there could be special cases of
the input signals being very narrow pulses where the delay may be an
impact but then they are going to have problems being detected by the
synchronizer - but you did not mention that detail.

The OP is worried about glitches in the combinatorial logic.  In
general, a glitch can be generated at the output of some combinatorial
logic whenever any input changes, even if (under steady state
conditions) that input should not affect the output.

Actually, the OP is worried about something that does not need to be
worried about.  Glitches causing resets are things that need to be
avoided when you're trying to *prevent* a false reset from occurring
(i.e. resetting when you don't want to be).  What the OP describes is
two inputs which are supposed to cause a reset.  A 'glitch' on one of
them would be a case of something that should cause a reset, not
something that should be prevented.

Exactly right, which is why I said:

"For the specific case of an AND ... the OP needn't worry."

Cheers,
Allan
Thanks for all of your feedback. The only reason I mentioned the AND
function
is because I generally use active LO resets. I can see now that
having some
logic in the asynchronous reset path is not a big deal since I am
actually dealing
with a reset circuit.

I just thought I had heard somewhere that avoiding combinational logic
in the
asynchronous reset path was a good design practice.
 
On Nov 21, 8:40 pm, Analog_Guy <analog_...@hotmail.com> wrote:

I just thought I had heard somewhere that avoiding combinational logic
in the
asynchronous reset path was a good design practice.- Hide quoted text -
In certain situations combinatorial logic in the reset path should be
avoided. See my reply to your post in comp.lang.vhdl

KJ
 
I generally implement resets with asynchronous assertion and
synchronous de-assertion. With a single reset, this is simple.
However, what happens if there are multiple reset inputs but I only
want one internal reset?

I was always under the impression that one should not have any
combinational logic in the asynchronous reset path, as it could lead
to static hazards (and reset glitches). So, how do you combine two
resets into one without using combinational logic somewhere?

I was thinking of two scenarios:
1. AND the two resets coming into the FPGA, and connect to the
asynchronous reset of a synchronizer. The output of the synchronizer
is the single internal reset.
2. Individually synchronize the two resets coming into the FPGA (note
that each reset input feeds the asynchronous reset of the
synchronizer). AND the output of each of the synchronizers and feed
this single signal into the asynchronous reset of a final flip-flop.
The output of this flip-flop is the single internal reset.

In both cases we achieve asynchronous assertion and synchronous de-
assertion ... however, in both cases there is combinational logic in
the asynchronous reset path.

Any suggestions how these multiple resets should be combined?
For multiple resets you always run them into a metastable synchronise
first and then combine them into one and resync it through a flop . Nic
thing about resets is that you can delay them quite a bit and they stil
work fine.

You also want to design for a multicycle reset. If all your sync logic wil
guarantee that all resets will be at least 4 cycles wide then you can us
that in you module design. Don't put reset logic on a flop if it's upstrea
flops have a reset that will force it into reset within 3 additiona
clocks.

You also want to cascade your resets. If you have a power on reset and
soft reset then you want the power on reset to cascade down and also forc
the soft reset when it is active. If you have any logic is must run durin
the power on reset then you must create a special simulation_test reset
That should cascade down to force both the power_on and soft resets.

John Eaton



---------------------------------------
Posted through http://www.FPGARelated.com
 

Welcome to EDABoard.com

Sponsor

Back
Top