f



A spectre is haunting this newsgroup, the spectre of metastability

To paraphrase Karl Marx:
A spectre is haunting this newsgroup, the spectre of metastability.
Whenever something works unreliably, metastability gets the blame. But
the problem is usually elsewhere.

Metastability causes a non-deterministic extra output delay, when a
flip-flop's D input changes asynchronously, and happens to change
within an extremely narrow capture window (a tiny fraction of a
femtosecond !). This capture window is located at an unknown (and
unstable) point somewhere within the set-up time window specified in
the data sheet. The capture window is billions of times smaller than
the specified set-up time window. The likelihood of a flip-flop going
metastable is thus extremely small. The likelihood of a metastable
delay longer than 3 ns is even less.
As an example, a 1 MHz asynchronous signal, synchronized by a 100 MHz
clock, causes an extra 3 ns delay statistically once every billion
years. If the asynchronous event is at 10 MHz, the 3 ns delay occurs
ten times more often, once every 100 million years.
But a 2.5 ns delay happens a million times more often !
See the Xilinx application note XAPP094
You should worry about metastability only when the clock frequency is
so high that a few ns of extra delay out of the synchronizer flip-flop
might causes failure. The recommended standard procedure,
double-synchronizing in two close-by flip-flops, solves those cases.
Try to avoid clocking synchronizers at 500 MHz or more...
So much about metastability.

The real cause of problems is often the typical mistake, when a
designer feeds an asynchronous input signal to more than one
synchronizer flip-flop in parallel, (or an asynchronous byte to a
register, without additional handshake) in the mistaken believe that
all these flip-flops will synchronize the input on the same identical
clock edge.
This might work occasionally, but sooner or later subtle difference in
routing delay or set-up times will make one flip-flop use one clock
edge, and another flip-flop use the next clock edge. Depending on the
specific design, this might cause a severe malfunction.
Rule #1: Never feed an asynchronous input into more than one
synchronizer flip-flop. Never ever.

Peter Alfke

0
Peter
10/27/2006 9:25:09 PM
comp.arch.fpga 18587 articles. 2 followers. Post Follow

38 Replies
2383 Views

Similar Articles

[PageSpeed] 36

Applause!!!
0
Ben
10/27/2006 10:04:30 PM
Peter Alfke wrote:
> To paraphrase Karl Marx:
> A spectre is haunting this newsgroup, the spectre of metastability.
> Whenever something works unreliably, metastability gets the blame. But
> the problem is usually elsewhere.
> 
> Metastability causes a non-deterministic extra output delay, when a
> flip-flop's D input changes asynchronously, and happens to change
> within an extremely narrow capture window (a tiny fraction of a
> femtosecond !). This capture window is located at an unknown (and
> unstable) point somewhere within the set-up time window specified in
> the data sheet. The capture window is billions of times smaller than
> the specified set-up time window. The likelihood of a flip-flop going
> metastable is thus extremely small. The likelihood of a metastable
> delay longer than 3 ns is even less.
> As an example, a 1 MHz asynchronous signal, synchronized by a 100 MHz
> clock, causes an extra 3 ns delay statistically once every billion
> years. If the asynchronous event is at 10 MHz, the 3 ns delay occurs
> ten times more often, once every 100 million years.
> But a 2.5 ns delay happens a million times more often !
> See the Xilinx application note XAPP094
> You should worry about metastability only when the clock frequency is
> so high that a few ns of extra delay out of the synchronizer flip-flop
> might causes failure. The recommended standard procedure,
> double-synchronizing in two close-by flip-flops, solves those cases.
> Try to avoid clocking synchronizers at 500 MHz or more...
> So much about metastability.
> 
> The real cause of problems is often the typical mistake, when a
> designer feeds an asynchronous input signal to more than one
> synchronizer flip-flop in parallel, (or an asynchronous byte to a
> register, without additional handshake) in the mistaken believe that
> all these flip-flops will synchronize the input on the same identical
> clock edge.
> This might work occasionally, but sooner or later subtle difference in
> routing delay or set-up times will make one flip-flop use one clock
> edge, and another flip-flop use the next clock edge. Depending on the
> specific design, this might cause a severe malfunction.
> Rule #1: Never feed an asynchronous input into more than one
> synchronizer flip-flop. Never ever.
> 
> Peter Alfke
> 

First, I fully agree that metastability is a very rare issue, and if it 
_does_ occur, it is because the designer has not guarded against it. Yes 
- the designer has a responsibility to meet the setup and hold times 
(which will help prevent such issues).

Second, metastability, as a potential problem, _does_ exist in any FF 
based system, by definition. See point number 1.

So I agree with Peter Afke on this. I understand why the thread was 
named that way too :)

I've noticed the large number of recent threads 'blaming' purported 
metastability issues for problems, but at (for instance) 10MHz, a 
metastability issue would only show up in the occasional few million or 
so transactions (at an absolute maximum, and then only a few times at 
that rate).

So if there's a problem with your design throwing bad data at a rate of 
1 in a million or so, check your timing. It's highly unlikely to be 
metastability.

I have had *true* metastable problems (where an output would float, 
hover, oscillate and eventually settle after some 10s of 
*milliseconds*), but those I have seen recently don't qualify :)

Cheers

PeteS


0
PeteS
10/27/2006 10:09:00 PM
On 27 Oct 2006 14:25:09 -0700, "Peter Alfke" <peter@xilinx.com> wrote:

>To paraphrase Karl Marx:
>A spectre is haunting this newsgroup, the spectre of metastability.
>Whenever something works unreliably, metastability gets the blame. But
>the problem is usually elsewhere.

In my experience, ground bounce is a bigger problem.
Especially in a device that is nearly 'full' it is
wise to invest in a few fabricated grounds (dedicate
a pin at a strategic location, i.e. as far away as
possible from other ground pins, drive it to ground,
and tie it to ground externally).

When you find that moving cells around alleviates or
intensifies observed instabilities, you may want to
look into ground bounce problems.

>Metastability causes a non-deterministic extra output delay, when a
>flip-flop's D input changes asynchronously, and happens to change
>within an extremely narrow capture window (a tiny fraction of a
>femtosecond !). This capture window is located at an unknown (and
>unstable) point somewhere within the set-up time window specified in
>the data sheet. The capture window is billions of times smaller than
>the specified set-up time window. The likelihood of a flip-flop going
>metastable is thus extremely small. The likelihood of a metastable
>delay longer than 3 ns is even less.
>As an example, a 1 MHz asynchronous signal, synchronized by a 100 MHz
>clock, causes an extra 3 ns delay statistically once every billion
>years. If the asynchronous event is at 10 MHz, the 3 ns delay occurs
>ten times more often, once every 100 million years.
>But a 2.5 ns delay happens a million times more often !
>See the Xilinx application note XAPP094
>You should worry about metastability only when the clock frequency is
>so high that a few ns of extra delay out of the synchronizer flip-flop
>might causes failure. The recommended standard procedure,
>double-synchronizing in two close-by flip-flops, solves those cases.

I've found that one synchronizing flip-flop was not enough
in one particular case (from a 4-ish to 50-ish MHz domain).
Two was. Does one ever work reliably ? Or has the 'window'
become smaller in the past few years ?


John Kortink
Windfall Engineering

-- 

Email    : kortink@inter.nl.net
Homepage : http://www.windfall.nl

Your hardware/software designs realised !

0
John
10/27/2006 10:24:48 PM
PeteS wrote:

> 
> I have had *true* metastable problems (where an output would float, 
> hover, oscillate and eventually settle after some 10s of 
> *milliseconds*), but those I have seen recently don't qualify :)

Can you clarify the device/process/circumstances ?

-jg

0
Jim
10/27/2006 10:48:40 PM
Jim Granville wrote:
> PeteS wrote:
> 
>>
>> I have had *true* metastable problems (where an output would float, 
>> hover, oscillate and eventually settle after some 10s of 
>> *milliseconds*), but those I have seen recently don't qualify :)
> 
> 
> Can you clarify the device/process/circumstances ?
> 
> -jg
> 

This was a discrete design with FETs that I was asked to test (at a 
customer site). The feedback loop was not particularly well done, so 
when metastability did occur, it was spectacular.

Cheers

PeteS
0
PeteS
10/27/2006 10:52:58 PM
PeteS wrote:
> Jim Granville wrote:
> 
>> PeteS wrote:
>>
>>>
>>> I have had *true* metastable problems (where an output would float, 
>>> hover, oscillate and eventually settle after some 10s of 
>>> *milliseconds*), but those I have seen recently don't qualify :)
>>
>> Can you clarify the device/process/circumstances ?
>>
>> -jg
>>
> 
> This was a discrete design with FETs that I was asked to test (at a 
> customer site). The feedback loop was not particularly well done, so 
> when metastability did occur, it was spectacular.

Do you mean they built a D-FF, using discrete FETS ?!

I have seen transistion oscillations (slow edges) cause very strange 
effects in Digital Devices, but I'd not call that effect metastability.

-jg

0
Jim
10/27/2006 11:53:25 PM
Well, in the beginning of my professional life, I built flip-flops out
of two Ge transistors, 8 resistors, two diodes and two capacitors.
Remember, the term J-K flip-flop comes from a standardized sinle-FF
pc-board where the connector oins were labeled A-Z, and the set and
reset inputs were on the adjacent central pins J and K.
Not a joke...
Peter Alfke

On Oct 27, 4:53 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> PeteS wrote:
> > Jim Granville wrote:
>
> >> PeteS wrote:
>
> >>> I have had *true* metastable problems (where an output would float,
> >>> hover, oscillate and eventually settle after some 10s of
> >>> *milliseconds*), but those I have seen recently don't qualify :)
>
> >> Can you clarify the device/process/circumstances ?
>
> >> -jg
>
> > This was a discrete design with FETs that I was asked to test (at a
> > customer site). The feedback loop was not particularly well done, so
> > when metastability did occur, it was spectacular.Do you mean they built a D-FF, using discrete FETS ?!
>
> I have seen transistion oscillations (slow edges) cause very strange
> effects in Digital Devices, but I'd not call that effect metastability.
> 
> -jg

0
Peter
10/28/2006 12:32:55 AM
Peter Alfke wrote:
> Well, in the beginning of my professional life, I built flip-flops out
> of two Ge transistors, 8 resistors, two diodes and two capacitors.
> Remember, the term J-K flip-flop comes from a standardized sinle-FF
> pc-board where the connector oins were labeled A-Z, and the set and
> reset inputs were on the adjacent central pins J and K.
> Not a joke...
> Peter Alfke
> 
> On Oct 27, 4:53 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
> 
>>PeteS wrote:
>>
>>>Jim Granville wrote:
>>
>>>>PeteS wrote:
>>
>>>>>I have had *true* metastable problems (where an output would float,
>>>>>hover, oscillate and eventually settle after some 10s of
>>>>>*milliseconds*), but those I have seen recently don't qualify :)
>>
>>>>Can you clarify the device/process/circumstances ?
>>
>>>>-jg
>>
>>>This was a discrete design with FETs that I was asked to test (at a
>>>customer site). The feedback loop was not particularly well done, so
>>>when metastability did occur, it was spectacular.Do you mean they built a D-FF, using discrete FETS ?!
>>
>>I have seen transistion oscillations (slow edges) cause very strange
>>effects in Digital Devices, but I'd not call that effect metastability.
>>
>>-jg
> 
> 

