Original (5V) Xilinx Spartan ?

[Luiz Carlos]

Hi Peter,

Sorry, Luiz. I can handle German, French, Italian and Scandinavian.

Amazing!

But Spanish and Portuguese are not my forte...

What a pity!

What is it you want to discuss?
Peter

I just said that, if you want, we can recapitulate the metastability
stuff. During your absence we found the cure for metastability (Rick
designed the circuit), we built, tested and patented a perpetual
motion machine (Ray worked a lot here) and finally, we almost finished
a prototype of a Time Machine. We are preparing a Dinosaur Hunt, do
you want to join us?

Now, coming back to Earth.
You said (@ Thinking out loud about metastability): "I have never seen
strange levels or oscillations ( well, 25 years ago we had TTL
oscillations). Metastability just affects the delay on the Q output."
But Philip Freidin showed (@ Mitigating metastability) some pictures
of the FF output during metastability that disagree.
Do the Xilinx FFs have a different behavior?

One more question.
You also said (@Thinking out loud about metastability): "Remember:
Metastability causes an extra 3 ns of unpredictable delay once in a
billion years... Seems to be an affordable risk.".
What kind of input? What clock frequency?

Luiz Carlos

 

[Luiz Carlos]

Peter,

Forget my last question, I saw your post at "opinions are OK".

Luiz Carlos

 

[Luiz Carlos]

Hi Austin,

I was just kidding with Peter. No ofense at all. I just said that, if
he wants, we can recapitulate all the metastability stuff, so he does
not need to be sad about not beeing here! See my other post.

As he come back from Portugal, I wrote in portuguese!

Luiz Carlos

 

[Peter Alfke]

Luiz Carlos wrote:

You said (@ Thinking out loud about metastability): "I have never seen
strange levels or oscillations ( well, 25 years ago we had TTL
oscillations). Metastability just affects the delay on the Q output."
But Philip Freidin showed (@ Mitigating metastability) some pictures
of the FF output during metastability that disagree.
Do the Xilinx FFs have a different behavior?

I have a lot of respect for Phil, we are personal friends and have
worked together for over 20 years. I think he used old TTL pictures.

One more question.
You also said (@Thinking out loud about metastability): "Remember:
Metastability causes an extra 3 ns of unpredictable delay once in a
billion years... Seems to be an affordable risk.".
What kind of input? What clock frequency?

300 MHz clock, ~50 MHz data, Virtex-IIPro. See TechXclusive on the
Xilinx web.

Peter

 

[Ray Andraka]

Peter,

My understanding was that those pictures were of Xilinx parts. Of course if
you sample them at a low enough rate, it looks like an unpredictable delay
even if it is not.

Peter Alfke wrote:

I have a lot of respect for Phil, we are personal friends and have
worked together for over 20 years. I think he used old TTL pictures.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

 

[Jim Granville]

Ray Andraka wrote:

Peter,

My understanding was that those pictures were of Xilinx parts.

Can Philip Freidin clarify these photos ?
ie devices (date codes & process?) under test,
and clock / data conditions to stimulate the
failures, and appx failure rates observed ?

-jg

From Philip's excellent FAQ:

The test systems that I have designed are quite different. These
test systems only collect trajectory data when the flip flop
goes metastable, and they sample the DUT output at 1GSamples per
second, thus taking a sample every nanosecond. The result is
that the scope pictures I have show the actual trajectory of
the metastable.

For your viewing pleasure, I have put them up on the web:

www.fpga-faq.com/Images/meta_pic_1.jpg
www.fpga-faq.com/Images/meta_pic_2.jpg
www.fpga-faq.com/Images/meta_pic_3.jpg

These are far from just delayed outputs! The end result though
is still the same, systems that fail. But seeing these scope
pictures of the actual Q output might make you think about how
you measure metastability.

Of course if
you sample them at a low enough rate, it looks like an unpredictable delay
even if it is not.

Peter Alfke wrote:

I have a lot of respect for Phil, we are personal friends and have
worked together for over 20 years. I think he used old TTL pictures.

 

[Hal Murray]

