Function/Reset pushbutton

[Vladimir Vassilevsky]

In modern electronic gadgets, quite often, a pushbutton has some
function and a hardware reset functionality. If you tap a pushbutton, it
activates a function. If you press and hold the pushbutton for about 10
seconds, it acts as hardware reset.

I wonder what is the schematics for that. Should be super simple and
cheap. I would not trust R-C for 10 second delays. An oscillator with
divider logic would be bulky. Is there a specialized IC for that purpose?

Vladimir Vassilevsky
DSP and Mixed Signal Designs
www.abvolt.com

[Spehro Pefhany]

STM6519?

There look to be others. You could also use a microcontroller,
perhaps.



Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

[John Larkin]

On Thu, 11 Apr 2013 21:38:24 -0500, Vladimir Vassilevsky <nos...@nowhere.com>
wrote:

A 10 second RC is not unreasonable. A 10 uF ceramic cap and a meg or two. 10
seconds sounds a bit much, maybe.

But I bet most gadgets do it in software, so it's not a truly hard reset.


--

John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

[Vladimir Vassilevsky]

On 4/11/2013 10:04 PM, Spehro Pefhany wrote:
> On Thu, 11 Apr 2013 21:38:24 -0500, the renowned Vladimir Vassilevsky
> <nos...@nowhere.com> wrote:
>
>>
>> In modern electronic gadgets, quite often, a pushbutton has some
>> function and a hardware reset functionality. If you tap a pushbutton, it
>> activates a function. If you press and hold the pushbutton for about 10
>> seconds, it acts as hardware reset.
>>
>> I wonder what is the schematics for that. Should be super simple and
>> cheap. I would not trust R-C for 10 second delays. An oscillator with
>> divider logic would be bulky. Is there a specialized IC for that purpose?
>>

>

> STM6519?
> There look to be others.

Thanks, that's exactly it.

> You could also use a microcontroller,
> perhaps.

MCU is just another part that has to be programmed and tested. And it is
prone to hangups, too.

[Tim Wescott]

One could use an 8-pin (or 6-pin) processor whose entire job in life is
to generate that reset pulse. That would at least minimize the number of
lines of code for a bug to hide in.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

[Jan Panteltje]

On a sunny day (Thu, 11 Apr 2013 21:38:24 -0500) it happened Vladimir
Vassilevsky <nos...@nowhere.com> wrote in
<pqqdnSFKfckL7vrM...@giganews.com>:

>
>In modern electronic gadgets, quite often, a pushbutton has some
>function and a hardware reset functionality. If you tap a pushbutton, it
>activates a function. If you press and hold the pushbutton for about 10
>seconds, it acts as hardware reset.
>
>I wonder what is the schematics for that. Should be super simple and
>cheap. I would not trust R-C for 10 second delays. An oscillator with
>divider logic would be bulky. Is there a specialized IC for that purpose?

I have that as some extra code in the PIC,
for example in my gamma spectrometer, 10 seonds push on the red button wil power it down,
10 seconds to prevent accidently switching it off.
The PIC does a lot more, but for simple cases a PIC (with internal osillator)
may even be cheaper than some RC stuff, and certainly more accurate (2%).
And it can drive LEDs and other things too, current consumption in the uA range.
More keys (gamma spectrometer has 18 push buttons), all in one PIC.

In short: it is all digital.

[Jan Panteltje]

On a sunny day (Thu, 11 Apr 2013 22:31:15 -0500) it happened Vladimir
Vassilevsky <nos...@nowhere.com> wrote in
<HOidnXDigqxk4vrM...@giganews.com>:

Only if your code makes it do that ;-)

[hamilton]

On 4/11/2013 9:04 PM, Spehro Pefhany wrote:
> On Thu, 11 Apr 2013 21:38:24 -0500, the renowned Vladimir Vassilevsky
> <nos...@nowhere.com> wrote:
>
>>
>> In modern electronic gadgets, quite often, a pushbutton has some
>> function and a hardware reset functionality. If you tap a pushbutton, it
>> activates a function. If you press and hold the pushbutton for about 10
>> seconds, it acts as hardware reset.
>>
>> I wonder what is the schematics for that. Should be super simple and
>> cheap. I would not trust R-C for 10 second delays. An oscillator with
>> divider logic would be bulky. Is there a specialized IC for that purpose?
>>
>> Vladimir Vassilevsky
>> DSP and Mixed Signal Designs
>> www.abvolt.com
>
> STM6519?
>
> There look to be others. You could also use a microcontroller,
> perhaps.
>
>
>
> Best regards,
> Spehro Pefhany
>

Digikey has STM6519 for $0.97 for one unit, .675 for 100
10f204 for $0.65 for one unit, .38 for 100

How many do you need for your products ?

[Joerg]

Vladimir Vassilevsky wrote:
>
> In modern electronic gadgets, quite often, a pushbutton has some
> function and a hardware reset functionality. If you tap a pushbutton, it
> activates a function. If you press and hold the pushbutton for about 10
> seconds, it acts as hardware reset.
>
> I wonder what is the schematics for that. Should be super simple and
> cheap. I would not trust R-C for 10 second delays. An oscillator with
> divider logic would be bulky. Is there a specialized IC for that purpose?
>