Amusing

I too have made flip flops from discrete parts in the distant past. The 
metastable problem I encountered was due to slow rising inputs on pure 
CMOS (a well known issue) and was indeed part of the feedback path.

I remember making a D FF using discrete parts only a few years ago 
because it had to operate at up to 30VDC. I had to put all the usual 
warnings on the schematic page about setup/hold times etc.

There are times when the knowledge of just what a FF (be it JK, D or 
M/S) is comes in _real_ handy.

Cheers

PeteS
0
PeteS
10/28/2006 7:02:26 PM
We had a discussion at lunch, about the future when us dinosaurs are
gone.
Who will then understand those subtleties, only the tiny cadre of IC
designers?
Many new college graduates' eyes glaze over when I ask them about the
way a flip-flop works, and how it avoids a race condition in a shift
register. And clock skew and hold-time issues.
Hard-earned "wisdom"...
Peter Alfke

On Oct 28, 12:02 pm, PeteS <peter.smith8...@ntlworld.com> wrote:
> Peter Alfke wrote:
> > Well, in the beginning of my professional life, I built flip-flops out
> > of two Ge transistors, 8 resistors, two diodes and two capacitors.
> > Remember, the term J-K flip-flop comes from a standardized sinle-FF
> > pc-board where the connector oins were labeled A-Z, and the set and
> > reset inputs were on the adjacent central pins J and K.
> > Not a joke...
> > Peter Alfke
>
> > On Oct 27, 4:53 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> > wrote:
>
> >>PeteS wrote:
>
> >>>Jim Granville wrote:
>
> >>>>PeteS wrote:
>
> >>>>>I have had *true* metastable problems (where an output would float,
> >>>>>hover, oscillate and eventually settle after some 10s of
> >>>>>*milliseconds*), but those I have seen recently don't qualify :)
>
> >>>>Can you clarify the device/process/circumstances ?
>
> >>>>-jg
>
> >>>This was a discrete design with FETs that I was asked to test (at a
> >>>customer site). The feedback loop was not particularly well done, so
> >>>when metastability did occur, it was spectacular.Do you mean they built a D-FF, using discrete FETS ?!
>
> >>I have seen transistion oscillations (slow edges) cause very strange
> >>effects in Digital Devices, but I'd not call that effect metastability.
>
> >>-jgAmusing
>
> I too have made flip flops from discrete parts in the distant past. The
> metastable problem I encountered was due to slow rising inputs on pure
> CMOS (a well known issue) and was indeed part of the feedback path.
>
> I remember making a D FF using discrete parts only a few years ago
> because it had to operate at up to 30VDC. I had to put all the usual
> warnings on the schematic page about setup/hold times etc.
>
> There are times when the knowledge of just what a FF (be it JK, D or
> M/S) is comes in _real_ handy.
> 
> Cheers
> 
> PeteS

0
Peter
10/28/2006 9:03:23 PM
Peter Alfke wrote:
> We had a discussion at lunch, about the future when us dinosaurs are
> gone.
> Who will then understand those subtleties, only the tiny cadre of IC
> designers?
> Many new college graduates' eyes glaze over when I ask them about the
> way a flip-flop works, and how it avoids a race condition in a shift
> register. And clock skew and hold-time issues.
> Hard-earned "wisdom"...
> Peter Alfke
> 
> On Oct 28, 12:02 pm, PeteS <peter.smith8...@ntlworld.com> wrote:
> 
>>Peter Alfke wrote:
>>
>>>Well, in the beginning of my professional life, I built flip-flops out
>>>of two Ge transistors, 8 resistors, two diodes and two capacitors.
>>>Remember, the term J-K flip-flop comes from a standardized sinle-FF
>>>pc-board where the connector oins were labeled A-Z, and the set and
>>>reset inputs were on the adjacent central pins J and K.
>>>Not a joke...
>>>Peter Alfke
>>
>>>On Oct 27, 4:53 pm, Jim Granville <no.s...@designtools.maps.co.nz>
>>>wrote:
>>
>>>>PeteS wrote:
>>
>>>>>Jim Granville wrote:
>>
>>>>>>PeteS wrote:
>>
>>>>>>>I have had *true* metastable problems (where an output would float,
>>>>>>>hover, oscillate and eventually settle after some 10s of
>>>>>>>*milliseconds*), but those I have seen recently don't qualify :)
>>
>>>>>>Can you clarify the device/process/circumstances ?
>>
>>>>>>-jg
>>
>>>>>This was a discrete design with FETs that I was asked to test (at a
>>>>>customer site). The feedback loop was not particularly well done, so
>>>>>when metastability did occur, it was spectacular.Do you mean they built a D-FF, using discrete FETS ?!
>>
>>>>I have seen transistion oscillations (slow edges) cause very strange
>>>>effects in Digital Devices, but I'd not call that effect metastability.
>>
>>>>-jgAmusing
>>
>>I too have made flip flops from discrete parts in the distant past. The
>>metastable problem I encountered was due to slow rising inputs on pure
>>CMOS (a well known issue) and was indeed part of the feedback path.
>>
>>I remember making a D FF using discrete parts only a few years ago
>>because it had to operate at up to 30VDC. I had to put all the usual
>>warnings on the schematic page about setup/hold times etc.
>>
>>There are times when the knowledge of just what a FF (be it JK, D or
>>M/S) is comes in _real_ handy.
>>
>>Cheers
>>
>>PeteS
> 
> 

Well, I am not an IC designer (well, not regularly). Perhaps the answer 
is education - real education. The new crowd doesn't seem to understand 
the fundamentals that are key to successful design of any type be it IC, 
board level or any other.

Like the other dinosaurs, I've seen and done things most youngsters 
don't even consider, but the youngsters that have been around when *I 
did them* were awed, and they wanted to learn, so I think there's hope.


I am sure the youngsters that were around when *you* have done 
astounding things (to them) were awed too. Perhaps it's a matter of 
making sure they understand the limitations of their current knowledge :)

It's different in a way - we were *figuring out* what made things work; 
nowadays it's taken for granted. We need to make sure the kids 
understand that this knowledge is key to successful design.

Cheers

PeteS
0
PeteS
10/28/2006 9:50:05 PM
Peter Alfke wrote:
> We had a discussion at lunch, about the future when us dinosaurs are
> gone.
> Who will then understand those subtleties, only the tiny cadre of IC
> designers?
> Many new college graduates' eyes glaze over when I ask them about the
> way a flip-flop works, and how it avoids a race condition in a shift
> register. And clock skew and hold-time issues.
> Hard-earned "wisdom"...
> Peter Alfke
> 
> On Oct 28, 12:02 pm, PeteS <peter.smith8...@ntlworld.com> wrote:
> 
>>Peter Alfke wrote:
>>
>>>Well, in the beginning of my professional life, I built flip-flops out
>>>of two Ge transistors, 8 resistors, two diodes and two capacitors.
>>>Remember, the term J-K flip-flop comes from a standardized sinle-FF
>>>pc-board where the connector oins were labeled A-Z, and the set and
>>>reset inputs were on the adjacent central pins J and K.
>>>Not a joke...
>>>Peter Alfke
>>
>>>On Oct 27, 4:53 pm, Jim Granville <no.s...@designtools.maps.co.nz>
>>>wrote:
>>
>>>>PeteS wrote:
>>
>>>>>Jim Granville wrote:
>>
>>>>>>PeteS wrote:
>>
>>>>>>>I have had *true* metastable problems (where an output would float,
>>>>>>>hover, oscillate and eventually settle after some 10s of
>>>>>>>*milliseconds*), but those I have seen recently don't qualify :)
>>
>>>>>>Can you clarify the device/process/circumstances ?
>>
>>>>>>-jg
>>
>>>>>This was a discrete design with FETs that I was asked to test (at a
>>>>>customer site). The feedback loop was not particularly well done, so
>>>>>when metastability did occur, it was spectacular.Do you mean they built a D-FF, using discrete FETS ?!
>>
>>>>I have seen transistion oscillations (slow edges) cause very strange
>>>>effects in Digital Devices, but I'd not call that effect metastability.
>>
>>>>-jgAmusing
>>
>>I too have made flip flops from discrete parts in the distant past. The
>>metastable problem I encountered was due to slow rising inputs on pure
>>CMOS (a well known issue) and was indeed part of the feedback path.
>>
>>I remember making a D FF using discrete parts only a few years ago
>>because it had to operate at up to 30VDC. I had to put all the usual
>>warnings on the schematic page about setup/hold times etc.
>>
>>There are times when the knowledge of just what a FF (be it JK, D or
>>M/S) is comes in _real_ handy.
>>
>>Cheers
>>
>>PeteS
> 
> 

There was a TV show perhaps 20 years ago the name of which I do not 
remember. In it, the computer that ran the spacecraft (named Mentor 
because the female of the group had thought the name) refused to give 
information about using the transporter system.

It said 'Wisdom is earned, not given'

Cheers

PeteS
0
PeteS
10/28/2006 10:24:03 PM
There is a difference, 60 years ago, a curious kid could at least try
to understand the world around him/her.
Clocks, carburators, telephones, radios, typewriters, etc.
Nowadays, these functions are black boxes that few people really
understand, let alone are able to repair.
Youngsters today can breathe life into a pc by hitting buttons in
mysterious sequences...
Do they really understand what they are doing or what's going on?
"If the engine stalls, roll down the window"  :-)

Here is a simple test, flunked by many engineers:
How can everybody smoothely adjust the heat of an electric stove, or a
steam iron ?
Hint: It is super-cheap, no Variac, no electronics. Smoke and mirrors?
Answer: it's slow pulse-width modulation, controlled by a self-heating
bimetal strip.
Cost: pennies...

Well, the older generation has bemoaned the superficiality of the
younger generation,
ever since Socrates did so, a hundred generations ago. Maybe there is
hope...
Peter Alfke