I see why metastability can't be detected or corrected within the
digital domain, but I still don't quite understand why metasability
can't be detected in the ANALOG domain and then corrected after a
FIXED (rather than exponentially decaying probability) time-window
after the clock cycle to be forced into one of the stable states.

[Apologies if everybody was hoping this horse was dead.]

Suppose you have an analog detector. It's output is 0, 1, or
maybe when in transition. How do you turn that into a clean
digital signal? Doing that is the same as solving the metastability
problem.

A digital logic gate when operating near threshold is roughly
linear. It's trying to decide if the input is above or below
the threshold. A gate is really an analog circuit if you look
hard enough, just saturated most of the time. But the times we
are interested in are when it's not saturated.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Peter Alfke]

I talked with Phil, and he mentioned that his metastability tests that
generated the figures showing some oscillation were actually done with
Xilinx XC4000 devices. So I stand corrected. If this type of behavior
still exists in Virtex ( and I do not have Phil's sophisticated trigger
set-up ), then I might have underreported the delay by up to a factor of
2. This should not be a real problem, since we are really talking about
much larger orders of magnitude, like millions and billions of years.
But yes, I was wrong in claiming that CMOS latches cannot oscillate for
one period...
Eating humble pie,
Peter Alfke
===================
Ray Andraka wrote:

Peter,

My understanding was that those pictures were of Xilinx parts. Of course if
you sample them at a low enough rate, it looks like an unpredictable delay
even if it is not.

Peter Alfke wrote:

I have a lot of respect for Phil, we are personal friends and have
worked together for over 20 years. I think he used old TTL pictures.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

 

[rickman]

rob d wrote:

Here is a solution that I can't yet find a hole in.

Put a comparator on the output of the flip flop(ff1) and call its
output "meta"
comparator indicates meta when ff1 output is just above a logic 1 min
down to just below a logic 0 max.

now create the next flip flop

when meta then ff2 = not ff2 (if ff1 is metastable its input was
changing)
else ff2 = ff1.

ff2 will never be meta stable as long as timing for meta is met.

We can now use ff1 in a state machine by creating a combinatorial
signal that reflects what ff1 is doing or trying to do.

when meta then ff1_meta_hard = ff2 else ff1_meta_hard = ff1.

even if you don't shoot me down I don't expect thousands of
comparators in Vertex 4!

I don't understand why this is so hard to understand. Nothing personal,
it is just that a lot of people keep trying to make the comparator
solution work. The problem is that the output of the comparator has the
same problem as the output of FF1. It can be inderterminate (between
logic 0 and logic 1) for an indeterminate amount of time. "meta" can be
in transition at the time that FF2 is clocked with will clearly lead to
FF2 going metastable.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Marc Baker]

The Xilinx web pages typically combine 5V Spartan with the 3.3V Spartan-XL and
refer to the "Spartan/XL" together since they have the same basic architecture.
The data sheet is also a combined document. Let me know what search options you
used that came up empty for the XCS10. According to muxlab.com MuxLab is "is a
leading designer of value-added connectivity hardware allowing audio-video and
data equipment to be connected via cost-effective copper twisted pair." No
relation to Xilinx and not a second source. I don't see them mentioned on the
Newark web site.

Jon Elson wrote:

Well, the Xilinx web pages show no mention of Spartan without the XL,
II, etc. and a search of XCS10 comes up with nothing. Digi-Key used to stock
the
XCS10 through XCS40 or so, and other distributors also had them in their
on-line catalogs. Now, when I search at various distributors, I either get no
match or
"special order". I'll have to talk to some people. Also, who is "MuxLab,
Inc."? They
are apparently supplying something to Newark with the part number
XCS10-3PC84C, and call it a CMOS-CPLD-xxx or something like that. Is that a
real second source?

Or, is MuxLab just emptying out their warehouse full of old parts?

Thanks,

Jon

--
Marc Baker
Xilinx Applications
(408) 879-5375

 

[rob d]

rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F686187.8F7C65A5@yahoo.com>...

rob d wrote:

Here is a solution that I can't yet find a hole in.