The CD4060 is a low cost IC to do long-delay stuff with. Or the 74HC4060
version if you are dealing with lower supply voltages. Essentially it
contains an oscillator running at some reasonable clock and a long
divider, saving you from having to deal with leakage in electrolytic
timing caps.

The CD-series is especially nice because of its wide operating voltage
range which makes it easy to run them on an unregulated battery voltage.
The more fancy chips are often process-limited to 6V or so.

--
Regards, Joerg

http://www.analogconsultants.com/

[Vladimir Vassilevsky]

On 4/12/2013 12:04 AM, Tim Wescott wrote:
> On Thu, 11 Apr 2013 22:31:15 -0500, Vladimir Vassilevsky wrote:
>
>> On 4/11/2013 10:04 PM, Spehro Pefhany wrote:
>>> On Thu, 11 Apr 2013 21:38:24 -0500, the renowned Vladimir Vassilevsky
>>> <nos...@nowhere.com> wrote:
>>>
>>>
>>>> In modern electronic gadgets, quite often, a pushbutton has some
>>>> function and a hardware reset functionality. If you tap a pushbutton,
>>>> it activates a function. If you press and hold the pushbutton for
>>>> about 10 seconds, it acts as hardware reset.
>>>>
>>>> I wonder what is the schematics for that. Should be super simple and
>>>> cheap. I would not trust R-C for 10 second delays. An oscillator with
>>>> divider logic would be bulky. Is there a specialized IC for that
>>>> purpose?
>>>>
>>>>
>>
>>> STM6519?
>>> There look to be others.
>>
>> Thanks, that's exactly it.
>>
>>> You could also use a microcontroller, perhaps.
>>
>> MCU is just another part that has to be programmed and tested. And it is
>> prone to hangups, too.
>
> One could use an 8-pin (or 6-pin) processor whose entire job in life is
> to generate that reset pulse. That would at least minimize the number of
> lines of code for a bug to hide in.

Every other programmable component on the assembly is PITA for
manufacturing. As it has to be programmed (loaded with software) and
tested. And then there is always a question if this revision of MCU
software is compatible with PCB revision X and FPGA revision Y, etc, etc.

[Jeroen Belleman]

On 2013-04-12 16:58, Joerg wrote:
> Vladimir Vassilevsky wrote:
>>
>> In modern electronic gadgets, quite often, a pushbutton has some
>> function and a hardware reset functionality. If you tap a pushbutton, it
>> activates a function. If you press and hold the pushbutton for about 10
>> seconds, it acts as hardware reset.
>>
>> I wonder what is the schematics for that. Should be super simple and
>> cheap. I would not trust R-C for 10 second delays. An oscillator with
>> divider logic would be bulky. Is there a specialized IC for that purpose?
>>
>

> The CD4060 is a low cost IC to do long-delay stuff with. [...]


Seems to me this kind of functionality only makes sense
in the context of micro-controller-based gadgets. Its
implementation comes down to a few lines of code.

In a well-designed gadget, who needs a reset, anyway?

Jeroen Belleman

[Jan Panteltje]

On a sunny day (Fri, 12 Apr 2013 10:26:45 -0500) it happened Vladimir
Vassilevsky <nos...@nowhere.com> wrote in
<rLidnWMLpOsyuvXM...@giganews.com>:

>Every other programmable component on the assembly is PITA for
>manufacturing. As it has to be programmed (loaded with software) and
>tested. And then there is always a question if this revision of MCU

>software is compatible with PCB revision X and FPGA revision Ycetc, etc.

Come on, if you have a FPGA on board use a counter in that.

[Vladimir Vassilevsky]

Uhm, no.

Take a screwdriver and poke with it around a microcontroller. After some
time of poking, the micro will hang up till powerdown. It is no matter
how good is your code and how good is schematics and layout; despite of
all watchdogs and supervisors.

[Vladimir Vassilevsky]

That's software solution; not real hardware reset.

VLV

[Jan Panteltje]

On a sunny day (Fri, 12 Apr 2013 10:36:55 -0500) it happened Vladimir
Vassilevsky <nos...@nowhere.com> wrote in
<ieydnRU_TIeOt_XM...@giganews.com>:

>Uhm, no.
>
>Take a screwdriver and poke with it around a microcontroller. After some
>time of poking, the micro will hang up till powerdown.

Do the same with your eye and it will stop working too.
What is your point?

[Jan Panteltje]

On a sunny day (Fri, 12 Apr 2013 10:43:58 -0500) it happened Vladimir
Vassilevsky <nos...@nowhere.com> wrote in
<wKqdnVU4eMQutvXM...@giganews.com>:

What does HDL mean to you????

[Joerg]

Sure, but not if the circuitry works with regular logic instead of a uC.

> In a well-designed gadget, who needs a reset, anyway?
>

The user does, after he finds out it's not so well designed as the
designer thought it was :-)

