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.
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.
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
any application where the FPGA is driving downstream power devices : eg in Motor Drive applications.
That said, normally that type of hard reset, is normally done with external logic devices that collect a number of 'OK' signals before actually allowing the power devices to turn on...
-jg
How about TriState contention? If I'm controlling TriState buffers with FFs that aren't initialized until the clock comes along, I run the risk of turning on more than one set of TriStates on a signal or bus. And when you're using high-current drivers, this can cause smoke; I've seen it.
Bob Perlman Cambrian Design Works
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...
Maybe you should :-)
Cheers, Martin
-- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
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
Found it!
Cheers, Martin
-- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
That's true
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
And if you're turning over control of the motor driver to a part that is clocked, I would expect that 'clock is running' would be one of those 'OK' signals. Furthermore, knowing that the clock is an input to the motor driver function, I would guess that the PCBA design would not even release reset to the FPGA until after the clock is actually running. Or is that not typically how one would do it?
KJ
Those must be some hefty drivers if they can cause smoke in the probably only a couple of milliseconds between when reset gets released until the clock starts running (assuming that reset was even released first, typically I wouldn't do that). I've seen bus driver TTL type devices, which are relatively hefty drivers, shorted for several weeks while waiting for the short on the board to be found and fixed without any smoke occurring and marveled that devices can take such abuse and still work. Probably cut into the shelf life of that board a bit but this was an engineering prototype.
So is there some publicly available "high current tri-state bus where reset releases before clock is running" you can refer to? Or was this some internal proprietary bus?
KJ
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
The drivers I'm referring to are chips like the ones you'd find in the
74ABT and 74LVT families. If memory serves, they source 32 mA HIGH and sink 64mA LOW. If you have one 16-output buffer chip contending with another, believe me, you will burn at least one of them out, and it won't take long. And if you somehow manage to keep the contention short enough to avoid burning them out immediately, you will shorten their lives.This is not conjecture; I've seen it happen in actual hardware. I used to help design ultrasound machines, and I learned that if you want to get a physician mad, make smoke come out of something his clinic just paid $200K for. They are touchy like that.
As for releasing the reset after the clock starts running, yes, that's what you want to do. But how does that prevent contention if the resets are purely synchronous? You could gate every TriState enable with the reset, but that slows down the enable path. Or you could rely on the end-of-configuration reset to initialize the TriState controls, but that's just another form of asynchronous reset.
And what if the clock doesn't start? It's OK for the system to malfunction if the clock doesn't come up, but it's considered bad form for the system to destroy itself.
It's amazing how much you can abuse hardware and still have it function, but that doesn't mean that hardware abuse is a good idea. I, too, have seen single chip outputs shorted for long periods of time without destroying the driver, but when you short multiple high-current outputs, all bets are off.
And low-drive outputs aren't a guarantee of trouble-free contention, either. In one system I worked on, we had a TriState bus with a RAM on it, and the RAM's TriState enable was under software control. Unfortunately, the software guys weren't aware that they were supposed to disable the RAM at startup, resulting in a brief period of contention every time the system booted. The RAM drivers were pretty weak, maybe 4mA, so you wouldn't suspect that'd be a problem, but we started getting boards back from the field with bad RAMs after 8 or 9 months.
Bob Perlman Cambrian Design Works
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
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
Yes....and it is done so automagically by the FPGA...thank you.
No problem. My point is I'm looking for the actual application that really does require specified reset behaviour PRIOR to the clock starting.
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
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:
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.