Put a comparator on the output of the flip flop(ff1) and call its
output "meta"
comparator indicates meta when ff1 output is just above a logic 1 min
down to just below a logic 0 max.

now create the next flip flop

when meta then ff2 = not ff2 (if ff1 is metastable its input was
changing)
else ff2 = ff1.

ff2 will never be meta stable as long as timing for meta is met.

We can now use ff1 in a state machine by creating a combinatorial
signal that reflects what ff1 is doing or trying to do.

when meta then ff1_meta_hard = ff2 else ff1_meta_hard = ff1.

even if you don't shoot me down I don't expect thousands of
comparators in Vertex 4!

I don't understand why this is so hard to understand. Nothing personal,
it is just that a lot of people keep trying to make the comparator
solution work. The problem is that the output of the comparator has the
same problem as the output of FF1. It can be inderterminate (between
logic 0 and logic 1) for an indeterminate amount of time. "meta" can be
in transition at the time that FF2 is clocked with will clearly lead to
FF2 going metastable.

I accept that with op amps with non infinite gain then just at the
edges of the comparator detection the comparator timing might be slow
or unknown(what you have called metastable-I don't know why), this
does not matter.

Lets just suppose that ff1 was only just metastable and was nearly
high. In this scenario with meta unknown then, the mux on ff2 may be
switching wildly or trying to average (I don't know modern semi
theory) the two inputs to ff2. However ff1 is just about 1 and so is
"not ff2" and ff2 will see a solid 1.

There may be a hole in my "design" but unless there is something about
op amp comparators I have forgotten (I did the theory about 15 yrs
ago) then this isn't it.

The problem with a forum like this is that someone steps out of the
box and other people think that the "out of boxer" has no experience
at all. As my last sentence sort of implied I'm not looking for a
solution, the maths for metastability is well understood and I'm not
looking to pay the obvious penalties for not using the classic
solution.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[rob d]

Jim Granville <jim.granville@designtools.co.nz> wrote in message news:<3F6BB012.1C31@designtools.co.nz>...

rob d wrote:

snip> Lets just suppose that ff1 was only just metastable and was
nearly
high. In this scenario with meta unknown then, the mux on ff2 may be
switching wildly or trying to average (I don't know modern semi
theory) the two inputs to ff2. However ff1 is just about 1 and so is
"not ff2" and ff2 will see a solid 1.

There may be a hole in my "design" but unless there is something about
op amp comparators I have forgotten (I did the theory about 15 yrs
ago) then this isn't it.

The problem with a forum like this is that someone steps out of the
box and other people think that the "out of boxer" has no experience
at all. As my last sentence sort of implied I'm not looking for a
solution, the maths for metastability is well understood and I'm not
looking to pay the obvious penalties for not using the classic
solution.

Try thinking also in the time domain, as well as the voltage domain.

(ideal) Comparators may solve a voltage domain uncertainty, but
what about a signal like in Philip's photos, that
'heads one way, then changes it's mind', but is otherwise valid in
a digital sense. ( effectively a runt pulse )
Hard to see how any extra sensing can 'fix that after the event' ?

-jg

There is an issue if FF1 is metastable on two successive clock edges
when the input is slowly rising as FF2 will toggle twice, which simple
design practice can solve, but there is no issue if FF1 is meta twice
with an input pulse at exactly the clock period (FF2 toggling twice is
what the input has done). Other than that I haven't understood you.

 

[Jim Granville]

Peter Alfke wrote:

Let me try to repair the damage I did with my impatience:

When capturing data that is asynchronous with the clock, the flip-flop
will inevitably go metastable sooner or later.
Metastability manifests itself in unpredictable additional clock-to-out delay.
The user knows the clock frequency, probably knows the data freqiuency
at least roughly, and should know the amount of tolerable extra delay,
or the acceptable Mean-Time-Between-Failure.

Then one can consult the app note and table and see the connection.
MTBF is always inverse proportional to the product of the clock and data frequencies.

Last October I published a XilinxTechXclusives paper which shows that at
a 300 MHz clock rate and 50 MHz data rate, the MTBF is one microsecond
for a total clock-to-Q plus set-up time of 1.0 ns. MTBF then increases a
million times for every additional half nanosecond available as extra delay.
At 3 ns, the MTBF is over a billion years.
All MTBF values must be scaled by the product of the two frequencies:
At 100 MHz clock and ~10 MHz data, the MTBF is, therefore, 15 times
longer.

Is this correct ?
Wouldn't the 3.3nS to 10nS increase in clock time, buy you (10-3.3)/0.5
lots of 'a million times' scalings ?

Of do you mean the time to trigger a Event, not fail due to one ?

What about this issue:
With a CLK.Data stream, the CLK pulses that are not
adjacent to the DATA edges, cannot have metastable events, so
should not enter the scaling ?



The best model would seem to be a Data.Aperture AND a Clock.Aperture,
(both very small, but I don't think they HAVE to be equal ) and
when they overlap/come closer than a critical time threshold,
the metatstable dice rolls. What happens after the roll, depends on
how far away the next clock is (call this the settling tail)

Prediction stats would be an area-overlap basis, and assuming
async signals ( non zero phase velocity ) the area product would
be proportional to
(Data.Aperture/Data.EdgeT) x (Clock.Aperture/Clock.EdgeT)

Typically, Data.EdgeT = Data H or L time
Clock.EdgeT = ClkPeriod

This is average trigger/dice roll prediction, but the
actual 'metastable dice roll profile' will depend on the
phase velocity, and will have peaks much higher than the average.

What if your system hits/moves very slowly over this 'phase jackpot' ?

Here, area-mitigation stats are not much use, and you have to rely
mainly on the settling tail to next clock ( and maybe a small amount on
the natural system jitter )
IIRC Peter quoted 0.05fs virtual aperture time, and
natural jitter is likely to be some few ps - certainly large relative to
the aperture ?

An experimental setup designed to focus on this phase jackpot,
would give interesting results, and allow peak estimates, as well as a
higher
occurance for more usefull Tail stats gathering.


Summary : Best predictor model would have Data.Aperture, Clock.Aperture
and a Settling Tail.
Exact nature of the settling tail is system measurable over a range
of a few decades, but extrapolation is dangerous.

So, in short:
Metastability is unavoidable. All attempts to avoid it are inherently
doomed, but the quantitative impact of metastability is quite tolerable.

That's it.

Agreed. I still think from an 'average user' perspective, that a
specific 'design cell' approach would help.

Also, from a technical detail viewpoint, implementing a
'regenerative latch triplet' [Pre-Latch + Flip Flop] or [Dual Flip Flop]
in a single local space, removes routing delays from one metastable
tail.

It does NOT 'fix' metastable behaviour, but it does encapsulate it,
and move it to the best the silicon can provide, and eliminates
the potentially variable routing delays.
It also allows for future technical research and improvements to
reduce the apertures, and the settling tail.

- jg

Peter Alfke, Xilinx Applications
===================
Jim Granville wrote:

Austin Lesea wrote:

So what is wrong with telling folks that fixing
metastability is a myth and waste of time?

Nothing.

It is similar to the patent office not considering perpetual motion
machines.

The basic physics of it is well understood, and that is that.....

Perhaps not a ideal choice of words

The practical reality and impact of metastability are (hopefully)
well understood.
As to basic physics, or even models, well - that seemed to be pretty
much up in the air

From all of this, I think there emerges a case for
a 'Metastable Block' or cell, which can be used in the tools,
and that the tools can model, and sdvise-the-use-of.

This could have variants of Fall/Rise edge dual Flip Flips, or
a Latch+FF ( effectively the same thing, but may be a better hardware
fit on some target devices )
( Tsu = half clock),
or
Rise/Rise dual Flip Flop
( Tsu = full clock, but longer metastable settling time )

This would help those who have yet to encounter WHY they
need to address metastable events.

- jg

 

[Peter Alfke]

I checked with Spartan marketing ( I will never quote specific prices
without their blessing ), and they confirmed my numbers:

The price per LUT/flip-flop is not constant.
At the small end, the package cost drives it up,
and at the high end, it is the yield loss that drives it up.

The sweet spot is around the 3S1000 with 15 360 LUTs/FFs.
It will sell in late 2004, slowest speed grade in large quantities for
$20.
That's 0.13 cents per LUT/FF.

The number for the 2S400 is $10 for 3840 LUTs/FFs = 0.26 cents per LUT
For the top-end 3S5000 it is $150 for 66 560 LUTs/FFs = 0.23 cents per LUT.

That means I was pretty close with my 0.2 cents.

Peter Alfke

===================================
rickman wrote:

Peter,

I would like to know how you came to this number for the Spartan3
parts. If I use this number for the XC3S400, I get 7168 x $0.002 =
$14.336. For the XC3S5000 I get 66,560 x $.002 = $133.12. Are these
realistic prices at all? What assumptions did you use?

I understand that your .2 cents figure is only a rough rule of thumb,
but to be at all useful an understanding of the basis is needed.

BTW, the discussion on metastability may appear to be a waste of
"bandwidth", but it is an important discussion since most people seem to
learn about it here rather than in school or elsewhere. I know there
were a great many things that were never even mentioned in school that
turned out to be essential to designing good circuits in the "real
world".

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Pete Fraser]

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3F5FB508.CC525671@xilinx.com...

I checked with Spartan marketing ( I will never quote specific prices
without their blessing ), and they confirmed my numbers:

The price per LUT/flip-flop is not constant.
At the small end, the package cost drives it up,
and at the high end, it is the yield loss that drives it up.

The sweet spot is around the 3S1000 with 15 360 LUTs/FFs.
It will sell in late 2004, slowest speed grade in large quantities for
$20.
That's 0.13 cents per LUT/FF.

I'm assuming XC3S1000-4FG676C will cost $85.65 in 5000 quantities.

(This was a recent Xilinx quote.)

I also assume that the $20 figure is for seriously large quanities,
but I'm still surprised there's that much of a difference.

 

[rickman]

Jim Granville wrote:

Peter Alfke wrote:

Let me try to repair the damage I did with my impatience:

When capturing data that is asynchronous with the clock, the flip-flop
will inevitably go metastable sooner or later.
Metastability manifests itself in unpredictable additional clock-to-out delay.
The user knows the clock frequency, probably knows the data freqiuency
at least roughly, and should know the amount of tolerable extra delay,
or the acceptable Mean-Time-Between-Failure.

Then one can consult the app note and table and see the connection.
MTBF is always inverse proportional to the product of the clock and data frequencies.

Last October I published a XilinxTechXclusives paper which shows that at
a 300 MHz clock rate and 50 MHz data rate, the MTBF is one microsecond
for a total clock-to-Q plus set-up time of 1.0 ns. MTBF then increases a
million times for every additional half nanosecond available as extra delay.
At 3 ns, the MTBF is over a billion years.
All MTBF values must be scaled by the product of the two frequencies:
At 100 MHz clock and ~10 MHz data, the MTBF is, therefore, 15 times
longer.

Is this correct ?
Wouldn't the 3.3nS to 10nS increase in clock time, buy you (10-3.3)/0.5
lots of 'a million times' scalings ?

Jim, I have seen your name here before, but I don't know what your
level of understanding of metastability is. So forgive me if I sound
like I am talking down to you. I don't know if you are trying to
discuss fine details of this topic or if you are new to the issues of
metastability.

If you look up references about metastability you will find that the
MTBF time scales linearly with clock and data rate, but exponentially
with settling time. There is a constant for each part of the equation.
These two constants are what characterize a particular FF design and
process used to build it. Peter's comment is saying that if you allow
just 3 ns settling time with his rates and parts, you will have an MTBF
of a billion years. Certainly you can go longer and get MTBF times
longer than the age of the universe. So yes, 10 ns would be way more
than enough.

Of do you mean the time to trigger a Event, not fail due to one ?

No, a metastable event will happen with a much higher rate based only on
the rate of the clock and data. But it will have no impact on your
circuit if you don't use the output until after the metastability has
settled out. Given a time period this calculation determines how often
the metastable event will persist and cause an error.

What about this issue:
With a CLK.Data stream, the CLK pulses that are not
adjacent to the DATA edges, cannot have metastable events, so
should not enter the scaling ?

This is already considered in the calculation. That is why the
frequencies are multiplied. The assumption is that the two rates are
truely asynchronous and are not correlated in any way. The the chance
of them happening in just the right timing relation is a function of how
often each of them is occuring.

The best model would seem to be a Data.Aperture AND a Clock.Aperture,
(both very small, but I don't think they HAVE to be equal ) and
when they overlap/come closer than a critical time threshold,
the metatstable dice rolls. What happens after the roll, depends on
how far away the next clock is (call this the settling tail)

This may sound good, but it no different than the current model and
would be much harder to measure. It is best not to think too hard about
this, but rather to be a bit on the empirical side. That seems to be
one way that Peter is very smart. His measurements seem very good to me
and many others. It is no good to rationalize about things you really
can't measure.

Prediction stats would be an area-overlap basis, and assuming
async signals ( non zero phase velocity ) the area product would
be proportional to
(Data.Aperture/Data.EdgeT) x (Clock.Aperture/Clock.EdgeT)

Typically, Data.EdgeT = Data H or L time
Clock.EdgeT = ClkPeriod

This is average trigger/dice roll prediction, but the
actual 'metastable dice roll profile' will depend on the
phase velocity, and will have peaks much higher than the average.

I think "phase velocity" is *way* over the top. Before improving on the
current formula, it would be good to find something wrong with it. Is
there anything about it that falls short?

What if your system hits/moves very slowly over this 'phase jackpot' ?

Here, area-mitigation stats are not much use, and you have to rely
mainly on the settling tail to next clock ( and maybe a small amount on
the natural system jitter )
IIRC Peter quoted 0.05fs virtual aperture time, and
natural jitter is likely to be some few ps - certainly large relative to
the aperture ?

All of this is really just a way to relate what is happening. Since the
noise in the circuit is relatively large, I would expect tons more
jitter in the "window" than the actual width. So really the fs window
is just a concept, not a very real event.

An experimental setup designed to focus on this phase jackpot,
would give interesting results, and allow peak estimates, as well as a
higher
occurance for more usefull Tail stats gathering.


Summary : Best predictor model would have Data.Aperture, Clock.Aperture
and a Settling Tail.
Exact nature of the settling tail is system measurable over a range
of a few decades, but extrapolation is dangerous.

Can you explain how this would be better than the current model?

So, in short:
Metastability is unavoidable. All attempts to avoid it are inherently
doomed, but the quantitative impact of metastability is quite tolerable.

That's it.

Agreed. I still think from an 'average user' perspective, that a
specific 'design cell' approach would help.

Also, from a technical detail viewpoint, implementing a
'regenerative latch triplet' [Pre-Latch + Flip Flop] or [Dual Flip Flop]
in a single local space, removes routing delays from one metastable
tail.

It does NOT 'fix' metastable behaviour, but it does encapsulate it,
and move it to the best the silicon can provide, and eliminates
the potentially variable routing delays.
It also allows for future technical research and improvements to
reduce the apertures, and the settling tail.

Or you can just use the double FF approach and require a routing time
for this path that is at least 3 ns less than the clock period. Again,
simple, empirical and effective.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[rickman]

Pete Fraser wrote:

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3F5FB508.CC525671@xilinx.com...
I checked with Spartan marketing ( I will never quote specific prices
without their blessing ), and they confirmed my numbers:

The price per LUT/flip-flop is not constant.
At the small end, the package cost drives it up,
and at the high end, it is the yield loss that drives it up.

The sweet spot is around the 3S1000 with 15 360 LUTs/FFs.
It will sell in late 2004, slowest speed grade in large quantities for
$20.
That's 0.13 cents per LUT/FF.


I'm assuming XC3S1000-4FG676C will cost $85.65 in 5000 quantities.

(This was a recent Xilinx quote.)

I also assume that the $20 figure is for seriously large quanities,
but I'm still surprised there's that much of a difference.

I recommend that you find an alternative and go back to your supplier
for a better price. I have not gotten a quote for this part, but based
on my experience you should be able to do better than $40 at your volume
and package. You might be able to get below $30.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Jim Granville]

rickman wrote:

Jim Granville wrote:

Peter Alfke wrote:

Let me try to repair the damage I did with my impatience:

When capturing data that is asynchronous with the clock, the flip-flop
will inevitably go metastable sooner or later.
Metastability manifests itself in unpredictable additional clock-to-out delay.
The user knows the clock frequency, probably knows the data freqiuency
at least roughly, and should know the amount of tolerable extra delay,
or the acceptable Mean-Time-Between-Failure.

Then one can consult the app note and table and see the connection.
MTBF is always inverse proportional to the product of the clock and data frequencies.

Last October I published a XilinxTechXclusives paper which shows that at
a 300 MHz clock rate and 50 MHz data rate, the MTBF is one microsecond
for a total clock-to-Q plus set-up time of 1.0 ns. MTBF then increases a
million times for every additional half nanosecond available as extra delay.
At 3 ns, the MTBF is over a billion years.
All MTBF values must be scaled by the product of the two frequencies:
At 100 MHz clock and ~10 MHz data, the MTBF is, therefore, 15 times
longer.

Is this correct ?
Wouldn't the 3.3nS to 10nS increase in clock time, buy you (10-3.3)/0.5
lots of 'a million times' scalings ?

Jim, I have seen your name here before, but I don't know what your
level of understanding of metastability is. So forgive me if I sound
like I am talking down to you. I don't know if you are trying to
discuss fine details of this topic or if you are new to the issues of
metastability.

Sorry, was I that unclear ?

If you look up references about metastability you will find that the
MTBF time scales linearly with clock and data rate, but exponentially
with settling time. There is a constant for each part of the equation.
These two constants are what characterize a particular FF design and
process used to build it.

Peter's comment is saying that if you allow
just 3 ns settling time with his rates and parts, you will have an MTBF
of a billion years. Certainly you can go longer and get MTBF times
longer than the age of the universe. So yes, 10 ns would be way more
than enough.

I think we are saying the same thing.

Or do you mean the time to trigger a Event, not fail due to one ?

No, a metastable event will happen with a much higher rate based only on
the rate of the clock and data. But it will have no impact on your
circuit if you don't use the output until after the metastability has
settled out. Given a time period this calculation determines how often
the metastable event will persist and cause an error.

I was asking Peter for a clarify, only he can know what he meant.

What about this issue:
With a CLK.Data stream, the CLK pulses that are not
adjacent to the DATA edges, cannot have metastable events, so
should not enter the scaling ?

This is already considered in the calculation. That is why the
frequencies are multiplied. The assumption is that the two rates are
truely asynchronous and are not correlated in any way. The the chance
of them happening in just the right timing relation is a function of how
often each of them is occuring.


The best model would seem to be a Data.Aperture AND a Clock.Aperture,
(both very small, but I don't think they HAVE to be equal ) and
when they overlap/come closer than a critical time threshold,
the metatstable dice rolls. What happens after the roll, depends on
how far away the next clock is (call this the settling tail)

This may sound good, but it no different than the current model and
would be much harder to measure. It is best not to think too hard about
this, but rather to be a bit on the empirical side. That seems to be
one way that Peter is very smart. His measurements seem very good to me
and many others.
It is no good to rationalize about things you really can't measure.

I beg to differ. The best understanding come from finding models that
are easy to explain, and can be used in the widest manner, and that
also help guide (new) measurements and understanding.
Being a designer, I am all for 'hard numbers'.

Prediction stats would be an area-overlap basis, and assuming
async signals ( non zero phase velocity ) the area product would
be proportional to
(Data.Aperture/Data.EdgeT) x (Clock.Aperture/Clock.EdgeT)

Typically, Data.EdgeT = Data H or L time
Clock.EdgeT = ClkPeriod

This is average trigger/dice roll prediction, but the
actual 'metastable dice roll profile' will depend on the
phase velocity, and will have peaks much higher than the average.

I think "phase velocity" is *way* over the top. Before improving on the
current formula, it would be good to find something wrong with it.
Is there anything about it that falls short?

Above you state
" The assumption is that the two rates are truely asynchronous
and are not correlated in any way."

If the model cannot cope with other than this
hypothetical ideal, that's rather 'falling short' ?

The concept of phase velocity is not way over the top, as it
introduces the important concept/point of what to do,
when 'truely async' does not apply, and also what to do, if
you design needs PEAK rather than simple average tolerance.
In some designs, that aspect will be important :

A system can have an 'average MTBF' number of some years,
but still fail a number of times in one hour.

IIRC Austin L. gave a good real-world example ?

What if your system hits/moves very slowly over this 'phase jackpot' ?

Here, area-mitigation stats are not much use, and you have to rely
mainly on the settling tail to next clock ( and maybe a small amount on
the natural system jitter )
IIRC Peter quoted 0.05fs virtual aperture time, and
natural jitter is likely to be some few ps - certainly large relative to
the aperture ?

All of this is really just a way to relate what is happening. Since the
noise in the circuit is relatively large, I would expect tons more
jitter in the "window" than the actual width. So really the fs window
is just a concept, not a very real event.

Agreed, that's why I called it a virtual aperture.
The idea of Clock and data apertures also gives the correct
dimensions to the answer.

An experimental setup designed to focus on this phase jackpot,
would give interesting results, and allow peak estimates, as well as a
higher
occurance for more usefull Tail stats gathering.


Summary : Best predictor model would have Data.Aperture, Clock.Aperture
and a Settling Tail.
Exact nature of the settling tail is system measurable over a range
of a few decades, but extrapolation is dangerous.

Can you explain how this would be better than the current model?

See above. I don't see it as radically different than the current
thinking,
( the tail model is the same, only I'd be more cautious about
far-extrapolation )
but it does allow better handling of peak/average predictions, and
it leads to real measurements to define these two.

So, in short:
Metastability is unavoidable. All attempts to avoid it are inherently
doomed, but the quantitative impact of metastability is quite tolerable.

That's it.

Agreed. I still think from an 'average user' perspective, that a
specific 'design cell' approach would help.

Also, from a technical detail viewpoint, implementing a
'regenerative latch triplet' [Pre-Latch + Flip Flop] or [Dual Flip Flop]
in a single local space, removes routing delays from one metastable
tail.

It does NOT 'fix' metastable behaviour, but it does encapsulate it,
and move it to the best the silicon can provide, and eliminates
the potentially variable routing delays.
It also allows for future technical research and improvements to
reduce the apertures, and the settling tail.

Or you can just use the double FF approach and require a routing time
for this path that is at least 3 ns less than the clock period. Again,
simple, empirical and effective.

But you have to know enough to take those steps, and it is still
exposed,
more than encapsulated.
I'm thinking of the newest breed of graduate, and they represent more
the
average user than you or I

-jg

 

[Peter Alfke]

I meant to write a lengthy rebuttal and explanation, but rickman said it all.
Thanks !
Peter Alfke

 

[Peter Alfke]

I have a new idea how to simplify the metstable explanation and calculation.
Following Albert Einstein's advice that everything should be made as
simple as possible, but not any simpler:

We all agree that the extra metastable delay occurs when the data input
changes in a tiny timing window relative to the clock edge. We also
agree that the metastable delay is a strong function of how exactly the
data transition hits the center of that window.
That means, we can define the width of the window as a function of the
expected metastable delay.

Measurements on Virtex-IIPro flip-flops showed that the metastable
window is:

• 0.07 femtoseconds for a delay of 1.5 ns.
• The window gets a million times smaller for every additional 0.5 ns of delay.

Every CMOS flip-flop will behave similarily. The manufacturer just has
to give you the two parameters ( x femtoseconds at a specified delay,
and y times smaller per ns of additional delay)

The rest is simple math, and it even applies to Jim's question of
non-asynchronous data inputs. I like this simple formula because it
directly describes the actual physical behavior of the flip-flop, and
gives the user all the information for any specific systems-oriented
statistical calculations.

Peter Alfke, Xilinx Applications