It still rings in my ears. Major luxury CAD vendor, expensive CAD suite.
Did not have a reset, you had to do CTRL-ALT-DEL when it crashed. So I
called it in because I couldn't work like that. "No this can't be, can
we do an online session where you give us control of your desktop" ...
"Sure" ... another support engineer walk into room ... then the manager
walks in as well ... at some point one of the guys exclaims "I can't
believe this is happening!"

[Vladimir Vassilevsky]

My point: Hardware reset must be true hardware reset. It should work no
matter what.

[Joerg]

Jan Panteltje wrote:
> On a sunny day (Fri, 12 Apr 2013 10:43:58 -0500) it happened Vladimir
> Vassilevsky <nos...@nowhere.com> wrote in
> <wKqdnVU4eMQutvXM...@giganews.com>:
>
>> On 4/12/2013 10:35 AM, Jan Panteltje wrote:
>>> On a sunny day (Fri, 12 Apr 2013 10:26:45 -0500) it happened Vladimir
>>> Vassilevsky <nos...@nowhere.com> wrote in
>>> <rLidnWMLpOsyuvXM...@giganews.com>:
>>>
>>>> Every other programmable component on the assembly is PITA for
>>>> manufacturing. As it has to be programmed (loaded with software) and
>>>> tested. And then there is always a question if this revision of MCU
>>>> software is compatible with PCB revision X and FPGA revision Ycetc, etc.
>>> Come on, if you have a FPGA on board use a counter in that.
>>>
>> That's software solution; not real hardware reset.
>>
>> VLV
>
> What does HDL mean to you????

That it can hang.

[Jan Panteltje]

On a sunny day (Fri, 12 Apr 2013 08:59:47 -0700) it happened Joerg
<inv...@invalid.invalid> wrote in <asqpbq...@mid.individual.net>:

HDL stands for Hardware Description Language.
It specifies some hardware configuration.
In FPGA how all gates and flipflops, registers and other stuff is connected together.
Once configured it is just like the little peeseebees you make, but internal to the chip.
Pure hardware.

Sure you can make it go wrong by poking a screwdriver on some FPGA pins,
and I am sure I can make your peeseebee designs go wrong by sticking a screwdriver
in the right (or wrong depending on POV) places.
You are more likely to kill you CD40XXx counter (needs a crystal too!) by poking
then to somehow hit and affect an internal counter in FPGA.
Even more chances to short some supply rail.
Have you even ever programmed a FPGA or written some HDL?
Or Vladimir?
Silly answers.

[Joerg]

VHDL is usually generated via a software suite. Out comes a big chunk of
code that gets downloaded. The software suite can have bugs, and I have
diagnosed numerous cases where that was so. These bugs can be nasty,
only show up after a long time when a certain not so usual condition
happens in the IC.

> Sure you can make it go wrong by poking a screwdriver on some FPGA pins,
> and I am sure I can make your peeseebee designs go wrong by sticking a screwdriver
> in the right (or wrong depending on POV) places.

I wasn't talking about shorting stuff, that can kill a circuit.

> You are more likely to kill you CD40XXx counter (needs a crystal too!) by poking
> then to somehow hit and affect an internal counter in FPGA.

What for does it need a crystal? Take a look at figure 12 the datasheet:

http://www.ti.com/lit/ds/symlink/cd4060b.pdf

> Even more chances to short some supply rail.
> Have you even ever programmed a FPGA or written some HDL?

I do not do FPGA but have found numerous bugs in them. Sometimes with
rather unorthodox tools.


> Or Vladimir?
> Silly answers.
>

Huh?

[Jan Panteltje]

On a sunny day (Fri, 12 Apr 2013 10:07:46 -0700) it happened Joerg
<inv...@invalid.invalid> wrote in <asqtb9...@mid.individual.net>:

>> HDL stands for Hardware Description Language.
>> It specifies some hardware configuration.
>> In FPGA how all gates and flipflops, registers and other stuff is connected together.
>> Once configured it is just like the little peeseebees you make, but internal to the chip.
>> Pure hardware.
>>
>
>VHDL is usually generated via a software suite. Out comes a big chunk of
>code that gets downloaded. The software suite can have bugs, and I have
>diagnosed numerous cases where that was so. These bugs can be nasty,
>only show up after a long time when a certain not so usual condition
>happens in the IC.


>
>> Sure you can make it go wrong by poking a screwdriver on some FPGA pins,
>> and I am sure I can make your peeseebee designs go wrong by sticking a screwdriver
>> in the right (or wrong depending on POV) places.
>
>
>I wasn't talking about shorting stuff, that can kill a circuit.
>
>
>> You are more likely to kill you CD40XXx counter (needs a crystal too!) by poking
>> then to somehow hit and affect an internal counter in FPGA.
>
>
>What for does it need a crystal? Take a look at figure 12 the datasheet:
>
>http://www.ti.com/lit/ds/symlink/cd4060b.pdf

Vladimir specidied high accuracy, your circuit is even more expensive with
small tolerence caps and resistors, if it is stable at all due to chip tolerances in voltage thresholds.
Takes me righ tback to the seventies....
We have advanced.