On Oct 28, 3:24 pm, PeteS <peter.smith8...@ntlworld.com> wrote:
> Peter Alfke wrote:
> > We had a discussion at lunch, about the future when us dinosaurs are
> > gone.
> > Who will then understand those subtleties, only the tiny cadre of IC
> > designers?
> > Many new college graduates' eyes glaze over when I ask them about the
> > way a flip-flop works, and how it avoids a race condition in a shift
> > register. And clock skew and hold-time issues.
> > Hard-earned "wisdom"...
> > Peter Alfke
>
> > On Oct 28, 12:02 pm, PeteS <peter.smith8...@ntlworld.com> wrote:
>
> >>Peter Alfke wrote:
>
> >>>Well, in the beginning of my professional life, I built flip-flops out
> >>>of two Ge transistors, 8 resistors, two diodes and two capacitors.
> >>>Remember, the term J-K flip-flop comes from a standardized sinle-FF
> >>>pc-board where the connector oins were labeled A-Z, and the set and
> >>>reset inputs were on the adjacent central pins J and K.
> >>>Not a joke...
> >>>Peter Alfke
>
> >>>On Oct 27, 4:53 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> >>>wrote:
>
> >>>>PeteS wrote:
>
> >>>>>Jim Granville wrote:
>
> >>>>>>PeteS wrote:
>
> >>>>>>>I have had *true* metastable problems (where an output would float,
> >>>>>>>hover, oscillate and eventually settle after some 10s of
> >>>>>>>*milliseconds*), but those I have seen recently don't qualify :)
>
> >>>>>>Can you clarify the device/process/circumstances ?
>
> >>>>>>-jg
>
> >>>>>This was a discrete design with FETs that I was asked to test (at a
> >>>>>customer site). The feedback loop was not particularly well done, so
> >>>>>when metastability did occur, it was spectacular.Do you mean they built a D-FF, using discrete FETS ?!
>
> >>>>I have seen transistion oscillations (slow edges) cause very strange
> >>>>effects in Digital Devices, but I'd not call that effect metastability.
>
> >>>>-jgAmusing
>
> >>I too have made flip flops from discrete parts in the distant past. The
> >>metastable problem I encountered was due to slow rising inputs on pure
> >>CMOS (a well known issue) and was indeed part of the feedback path.
>
> >>I remember making a D FF using discrete parts only a few years ago
> >>because it had to operate at up to 30VDC. I had to put all the usual
> >>warnings on the schematic page about setup/hold times etc.
>
> >>There are times when the knowledge of just what a FF (be it JK, D or
> >>M/S) is comes in _real_ handy.
>
> >>Cheers
>
> >>PeteSThere was a TV show perhaps 20 years ago the name of which I do not
> remember. In it, the computer that ran the spacecraft (named Mentor
> because the female of the group had thought the name) refused to give
> information about using the transporter system.
> 
> It said 'Wisdom is earned, not given'
> 
> Cheers
> 
> PeteS

0
Peter
10/29/2006 4:16:26 AM
Peter,

you're right that youngsters (my friends for example) don't know how
the computer really works despite the fact that they use it almost
every day. This secret is revealed only to the most curious youngsters
that devote their time to it. I am sure that there are still youngsters
which are willing to understand the secrets of a silicon brain. Now in
the in age of internet information is  easily available to anyone
connected, may it be a 6 years old kid or a 100 grandpa (no offence
Peter). The people with knowledge should be willing to give their
knowledge to the masses (p.e. publish it on the net), there will always
be someone that will accept it.
The problem is that a life is too short to explore all the interesting
things. When you explore things we usually begin at the surface of the
problem. Then you remove it layer by layer, like peeling an onion. What
to do when there are too many layers. Computer technology gains many
new layers every year (an exponential number according to moore's law).
I think that nobody can keep the pace with this layers. So at some
point you give up and study only the things you prefer. Youngsters are
familiar with games, so some learn how to make one. The others prefer
the secrets of operating system - they build OS. Some of them are
interested in HW - like most of us in this newsgroup. I for example am
a very curious mechanical engineer. When I got bored in mechanical
engineering, where the pace of development is nothing in comparison to
electronic industry, I also studied electronics. Now I prefer
electronics for a simple reason - it is far more complex hence gives me
much more satisfaction when learning.
Sometimes I realise that I am very weak in fundamentals, because I am
missing the lectures in fundamentals of electronics. To be honest I
don't have a clue what a "FF metastability" is and what is the cause of
it. BTW: What is an FF? I imagine it like a memory cell. Despite my
poor knowledge in fundamentals I am able to build very complex computer
systems, write software for it... How that can be? Well some people are
devoted to fundamentals, some to layer above that, the others to layer
above that layer and so on. At the end there are "normal" computer
users that do not want to know how the computer works, they just want
to use it for Word, games, watching movies...
I wouldn't worry about the passing the knowledge to youngsters. If
there will be a need for that knowledge they will learn it. So specific
knowledge is learned by a small group of people but the Word usage and
Email sending is learned by almost every youngster (in the Western
world!). That's an evolution.

Cheers,

Guru


Peter Alfke wrote:
> There is a difference, 60 years ago, a curious kid could at least try
> to understand the world around him/her.
> Clocks, carburators, telephones, radios, typewriters, etc.
> Nowadays, these functions are black boxes that few people really
> understand, let alone are able to repair.
> Youngsters today can breathe life into a pc by hitting buttons in
> mysterious sequences...
> Do they really understand what they are doing or what's going on?
> "If the engine stalls, roll down the window"  :-)
>
> Here is a simple test, flunked by many engineers:
> How can everybody smoothely adjust the heat of an electric stove, or a
> steam iron ?
> Hint: It is super-cheap, no Variac, no electronics. Smoke and mirrors?
> Answer: it's slow pulse-width modulation, controlled by a self-heating
> bimetal strip.
> Cost: pennies...
>
> Well, the older generation has bemoaned the superficiality of the
> younger generation,
> ever since Socrates did so, a hundred generations ago. Maybe there is
> hope...
> Peter Alfke
>
>
> On Oct 28, 3:24 pm, PeteS <peter.smith8...@ntlworld.com> wrote:
> > Peter Alfke wrote:
> > > We had a discussion at lunch, about the future when us dinosaurs are
> > > gone.
> > > Who will then understand those subtleties, only the tiny cadre of IC
> > > designers?
> > > Many new college graduates' eyes glaze over when I ask them about the
> > > way a flip-flop works, and how it avoids a race condition in a shift
> > > register. And clock skew and hold-time issues.
> > > Hard-earned "wisdom"...
> > > Peter Alfke
> >
> > > On Oct 28, 12:02 pm, PeteS <peter.smith8...@ntlworld.com> wrote:
> >
> > >>Peter Alfke wrote:
> >
> > >>>Well, in the beginning of my professional life, I built flip-flops out
> > >>>of two Ge transistors, 8 resistors, two diodes and two capacitors.
> > >>>Remember, the term J-K flip-flop comes from a standardized sinle-FF
> > >>>pc-board where the connector oins were labeled A-Z, and the set and
> > >>>reset inputs were on the adjacent central pins J and K.
> > >>>Not a joke...
> > >>>Peter Alfke
> >
> > >>>On Oct 27, 4:53 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> > >>>wrote:
> >
> > >>>>PeteS wrote:
> >
> > >>>>>Jim Granville wrote:
> >
> > >>>>>>PeteS wrote:
> >
> > >>>>>>>I have had *true* metastable problems (where an output would float,
> > >>>>>>>hover, oscillate and eventually settle after some 10s of
> > >>>>>>>*milliseconds*), but those I have seen recently don't qualify :)
> >
> > >>>>>>Can you clarify the device/process/circumstances ?
> >
> > >>>>>>-jg
> >
> > >>>>>This was a discrete design with FETs that I was asked to test (at a
> > >>>>>customer site). The feedback loop was not particularly well done, so
> > >>>>>when metastability did occur, it was spectacular.Do you mean they built a D-FF, using discrete FETS ?!
> >
> > >>>>I have seen transistion oscillations (slow edges) cause very strange
> > >>>>effects in Digital Devices, but I'd not call that effect metastability.
> >
> > >>>>-jgAmusing
> >
> > >>I too have made flip flops from discrete parts in the distant past. The
> > >>metastable problem I encountered was due to slow rising inputs on pure
> > >>CMOS (a well known issue) and was indeed part of the feedback path.
> >
> > >>I remember making a D FF using discrete parts only a few years ago
> > >>because it had to operate at up to 30VDC. I had to put all the usual
> > >>warnings on the schematic page about setup/hold times etc.
> >
> > >>There are times when the knowledge of just what a FF (be it JK, D or
> > >>M/S) is comes in _real_ handy.
> >
> > >>Cheers
> >
> > >>PeteSThere was a TV show perhaps 20 years ago the name of which I do not
> > remember. In it, the computer that ran the spacecraft (named Mentor
> > because the female of the group had thought the name) refused to give
> > information about using the transporter system.
> >
> > It said 'Wisdom is earned, not given'
> > 
> > Cheers
> > 
> > PeteS

0
Guru
10/29/2006 5:07:43 PM
Guru wrote:

