An implementation of a clean reset signal

[Duane Clark]

KJ wrote:

The clock not running is the common rebuttal that keeps coming up but if the
clock isn't running then just what behaviour DO you expect out of that part?
...

On critical designs, I use an asynchronous reset/synchronous deassert to
make sure the FPGA outputs are in a known state, and remain there until
the internal logic has a clock and has been cleanly and synchronously
reset. I also don't see how applying an asyncronous reset to internal
logic adds anything, and don't bother with it.

 

[Andrew FPGA]

If you take a step back and realize that you probably shouldn't expect
anything useful out of a part that is not receiving the proper inputs yet
(perhaps by design, after all it could be a power saving measure) then the
outputs that do not actually reset themselves until the clock does start up
is not really an issue.

Ok but what if those FPGA outputs can cause problems for other parts of
the system, say if the FPGA is on a bus. Maybe there are some bus
protocols out there where the bus clock can stop, and the peripheral
needs to be able to be reset by the bus master??

To be honest, all my designs to date have used synchronous resets so I
can't come up with a specific example where I had to have an async
initiated reset. The synchronous reset is simpler for me to understand
and analyse so thats what I use.

 

[KJ]

"Andrew FPGA" <andrew.newsgroup@gmail.com> wrote in message
news:1160349835.918930.124340@i42g2000cwa.googlegroups.com...

If you take a step back and realize that you probably shouldn't expect
anything useful out of a part that is not receiving the proper inputs yet
(perhaps by design, after all it could be a power saving measure) then
the
outputs that do not actually reset themselves until the clock does start
up
is not really an issue.

Ok but what if those FPGA outputs can cause problems for other parts of
the system, say if the FPGA is on a bus. Maybe there are some bus
protocols out there where the bus clock can stop, and the peripheral
needs to be able to be reset by the bus master??
Like I said, I don't discount that there may be these cases...but have yet

to hear anyone actually name a specific case where the clock isn't running
but a specific reset condition is required.

Can anyone actually provide one? Hard to believe that such a case doesn't
exist, but also hard to believe that one hasn't been articulated
either....oh well.

KJ

 

[Peter Alfke]

I suppose the following is common knowledge:
In all Xilinx FPGAs the internal flip-flops (and there are between
2,000 and 200,000 of them) are automatically asynchronously reset (or
preset, as an individual option). Any (desirable) additional
synchronous clear or set is up to the user, but usually the number of
critical flip-flops is quite limited...
Peter Alfke
==============
KJ wrote:

"Andrew FPGA" <andrew.newsgroup@gmail.com> wrote in message
news:1160349835.918930.124340@i42g2000cwa.googlegroups.com...
If you take a step back and realize that you probably shouldn't expect
anything useful out of a part that is not receiving the proper inputs yet
(perhaps by design, after all it could be a power saving measure) then
the
outputs that do not actually reset themselves until the clock does start
up
is not really an issue.

Ok but what if those FPGA outputs can cause problems for other parts of
the system, say if the FPGA is on a bus. Maybe there are some bus
protocols out there where the bus clock can stop, and the peripheral
needs to be able to be reset by the bus master??
Like I said, I don't discount that there may be these cases...but have yet
to hear anyone actually name a specific case where the clock isn't running
but a specific reset condition is required.

Can anyone actually provide one? Hard to believe that such a case doesn't
exist, but also hard to believe that one hasn't been articulated
either....oh well.

KJ

 

[Martin Thompson]

"Ben Jones" <ben.jones@xilinx.com> writes:

"Martin Thompson" <martin.j.thompson@trw.com> wrote in message
news:ulkntke5c.fsf@trw.com...
"Ben Jones" <ben.jones@xilinx.com> writes:

I have never heard a credible excuse for using an async reset
for any internal logic. I'm racking my brains to come up with some
clock-domain-crossing circuit that needs one