>
>> Even more chances to short some supply rail.
>> Have you even ever programmed a FPGA or written some HDL?
>
>
>I do not do FPGA but have found numerous bugs in them. Sometimes with
>rather unorthodox tools.

That old bicycle with dynamo and you peddling as signal generator I can imagine.





Normally FPGA code is tested in some test code setup,
the only thing that bugged me about webpack is the insane error messages you sometimes
get when you make some mistake, sends you in the wrong direction.
Once it works it always works.
You have to rely on the software for the timing specs being valid over the full temp range
etc... But it is up to you how much extra margin you keep.


>Huh?

Cannot help you there, but it is the beginning o wanting to understand I suppose.

[Tim Wescott]

In spite of me tweaking him with the notion of a six-pin processor,
Vladimir has a very valid point: there are some functions that you'd just
as soon leave in hardware rather than software.

One may, on a design-by-design basis, review these decisions. But that
doesn't mean that there isn't a valid place for what he's asking.

[Joerg]

Did you forget your glasses? Quote from OP "If you press and hold the
pushbutton for about 10 seconds, ..."
^^^^^^^

Now tell us, how high of an accuracy is "about"?

[...]

[Tim Wescott]

:)

[Spehro Pefhany]

Hardware can be more than an equal partner in such endeavors.

[Jan Panteltje]

On a sunny day (Fri, 12 Apr 2013 11:08:01 -0700) it happened Joerg
<inv...@invalid.invalid> wrote in <asr0s8...@mid.individual.net>:

>> Vladimir specidied high accuracy, your circuit is even more expensive with
>> small tolerence caps and resistors, if it is stable at all due to chip tolerances in voltage thresholds.
>> Takes me righ tback to the seventies....
>> We have advanced.
>>
>
>Did you forget your glasses? Quote from OP "If you press and hold the
>pushbutton for about 10 seconds, ..."
> ^^^^^^^
>
>Now tell us, how high of an accuracy is "about"?

Actually he wrote:
>I wonder what is the schematics for that. Should be super simple and
>cheap. I would not trust R-C for 10 second delays. An oscillator with
>divider logic would be bulky. Is there a specialized IC for that purpose?

Your 'solution' from 30 years back in the last centrury is exactly what he did NOT trust and want.


A simple 8 pin PIC using internal oscillator gives 2% accuracy an can be used for other things too,
and is cheaper than specialized chips.
If you have a FPGA on board use that.

If you cannot understand that no need to get all worked up about it :-)
Just retire and grow some plants or go to a warm place in the sun where they have hula
girls and large cool drinks.

[Joerg]

Jan Panteltje wrote:
> On a sunny day (Fri, 12 Apr 2013 11:08:01 -0700) it happened Joerg
> <inv...@invalid.invalid> wrote in <asr0s8...@mid.individual.net>:
>
>>> Vladimir specidied high accuracy, your circuit is even more expensive with
>>> small tolerence caps and resistors, if it is stable at all due to chip tolerances in voltage thresholds.
>>> Takes me righ tback to the seventies....
>>> We have advanced.
>>>
>> Did you forget your glasses? Quote from OP "If you press and hold the
>> pushbutton for about 10 seconds, ..."
>> ^^^^^^^
>>
>> Now tell us, how high of an accuracy is "about"?
>
> Actually he wrote:
> >I wonder what is the schematics for that. Should be super simple and
> >cheap. I would not trust R-C for 10 second delays. An oscillator with
> >divider logic would be bulky. Is there a specialized IC for that purpose?
>

So where is the requirement "high accuracy" in there?

[Jan Panteltje]

On a sunny day (Fri, 12 Apr 2013 12:07:58 -0700) it happened Joerg
<inv...@invalid.invalid> wrote in <asr4cm...@mid.individual.net>:

Implied as obvious from 'would not trust 10 seconds RC'
10 seconds RC IS inaccurate, and the opposite of accurate,
at least on my planet,

[Joerg]

Jan Panteltje wrote:
> On a sunny day (Fri, 12 Apr 2013 12:07:58 -0700) it happened Joerg
> <inv...@invalid.invalid> wrote in <asr4cm...@mid.individual.net>:
>
>> Jan Panteltje wrote:
>>> On a sunny day (Fri, 12 Apr 2013 11:08:01 -0700) it happened Joerg
>>> <inv...@invalid.invalid> wrote in <asr0s8...@mid.individual.net>:
>>>
>>>>> Vladimir specidied high accuracy, your circuit is even more expensive with
>>>>> small tolerence caps and resistors, if it is stable at all due to chip tolerances in voltage thresholds.
>>>>> Takes me righ tback to the seventies....
>>>>> We have advanced.
>>>>>
>>>> Did you forget your glasses? Quote from OP "If you press and hold the
>>>> pushbutton for about 10 seconds, ..."
>>>> ^^^^^^^
>>>>
>>>> Now tell us, how high of an accuracy is "about"?
>>> Actually he wrote:
>>> >I wonder what is the schematics for that. Should be super simple and
>>> >cheap. I would not trust R-C for 10 second delays. An oscillator with
>>> >divider logic would be bulky. Is there a specialized IC for that purpose?
>>>
>
>> So where is the requirement "high accuracy" in there?
>
> Implied as obvious from 'would not trust 10 seconds RC'
> 10 seconds RC IS inaccurate, and the opposite of accurate,
> at least on my planet,
>

