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?

Reply to
bjzhangwn
Loading thread data ...

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

Reply to
Peter Alfke

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?

Reply to
StanleyLee

StanleyLee schrieb:

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

Antti

Reply to
Antti

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)

Reply to
Phil Hays

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

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!

Reply to
StanleyLee

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
Reply to
Aurelian Lazarut

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)

Reply to
Phil Hays

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:

Reply to
saumyajit_tech

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.

Reply to
mk

I thought we were talking about FPGAs ... the DFT logic for the FPGA is already in the FPGA and is completely independant of the design that you put in the FPGA. You don't use scan insertion tools for FPGAs .. that's ASIC land.

Mike

Reply to
Mike Lewis

Yes Mike, you are right. There is no point in talking abut DFT logic in the FPGAs. Even I have mentioned this point in my post.

I was expecting some comment on the first point that I had mentioned (regarding the Reset).

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.

In case the dcm lock pin is being used as the core reset, then also we should not be much worried about the reset pulse width. As the DCM needs number of clock cycles before getting locked.

any expert comments on this is highly appreciated.

Regards, Saumyajit

Reply to
saumyajit_tech

Reply to
Peter Alfke

Some systems require controlled behavior, even in the absence (due to failure, etc.) of a clock. In these cases, an asynchronously asserted, synchronously deasserted reset is one method:

process (rstin, clk) is variable rstmeta : std_logic; begin if rstin = '1' then rstout

Reply to
Andy

Hi, I am still confused about the usage of SRL16 in reset circuit, if I am using a single clock which is got out of a DCM, is the SRL16 unnecessary? Or, I should use it to syncronize the reset signal, just like a FF? I think if I connect a FF to the LOCKED pin of DCM, I can get the same as SRL16, because the LOCKED pin will be avalid only when the clock output is stable, so the SRL16 is unnecessary, a single FF is OK, too.

Can anybody give me some example of using SRL16 in reset circuit, please? Both code examples and application notes are OK.

Thank you very much!

Reply to
Stanley Lee

Reply to
Peter Alfke

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.