The TL431 has uA's of REF current, but I vaguely recall a CMOS version with VREF=1.25V that might work.
Personally I prefer, for long timeouts, a CD4060-style approach... oscillator plus counter. I've even used that approach within custom chips where I only needed a 10ms safety window... because I could use an on-chip RC.... transistors are free ;-) ...Jim Thompson
--
| James E.Thompson | mens |
| Analog Innovations | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
I have done that in a design once. Worked fine. Then, many years later, the contract assembler decided on their own that they could save a penny and buy this cap from Uncle Chen's Capacitor Bakery down the road. And all hell broke loose ...
For New Yorkers they better suggest 20 seconds :-)
-- Regards, Joerg http://www.analogconsultants.com/
There is something wrong if you can't design an 8 pin MCU and get it on a board without a programming header. Any MCU or flash based FPGA I have seen can be bought programmed from distribution. Then it is a custom part number just for you and just like any other part in your inventory, it becomes a known quantity. If the firmware changes, that is a new part and a new part number.
I don't see how that is different from hardware anyway. It has been more than once that I've seen a production line shut down because a transistor maker changed their process on a part changing an uncontrolled part spec. Lots of times designs end up depending on a part feature that isn't part of the spec, mostly unintentional I expect.
Using software on MCUs really doesn't have to be the same as managing version control on a Linux box.
-- Rick
That is like when the cable people tell you to unplug the modem for 30 seconds to let the CMOS memory erase... lol. if the thing has anything like a proper reset circuit it should reset with a fraction of a second unplug. If it doesn't, why am I using it, it is crap!
-- Rick
How do you know the reset chip you bought isn't an MCU with a private label?
-- Rick
I've worked on a lot of highly specified equipment, but I don't think I've ever seen a screwdriver poking spec.
Someone said the same thing is true of PLDs, but I think not... I've never had a PLD hang on me like an MCU might. It might have something to do with the difference between hardware and software.
-- Rick
PLDs should not 'hang' but that does not mean that the power-up state is known, merely that it will be in one of the possible states for that particular arrangement of logic. Poking a screwdriver around might put it in an unexpected state.
No, no, that's to give them time to pull the big binder with the standard answers in there. If the answer ain't in there they'll tell you to re-install the operating system :-)
-- Regards, Joerg http://www.analogconsultants.com/
It used to be de-frag the hard drive. I actually had a conversation about this with an HP rep when I had a problem with a printer some 12 years ago. I laughed when she told me to do this and told her it was nonsense. She swore the senior techs recommend it all the time!
-- Rick
What do you mean, it "does not mean the power up state is known"? I designed "that particular arrangement of logic". If it is wrong, I will know about it because I implemented it, simulated it and planned for all possible inputs and single event upsets. If a bug gets past this, it is no different from a ASSP device which is also designed using the same methods.
The I2C bus is a classic example of ASSP problems. Heck, the protocol itself is to blame really and all the I2C chips built before a certain point had the problem. Even today many have it.
I think this is just an example of someone shying away from things they don't know much about. Not that we don't all do that.
-- Rick
I'm just saying that, in general, a PLD requires a reliable reset signal just as a microcontroller does.
It might have something to do with how closely you are looking at the PLD...
I've had a block RAM in an FPGA "forget" some bits after a clock glitch, even though the write enable was permanently tied inactive. Does that count as a hang?
It's actually a well know feature of certain types of self timed static ram and is not limited to FPGAs. Xilinx and Altera block rams in all FPGA families have this problem.
Here's the relevant Xilinx Answer Record:
One of the Altera families (I forget which one) could hang its RAM so badly under similar conditions that the part had to be reconfigured for it to recover. They mentioned it in the datasheet, which I thought was considerate of them.
Regards, Allan
All synchronous logic can screw up with clock glitches. That includes parts where all the logic is internal and you don't see it such as reset controllers. A power glitch and the controller malfunctions...
How do you prevent this problem when designing with PLDs? I do it by designing clocks that don't glitch. I also avoid leaving screwdrivers lay (or is it lie?) on my circuits...
Humor aside, I think you said the Xilinx DCM could generate a glitch that would screw up the rest of the chip while the DCM was locking. Is that right? Does Xilinx expect you to gate the clock output until it is locked? Obviously this is a major issue in any design that uses those two components.
A friend who works on telecom equipment told me once that the time between faults for that sort of gear is so long, that it can be
*extremely* hard to isolate bugs. This sounds like a problem that would prevent these features from ever being used in telecom gear, and yet telecom is one of the really big customers for their parts. I believe networking is the biggest user of FPGAs, although I think they have lower standards when it comes to glitches in operation. My point is that there must be a way to use these features without locking up the chip.-- Rick
Yes, all synchronous logic can screw up with clock glitches, etc., but mostly it will come good again after a reset. The ram problem affects rams used as ROMs - fixed lookup tables that can get corrupted. Reset doesn't fix that; the FPGA needs to be reloaded.
Intuitively, one expects that a ROM doesn't change its values regardless of how its used. Finding out that preloaded rams in FPGAs used as ROMs can change their contents is rather disturbing.
There are a few ways to deal with it:
- don't use RAMs as ROMs.
- keep the CE input inactive whenever the clock can glitch
- use a BUFGMUX / BUFGCE (etc) on the output of a DCM to mute potential clock glitches
- detect corruption and somehow restore the contents, perhaps by reloading the FPGA.
In all the tests I did, I only had a problem on the initial DCM lock. If it survived the initial lock, everything was fine. I only noticed this problem at all because my application had hundreds of RAMS used ROMs, and they were tested after the FPGA was loaded as part of the product self test.
On the worst boards I could get a few failures per minute during testing. On the best boards I couldn't get it to fail at all.
Yes, exactly right. My particular problem was with Virtex2-Pro in a design from about a decade back. I haven't noticed the problem on newer devices, but I've been very careful to avoid designs that can fail in this way. Hopefully the newer PLL-based clock managers (MMCM) are better than the old DLLs.
IP published by Xilinx that uses RAMs as ROMs mostly ignores this problem.
IP *I* write is good, and can be verified by design review. What really worries me is the IP that is closed source, and silently gets added to my design by the tools. (If you've used a tool like XPS you'll know what I mean.)
Regards, Allan
Yes, I get that. But I can see how a clock glitch can screw it up since it is *not* a ROM, just a RAM with the write disabled. Actually, it is easy to prevent this if I read the note properly. They talk about a precondition that the block RAM enable is asserted. Of course, they are talking about address setup/hold violations, not clock glitches, so your issue may be slightly different. Did you find that deasserting the overall enable would prevent the problem?
That's not a very good one... :(
Ok, that makes good sense!
Yes, I anticipated that.
Not fun, but possible. I remember a satellite application where to deal with SEU, they would periodically reconfigure the FPGA. So any glitch was short lived.
This is one of those little known failure modes I expect. I would not have thought of it. I *would* expect there to be a note about this in the DCM information, not just an Answer Record that could be found
*after* you are bitten by the bug.I remember hearing warnings about the output of the DCMs being "invalid" until locked. I never heard about such serious downstream impacts.
My typical design is not so large that I can't craft all my own code. I also have not used a Xilinx part in close to a decade. I have been using Lattice parts a lot lately. I will be working on an ICE40 design in the near future. *very* low power... pretty cool parts, so to speak...
-- Rick
think
something
will
all
is
If i might dare to amplify, not only the signal but the response as well. I suspect that rickman includes this in his designs, but not everyone else.
?-)
How about a really simple one, Use the Motorola MC14490 cmos switch bounce eliminator. The single capacitor sets delay anywhere you want and you have
5 more channels to work with. Could make something reset at 5 seconds and 1 0 seconds. Fun to work with too.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.