With an electrolytic in there you can have +80/-20% or so tolerance.
With the CD4060 and regular ceramics, however, the reset could take 9sec
in one case, 11sec in another. Big deal. Well, maybe on whichever planet
you've landed that does make a difference for a simple reset function :-)

Didn't you call in from outer space some time ago?

[John Larkin]

Why would a 10 second time constant be any less accurate than a 10
microsecond one?


--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro acquisition and simulation

[Jan Panteltje]

On a sunny day (Fri, 12 Apr 2013 13:41:18 -0700) it happened Joerg
<inv...@invalid.invalid> wrote in <asr9rn...@mid.individual.net>:

>>> So where is the requirement "high accuracy" in there?
>>
>> Implied as obvious from 'would not trust 10 seconds RC'
>> 10 seconds RC IS inaccurate, and the opposite of accurate,
>> at least on my planet,
>>
>
>With an electrolytic in there you can have +80/-20% or so tolerance.

Bad electrolitics

>With the CD4060 and regular ceramics, however, the reset could take 9sec
>in one case, 11sec in another.

Terrible.


>Big deal.

Yes.

>Well, maybe on whichever planet
>you've landed that does make a difference for a simple reset function :-)

On my planet earth it does.

>Didn't you call in from outer space some time ago?

No was not me, did they ask you to join in abduction?
Do not say yes, Joerg, they do horrible experiments with humans.
I have seen that movie, Mars Attacks, where they put a dogs body on the head on the nice female reporter.
She was scratching herself with a rear leg.
Just put that receiver down when they call again, really!

[Joerg]

Jan Panteltje wrote:
> On a sunny day (Fri, 12 Apr 2013 13:41:18 -0700) it happened Joerg
> <inv...@invalid.invalid> wrote in <asr9rn...@mid.individual.net>:
>
>>>> So where is the requirement "high accuracy" in there?
>>> Implied as obvious from 'would not trust 10 seconds RC'
>>> 10 seconds RC IS inaccurate, and the opposite of accurate,
>>> at least on my planet,
>>>
>> With an electrolytic in there you can have +80/-20% or so tolerance.
>
> Bad electrolitics
>

Pretty standard. You need to get out more ...

>> With the CD4060 and regular ceramics, however, the reset could take 9sec
>> in one case, 11sec in another.
>
> Terrible.
>
>
>> Big deal.
>
> Yes.
>

For a reset? Good grief.

>
>> Well, maybe on whichever planet
>> you've landed that does make a difference for a simple reset function :-)
>
> On my planet earth it does.
>

Aha. Then you do live on another planet.

>
>> Didn't you call in from outer space some time ago?
>
> No was not me, did they ask you to join in abduction?
> Do not say yes, Joerg, they do horrible experiments with humans.
> I have seen that movie, Mars Attacks, where they put a dogs body on the head on the nice female reporter.
> She was scratching herself with a rear leg.
> Just put that receiver down when they call again, really!
>

Just had that, the cell phone and the lanline rang at exactly the same
time. They are coming! GAAAH!!

[Jim Thompson]

On Fri, 12 Apr 2013 14:49:10 -0700, Joerg <inv...@invalid.invalid>
wrote:

What? The Killer Tomatoes ?>:-}

...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.

[Spehro Pefhany]

On Fri, 12 Apr 2013 14:49:10 -0700, the renowned Joerg
<inv...@invalid.invalid> wrote:

>Jan Panteltje wrote:
>> On a sunny day (Fri, 12 Apr 2013 13:41:18 -0700) it happened Joerg
>> <inv...@invalid.invalid> wrote in <asr9rn...@mid.individual.net>:
>>
>>>>> So where is the requirement "high accuracy" in there?
>>>> Implied as obvious from 'would not trust 10 seconds RC'
>>>> 10 seconds RC IS inaccurate, and the opposite of accurate,
>>>> at least on my planet,
>>>>
>>> With an electrolytic in there you can have +80/-20% or so tolerance.
>>
>> Bad electrolitics
>>
>
>Pretty standard. You need to get out more ...

For timing, low leakage aluminum electrolytics are typically +/-20%.

Good for high volume designs- quite cheap you can keep the impedances
reasonably low on the board by using 100uF or 220uF cap and 50-100K.
>

The manual is probably going to tell the user to hold it for 10
seconds even if it takes 5 seconds to reset, since many people are not
all that good at judging time.


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

[Jim Thompson]

On Fri, 12 Apr 2013 18:24:35 -0400, Spehro Pefhany
<spef...@interlogDOTyou.knowwhat> wrote:

