stable reset in fpga

I want to know how I can reset the logic in fpga and make the least
metastable.I use 2 clock in fpga and if it is nessesary to make the
reset input signal synchronize under the clock?

bjzhangwn wrote:
> I want to know how I can reset the logic in fpga and make the least
> metastable.I use 2 clock in fpga and if it is nessesary to make the
> reset input signal synchronize under the clock?

If you use an asynchronous reset signal while the clock is running,
then you must be concerned about the trailing end of Reset. Reset will
not go away everywhere at the same time, which means that some parts of
the circuit end the reset before a certain clock edge, others after
that edge. This can have ugly consequences.

The standard remedy is to augment (stretch) the asynchronous reset with
a local synchronous reset that lasts longer, but then of course ends
synchronously.
SRL16 shift registers are a popular and cheap way of doing that.
Peter Alfk, Xilinx

Peter Alfke wrote:
> bjzhangwn wrote:
> > I want to know how I can reset the logic in fpga and make the least
> > metastable.I use 2 clock in fpga and if it is nessesary to make the
> > reset input signal synchronize under the clock?
>
> If you use an asynchronous reset signal while the clock is running,
> then you must be concerned about the trailing end of Reset. Reset will
> not go away everywhere at the same time, which means that some parts of
> the circuit end the reset before a certain clock edge, others after
> that edge. This can have ugly consequences.
>
> The standard remedy is to augment (stretch) the asynchronous reset with
> a local synchronous reset that lasts longer, but then of course ends
> synchronously.
> SRL16 shift registers are a popular and cheap way of doing that.
> Peter Alfk, Xilinx

Thanks for Peter's answer, but I have a problem is that why use SRL16?
Why do not use a simple flip-flop? And if I use  the LOCKED pin of  a
DCM, is it synchronous with the input clock of the DCM?

StanleyLee schrieb:

> Peter Alfke wrote:
> > bjzhangwn wrote:
> > > I want to know how I can reset the logic in fpga and make the least
> > > metastable.I use 2 clock in fpga and if it is nessesary to make the
> > > reset input signal synchronize under the clock?
> >
> > If you use an asynchronous reset signal while the clock is running,
> > then you must be concerned about the trailing end of Reset. Reset will
> > not go away everywhere at the same time, which means that some parts of
> > the circuit end the reset before a certain clock edge, others after
> > that edge. This can have ugly consequences.
> >
> > The standard remedy is to augment (stretch) the asynchronous reset with
> > a local synchronous reset that lasts longer, but then of course ends
> > synchronously.
> > SRL16 shift registers are a popular and cheap way of doing that.
> > Peter Alfk, Xilinx
>
> Thanks for Peter's answer, but I have a problem is that why use SRL16?
> Why do not use a simple flip-flop? And if I use  the LOCKED pin of  a
> DCM, is it synchronous with the input clock of the DCM?

interesting, I see no reason why the LOCKED signal should be synch to
any of the DCM clocks, I bet it isnt.

Antti

"StanleyLee" <lizhongqi@hotmail.com> wrote:

>Peter Alfke wrote:

>> If you use an asynchronous reset signal while the clock is running,
>> then you must be concerned about the trailing end of Reset. Reset will
>> not go away everywhere at the same time, which means that some parts of
>> the circuit end the reset before a certain clock edge, others after
>> that edge. This can have ugly consequences.
>>
>> The standard remedy is to augment (stretch) the asynchronous reset with
>> a local synchronous reset that lasts longer, but then of course ends
>> synchronously.
>> SRL16 shift registers are a popular and cheap way of doing that.
>> Peter Alfk, Xilinx
>
>Thanks for Peter's answer, but I have a problem is that why use SRL16?
>Why do not use a simple flip-flop? And if I use  the LOCKED pin of  a
>DCM, is it synchronous with the input clock of the DCM?

If reset goes away in less than a clock period, then a single FF will
work, with enough care.  Not a usual case anymore, unless the clock
rate is fairly slow.  If reset takes multiple clocks to go away, but
less than 16, and the reset assertion time is longer than 16 clocks,
then a SRL16 is a very cheap and very good solution.  This is a common
case.