> Then you remove it layer by layer, like peeling an onion. What
> to do when there are too many layers. Computer technology gains many
> new layers every year (an exponential number according to moore's law).

Moore's Law says that the transistor density of integrated circuits,
doubles every 24 months:

http://en.wikipedia.org/wiki/Moore%27s_Law

I think layers are increased more linear, maybe one every 5 years, like
when upgrading from DOS with direct hardware access to Windows, with an
intermediate layer for abstracting the hardware access, or from Intel 8086
to Intel 386, with many virtual 8086. So you can keep the pace with the
layers. You don't need to be an expert for every layer, but it is easy to
learn the basics about which layers exists, what they are doing and how
they interact with other layers.

It is more difficult to keep the pace with all the new components, like
PCIe, new WiFi standards etc., but usually they don't change the layers or
introduce new concepts. If PCs would be built with FPGAs instead of CPUs,
and if you start a game, which reconfigures a part of a FPGA at runtime to
implement special 3D shading algorithms in hardware, this would change many
concepts, because then you don't need to buy a new graphics card, but you
can install a new IP core to enhance the functionality and speed of your
graphics subsystem. If it is too slow, just plugin some more FPGAs and the
power is available for higher performance graphics, but when you need OCR,
the same FPGAs could be reconfigured with neuronal net algorithms to do
this at high speed.

There are already some serious applications to use the computational power
of shader engines of graphics cards, but most of the time they are idle,
when you are not playing games. Implementing an optimized CPU in FPGAs for
the current task would be much better.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
0
Frank
10/29/2006 6:19:50 PM
Frank, I was addressing a different issue:
That the knowledge base of the fundamental technology inevitably is
supported by fewer and fewer engineers, so that soon (now!) people will
manipulate and use technology that they really do not understand.
And that is a drastic change from 40 years ago.
I think you understand German, to appreciate Goethe's words:

Was du ererbt von Deinen V=E4tern hast,_
Erwirb es, um es zu besitzen!

Cheers
Peter



On Oct 29, 10:19 am, Frank Buss <f...@frank-buss.de> wrote:
> Guru wrote:
> > Then you remove it layer by layer, like peeling an onion. What
> > to do when there are too many layers. Computer technology gains many
> > new layers every year (an exponential number according to moore's law).=
Moore's Law says that the transistor density of integrated circuits,
> doubles every 24 months:
>
> http://en.wikipedia.org/wiki/Moore%27s_Law
>
> I think layers are increased more linear, maybe one every 5 years, like
> when upgrading from DOS with direct hardware access to Windows, with an
> intermediate layer for abstracting the hardware access, or from Intel 8086
> to Intel 386, with many virtual 8086. So you can keep the pace with the
> layers. You don't need to be an expert for every layer, but it is easy to
> learn the basics about which layers exists, what they are doing and how
> they interact with other layers.
>
> It is more difficult to keep the pace with all the new components, like
> PCIe, new WiFi standards etc., but usually they don't change the layers or
> introduce new concepts. If PCs would be built with FPGAs instead of CPUs,
> and if you start a game, which reconfigures a part of a FPGA at runtime to
> implement special 3D shading algorithms in hardware, this would change ma=
ny
> concepts, because then you don't need to buy a new graphics card, but you
> can install a new IP core to enhance the functionality and speed of your
> graphics subsystem. If it is too slow, just plugin some more FPGAs and the
> power is available for higher performance graphics, but when you need OCR,
> the same FPGAs could be reconfigured with neuronal net algorithms to do
> this at high speed.
>
> There are already some serious applications to use the computational power
> of shader engines of graphics cards, but most of the time they are idle,
> when you are not playing games. Implementing an optimized CPU in FPGAs for
> the current task would be much better.
>
> --
> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys=
tems.de

0
Peter
10/29/2006 7:20:43 PM
Peter Alfke wrote:

> That the knowledge base of the fundamental technology inevitably is
> supported by fewer and fewer engineers, so that soon (now!) people will
> manipulate and use technology that they really do not understand.

The good news: the fewer people know the basics, the more you can earn,
when a customer needs it :-)

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
0
Frank
10/29/2006 7:38:42 PM
"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:1162149643.159519.289870@i42g2000cwa.googlegroups.com...
> Frank, I was addressing a different issue:
> That the knowledge base of the fundamental technology inevitably is
> supported by fewer and fewer engineers,
But with a capitalistic economy one would expect that it will be supported 
by the proper number of engineers and if that number is 'small' than those 
few will earn more money than if there were a 'lot' of those engineers.  In 
any case, the appropriate amount of money will be spent on those 
functions....but of course nowhere is there a true capitalistic economy, but 
I expect that the knowledge/skill transfer will in fact be transferred if 
there still exists a market for it.

> so that soon (now!) people will
> manipulate and use technology that they really do not understand.
> And that is a drastic change from 40 years ago.
Ummm.....the true 'fundamental' knowledge underpinning all electronics as we 
understand it today are contained in Maxwell's equations and quantum 
mechanics.  I'd hazard a guess that engineer's have been designing without 
that true knowledge of both for far longer than 40 years.

What you're considering as fundamental seem to be the things things that you 
started your career with and were thought to be 'fundamental' back then, 
like how flip flops are constructed from transistors, why delays are 
important, bandwidths of transistors, etc.  But even those things are 
abstractions of Maxwell and quantum....is that a 'bad' thing?  History would 
indicate that it's not.  The electronics industry has done quite well in 
designing many things without having to hark back to Maxwell and quantum to 
design something.  There is the quote about seeing farther because I stood 
on the shoulders of giants that comes to mind.

How far away one can get without a knowledge of what is 'fundamental' though 
is where catastrophes can happen but productivity improvements over time are 
driven by having this knowledge somehow 'encoded' and moving away from 
direct application of that fundamental knowledge so that the designers of 
the future do not need to understand it all....as stated earlier, there are 
many layers to the onion, to many to be fully grasped by someone who also 
needs to be economically productive to society (translation:  employable).

There is the real danger of not passing along the new 'fundamentals' to the 
next generation so that lack of knowledge of old does not result in failures 
of the future.  What exactly the new 'fundamental' things are is 
subjective....but in any case they won't be truly be 'fundamental' unless it 
is a replacement for Maxwell's equations and the theory of quantum 
mechanics.

KJ 


0
KJ
10/29/2006 8:15:58 PM
Peter Alfke a �crit :
> To paraphrase Karl Marx:
> A spectre is haunting this newsgroup, the spectre of metastability.
> Whenever something works unreliably, metastability gets the blame. But
> the problem is usually elsewhere.

Strangely enough, this newsgroup is the only place where I have seen ths 
aformentionned ghost in 10 years of digital design.
(yeah I know Peter, these 10 years make me look like a baby, compared to 
your experience ;o)

[...]

> Rule #1: Never feed an asynchronous input into more than one
> synchronizer flip-flop. Never ever.

Got bitten once there. Never twice.

Nicolas
0
Nicolas
10/29/2006 8:20:27 PM
KJ wrote:
> "Peter Alfke" <alfke@sbcglobal.net> wrote in message 
> news:1162149643.159519.289870@i42g2000cwa.googlegroups.com...
>> Frank, I was addressing a different issue:
>> That the knowledge base of the fundamental technology inevitably is
>> supported by fewer and fewer engineers,
> But with a capitalistic economy one would expect that it will be supported 
> by the proper number of engineers and if that number is 'small' than those 
> few will earn more money than if there were a 'lot' of those engineers.  In 
> any case, the appropriate amount of money will be spent on those 
> functions....but of course nowhere is there a true capitalistic economy, but 
> I expect that the knowledge/skill transfer will in fact be transferred if 
> there still exists a market for it.
> 
>> so that soon (now!) people will
>> manipulate and use technology that they really do not understand.
>> And that is a drastic change from 40 years ago.
> Ummm.....the true 'fundamental' knowledge underpinning all electronics as we 
> understand it today are contained in Maxwell's equations and quantum 
> mechanics.  I'd hazard a guess that engineer's have been designing without 
> that true knowledge of both for far longer than 40 years.
> 
> What you're considering as fundamental seem to be the things things that you 
> started your career with and were thought to be 'fundamental' back then, 
> like how flip flops are constructed from transistors, why delays are 
> important, bandwidths of transistors, etc.  But even those things are 
> abstractions of Maxwell and quantum....is that a 'bad' thing?  History would 
> indicate that it's not.  The electronics industry has done quite well in 
> designing many things without having to hark back to Maxwell and quantum to 
> design something.  There is the quote about seeing farther because I stood 
> on the shoulders of giants that comes to mind.
> 
> How far away one can get without a knowledge of what is 'fundamental' though 
> is where catastrophes can happen but productivity improvements over time are 
> driven by having this knowledge somehow 'encoded' and moving away from 
> direct application of that fundamental knowledge so that the designers of 
> the future do not need to understand it all....as stated earlier, there are 
> many layers to the onion, to many to be fully grasped by someone who also 
> needs to be economically productive to society (translation:  employable).
> 
> There is the real danger of not passing along the new 'fundamentals' to the 
> next generation so that lack of knowledge of old does not result in failures 
> of the future.  What exactly the new 'fundamental' things are is 
> subjective....but in any case they won't be truly be 'fundamental' unless it 
> is a replacement for Maxwell's equations and the theory of quantum 
> mechanics.
> 
> KJ 
> 
> 

Well, there's fundamentals and there's fundamentals :)

One I see missing is an intuitive feel for transmission lines. For 
years, new engineers were churned out with the mantra of 'everything's 
going digital and we don't need that analog crap', but when edge rates 
are significantly sub-microsecond everything's a transmission line.

Certainly it has enhanced my employability that I learned those things 
both in theory and hard earned practice, but far more people need to 
learn these things in a world of ultra highspeed interconnects. One can 
not always trust to software simulations[1] quite apart from the issue 
of setting up a layout.[2]

This is a fundamental, at least imo, and it doesn't seem to be getting 
the attention it deserves.[3]

Other things could be cited, of course. Using a technology one does not 
understand is all well and good while it works. When it doesn't, the 
person is stumped because they don't understand the underlying principles.

[1] The most amusing software bug I ever had was an updated release of 
Altera's HDL tools where it synthesised a SCSI controller to a single 
wire. That was the predecessor to Quartus and happened in '98.

[2] Really highspeed systems have the layout defined for the 
interconnect [for best signal integrity and EMC issues] which then 
determines part placement, which is almost 180 out from standard layouts.

[3] This is a huge growth industry for those with the requisite 
knowledge; see e.g. Howard Johnson et.al. They'll give a seminar at a 
company for a few $10k or so for a day plus printed materials.


Cheers

PeteS
0
PeteS
10/29/2006 9:17:10 PM
"KJ" <kkjennings@sbcglobal.net> wrote in message 
news:2_71h.17705$TV3.7155@newssvr21.news.prodigy.com...
>
> What you're considering as fundamental seem to be the things things that 
> you started your career with and were thought to be 'fundamental' back 
> then,

This was EXACTLY the point I wanted to make...

There are two issues here - one is a valid point about it being useful to 
understand one or two layers below the abstraction you're working at, and a 
tangential one which is merely a placeholder for the vague regret we all 
feel that very much younger people are capable of doing something like our 
jobs, using a changing set of skills.

Technological progression, in pushing down what's fundamental and up what's 
possible RELIES on people being able to concentrate on only a limited number 
of layers in the stack.

The guys at CERN can't spend their time worrying about how you would use a 
boson to make a better automobile door handle any more than people 
programming desktop computers should worry about electronics.

One can endlessly and enjoyably debate which particular things are 
'fundamental' to solving a particular task, but one shouldn't fool oneself 
that there's a right answer.

Will



0
Will
10/30/2006 11:48:22 PM
I agree, and I was not making a moral statement.
Just that the ranks of engineers that can debug low-level (fundamental)
problems are shrinking.
Soon only IC designers will understand these things (because they are
still their livelihood), since everybody else has "moved up". ( I have
a son who works in software R&D, and we have very limited common ground
in electronic things).
I was, however, bemoaning the fact that so many things in our lives
have become black mystery boxes that defy "healthy curiosity". And that
phenomenon is new, within the last 50 years, a short time in the
evolution of technology.
Peter Alfke


On Oct 30, 3:48 pm, "Will Dean" <w...@nospam.demon.co.uk> wrote:
> "KJ" <kkjenni...@sbcglobal.net> wrote in messagenews:2_71h.17705$TV3.7155@newssvr21.news.prodigy.com...
>
>
>
> > What you're considering as fundamental seem to be the things things that
> > you started your career with and were thought to be 'fundamental' back
> > then,This was EXACTLY the point I wanted to make...
>
> There are two issues here - one is a valid point about it being useful to
> understand one or two layers below the abstraction you're working at, and a
> tangential one which is merely a placeholder for the vague regret we all
> feel that very much younger people are capable of doing something like our
> jobs, using a changing set of skills.
>
> Technological progression, in pushing down what's fundamental and up what's
> possible RELIES on people being able to concentrate on only a limited number
> of layers in the stack.
>
> The guys at CERN can't spend their time worrying about how you would use a
> boson to make a better automobile door handle any more than people
> programming desktop computers should worry about electronics.
>
> One can endlessly and enjoyably debate which particular things are
> 'fundamental' to solving a particular task, but one shouldn't fool oneself
> that there's a right answer.
> 
> Will