>On Fri, 12 Apr 2013 14:49:10 -0700, the renowned Joerg
><inv...@invalid.invalid> wrote:
>
>>Jan Panteltje wrote:
>>> On a sunny day (Fri, 12 Apr 2013 13:41:18 -0700) it happened Joerg
>>> <inv...@invalid.invalid> wrote in <asr9rn...@mid.individual.net>:
>>>
>>>>>> So where is the requirement "high accuracy" in there?
>>>>> Implied as obvious from 'would not trust 10 seconds RC'
>>>>> 10 seconds RC IS inaccurate, and the opposite of accurate,
>>>>> at least on my planet,
>>>>>
>>>> With an electrolytic in there you can have +80/-20% or so tolerance.
>>>
>>> Bad electrolitics
>>>
>>
>>Pretty standard. You need to get out more ...
>
>For timing, low leakage aluminum electrolytics are typically +/-20%.
>
>Good for high volume designs- quite cheap you can keep the impedances
>reasonably low on the board by using 100uF or 220uF cap and 50-100K.
>>
>
>The manual is probably going to tell the user to hold it for 10
>seconds even if it takes 5 seconds to reset, since many people are not
>all that good at judging time.
>
>
>Best regards,
>Spehro Pefhany

Design it so that an LED blinks upon reset activation, then tell user
to hold button down until blink is observed.

[Spehro Pefhany]

On Fri, 12 Apr 2013 07:37:30 -0600, the renowned hamilton
<hami...@nothere.com> wrote:

>On 4/11/2013 9:04 PM, Spehro Pefhany wrote:
>> On Thu, 11 Apr 2013 21:38:24 -0500, the renowned Vladimir Vassilevsky
>> <nos...@nowhere.com> wrote:
>>
>>>
>>> In modern electronic gadgets, quite often, a pushbutton has some
>>> function and a hardware reset functionality. If you tap a pushbutton, it
>>> activates a function. If you press and hold the pushbutton for about 10
>>> seconds, it acts as hardware reset.
>>>

>>> I wonder what is the schematics for that. Should be super simple and
>>> cheap. I would not trust R-C for 10 second delays. An oscillator with
>>> divider logic would be bulky. Is there a specialized IC for that purpose?
>>>

>>> Vladimir Vassilevsky
>>> DSP and Mixed Signal Designs
>>> www.abvolt.com
>>

>> STM6519?
>>
>> There look to be others. You could also use a microcontroller,
>> perhaps.
>>
>>
>>
>> Best regards,
>> Spehro Pefhany
>>
>
>Digikey has STM6519 for $0.97 for one unit, .675 for 100
> 10f204 for $0.65 for one unit, .38 for 100
>
>How many do you need for your products ?

You might need to add a reset circuit for the 10F204 itself. It
doesn't even have nominal BOR.

[Spehro Pefhany]

That's a good suggestion.. usually the device goes dark after the
button is held, so the user gets feedback.

[Jim Thompson]

On Fri, 12 Apr 2013 18:50:05 -0400, Spehro Pefhany

Something around here does just that, but it took me a few head
scratches before I remembered... programming the cable remote...
blinks twice when it's done.

[Jasen Betts]

On 2013-04-12, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>
> In modern electronic gadgets, quite often, a pushbutton has some
> function and a hardware reset functionality. If you tap a pushbutton, it
> activates a function. If you press and hold the pushbutton for about 10
> seconds, it acts as hardware reset.
>
> I wonder what is the schematics for that. Should be super simple and
> cheap. I would not trust R-C for 10 second delays.

Why not? 10uF and a 555 (or something else that triggers near
2/3 VCC ) do you need high precision in this application ?
all these parts are available as in small-ish surface mount parts
the cap in 0805 (2mm x 1.2mm) the 555 in sizes down below 2mm square
if your're short of space

you could possibly use a TL431 instead of the 555 it depends on
on the voltage needed for reset and how much current the 431
needs on the ref pin. I've got some TL431's but I can't find them at
the moment.

> An oscillator with
> divider logic would be bulky. Is there a specialized IC for that purpose?

Oscillator with divider? 4060

reset chip? digikey has these:

http://www.fairchildsemi.com/ds/FT/FT3001.pdf

--
⚂⚃ 100% natural

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Jim Thompson]

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 ;-)

[Joerg]

Spehro Pefhany wrote:
> On Fri, 12 Apr 2013 14:49:10 -0700, the renowned Joerg
> <inv...@invalid.invalid> wrote:
>
>> Jan Panteltje wrote:
>>> On a sunny day (Fri, 12 Apr 2013 13:41:18 -0700) it happened Joerg
>>> <inv...@invalid.invalid> wrote in <asr9rn...@mid.individual.net>:
>>>
>>>>>> So where is the requirement "high accuracy" in there?
>>>>> Implied as obvious from 'would not trust 10 seconds RC'
>>>>> 10 seconds RC IS inaccurate, and the opposite of accurate,
>>>>> at least on my planet,
>>>>>
>>>> With an electrolytic in there you can have +80/-20% or so tolerance.
>>> Bad electrolitics
>>>
>> Pretty standard. You need to get out more ...
>
> For timing, low leakage aluminum electrolytics are typically +/-20%.
>
> Good for high volume designs- quite cheap you can keep the impedances
> reasonably low on the board by using 100uF or 220uF cap and 50-100K.
>

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 ...