Short reset assertion time cases might require a shift register built
out of FFs, or a counter, to stretch the synchronous reset.


--
Phil Hays (Xilinx, but speaking for himself)

Phil Hays =E5=86=99=E9=81=93=EF=BC=9A

> "StanleyLee" <lizhongqi@hotmail.com> wrote:
>
> >Peter Alfke wrote:
>
> >> If you use an asynchronous reset signal while the clock is running,
> >> then you must be concerned about the trailing end of Reset. Reset will
> >> not go away everywhere at the same time, which means that some parts of
> >> the circuit end the reset before a certain clock edge, others after
> >> that edge. This can have ugly consequences.
> >>
> >> The standard remedy is to augment (stretch) the asynchronous reset with
> >> a local synchronous reset that lasts longer, but then of course ends
> >> synchronously.
> >> SRL16 shift registers are a popular and cheap way of doing that.
> >> Peter Alfk, Xilinx
> >
> >Thanks for Peter's answer, but I have a problem is that why use SRL16?
> >Why do not use a simple flip-flop? And if I use  the LOCKED pin of  a
> >DCM, is it synchronous with the input clock of the DCM?
>
> If reset goes away in less than a clock period, then a single FF will
> work, with enough care.  Not a usual case anymore, unless the clock
> rate is fairly slow.  If reset takes multiple clocks to go away, but
> less than 16, and the reset assertion time is longer than 16 clocks,
> then a SRL16 is a very cheap and very good solution.  This is a common
> case.
>
> Short reset assertion time cases might require a shift register built
> out of FFs, or a counter, to stretch the synchronous reset.
>
>
> --
> Phil Hays (Xilinx, but speaking for himself)

Thanks for Phils answer, but how should I use the SRL16? In my opinion,
if I do it as following, there is no difference between SRL16 and FF
except there is 16 cycles delay when  use SRL16.

D=3D>asynchronous reset in;
Q=3D>synchronous reset out;
A3,A2,A1,A0 =3D> '1';
CLK =3D> system clock;

Thank you!

StanleyLee wrote:

>Phil Hays 写道：
>
>  
>
>>"StanleyLee" <lizhongqi@hotmail.com> wrote:
>>
>>    
>>
>>>Peter Alfke wrote:
>>>      
>>>
>>>>If you use an asynchronous reset signal while the clock is running,
>>>>then you must be concerned about the trailing end of Reset. Reset will
>>>>not go away everywhere at the same time, which means that some parts of
>>>>the circuit end the reset before a certain clock edge, others after
>>>>that edge. This can have ugly consequences.
>>>>
>>>>The standard remedy is to augment (stretch) the asynchronous reset with
>>>>a local synchronous reset that lasts longer, but then of course ends
>>>>synchronously.
>>>>SRL16 shift registers are a popular and cheap way of doing that.
>>>>Peter Alfk, Xilinx
>>>>        
>>>>
>>>Thanks for Peter's answer, but I have a problem is that why use SRL16?
>>>Why do not use a simple flip-flop? And if I use  the LOCKED pin of  a
>>>DCM, is it synchronous with the input clock of the DCM?
>>>      
>>>
>>If reset goes away in less than a clock period, then a single FF will
>>work, with enough care.  Not a usual case anymore, unless the clock
>>rate is fairly slow.  If reset takes multiple clocks to go away, but
>>less than 16, and the reset assertion time is longer than 16 clocks,
>>then a SRL16 is a very cheap and very good solution.  This is a common
>>case.
>>
>>Short reset assertion time cases might require a shift register built
>>out of FFs, or a counter, to stretch the synchronous reset.
>>
>>
>>--
>>Phil Hays (Xilinx, but speaking for himself)
>>    
>>
>
>Thanks for Phils answer, but how should I use the SRL16? In my opinion,
>if I do it as following, there is no difference between SRL16 and FF
>except there is 16 cycles delay when  use SRL16.
>
>D=>asynchronous reset in;
>Q=>synchronous reset out;
>A3,A2,A1,A0 => '1';
>CLK => system clock;
>
>Thank you!
>
>  
>
The main difference is from the used resource perspective, with SRL16 
you need just a LUT (from a SLICEM) with the choice of up to 16 clks 
(taps) and no routing, but using FFs you need from 1 FF to 16 FFs + 
routing, depending on the number  of TAPs you want
functionally speaking it's the same thing in both.
Aurash