0
Peter
10/31/2006 12:51:31 AM
I consider myself to still be a youngster.  I'm only 24 years old and
I'm relatively recently out of college, but I find nothing you mention
here foreign.  This stuff is still being taught in schools (though I
might argue my school didn't do a great job of it).  The reality of it
all is that low level electronics remains useful.  I have never once
regretted understanding how a transistor works.  I have recently been
looking a flip flop designs since my company was having a hard time
meeting timing.  While I'm not an expert, others are, and I've yet to
ever meet a person who know this kind of stuff and doesn't want to
share that knowledge.

The kinds of things I deal with on perhaps a monthly basis are:
  * What are the costs of transmission gate input flip flop versus a
cmos input?
  * Can Astro synthesis a 4GHz clock tree?
  * How much drive would it take to overpower the drive of another cell
(multiple outputs tied together)?
  * What are possible resolve states when you have a race on an async
set/reset flop?

People still have to solve these problems.  They aren't going away.
The younger engineers still face these.

Now I admit that I do work as an IC designer, but ICs are here to stay.
 They may become fewer, but as long as they exist and get more
complicated, plenty of people will be employed in that industry.

My point to add to this is that many older engineers have difficulty
grasping new ways of operating.  Convincing experienced engineers that
synthesis tools actually work can be like pulling teeth sometimes.
Just the other day, some engineers were ranting about some code that a
contractor wrote that was very very behavioral.  They were complaining
about how that was killing timing and adding 10s to 100s of levels of
logic.  They hadn't tried it out.  I ran it through the synthesizer and
it was *faster* than the low level code.

I don't see knowledge of the really low level stuff going away.  In
fact I see it increasing.  Things like quantum physics and maxwell's
equations are getting used more and more to make electronics work.
TCAD engineers live in this realm and TCAD is getting used more and
more for things like process definition and modeling.  What I see
happening is the rift between the low level process/cell designers and
the logic designers growing as the logic designers get more high level
and the process/cell designers have to get closer to the real physics
of the system.  Not all of the knowledge is necessary for all parties.
The fact is that if a good library is present (and nothing super funky
is in the design), a logic designer doesn't need to know electronics.
They simply need to know the how to work with the models that are
employed by the tools.

-Arlen

0
gallen
10/31/2006 3:21:14 AM
Good for you, Arien.
Over the past 35 years I have interviewed many hundreds of new college
grads. Among others I always asked a very simple question:
Show me how you analyze the max clock frequency of a 2-bit shift
register (what data-sheet parameters do you need, where do they apply,
and what is the math between them?). Most can do that, after some
prodding. Then: What happens to the max frequency when there is clock
skew between the two flip-flops. About half gave the wrong answer to
this slightly tricky question. So they did not get hired...In a new
grad I do not look for factual knowledge, but for the ability to think
clearly.
Some passed this test with flying colors, sometimes amazed at the
implication of their own answer.
I was looking for nuts-and-bolts applications engineers, and other
interviewers tested their systems and software skills. We were (and
are) pretty selective...
Peter Alfke
========================
On Oct 30, 7:21 pm, "gallen" <arlen...@gmail.com> wrote:
> I consider myself to still be a youngster.  I'm only 24 years old and
> I'm relatively recently out of college, but I find nothing you mention
> here foreign.  This stuff is still being taught in schools (though I
> might argue my school didn't do a great job of it).  The reality of it
> all is that low level electronics remains useful.  I have never once
> regretted understanding how a transistor works.  I have recently been
> looking a flip flop designs since my company was having a hard time
> meeting timing.  While I'm not an expert, others are, and I've yet to
> ever meet a person who know this kind of stuff and doesn't want to
> share that knowledge.
>
> The kinds of things I deal with on perhaps a monthly basis are:
>   * What are the costs of transmission gate input flip flop versus a
> cmos input?
>   * Can Astro synthesis a 4GHz clock tree?
>   * How much drive would it take to overpower the drive of another cell
> (multiple outputs tied together)?
>   * What are possible resolve states when you have a race on an async
> set/reset flop?
>
> People still have to solve these problems.  They aren't going away.
> The younger engineers still face these.
>
> Now I admit that I do work as an IC designer, but ICs are here to stay.
>  They may become fewer, but as long as they exist and get more
> complicated, plenty of people will be employed in that industry.
>
> My point to add to this is that many older engineers have difficulty
> grasping new ways of operating.  Convincing experienced engineers that
> synthesis tools actually work can be like pulling teeth sometimes.
> Just the other day, some engineers were ranting about some code that a
> contractor wrote that was very very behavioral.  They were complaining
> about how that was killing timing and adding 10s to 100s of levels of
> logic.  They hadn't tried it out.  I ran it through the synthesizer and
> it was *faster* than the low level code.
>
> I don't see knowledge of the really low level stuff going away.  In
> fact I see it increasing.  Things like quantum physics and maxwell's
> equations are getting used more and more to make electronics work.
> TCAD engineers live in this realm and TCAD is getting used more and
> more for things like process definition and modeling.  What I see
> happening is the rift between the low level process/cell designers and
> the logic designers growing as the logic designers get more high level
> and the process/cell designers have to get closer to the real physics
> of the system.  Not all of the knowledge is necessary for all parties.
> The fact is that if a good library is present (and nothing super funky
> is in the design), a logic designer doesn't need to know electronics.
> They simply need to know the how to work with the models that are
> employed by the tools.
> 
> -Arlen

0
Peter
10/31/2006 4:35:49 AM
"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:1162255891.335808.86090@m7g2000cwm.googlegroups.com...
>I agree, and I was not making a moral statement.
> Just that the ranks of engineers that can debug low-level (fundamental)
> problems are shrinking.
But you haven't established that this is a 'problem'.  Shrinking to fit the 
number of slots that the world needs is economically sound.  Shrinking below 
that will cause a shortage which will cause the price of people who have 
those skills to go up.

> Soon only IC designers will understand these things (because they are
> still their livelihood), since everybody else has "moved up".
But maybe they will be the only ones who use this on a day to day basis and 
have an actual need to know this.  Can you say that you understand the 
operation of flip flops and can demonstrate this using the equations of 
quantum mechanical level or can you even compute the fields that will be 
produced by that changing flip flop by using Maxwell's equations?  Maybe you 
can, but I'll hazard to say that if forced to do this in front of someone 
who is skilled in either or both of these theories then probably not.

> ( I have
> a son who works in software R&D, and we have very limited common ground
> in electronic things).
But maybe he is very skilled in other areas....keep in mind Adam Smith and 
the division of labor in economic theory.

> I was, however, bemoaning the fact that so many things in our lives
> have become black mystery boxes that defy "healthy curiosity". And that
> phenomenon is new, within the last 50 years, a short time in the
> evolution of technology.
My point on the earlier post was that it has gone on for much longer.  The 
true fundamentals of electronics haven't changed in roughly a century 
(Maxwell and quantum) and yet I would hazard to say that the number of 
engineers designing electrical or electronic equipment that directly use 
these theories is pretty close to 0....and would speculate that that is also 
roughly the number of engineers who directly used it 10, 20, 30, etc...... 
years ago as well.

I don't think many things defy the healthy curiousity but as designers get 
more and more productive there becomes more and more knowledge that one must 
accumulate if you want to satisfy that curiousity completely not because the 
fundamentals are changing but because the approximations and shortcuts that 
are used above those fundamentals in order to realize those productivity 
improvements get more and more each year.  One can still do it, one can 
still specialize in any of those areas if you choose to but and there will 
still generally be a market for people who have accumulated more of that 
specialized skill....if it is still relevant to the world at large.

KJ


0
KJ
10/31/2006 11:15:04 AM
"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:1162269349.885081.72560@k70g2000cwa.googlegroups.com...
> Good for you, Arien.
> Over the past 35 years I have interviewed many hundreds of new college
> grads. Among others I always asked a very simple question:
> Show me how you analyze the max clock frequency of a 2-bit shift
> register (what data-sheet parameters do you need, where do they apply,
> and what is the math between them?).
> Most can do that, after some
> prodding. Then: What happens to the max frequency when there is clock
> skew between the two flip-flops. About half gave the wrong answer to
> this slightly tricky question. So they did not get hired...In a new
> grad I do not look for factual knowledge, but for the ability to think
> clearly.
Kind of missed how you factored in the stress associated with the interview 
process.  It's easy to sit on the side of the questioner in that situation, 
not so easy the other way around.  Sometimes the weak answers have nothing 
to do with the skills of that person but reflects how that person tenses up 
in stressful situations.  If they do, then maybe they're not appropriate for 
a client facing position, but maybe you're not interviewing someone for that 
type of position either.

> Some passed this test with flying colors, sometimes amazed at the
> implication of their own answer.
Being able to think quickly on your feet is a skill that can help land that 
job offer.  It can also come in handy when on the job...but along with other 
skills too.

> I was looking for nuts-and-bolts applications engineers, and other
> interviewers tested their systems and software skills.
What about them 'people skills'?  The arrogant ones who know the nuts and 
bolts and flew through your test might be rather disruptive in the work 
place.  Generally they become sidelined because of their arrogance...or work 
their way up the management chain to become CEO.

> We were (and are) pretty selective...
This made me ponder why most of the posts about problems with tools are 
centered around brand X.  'Most' here meaning that the percentage of brand X 
questions/complaints appears to be far above brand X's market share.  It 
could just be my perception of the posts though.

KJ


0
KJ
10/31/2006 11:27:44 AM
Nicolas Matringe wrote:
> Peter Alfke a =E9crit :
> > Rule #1: Never feed an asynchronous input into more than one
> > synchronizer flip-flop. Never ever.
>
> Got bitten once there. Never twice.

Is it possible that this situation could occur if register duplication
is enabled (to improve timing) in the tools (eg XST)?

If so. is there a method to mark the synchronizer in HDL to ensure it
is never automatically duplicated?

Tom

0
Tom
10/31/2006 2:23:25 PM
The first synchronizing flip flop on an async input will experience
metastability, sooner or later. Whether that metastability lasts long
enough to cause a functional problem depends on how the output is used.
If it becomes a causal input (i.e. clk or async rst) to something else,
it can become a problem very quickly (read: "don't do that"). If there
is very little timing margin to the next non-causal (i.e. D, CE, or
sync rst) input(s), then it can also cause problems fairly quickly. The
admonishment to "add a second flop" is usually an attempt to create a
high slack/margin path to the next clocked element, but may not be
sufficient. Ideally, that path (or any path out of the first
synchronizing flop) should be constrained to be faster than the clock
period would indicate, to force the synthesis/P&R process to provide
extra timing margin (slack), in case MS should delay the output a bit.
The more slack/margin, the more immunity to MS a design has. Also, the
first synchronizing flop on an input should have a no-replicate
constraint on it, just in case the synth/P&R tool wants to replicate it
to solve fanout problems from that first flop.

Also recognize that even async rst/prst inputs to flops must be
properly synchronized with respect to the deasserting edge, since that
edge is effectively a "synchronous" input, subject to setup/hold
requirements too.

Whether or not a problem is caused by metastability or by improper
synchronization, it is still solved by the same proper synchronization
techniques. It is true that MS has been reduced significantly by the
newer, faster FPGA devices, but it is not totally eliminated, and the
higher speeds & tighter timing margins of designs implemented in these
FPGAs at least partially offset the improvements in MS in the flops
themselves.

Follow the guidelines in the app notes for simultaneous switching
outputs, and properly ground/bypass the on-board PDS, and ground bounce
will not be an issue. Once it becomes an issue, there are numerous
"creative" solutions to the problem, but they are best avoided up
front.

Andy

John Kortink wrote:
> On 27 Oct 2006 14:25:09 -0700, "Peter Alfke" <peter@xilinx.com> wrote:
>
> >To paraphrase Karl Marx:
> >A spectre is haunting this newsgroup, the spectre of metastability.
> >Whenever something works unreliably, metastability gets the blame. But
> >the problem is usually elsewhere.
>
> In my experience, ground bounce is a bigger problem.
> Especially in a device that is nearly 'full' it is
> wise to invest in a few fabricated grounds (dedicate
> a pin at a strategic location, i.e. as far away as
> possible from other ground pins, drive it to ground,
> and tie it to ground externally).
>
> When you find that moving cells around alleviates or
> intensifies observed instabilities, you may want to
> look into ground bounce problems.
>
> >Metastability causes a non-deterministic extra output delay, when a
> >flip-flop's D input changes asynchronously, and happens to change
> >within an extremely narrow capture window (a tiny fraction of a
> >femtosecond !). This capture window is located at an unknown (and
> >unstable) point somewhere within the set-up time window specified in
> >the data sheet. The capture window is billions of times smaller than
> >the specified set-up time window. The likelihood of a flip-flop going
> >metastable is thus extremely small. The likelihood of a metastable
> >delay longer than 3 ns is even less.
> >As an example, a 1 MHz asynchronous signal, synchronized by a 100 MHz
> >clock, causes an extra 3 ns delay statistically once every billion
> >years. If the asynchronous event is at 10 MHz, the 3 ns delay occurs
> >ten times more often, once every 100 million years.
> >But a 2.5 ns delay happens a million times more often !
> >See the Xilinx application note XAPP094
> >You should worry about metastability only when the clock frequency is
> >so high that a few ns of extra delay out of the synchronizer flip-flop
> >might causes failure. The recommended standard procedure,
> >double-synchronizing in two close-by flip-flops, solves those cases.
>
> I've found that one synchronizing flip-flop was not enough
> in one particular case (from a 4-ish to 50-ish MHz domain).
> Two was. Does one ever work reliably ? Or has the 'window'
> become smaller in the past few years ?
>
>
> John Kortink
> Windfall Engineering
>
> --
>
> Email    : kortink@inter.nl.net
> Homepage : http://www.windfall.nl
> 
> Your hardware/software designs realised !

0
Andy
10/31/2006 2:25:45 PM
Tom a �crit :
> Nicolas Matringe wrote:
>> Peter Alfke a �crit :
>>> Rule #1: Never feed an asynchronous input into more than one
>>> synchronizer flip-flop. Never ever.
>> Got bitten once there. Never twice.
> 
> Is it possible that this situation could occur if register duplication
> is enabled (to improve timing) in the tools (eg XST)?

In theory it could.


> If so. is there a method to mark the synchronizer in HDL to ensure it
> is never automatically duplicated?


I am sure there is but I haven't used a Xilinx part for quite a long 
time. Austin or Peter (or many other readers) could give you a more 
accurate answer.

Nicolas
0
Nicolas
10/31/2006 3:28:32 PM
"Nicolas Matringe" <nicolas.matringe@fre.fre> wrote in message 
news:45476ba0$0$3879$426a74cc@news.free.fr...
> Tom a �crit :
>> Nicolas Matringe wrote:
>>> Peter Alfke a �crit :
>>>> Rule #1: Never feed an asynchronous input into more than one
>>>> synchronizer flip-flop. Never ever.
>>> Got bitten once there. Never twice.
>> Is it possible that this situation could occur if register duplication
>> is enabled (to improve timing) in the tools (eg XST)?
> In theory it could.

You may be right, but I think it's unlikely. If you're re-synchronizing 
properly then there are two levels of FFs, and the front-end FFs have a 
fanout of exactly one net each. So there is nothing to be gained by 
duplicating them, even if the back-end stage has a high fanout (the second 
stage would be duplicated instead).

In fact, register duplication rarely makes timing better; in fact in many 
high-performance pipelined designs, it can make it much worse (explanation 
available on demand).

>> If so. is there a method to mark the synchronizer in HDL to ensure it
>> is never automatically duplicated?

Yes. You can use the REGISTER_DUPLICATION constraint in your source code or 
XCF file to specifically turn this feature on or off for a specific entity 
or module.

Cheers,

       -Ben- 


0
Ben
10/31/2006 3:57:37 PM
gallen wrote:
> I consider myself to still be a youngster.  I'm only 24 years old and
> I'm relatively recently out of college, but I find nothing you mention
> here foreign.  This stuff is still being taught in schools (though I
> might argue my school didn't do a great job of it).  The reality of it
> all is that low level electronics remains useful.  I have never once
> regretted understanding how a transistor works.  I have recently been
> looking a flip flop designs since my company was having a hard time
> meeting timing.  While I'm not an expert, others are, and I've yet to
> ever meet a person who know this kind of stuff and doesn't want to
> share that knowledge.
> 
> The kinds of things I deal with on perhaps a monthly basis are:
>   * What are the costs of transmission gate input flip flop versus a
> cmos input?
>   * Can Astro synthesis a 4GHz clock tree?
>   * How much drive would it take to overpower the drive of another cell
> (multiple outputs tied together)?
>   * What are possible resolve states when you have a race on an async
> set/reset flop?
> 
> People still have to solve these problems.  They aren't going away.
> The younger engineers still face these.
> 
> Now I admit that I do work as an IC designer, but ICs are here to stay.
>  They may become fewer, but as long as they exist and get more
> complicated, plenty of people will be employed in that industry.
> 
> My point to add to this is that many older engineers have difficulty
> grasping new ways of operating.  Convincing experienced engineers that
> synthesis tools actually work can be like pulling teeth sometimes.
> Just the other day, some engineers were ranting about some code that a
> contractor wrote that was very very behavioral.  They were complaining
> about how that was killing timing and adding 10s to 100s of levels of
> logic.  They hadn't tried it out.  I ran it through the synthesizer and
> it was *faster* than the low level code.
> 
> I don't see knowledge of the really low level stuff going away.  In
> fact I see it increasing.  Things like quantum physics and maxwell's
> equations are getting used more and more to make electronics work.
> TCAD engineers live in this realm and TCAD is getting used more and
> more for things like process definition and modeling.  What I see
> happening is the rift between the low level process/cell designers and
> the logic designers growing as the logic designers get more high level
> and the process/cell designers have to get closer to the real physics
> of the system.  Not all of the knowledge is necessary for all parties.
> The fact is that if a good library is present (and nothing super funky
> is in the design), a logic designer doesn't need to know electronics.
> They simply need to know the how to work with the models that are
> employed by the tools.
> 
> -Arlen
> 

I have no problem using synthesis tools, although I have a healthy 
skepticism of *any* software based tool (which does not mean I won't use 
it or it's conclusions, merely that all non-trivial software has bugs).

As to a logic designer not needing to know the electronics; that's only 
true if said designer is only designing for where synthesis (or models 
that will be used) happens to be available. I've yet to see an LSI or 
larger device where the IO pins could be directly attached to 48V, (and 
be cheaper than the discrete alternative) yet that is a pretty standard 
logic design issue in some industries.

A POR indicator circuit for a 24V vehicle, for instance, could be 
constructed from standard cells, but at some point we meet the (very 
nasty) 24V system (which can go up to 80V during load dump and droop 
regularly during engine cranking). Of course, when designing power 
supplies (which I also do quite regularly) I expect those sorts of 
challenges.

Incidentally, the 'logic designer' syndrome you mention is precisely 
what I was railing against in an earlier post; it's shortsighted and 
foolish. A logic designer that can do logic but not electronics is _not_ 
an electrical/electronics engineer - they are either a software engineer 
or a mathematician.

Kudos to you for learning the low level parts.

As with Peter Afke, I too am very particular about who we hire. 
Generally I would prefer not to hire anyone than hire someone who 
doesn't have the urge to seek out answers and think for themselves. I am 
fully aware that such people _will_ make mistakes (it's an occupational 
hazard) but I would prefer that to hand-holding.

I worry about too few people who call themselves electrical/electronic 
engineers actually knowing sufficient about physical layer engineering.

Cheers

PeteS
0
PeteS
10/31/2006 7:51:09 PM
On 2006-10-31, Ben Jones <ben.jones@xilinx.com> wrote:
> In fact, register duplication rarely makes timing better; in fact in many 
> high-performance pipelined designs, it can make it much worse (explanation 
> available on demand).

I guess I'll bite and see if my understanding is close to what you have
in mind:

My feeling is that register duplication could worsen a design with
combinatorial logic followed by a flip flop. This means either that
the combinatorial logic has to be duplicated (which would enlarge the
design and perhaps slow down the circuit due to extra routing, or
by only duplicating the flip flop which will certainly demand extra
routing since it is normally possible to place a FF directly after a LUT
using only high speed dedicated routing.

On the other hand, I can't really see that register duplication will make
the performance much worse (unless the synthesizer makes very bad choices of
course) so you might have something else in mind.


/Anderas
0
Andreas
10/31/2006 9:08:42 PM
The original subject was metastability, and the second subject was
unreliable operation when an asynchronous signal is, in parallel,
synchronized in more than one flip-flop, where even the most minute
delay/set-up-time difference can cause severe problems.
Peter Alfke

On Oct 31, 1:08 pm, Andreas Ehliar <ehl...@lysator.liu.se> wrote:
> On 2006-10-31, Ben Jones <ben.jo...@xilinx.com> wrote:
>
> > In fact, register duplication rarely makes timing better; in fact in many
> > high-performance pipelined designs, it can make it much worse (explanation
> > available on demand).I guess I'll bite and see if my understanding is close to what you have
> in mind:
>
> My feeling is that register duplication could worsen a design with
> combinatorial logic followed by a flip flop. This means either that
> the combinatorial logic has to be duplicated (which would enlarge the
> design and perhaps slow down the circuit due to extra routing, or
> by only duplicating the flip flop which will certainly demand extra
> routing since it is normally possible to place a FF directly after a LUT
> using only high speed dedicated routing.
>
> On the other hand, I can't really see that register duplication will make
> the performance much worse (unless the synthesizer makes very bad choices of
> course) so you might have something else in mind.
> 
> /Anderas

0
Peter
10/31/2006 9:26:35 PM
"Andreas Ehliar" <ehliar@lysator.liu.se> wrote in message 
news:ei8e0q$avt$1@news.lysator.liu.se...
> On 2006-10-31, Ben Jones <ben.jones@xilinx.com> wrote:
>> In fact, register duplication rarely makes timing better; in fact in many
>> high-performance pipelined designs, it can make it much worse 
>> (explanation
>> available on demand).
>
> I guess I'll bite and see if my understanding is close to what you have
> in mind:
>
> My feeling is that register duplication could worsen a design with
> combinatorial logic followed by a flip flop. This means either that
> the combinatorial logic has to be duplicated (which would enlarge the
> design and perhaps slow down the circuit due to extra routing, or
> by only duplicating the flip flop which will certainly demand extra
> routing since it is normally possible to place a FF directly after a LUT
> using only high speed dedicated routing.

Got it in one. The "enlargement" problem isn't much of a problem, since in 
FPGA technology if you need to allocate a new register then you basically 
get the preceding LUT for free. However, it's the "extra routing" problem 
that's the killer.

> On the other hand, I can't really see that register duplication will make
> the performance much worse (unless the synthesizer makes very bad choices)

Say your design is supposed to run at 400MHz (2.5ns clock period). The extra 
route from the combinatorial output of the LUT to the input of the "extra" 
register added by the replication process may be 500ps. That's 20% of your 
cycle budget! Often, it's more like 800ps... of course if your clock speed 
is only 100MHz, this is much less of an issue.

There may be a few scenarios in which register duplication really is a good 
thing, but in my experience synthesis tools don't always find them. So I 
tend to just leave this "feature" turned off.

Cheers,

         -Ben-

(Whoops, off topic...) 


0
Ben
11/1/2006 10:32:30 AM
Just make sure you NEVER duplicate the one flip-flop that is supposed
to synchronize the asynchronous input. Then a 1 ps input delay or
set-up time difference can spell disaster.
Peter Alfke

On Nov 1, 2:32 am, "Ben Jones" <ben.jo...@xilinx.com> wrote:
> "Andreas Ehliar" <ehl...@lysator.liu.se> wrote in messagenews:ei8e0q$avt$1@news.lysator.liu.se...
>
>
>
> > On 2006-10-31, Ben Jones <ben.jo...@xilinx.com> wrote:
> >> In fact, register duplication rarely makes timing better; in fact in many
> >> high-performance pipelined designs, it can make it much worse
> >> (explanation
> >> available on demand).
>
> > I guess I'll bite and see if my understanding is close to what you have
> > in mind:
>
> > My feeling is that register duplication could worsen a design with
> > combinatorial logic followed by a flip flop. This means either that
> > the combinatorial logic has to be duplicated (which would enlarge the
> > design and perhaps slow down the circuit due to extra routing, or
> > by only duplicating the flip flop which will certainly demand extra
> > routing since it is normally possible to place a FF directly after a LUT
> > using only high speed dedicated routing.Got it in one. The "enlargement" problem isn't much of a problem, since in
> FPGA technology if you need to allocate a new register then you basically
> get the preceding LUT for free. However, it's the "extra routing" problem
> that's the killer.
>
> > On the other hand, I can't really see that register duplication will make
> > the performance much worse (unless the synthesizer makes very bad choices)Say your design is supposed to run at 400MHz (2.5ns clock period). The extra
> route from the combinatorial output of the LUT to the input of the "extra"
> register added by the replication process may be 500ps. That's 20% of your
> cycle budget! Often, it's more like 800ps... of course if your clock speed
> is only 100MHz, this is much less of an issue.
>
> There may be a few scenarios in which register duplication really is a good
> thing, but in my experience synthesis tools don't always find them. So I
> tend to just leave this "feature" turned off.
> 
> Cheers,
> 
>          -Ben-
> 
> (Whoops, off topic...)

0
Peter
11/1/2006 4:55:22 PM
Peter Alfke wrote:
> There is a difference, 60 years ago, a curious kid could at least try
> to understand the world around him/her.
> Clocks, carburators, telephones, radios, typewriters, etc.

In a talk at the Computer History Museum that Gordon Moore
gave on the history of Moore's Law, he was asked about what
influenced his interest in science.  His answer included playing
with chemistry sets and blowing things up.

He was later asked about the some of reasons for the decline
in US science education.  His answer was that nowadays kids
couldn't buy "real" chemistry set and blow things up.


IMHO. YMMV.
-- 
rhn A.T nicholson d.0.t C-o-M

0
Ron
11/2/2006 7:24:54 AM
On Wed, 1 Nov 2006 10:32:30 -0000, "Ben Jones" <ben.jones@xilinx.com>
wrote:

>There may be a few scenarios in which register duplication really is a good 
>thing, but in my experience synthesis tools don't always find them. So I 
>tend to just leave this "feature" turned off.

I think you'd normally use duplication to reduce routing congestion.
On a chip I was on recently, the vendor wouldn't take a netlist that
had any fanout cones with more than 2500 endpoints, and register
duplication was the only practical fix. I used Teraform (deceased?) to
measure the cones.

Evan

>(Whoops, off topic...) 
>

0
Evan
11/2/2006 4:50:48 PM
"Evan Lavelle" <eml@nospam.uk> wrote in message 
news:b77kk2hrrc8eks4lm668mnvi4ht9nbgp1h@4ax.com...
>
> I think you'd normally use duplication to reduce routing congestion.
> On a chip I was on recently, the vendor wouldn't take a netlist that
> had any fanout cones with more than 2500 endpoints, and register
> duplication was the only practical fix. I used Teraform (deceased?) to
> measure the cones.

Register duplication leads to more nets in the final design, not fewer, so 
it's not usually going to do much for congestion. However, for these 
high-fanout signals, it does make placement easier (because there are fewer 
rubber-bands pulling the driving element around the die).

If I had a net with a fanout greater than a few hundred, and it wasn't a 
clock or a reset, I'd probably do a bit of redesign at a higher level before 
resorting to replication. :)

Cheers,

      -Ben- 


0
Ben
11/2/2006 5:26:14 PM
On Thu, 2 Nov 2006 17:26:14 -0000, "Ben Jones" <ben.jones@xilinx.com>
wrote:

>If I had a net with a fanout greater than a few hundred, and it wasn't a 
>clock or a reset, I'd probably do a bit of redesign at a higher level before 
>resorting to replication. :)

It wasn't possible in this case, unfortunately, since I didn't
understand the design or have enough time. One cone actually had
10,000 endpoints.

Yes, the total number of nets increased, but not by a great deal - the
ideal solution would be to turn one source register into 4 registers,
each driving a cone of 2,500 endpoints.

Evan
0
Evan
11/2/2006 7:13:19 PM
Reply:

Similar Artilces:

Spectre of Metastability Update
Good news: the "spectre of metastability" appears to be on the wane. I live less than a mile from Xilinx HQ, yet on Halloween night, not a single person dressed as metastability showed up at my door for candy (the closest was a kid in a Napoleon Dynamite getup). Of course, real metastability is still out there. As Jack Nicholson would say, act accordingly. Bob Perlman Cambrian Design Works http://www.cambriandesign.com Bob Perlman wrote: > > on Halloween night, not a single person dressed as metastability > showed up at my door for candy > We had four houses' wo...

digital spectre haunting Reuters
Are we sitting comfortable. Then I shall begin. Today children we're going to play the `spot the BS' game .. ------ - quote - digital worm called Kelvir had penetrated Reuters Messaging system NEWS - Geek A digital worm called Kelvir had penetrated Reuters Messaging system Kelvir is one of the three most widely detected IM viruses in corporate sites, according to IMLogic, which recently released a report stating IM attacks are up more than 250% over last year. http://www.grabageek.net/modules/news/article.php?storyid=400 Reuters Squashes Worm, Restores IM "The majority of ...

Spectre for Windows
You may or may not be aware that I have webbed an entire *free* clinical reporting system thatuses SAS software at the address below. People are discovering it for the first time even 8 months after its release. http://www.datasavantconsulting.com/roland/spectre/ Although its reporting macros work on any platform, it was written to run on a Unix platform and has all the scripts to go with it as you would expect (plus a whole lot more). I am thinking of converting the scripts to python so that it can run on a Windows platform in much the same way that it now runs on a Unix platform (somewhere...

Spectre question
Hi everyone! Spectre seems to have a built-in setting that limits the maximum size of a psfascii tran.tran file. When simulating and this size is reached, Spectre either automatically shuts down or crashes. This size is around 2.5 GB. Does anyone know if there is a way to increase or change this setting? There doesn't seem to be a documented command-line switch for this, but perhaps there is an undocumented one. Thanks in advance! -Jason D. Bakos This is a bug in Spectre, Spectre should split result files greater than 2G. This bug should be fixed, but I assume you are using a 4....

spectre to hspice
Hi all, I would like to generate hspiceS for my digital layout. Since the layout contains more than 10 thousands transistors, generating hspiceS for this big layout becomes a big problem. What I did is generating the netlist in spectre format and changing it to hspice format using perl. I notice that the ways of representing the floating number in two different netlist formats is as follow. hspice --> 0.123e-6 spectre --> 1.23e-7 So when I convert from spectre netlist to hspice netlist, do I have to change this floating format also? If I don't change it and use it in nanosim s...

spectre captab?
Spectre has the option to print all the node capacitance values with an option called captab in the DC analysis options form. I specified node to node capacitance. The circuit consists of 1 diode connected npn. In my spectre.out file I see the following: Q1:int_b : 0 variable=0 0 Q1:int_b : Q1:int_b variable=536.081f 536.081f Q1:int_b : Q1:int_c variable=201.324f 201.324f Q1:int_b : Q1:int_e variable=334.757f 334.757f Q1:int_b : net24 variable=0 -0 Q1:int_c : 0 variable=98....

Spectre to Spice
I have my layout in DFII and I do the extraction using diva. Is there any way I can save the extracted netlist in spice format (that pspice or spice3 can simulate?) instead of spectre format? saby saby wrote: > I have my layout in DFII and I do the extraction using diva. Is there > any way I can save the extracted netlist in spice format (that pspice > or spice3 can simulate?) instead of spectre format? > > saby > if your design kit supports it, yes. Can you netlist your schematics for spice (using the proper simulator setting in analog artist) ? I don't have the s...

Spectre with SKILL
Hi, I want to command spectre with cadence and compare results with wich I want to have . Thank you . -- Message posted using http://www.talkaboutcad.com/group/comp.cad.cadence/ More information at http://www.talkaboutcad.com/faq.html On Wed, 06 Feb 2008 04:52:04 -0600, "TITO00992" <tito00992@yahoo.fr> wrote: >Hi, >I want to command spectre with cadence and compare results with wich I >want to have . >Thank you . That's nice for you. I hope you have an enjoyable time doing it. Regards, Andrew. > That's nice for you. I hope you have an enjoyable ti...

Spectre vs. SpectreRF
Can you tell me the differences between Spectre and SpectreRF? Thanks. See doc/spectreRF/spectreRF.pdf --- Erik kngo@dspg.com wrote: > Can you tell me the differences between Spectre and SpectreRF? Thanks. ...

spectre wrapper in ocean
Hi, I need to run spectre through a wrapper in ocean. In other words, I need to do something like: envSetVal("spectre.envOpts" "simExecName" 'string "mySpectreWrapper spectre") simulator('spectre) ..... .... .... run() By default spectre is run with +inter which starts MPS, and the spectre process is started by my wrapper (is runSimulation started in background?). The simulation never quits, I guess because it is waiting for some MPS commands. The obvious workaround envSetVal( "spectre.envOpts" "userCmdLineOption" &...

Spectre for Windows
I am working on porting my Spectre clinical reporting system over to Windows. Things are progressing rapidly. This weekend (24-25 Feb 2007) I will have a release that should at least run on Windows. It won't be able to create bookmarked PDFs as yet and I still can't get it to send me emails but I'll get round to working on that later. For Spectre to work on a Windows PC, Cygwin will be required so that its scripts can run. This is explained in the FAQ. I am using SAS Learning Edition 4.1so if you have that you should be OK. If you want to install the Windows version of Spectre t...

Spectre internal error
Hi, I'm not very experienced with cadence, but have been designing RF-CMOS circuitry with it for the last few months. I've successfully simulated and optimised a number of designs; primarily simple LNA circuits. I'm currently trying to optimise an LNA design based on a recent paper by Bruccoleri et. al, and keep running into problems. The circuit simulates fine using analog artist, but when I try to run the optimizer on it, it runs through iteration 0 okay, then during iteration 1 cds.log reports: *WARNING* gpwipx: Too many stripts for window (nA=8 nD=0) *Error* Y-directi...

Spectre Interactive Mode
Dear All, I would like to know if there is a manual or reference for the Interactive Skill Front End commands that are used in spectre interactive mode. I searched in google and in Skill reference files that come along with Cadence documentation, and can't find anything useful till now. The only thing I'm able to get is the list of possible commands: sclGetParameter sclListParameter sclGetAttribute sclSetAttribute sclListAttribute sclGetAnalysis sclGetCircuit sclGetInstance sclGetModel sclGetPrimitive sclListAnalysis ...

cshunt equivalent in spectre?
I am trying to find out if there is an equivalent way of enabling the HSPICE ..option cshunt=xx in Spectre. I've tried converting an HSPICE file to a Spectre file using spp -convert, but have not been successful. Chris: In the transient options there is a parameter called cmin. When cmin is set to a nonzero value it connects a capacitor from every node to ground. --- Erik csprice@eudoramail.com (Chris Price) wrote in message news:<86ed43bb.0402160944.2812ce26@posting.google.com>... > I am trying to find out if there is an equivalent way of enabling the > HSPICE > &...

Background simulation of the Spectre
Dear all, I am using the Spectre simulator to simulate the VCO. Now, I am using the Parametric Analysis function to simulate the tuning frequency range of the VCO (vary the Vctrl of the varactor). Actually, I want to simulate it in the background simulation. I have tried to run the script of the "runSimulation". It just run one times only and will not run the no. of the run I set in the Parametric Analysis. Therefore, how could I run the Parametric Analysis in the background simulation? Thanks wccheng Read up on LBS or if you have LSF set LBS_BASE_SYSTEM to LBS_LSF. Then you ...

Spectre vs Nanosim
Dear all, I have a SRAM circuit (/circuits with different wordlengths from 8 to 48) which I need to simulate and do the power analysis. Initially I thought I could do the power analysis by simulating the circuit with Spectre. But my supervisor said that it could take many days to simulate one such circuit and I have to do these simulations on more than one circuit. So he suggested me to explore the possibilitys with nanosim. Is it fesible to do such a power analysis on spectre or else would you suggest me to use nanosim instead. How much time will it take to simulate a SRAM circuit with wordlenghts 8, 12, 16, 32 and 48. Your inputs will be very much apprecieted. Thanks and Regards, Kamesh. I forgot to add one thing.The SRAM is a layout level circuit in the above. Thanks once again for your time, Kamesh. kamesh wrote: > Dear all, > > I have a SRAM circuit (/circuits with different wordlengths from 8 > to 48) which I need to simulate and do the power analysis. Initially I > thought I could do the power analysis by simulating the circuit with > Spectre. But my supervisor said that it could take many days to > simulate one such circuit and I have to do these simulations on more > than one circuit. So he suggested me to explore the possibilitys with > nanosim. Is it fesible to do such a power analysis on spectre or else > would you suggest me to use nanosim instead. How much time will it take > to simulate a SRAM circuit with wordlengh...

warning message from spectre
I am using BSIM4 models to design my circuit. When I simulate, a warning msg saying " Missing bulk-drain diode would be forward biased." apears. The transistor is in the linear region with source and drain and bulk at 0 and gate at Vdd. I read somewhere that this is because the parameter IS is being set to 0, and thus the diodes are being open ciruited. So why is this happening and how do I make sure that this doesnt happen? Thanx ...

Batch Mode in Spectre
Can anybody tell me when we use batch mode in spectre? Also, how to set the mode from interactive to batch? Thanks in advance! Hi, 1. The Interactive option allows faster response to simulator requests but also locks a simulator license when in use. When you run multiple simulations (ex corner Analysis) in batch mode, a new start-up is required for each single simulations. Means a new spectre process is called, License checked in, run, exit, license checked out and so on. This behaviour slows down the simulation. This is done only once with Interactive mode. When Spectre is launched in Interactive mode from ADE, the license is hold until ADE gets closed. Interactive mode is better if you're concerned about speed. You have to use Batch if you need to free the Spectre license. FYI: There is a more complete answer about this topic on the Cadence's Sourcelink : SR1838156. 2. The following document shall help you: Virtuoso=AE Analog Design Environment User Guide ($CDSHOME/doc/ anasimhelp/anasimhelp.pdf). This is the bit that answers your question: controlMode Used to run Spectre in batch or interactive modes depending on the value of the variable. To set this variable in the .cdsinit file or CIW, use the call: envSetVal(=93spectre.envOpts=94 =93controlMode=94 =91string =93batch=94) Hope it helps ! Riad. On May 29, 1:27 am, Riad KACED <riad.ka...@gmail.com> wrote: > Hi, > > 1. The Interactive option allows faster response to simulator requests > b...

Spectre simulation error
Hi all, Sometimes I have the following error when trying to create netlist and start simulation in Affirma Analog Circuit Enviroment: *Error* fprintf/sprintf: format spec. incompatible with data - nil After that netlist is not created, Spectre is not starting etc.. I am using Cadence 4.4.6. The problem is that this error appears more or less randomly - when you start a new design it can appear or not, but once Spectre started wveruthing is ok - I can modify things and simulate further on.. Similarly - once it has appeared, I can't do anything :( Has anyone met with similar things??? ...

spectre model files
Hi - I am trying to use spectre built-in primitives in my verilog AMS design using Cadence Environment tools. From cdsdoc, I understand that I have to create a primitive table in the directory in which I have my design. And apart from the primitive table, I should also have a model file. I am able to locate the main primitive table in /cadence/ldv41/tools.sun4v/affirma_ams/etc/files/spec_builtin.apt, but I cant find the model files...There are some model files in /cadence/local/models/spectre, but they are all NMOS or PMOS models. I was looking for resitors, capacitors, etc. Is there a speci...

Spectre Comms Rom
I have one of these for the vtx 5000, if anyone wants it. No garantees sorry! Brian -- From the Bed of Brian Gaff. The email is valid as briang1@blueyonder.co.uk Blind user. On Tuesday, 24 April 2012 19:54:18 UTC+1, Brian Gaff wrote: > I have one of these for the vtx 5000, if anyone wants it. No garantees > sorry! > > Brian > > -- > From the Bed of Brian Gaff. > The email is valid as briang1@blueyonder.co.uk > Blind user. yes please -any info? doesn't have proportional font or push printing for screen thirds? ...

spectre conditional models
Hi All, I am try to do something like the following in a spectre library file: // parameters useothermodel=0 if (useothermodel==1) { model mymodel othermodel } else { model mymodel normalmodel } // But spectre gives me a syntax error on the line after "model mymodel othermodel". A line which should not even have been read ! It turns out that instances or subcircuits are accepted in an if-then-else statement, but not models (dammit!). In my real case, there are many (many) models to be defined inside these if statements. Besides, the files that bear the "model" state...

Spectre Error #4
Dear group, We are setting up a new designkit and we are experiencing a strange problem when simulting. Inside a Verilog-A File I see following lines, which create a syntax error and I dont know why because I do not understand verilog-A Spectre just reports a syntax error during AHDL Readin. Whats going wrong ? `MPRcc( TR , 21.0 , "degC" , -250.0 , 1000.0 , "nominal (reference) temperature") `MPRoo( LMIN , 1.0e-08 , "m" , 0.0 , inf , "minimum allowed drawn length") `MPRoo( LMAX , 9.9e+09 , "m"...

spectre model file ?
dear all, i am new bie to cadence spectre. if i want to use hspice level 3 parameters of nmos and pmos,is it enough to enter the hspice parameters in spectre format with mos3 as level in a text file and save it in " .scs " extension and " ON " the read spice netlist function on analog design->set up-> environment option. or i have to convert the hspice level 3 parameters into spectre mos3 equivalent parameters using spp command why i am asking,i am getting some warning like wmlt,lmlt and some parameters are not valid in spectre while...

Web resources about - A spectre is haunting this newsgroup, the spectre of metastability - comp.arch.fpga

Metastability - Wikipedia, the free encyclopedia
A single particle analogy may be drawn with a ball resting in a hollow on a slope. With some perturbation the ball may start rolling again to ...

Profile - Dr Tom Roberts - Department of Chemistry and Biomolecular Sciences - Faculty of Science - Macquarie ...
Functions of Serpins in Plants and Algae Serpins are a family of proteins with unusual properties including structural metastability and an ...

BICEP2: some winners and losers
While some theories and theorists got even bangier, others were banged in their heads Update: on Friday, Nature will publish a rather helpful ...

Digital Questions
This page contains Digital Electronics tutorial, Combinational logic, Sequential logic, Kmaps, digital numbering system, logic gate truth tables, ...

Updates and upcoming events
Tensegrity icosahedrons are used to model biologic organisms from viruses to vertebrates, their cells, systems and subsystems.

Digital Design Interview Questions - 3
Set up time is the amount of time before the clock edge that the input signal needs to be stable to guarantee it is accepted properly on the ...

Can We Grasp The Brain’s Complexity?
An entertaining paper just out in Frontiers in Systems Neuroscience offers a panoramic view of the whole of neuroscience: Enlarging the scope: ...

Power awareness in RTL design analysis
Power awareness in RTL design analysis

SOC Verification: Can We Stop the Stampede? - EE Times
I see immediate parallels between the cowboys of the Wild West and today's system-on-chip (SoC) design and verification engineers. Cowhands struggle ...

Advanced Search
Default Description

Resources last updated: 3/20/2016 12:45:19 AM