> The manual is probably going to tell the user to hold it for 10
> seconds even if it takes 5 seconds to reset, since many people are not
> all that good at judging time.
>

For New Yorkers they better suggest 20 seconds :-)

[rickman]

On 4/12/2013 11:26 AM, Vladimir Vassilevsky wrote:
> On 4/12/2013 12:04 AM, Tim Wescott wrote:
>> On Thu, 11 Apr 2013 22:31:15 -0500, Vladimir Vassilevsky wrote:
>>
>>> On 4/11/2013 10:04 PM, Spehro Pefhany wrote:
>>>> On Thu, 11 Apr 2013 21:38:24 -0500, the renowned Vladimir Vassilevsky

>>>> <nos...@nowhere.com> wrote:
>>>>
>>>>
>>>>> In modern electronic gadgets, quite often, a pushbutton has some
>>>>> function and a hardware reset functionality. If you tap a pushbutton,
>>>>> it activates a function. If you press and hold the pushbutton for
>>>>> about 10 seconds, it acts as hardware reset.
>>>>>
>>>>> I wonder what is the schematics for that. Should be super simple and

>>>>> cheap. I would not trust R-C for 10 second delays. An oscillator with

>>>>> divider logic would be bulky. Is there a specialized IC for that
>>>>> purpose?
>>>>>
>>>>>
>>>

>>>> STM6519?
>>>> There look to be others.
>>>

>>> Thanks, that's exactly it.
>>>

>>>> You could also use a microcontroller, perhaps.
>>>

>>> MCU is just another part that has to be programmed and tested. And it is
>>> prone to hangups, too.
>>

>> One could use an 8-pin (or 6-pin) processor whose entire job in life is
>> to generate that reset pulse. That would at least minimize the number of
>> lines of code for a bug to hide in.

>
> Every other programmable component on the assembly is PITA for
> manufacturing. As it has to be programmed (loaded with software) and
> tested. And then there is always a question if this revision of MCU

> software is compatible with PCB revision X and FPGA revision Y, etc, etc.

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

[rickman]

On 4/12/2013 7:55 PM, Joerg wrote:

> Spehro Pefhany wrote:
>
>> The manual is probably going to tell the user to hold it for 10
>> seconds even if it takes 5 seconds to reset, since many people are not
>> all that good at judging time.
>>
>
> For New Yorkers they better suggest 20 seconds :-)

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

[rickman]

On 4/12/2013 1:57 PM, Tim Wescott wrote:
> On Fri, 12 Apr 2013 15:35:21 +0000, Jan Panteltje wrote:
>
>> On a sunny day (Fri, 12 Apr 2013 10:26:45 -0500) it happened Vladimir
>> Vassilevsky<nos...@nowhere.com> wrote in
>> <rLidnWMLpOsyuvXM...@giganews.com>:
>>
>>> Every other programmable component on the assembly is PITA for
>>> manufacturing. As it has to be programmed (loaded with software) and
>>> tested. And then there is always a question if this revision of MCU
>>> software is compatible with PCB revision X and FPGA revision Ycetc, etc.
>>
>> Come on, if you have a FPGA on board use a counter in that.
>
> In spite of me tweaking him with the notion of a six-pin processor,
> Vladimir has a very valid point: there are some functions that you'd just
> as soon leave in hardware rather than software.
>
> One may, on a design-by-design basis, review these decisions. But that
> doesn't mean that there isn't a valid place for what he's asking.

How do you know the reset chip you bought isn't an MCU with a private label?

--

Rick

[rickman]

On 4/12/2013 11:36 AM, Vladimir Vassilevsky wrote:
> On 4/12/2013 5:44 AM, Jan Panteltje wrote:
>> On a sunny day (Thu, 11 Apr 2013 22:31:15 -0500) it happened Vladimir
>> Vassilevsky <nos...@nowhere.com> wrote in
>> <HOidnXDigqxk4vrM...@giganews.com>:

>>
>>> On 4/11/2013 10:04 PM, Spehro Pefhany wrote:
>>>> On Thu, 11 Apr 2013 21:38:24 -0500, the renowned Vladimir Vassilevsky
>>>> <nos...@nowhere.com> wrote:
>>>>
>>>>>
>>>>> In modern electronic gadgets, quite often, a pushbutton has some
>>>>> function and a hardware reset functionality. If you tap a
>>>>> pushbutton, it
>>>>> activates a function. If you press and hold the pushbutton for
>>>>> about 10
>>>>> seconds, it acts as hardware reset.
>>>>>
>>>>> I wonder what is the schematics for that. Should be super simple and
>>>>> cheap. I would not trust R-C for 10 second delays. An oscillator with
>>>>> divider logic would be bulky. Is there a specialized IC for that
>>>>> purpose?
>>>>>
>>>
>>>>
>>>> STM6519?
>>>> There look to be others.
>>>
>>> Thanks, that's exactly it.
>>>
>>>> You could also use a microcontroller,
>>>> perhaps.
>>>
>>> MCU is just another part that has to be programmed and tested. And it is
>>> prone to hangups, too.
>>

