Source of reset for synchronous reset can lead to metastability?

Hi all,

Been reading a lot from the archives about synch/asynch resets. Found lots of good stuff and am now more enlightened.

My conclusions so far:

(1) Use synchronous reset in general on the flip flops for FPGAs

(2) If system requires asynch reset on the flip-flops, synchronise the release of the reset to the appropriate clock domain to avoid the release spanning a clock edge due to fanout delay.

Question 1: I guess the main reason for using an asynch reset is for when the circuit must be reset in the absence of a working clock? If so, how can the release ever be synched to said clock if it is not working? Hence, why ever use asynch reset on a clocked circuit?

Question 2 (the main one): In general it seems the best idea is to use a synchronous reset i.e.:

if (clk'event and clk = '1') then if (rst = '1') then // do reset else // synchronous logic end if; end if;

The question is to do with the source of the rst signal. Assuming that the rst signal pulse comes into the device via a pad, I assume that the circuitry external to the FPGA generating the pulse *must* do so synchronously to clk? (clearly if rst is generated on the device synchronous to clk then no problem). Otherwise, if rst is asynchronously generated, there must be a chance of the rst pulse transitioning too close to a clk edge at the flops and causing metastability? Or does this metastability issue only apply for the D/Q pins on the flop?

Thanks in advance for your time,

Ken

Reply to
Ken
Loading thread data ...

That's the best way. Sometimes there is an onboard cpu on the same clock, and it can toggle reset after loading the fpga from flash.

The problem is a logic race, not metastability. One way or another, the reset pulse needs to be synchronized before it gets to the global reset network on the fpga.

-- Mike Treseler

Reply to
Mike Treseler

An additional complication is that the global reset signal that is available on most FPGAs is slow relative to modern clock speeds. So even if it is synchronous at the pad, it may take more than one clock cycle to distribute over the chip.

Even if your clocks are slow, there is still the problem of multiple clocks.

The normal solution is to make a local copy of the reset signal that is synchronous to your local clock. Say one for each FSM.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray

I can think of a couple of situations where this might make sense. One is where you need to respond to a short duration reset signal that might not last during a clock transition. In most cases, building a one-instance synchronizer to generate a synchronous reset for the rest of the FPGA would be the best solution for this case.

Another is a safety-related reset, perhaps in a motion control system, where you need the reset to halt motion and cause an emergency stop, even if the clock were to fail. I have something like this in some of my designs. The external, analog-based one-shot watchdog timer will cause an e-stop even if the clock to the FPGA has gone static. I don't have any problem with an asynchronous release of this reset, in this case. it could cause a problem with a simulation, but it won't cause any problem in the actual application. The worst case is one more millisecond before the e-stop condition ends.

Jon

Reply to
Jon Elson

I missed something. This is a safety critical application. Why aren't you concerned about coming out of asynchronous resets?

[It's one of my hot buttons. I learned the hard way.]
--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray
070006050206060905080304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit

Hal Murray wrote:

The way the circuit works, it requires communication from the CPU to satisfy the watchdog, all other external fault conditions must be clear, then the command to come out of emergency stop must be given, and the global e_stop\ bus signal must rise under resistive pull-up to the logic threshold DURING the duration of the come out of estop command strobe. If it doesn't (presumably some other module pulling the e-stop\ bus low) it stays in e-stop. If it rises above the threshold, then the E-stop FF stays in the OK condition only as long as all the fault conditions stay in the no-fault state. All motion and auxilliary outputs are gated by E-stop. So, at most, one step could come out during the attempt to come out of estop that failed. It would be so narrow that a step motor driver would not accept it. Also, most of these systems actually power the step driver down with relays or a FET power ramp circuit with a time constant of .1 second. So, the drives won't be powered up unless they get a solid not-estop signal for a sizable part of a second.

Jon

Reply to
Jon Elson

This is absolutely false. Asynchronous resets are safe on th

assertion of them (who cares if some of the flops g metastable--you're in reset), but can be disastrous on thei deassertion. If reset is deasserted too close to the clock edge flops can go metastable

For an excellent discussion of synchronous vs. asynchronous resets

and techniques for safely resynchronizing asynchronous resets into clock domain please see the following papers

formatting link

formatting link

Reply to
pdq

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.