Does the flancter count? XCELL37, which doesn't seem to be on the
Xilinx site anymore... and Google isn't helping me find the original
place I saw it :-(

I have to confess, I've never heard of it.

Hmm, google seems to not provide any sources for it at all! The XCELL
archives seem broken as well :-(

I'll try and dig up an schematic and ASCII it later...

Then again, I don't do much flancting in most of my designs.

Maybe you should

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[Christian Ludlam]

On 9 Oct KJ wrote:

"Andrew FPGA" <andrew.newsgroup@gmail.com> wrote in message
news:1160349835.918930.124340@i42g2000cwa.googlegroups.com...
Ok but what if those FPGA outputs can cause problems for other parts of
the system, say if the FPGA is on a bus. Maybe there are some bus
protocols out there where the bus clock can stop, and the peripheral
needs to be able to be reset by the bus master??
Like I said, I don't discount that there may be these cases...but have yet
to hear anyone actually name a specific case where the clock isn't running
but a specific reset condition is required.

Can anyone actually provide one? Hard to believe that such a case doesn't
exist, but also hard to believe that one hasn't been articulated
either....oh well.

The PCI spec requires all outputs to be tristated on reset even in the
absense of a clock, so you need an async reset there.

--
Christian Ludlam
christian at recoil dot org

 

[Martin Thompson]

Martin Thompson <martin.j.thompson@trw.com> writes:

Hmm, google seems to not provide any sources for it at all! The XCELL
archives seem broken as well :-(

I'll try and dig up an schematic and ASCII it later...

Found it!

http://www.xilinx-china.com/company/consultants/flancter.pdf

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[KJ]

"Christian Ludlam" <chris-news@link.recoil.org> wrote in message
news:02c810734e.christian@venice.lab...

"Andrew FPGA" <andrew.newsgroup@gmail.com> wrote in message
news:1160349835.918930.124340@i42g2000cwa.googlegroups.com...
Ok but what if those FPGA outputs can cause problems for other parts of
the system, say if the FPGA is on a bus. Maybe there are some bus
protocols out there where the bus clock can stop, and the peripheral
needs to be able to be reset by the bus master??
Like I said, I don't discount that there may be these cases...but have
yet
to hear anyone actually name a specific case where the clock isn't
running
but a specific reset condition is required.

Can anyone actually provide one? Hard to believe that such a case
doesn't
exist, but also hard to believe that one hasn't been articulated
either....oh well.

The PCI spec requires all outputs to be tristated on reset even in the
absense of a clock,
That's true

so you need an async reset there.
But that's not.....just means that the tri-state control of outputs must be

shut off while reset is active....says nothing about any flip flops.

KJ

 

[Peter Alfke]

Output tristate in Xilinx FPGAs is driven by a flip-flop.
Peter Alfke
KJ wrote:

"Christian Ludlam" <chris-news@link.recoil.org> wrote in message
news:02c810734e.christian@venice.lab...
"Andrew FPGA" <andrew.newsgroup@gmail.com> wrote in message
news:1160349835.918930.124340@i42g2000cwa.googlegroups.com...
Ok but what if those FPGA outputs can cause problems for other parts of
the system, say if the FPGA is on a bus. Maybe there are some bus
protocols out there where the bus clock can stop, and the peripheral
needs to be able to be reset by the bus master??
Like I said, I don't discount that there may be these cases...but have
yet
to hear anyone actually name a specific case where the clock isn't
running
but a specific reset condition is required.

Can anyone actually provide one? Hard to believe that such a case
doesn't
exist, but also hard to believe that one hasn't been articulated
either....oh well.

The PCI spec requires all outputs to be tristated on reset even in the
absense of a clock,
That's true

so you need an async reset there.
But that's not.....just means that the tri-state control of outputs must be
shut off while reset is active....says nothing about any flip flops.

KJ

 

[KJ]

Peter Alfke wrote:

Output tristate in Xilinx FPGAs is driven by a flip-flop.
Peter Alfke

Guess I won't be able to implement anything resembling a
74xx244/374/etc. type of external interface in a Xilinx FPGA then

Anyway, given the controllable clearing/setting of flip flops that is
occurring in the Xilinx devices as you mentioned earlier, it would seem
that even in the absence of a clock one could insure that no output
that should be tri-stated by reset is actively driving the bus until
(if) that clock ever comes along simply by making the clocked signal
that drives the OE be '0' after configuration to disable the output
driver.

KJ

 

[Peter Alfke]

KJ wrote:

Peter Alfke wrote:
Output tristate in Xilinx FPGAs is driven by a flip-flop.
Peter Alfke

Guess I won't be able to implement anything resembling a
74xx244/374/etc. type of external interface in a Xilinx FPGA then

We have got to wean ourselves away from the 30-year old 7400-MSI

definitions. These circuits were defined as tiny sub-modules. Today's
FPGAs take a higher perspective, and implement certain functions
differently (=smarter).
It hurts to say something negative about 7400-MSI. Defining, applying,
and promoting it was my job in the early 'seventies. But that's a long
time ago...
Peter Alfke

 

[Peter Alfke]

What seems to be the problem?
Before and during configuration all Xilinx FPGA outputs are tristated.
During configuration, the 3-state-controlling flip-flop can and should
be asynchronously held reset.
It is only after the clock has started and the application runs that
the output can become active, if the user wants that to happen.
Where is the touchy problem?

Just to support Bob:
A 64-mA output sinks 64 mA at 0.4 V. And that is guaranteed worst case.
At nominal conditions it may behave not as an 8 Ohm, but rather as a 3
to 4 Ohm resistor. Easy to smoke in a multiple-contention case.

Peter Alfke

 

[KJ]

Peter Alfke wrote:

What seems to be the problem?
Before and during configuration all Xilinx FPGA outputs are tristated.
During configuration, the 3-state-controlling flip-flop can and should
be asynchronously held reset.
Yes....and it is done so automagically by the FPGA...thank you.

It is only after the clock has started and the application runs that
the output can become active, if the user wants that to happen.
Where is the touchy problem?
No problem. My point is I'm looking for the actual application that

really does require specified reset behaviour PRIOR to the clock
starting.

Just to support Bob:
A 64-mA output sinks 64 mA at 0.4 V. And that is guaranteed worst case.
At nominal conditions it may behave not as an 8 Ohm, but rather as a 3
to 4 Ohm resistor. Easy to smoke in a multiple-contention case.
Easy to smoke only if the condition persists for a 'long' time, where

the definition of 'long' is likely getting smaller as time goes by
since geometries shrink every few years and devices become less and
less tolerant of abuse. So how long is 'long' for your representative
Virtex-5 to smoke under the conditions you mentioned above?

Also, I think you're bolstering my point not Bob's. Bob's point was
that if the tri-state control is the output of a flip flop and you have
to wait for the clock in order to set the state of that flip flop then
you can have bus contention....I agree....however, using a device that
tri-states the outputs before and during configuration and clears the
flip flops you shouldn't have that contention because the output of
that flip flop won't be some unknown, it can be designed to be shut off
coming out of configuration and when the clock arrives, it arrives.

With older technology parts that may not have cleared the flops for you
the contention would only exist if reset was designed to be released
prior to clock and then only for the probably few milliseconds until
the clock actually started. But the older technology parts could also
take the abuse for that period of time and the design error (IMO) was
the releasing of reset prior to clock starting anyway. As an example,
take the PCI bus; reset is async to the clock but reset will not be
de-asserted until after the clock has been running for some nominal
number of cycles. Even the motor control example that was posted on
this thread was backed off a bit with the realization that there is
outside logic that checks first to see if things are 'OK' before
actually turning on the motors.

In any case, nobody has articulated yet the application that really
does require specified reset behaviour PRIOR to the clock starting thus
requiring use of the async reset (with the exception of the reset
signal synchronizer flip flop itself).

I think I'll quit on this thread (and in the future when it comes
up....hey stop the applause out there). If someone can actually
demonstrate such an application I'll be happy to hear about it until
then I'll just assume that such an application still might exist even
if it after several prods from the group they have yet to produce a
good example.

KJ

 

[Andy]

Most human-safety related requirements also include a "no single-point
failures" clause, which includes failures of any type of the clock
oscillator (no clock, fast/slow clock, etc.). Sure, there may be other
ways to handle these failures, but often the cheapest, simplest (and
all-importantly, easiest to verify/audit) method is an asynchronous
reset.

I've also designed VME interfaces in FPGAs when the only available
clock (16 MHz off the backplane) was slow enough to miss the minimum
gap between address strobes. Asynchronous reset saved the day... Not
that I recommend such approaches, but they do have their uses.

In general though, fully synchronous systems are usually easier to
verify (assuming the clock is known good!), and therefore are
preferable to asynchronous or partially asynchronous systems.

Andy


KJ wrote:

"Andrew FPGA" <andrew.newsgroup@gmail.com> wrote in message
news:1160349835.918930.124340@i42g2000cwa.googlegroups.com...
If you take a step back and realize that you probably shouldn't expect
anything useful out of a part that is not receiving the proper inputs yet
(perhaps by design, after all it could be a power saving measure) then
the
outputs that do not actually reset themselves until the clock does start
up
is not really an issue.

Ok but what if those FPGA outputs can cause problems for other parts of
the system, say if the FPGA is on a bus. Maybe there are some bus
protocols out there where the bus clock can stop, and the peripheral
needs to be able to be reset by the bus master??
Like I said, I don't discount that there may be these cases...but have yet
to hear anyone actually name a specific case where the clock isn't running
but a specific reset condition is required.

Can anyone actually provide one? Hard to believe that such a case doesn't
exist, but also hard to believe that one hasn't been articulated
either....oh well.

KJ

 

[Ray Andraka]

Peter Alfke wrote:

Output tristate in Xilinx FPGAs is driven by a flip-flop.
Peter Alfke

Doesn't have to be. There are flip-flops in the IOBs for the tristate
control, but they can be bypassed.

 

[Eli Bendersky]

Analog_Guy wrote:

Eli Bendersky wrote:

What does this technique lack to be the perfect solution for resets in
FPGA designs ? It seems that it evades all the common disadvantages of
conventional sync and async resets.


The only thing I see that this technique lacks is the ability to filter
(for noise, glitches)
the incoming reset signal. This approach can filter on the LO-HI
transition of reset,
but not on the HI-LO assertion.

So, if there is any noise or glitching on the reset input resulting in
a HI-LO transition, all
logic in the FPGA is instantly reset (i.e. asynchronous reset). Most
designs I work with
use some form of analog circuitry to provide the main reset to the
FPGA.

I do like the fact that reset will be applied even in the absence of a
clock. However, I have not yet implemented this technique because I am
not sure how to provide filtering on the HI-LO transition of the input
reset signal without requiring a clock. Can anyone help with this?
What are your ideas?

This isn't different from the "normal" async reset, however, where the
reset signal isn'f filtered. The solution usually used is an external
reset circuit (they come packed in nice tiny ICs these days) that
provides a clean reset signal of 200 ms (or whatever you set it to)
whenever there's a problem with the supplies, and as a byproduct, when
the power is going up.

Eli

 

[Al]

Eli Bendersky wrote:

The solution usually used is an external
reset circuit (they come packed in nice tiny ICs these days) that
provides a clean reset signal of 200 ms (or whatever you set it to)
whenever there's a problem with the supplies, and as a byproduct, when
the power is going up.

Excuse me Eli, can you give me a reference for those tiny ICs?
thanks a lot

Al

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer

 

[Eli Bendersky]

Al wrote:

Eli Bendersky wrote:
The solution usually used is an external
reset circuit (they come packed in nice tiny ICs these days) that
provides a clean reset signal of 200 ms (or whatever you set it to)
whenever there's a problem with the supplies, and as a byproduct, when
the power is going up.

Excuse me Eli, can you give me a reference for those tiny ICs?
thanks a lot

Al

Hello Al,

Googling "voltage supervisor" will bring up lots of results

Eli