>> Only if your code makes it do that ;-)
>

> Uhm, no.
>
> Take a screwdriver and poke with it around a microcontroller. After some
> time of poking, the micro will hang up till powerdown. It is no matter
> how good is your code and how good is schematics and layout; despite of
> all watchdogs and supervisors.

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

[Spehro Pefhany]

On Wed, 17 Apr 2013 13:22:17 -0400, rickman <gnu...@gmail.com> wrote:

>
>
>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.

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.

[Joerg]

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 :-)

[rickman]

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

[rickman]

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

[Spehro Pefhany]

On Wed, 17 Apr 2013 16:04:51 -0400, rickman <gnu...@gmail.com> wrote:

>On 4/17/2013 2:19 PM, Spehro Pefhany wrote:
>> On Wed, 17 Apr 2013 13:22:17 -0400, rickman<gnu...@gmail.com> wrote:
>>
>>>
>>>
>>> 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.
>>
>> 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.
>
>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.

I'm just saying that, in general, a PLD requires a reliable reset
signal just as a microcontroller does.

[Allan Herriman]

On Wed, 17 Apr 2013 13:22:17 -0400, rickman wrote:

[snip]

> 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.

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:
http://www.xilinx.com/support/answers/21870.htm
(The answer record says it happens on an address setup or hold time
violation, but I know from experience that it can happen if the clock has
a glitch, in my case caused by being connected to a DCM that generated an
out of spec clock while it was locking. Apart from that, my design was
fully synchronous and passed STA.)

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

[rickman]

On 4/18/2013 8:29 AM, Allan Herriman wrote:
> On Wed, 17 Apr 2013 13:22:17 -0400, rickman wrote:
>
> [snip]
>> 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.
>
> 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?

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...

> 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:
> http://www.xilinx.com/support/answers/21870.htm
> (The answer record says it happens on an address setup or hold time
> violation, but I know from experience that it can happen if the clock has
> a glitch, in my case caused by being connected to a DCM that generated an
> out of spec clock while it was locking. Apart from that, my design was
> fully synchronous and passed STA.)
>
> 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.

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

[Allan Herriman]

On Thu, 18 Apr 2013 17:36:35 -0400, rickman wrote:

> On 4/18/2013 8:29 AM, Allan Herriman wrote:
>> On Wed, 17 Apr 2013 13:22:17 -0400, rickman wrote:
>>
>> [snip]
>>> 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.
>>
>> 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?
>
> 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...

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.

>> 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:
>> http://www.xilinx.com/support/answers/21870.htm (The answer record says
>> it happens on an address setup or hold time violation, but I know from
>> experience that it can happen if the clock has a glitch, in my case
>> caused by being connected to a DCM that generated an out of spec clock
>> while it was locking. Apart from that, my design was fully synchronous
>> and passed STA.)
>>
>> 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.
>
> 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...

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.

> 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?

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.

> 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.

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

[rickman]

On 4/19/2013 8:25 AM, Allan Herriman wrote:
> On Thu, 18 Apr 2013 17:36:35 -0400, rickman wrote:
>
>> On 4/18/2013 8:29 AM, Allan Herriman wrote:
>>>
>>> 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?
>>
>> 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...
>
> 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.

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?

>>> 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:
>>> http://www.xilinx.com/support/answers/21870.htm (The answer record says
>>> it happens on an address setup or hold time violation, but I know from
>>> experience that it can happen if the clock has a glitch, in my case
>>> caused by being connected to a DCM that generated an out of spec clock
>>> while it was locking. Apart from that, my design was fully synchronous
>>> and passed STA.)
>>>
>>> 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.
>>
>> 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...
>
>
> There are a few ways to deal with it:
>
> - don't use RAMs as ROMs.

That's not a very good one... :(

> - keep the CE input inactive whenever the clock can glitch

Ok, that makes good sense!

> - use a BUFGMUX / BUFGCE (etc) on the output of a DCM to mute potential
> clock glitches

Yes, I anticipated that.

> - detect corruption and somehow restore the contents, perhaps by
> reloading the FPGA.

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.

> 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.

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.

>> 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?
>
> 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.

I remember hearing warnings about the output of the DCMs being "invalid"
until locked. I never heard about such serious downstream impacts.

>> 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.
>
> 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.)

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

[josephkk]

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.

?-)

[kilowatt]

On Thursday, April 11, 2013 7:38:24 PM UTC-7, Vladimir Vassilevsky wrote:
> In modern electronic gadgets, quite often, a pushbutton has some
>
> function and a hardware reset functionality. If you tap a pushbutton, it
>
> activates a function. If you press and hold the pushbutton for about 10
>
> seconds, it acts as hardware reset.
>
>
>
> I wonder what is the schematics for that. Should be super simple and
>
> cheap. I would not trust R-C for 10 second delays. An oscillator with
>
> divider logic would be bulky. Is there a specialized IC for that purpose?
>
>
>

> Vladimir Vassilevsky
>
> DSP and Mixed Signal Designs
>
> www.abvolt.com

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 10 seconds. Fun to work with too.