-- 
 __
/ /\/\ Aurelian Lazarut
\ \  / System Verification Engineer
/ /  \ Xilinx Ireland
\_\/\/
 
phone:	353 01 4032639
fax:	353 01 4640324
    
     

"StanleyLee" wrote:

>Phil Hays wrote:

>> If reset goes away in less than a clock period, then a single FF will
>> work, with enough care.  Not a usual case anymore, unless the clock
>> rate is fairly slow.  If reset takes multiple clocks to go away, but
>> less than 16, and the reset assertion time is longer than 16 clocks,
>> then a SRL16 is a very cheap and very good solution.  This is a common
>> case.

>Thanks for Phils answer, but how should I use the SRL16? In my opinion,
>if I do it as following, there is no difference between SRL16 and FF
>except there is 16 cycles delay when  use SRL16.

Exactly, and that difference may be required.

Suppose your clock period is 2.5 ns, and the time required to
propagate asynchronous reset to all FFs is 25 ns.  Then to make sure
that critical state was released from reset at the same time, then at
least 10 CLK cycles of delay would need to be added from the release
of asynchronous reset to the release of synchronous reset.

An SRL16 (plus 2 FFs) would do this just fine, as would a 10 bit shift
register built out of FFs, or a 4 bit counter.  The SRL16 uses the
smallest amount of hardware, there are reasons to use the other
methods at times.


--
Phil Hays (Xilinx, but speaking for himself)

I have few points here..

1) Here, I assume that the reset we are talking about is the Power ON
Reset which is connected to a switch (or equivalent ckt) in the board.
If this is the case, then the reset period is much more  higher than
some miliseconds.

2) My point number 2 is reagrding putting some logic( SRL16, FFs..) in
the reset ckt. I am afraid, it vilaotes the basic rule of
controllability of DFT.  I should be able to control the state of all
the FFs from a single reset pin out side the chip.  is not it true ?
Of course, when we say it is a FPGA, then we assume that it is already
tested and we should not be much worried about the DFT at this point.

Some documents say that the Input reset should be asserted
asyncronously and deasserted synchronously.  This also make some
sennse.

Regards,
Saumyajit

Phil Hays wrote:
> "StanleyLee" wrote:
>
> >Phil Hays wrote:
>
> >> If reset goes away in less than a clock period, then a single FF will
> >> work, with enough care.  Not a usual case anymore, unless the clock
> >> rate is fairly slow.  If reset takes multiple clocks to go away, but
> >> less than 16, and the reset assertion time is longer than 16 clocks,
> >> then a SRL16 is a very cheap and very good solution.  This is a common
> >> case.
>
> >Thanks for Phils answer, but how should I use the SRL16? In my opinion,
> >if I do it as following, there is no difference between SRL16 and FF
> >except there is 16 cycles delay when  use SRL16.
>
> Exactly, and that difference may be required.
>
> Suppose your clock period is 2.5 ns, and the time required to
> propagate asynchronous reset to all FFs is 25 ns.  Then to make sure
> that critical state was released from reset at the same time, then at
> least 10 CLK cycles of delay would need to be added from the release
> of asynchronous reset to the release of synchronous reset.
>
> An SRL16 (plus 2 FFs) would do this just fine, as would a 10 bit shift
> register built out of FFs, or a 4 bit counter.  The SRL16 uses the
> smallest amount of hardware, there are reasons to use the other
> methods at times.
> 
> 
> --
> Phil Hays (Xilinx, but speaking for himself)

On 5 Jul 2006 00:07:24 -0700, saumyajit_tech@yahoo.co.in wrote:

>2) My point number 2 is reagrding putting some logic( SRL16, FFs..) in
>the reset ckt. I am afraid, it vilaotes the basic rule of
>controllability of DFT.  I should be able to control the state of all
>the FFs from a single reset pin out side the chip.  is not it true ?

You can always insert control points after your reset logic so that
when you enable test the flops become externally controllable again.
It's easy to do this with current scan insertion tools.