EDK : FSL macros defined by Xilinx are wrong

Peter Alfke <peter@xilinx.com> wrote in message news:
But we cannot fix it, not with voting, nor with hysteresis, nor with any
other contraptions.

My thanks to Bob Perlman for kicking me in the shins. It's good to have
friends. :)
Peter Alfke
Question: When a D-type flip-flop is in meta-stability, is it's output
(Q pin) voltage equal to the input (D pin) voltage?

If it's not the same voltage, then a cascaded flip-flop, clocked just
after the first one, would not be in meta-stability! Isn't it?

Luiz Carlos
 
The output level of a flip-flop during its metastable time is
irrelevant. If it were in the middle ( which it isn't) we could easily
fix this with a zener diode.
The problem is timing. The Q output can - and will - change to the
opposite state at a totally unpredictable time. That's the problem:
unpredictable timing, not unknown levels.

Cascading flip-flops is the standard remedy, but it introduces latency.

Remember: Metastability causes an extra 3 ns of unpredictable delay once
in a billion years... Seems to be an affordable risk.

Peter Alfke
=========================
Luiz Carlos wrote:
Peter Alfke <peter@xilinx.com> wrote in message news:

But we cannot fix it, not with voting, nor with hysteresis, nor with any
other contraptions.

My thanks to Bob Perlman for kicking me in the shins. It's good to have
friends. :)
Peter Alfke

Question: When a D-type flip-flop is in meta-stability, is it's output
(Q pin) voltage equal to the input (D pin) voltage?

If it's not the same voltage, then a cascaded flip-flop, clocked just
after the first one, would not be in meta-stability! Isn't it?

Luiz Carlos
 
gregs@altera.com (Greg Steinke) wrote in message news:<5c1de958.0308261353.598286c4@posting.google.com>...
Matt,
Generally speaking, this kind of problem indicates that the device did
not correctly receive the preamble to the configuration bitstream, and
therefore did not start to process the data. This explains why nSTATUS
doesn't go low; the device has not yet started to look at the CRC for
each frame of data.
The problem turned out to be in the file I was sending. I was using
an SOF, because I thought it was raw. Once I found the .rbf option, I
switched to that, and it works now. I didn't find mention of this in
appnote 250, which is on Cyclone configuration.

Thanks for your help.
Matt
 
On a sunny day (Tue, 26 Aug 2003 18:58:54 GMT) it happened Rene Tschaggelar
<tschaggelar@dplanet.ch> wrote in
<d8a593f9a0070578ab8201755480f4a3@news.teranews.com>:

NOSPAM@NOSPAM.invalid.com wrote:
Hello,
Please, does anybody know if there's any FPGA manufacturer
that will give a sample FPGA for free?

You're going to spend days and weeks with the free software,
to become familiar.
And you may have to build your own programmer, again a day of
layout and etching, so what does it help if you don't have to
pay 4$ for a 4$ part ?
That will buy you a huge peche melba here, nice if its 40 celcius.
 
FWIW, I'm using the full 5.2i (not Webpack, the full package) as well as
Norton Antivirus and have yet to have any problems related to their
interaction.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"



"Leon Heller" <leon_heller@hotmail.com> wrote in message
news:3f4c8fd6$0$256$cc9e4d1f@news.dial.pipex.com...
In common with some other software I use, WebPack ISE is screwed up by
Norton Anti-virus software; for instance, User Constraints Chip Viewer
hangs. I'm still using 4.2, but 5.2 might have the same problem. I found
this rather puzzling, until I realised what was wrong.

Leon
--
Leon Heller, G1HSM
leon_heller@hotmail.com
http://www.geocities.com/leon_heller
 
I've installed ModelSim 5.7d SE and Xilinx ISE 5. and am trying to
build the Xilinx libraries using

compxlib -s mti_se -f all -l all -o c:\modeltech_5.7b\xilinx_libs -p
c:\Modeltech_5.6b\win32

I can see three modelsim version numbers (5.7d, 5.7b, 5.6b) in the above
four lines. Could this be a problem?

Jim Wu
jimwu88NOOOSPAM@yahoo.com
http://www.geocities.com/jimwu88/chips
 
Philip Freidin wrote:
Maybe the following would help some people:

http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm

Let me be dogmatic:

Flip flops may go metastable when input signals do not meet the setup
and hold specifications with regard to the clock signal. These inputs
include D, CE, CLR, PRE, S, R, T, J, K.

There is no cure for metastability. What you can do is trade latency
of your system for higher MTBF.

People that have found a cure are wrong.

Circuits that purport to solve metastability through hysteresis fail
because the hysteresis circuit itself can go metastable

Circuits that purport to solve metastability with injected noise fail
because the noise is as likely to push a non-metastable event into
being a metastable event as it is to helping to resolve such an
event.

Just because current flip flops are better than stuff of a few years
ago, and the probability and resolution time of metastable events
is better, does not mean you can ignore this stuff. If someone
says that things are so good now that "you almost don't have to
worry about this anymore", what it means is that you absolutely
need to understand it and design for it. If you don't, you will
have unreliable systems.

Nothing improves the MTBF of a metastable synchronizer better than
just waiting longer. Not clocking the intermediate signal on the
negative clock edge. Not voting. Not threshold testing. Not adding
noise. Not fancy SPICE simulations. Not predicting circuits. Not
circuits designed to bias the outcome to either 1 or 0. Not
clocking it twice as fast through twice as many flip flops.
Nothing.

From Thomas Cheney, October 1979:

"In closing, there is a great deal of theoretical and experimental
evidence that a region of anomalous behavior exists for every device
that has two stable states. The maturity of this topic is now such that
papers making contrary claims without theoretical or experimental support
should not be accepted for publication".

Philip Freidin
Very well put. I think it is so well said that it sould be added to the
FPGA FAQ. There is a comp.arch.fpga FAQ, right?

--

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
 
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:3f4a0737@dnews.tpgi.com.au...
I notice that the maximum recommended Virtex2pro Vbatt is 2.63V.
Lithium cells put out more than that.
Many chips don't go to sleep mode until the VDD has dropped quite a bit.

See: http://www.howell1964.freeserve.co.uk/MyHitachiPage.htm

The 2V63 value might be the ideal value on their VDD/IDD graph, with most
headroom for battery voltage droop, but lower voltages (e.g. 2V4) might work
just as well.

Is the solution as simple as a series Si diode on the Vbatt line?
Textbooks show zero current up to Vf but I suspect Vf drop depends on
current, even before then.

It should be a quick experiment to see what happens.
 
Thankyou Philip.
But as I said, I don't believe "There is no cure for metastability",
or any other problem. It's just a question of time.

Luiz Carlos.
 
kryten_droid wrote:
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:3f4a0737@dnews.tpgi.com.au...

I notice that the maximum recommended Virtex2pro Vbatt is 2.63V.
Lithium cells put out more than that.


Many chips don't go to sleep mode until the VDD has dropped quite a bit.

See: http://www.howell1964.freeserve.co.uk/MyHitachiPage.htm

Is this relevant to Virtex2pro?


The 2V63 value might be the ideal value on their VDD/IDD graph, with most
headroom for battery voltage droop, but lower voltages (e.g. 2V4) might work
just as well.

The data sheet indicates voltages down to 1.0V are fine.


Is the solution as simple as a series Si diode on the Vbatt line?


Textbooks show zero current up to Vf but I suspect Vf drop depends on
current, even before then.
You might like to Google for the "diode equation". It will confirm your
suspicion. BTW, you need better textbooks ;)

Extrapolating a curve in the 1N914 datasheet gives about 120 - 130mV
forward voltage at 100nA forward current.
(This diode has an ideality factor of about 2.)

The V2P data sheet indicates 100nA typical Ibatt over the recommended
operating conditions. They don't specify a maximum current - I hope
it's not 10uA or something. ;)

Regards,
Allan.
 
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:3f4df8f2$1@dnews.tpgi.com.au...
See: http://www.howell1964.freeserve.co.uk/MyHitachiPage.htm
Is this relevant to Virtex2pro?
The bits about chips often having definite thresholds for low-power modes
kicking in.

The data sheet indicates voltages down to 1.0V are fine.
Great, a 2V4 batt should be fine then.

You might like to Google for the "diode equation". It will confirm your
suspicion. BTW, you need better textbooks ;)
No insult to your intelligence intended.
It's just that on most graphs of Vf/If, it does look flat below Vf
threshold.

The V2P data sheet indicates 100nA typical Ibatt over the recommended
operating conditions. They don't specify a maximum current - I hope
it's not 10uA or something. ;)
Even with 700 mV drop, a 2V4 batt should be fine.
By the time it drops to 1V7, it is pretty much out of juice anyway.
 
Luiz,
you need to read up on metastability.
There are things even in physics that have no solution. Perpetual motion
is one. If you want to get philosophical about metastability, read
Heisenberg's Uncertainty papers.

Phil Freidin has described the problem very well. He and I agree 100% on
the problem. But I have made quantitative tests and know the (very low)
probability. Everybody has an opinion, very few have performed measurements...

Peter Alfke
=================================
Luiz Carlos wrote:
Peter Alfke <peter@xilinx.com> wrote in message news:<3F4D17D9.5CFD8B91@xilinx.com>...
The output level of a flip-flop during its metastable time is
irrelevant. If it were in the middle ( which it isn't) we could easily
fix this with a zener diode.
The problem is timing. The Q output can - and will - change to the
opposite state at a totally unpredictable time. That's the problem:
unpredictable timing, not unknown levels.

Cascading flip-flops is the standard remedy, but it introduces latency.

Remember: Metastability causes an extra 3 ns of unpredictable delay once
in a billion years... Seems to be an affordable risk.

Peter Alfke

Peter, kind of disagree.

Of course for the designer, the problem is timing. But the timing
problem is caused by the voltage problem. If we had a well defined
voltage behavior (as I thought, but now I know I were wrong), we could
fix the timing problem (as you said for the "in the middle" problem).
Anyway, I undestood what you said.

I also disagree that the problem has no solution. As an engineer I
don't believe in no solution problems, we just don't know the
solutions yet. But this is philosophy!

Luiz Carlos
 
John, there is only one way to find your answer:
Contact your local sales representative or distributor or FAE for the X
andalso for the A company and explain your requirements in as much
detail as possible ( speed, package, delivery date, etc).
Then let them each give you a quote.

Peter Alfke
============================
John Lee wrote:
Hi all,

What is the price for a maximux of 50K system gates, IO counts is not
an issue, with more than 100K volumn per year? We look at cyclone and
spartan series because Xilinx and Altera claimed they are cheap.

100K is the minimum.

Thanks,
John
 
On 28 Aug 2003 04:08:55 -0700, oen_br@yahoo.com.br (Luiz Carlos) wrote:
Thankyou Philip.
But as I said, I don't believe "There is no cure for metastability",
or any other problem. It's just a question of time.
Yep, you are right, it is just a matter of time. In this case
it is infinite.

When you do your designs do you

A) Do nothing special for async signals entering a synchronous
domain, because some day someone will solve this problem.

or

B) Use multistage synchronizers to move signals from one clock
domain to another, because some day someone will solve this
problem, but it hasn't happened yet.

or

C) Not sure, because I haven't ever seen this problem.

Luiz Carlos.
Philip
 
Jan Panteltje wrote:
On a sunny day (Tue, 26 Aug 2003 18:58:54 GMT) it happened Rene Tschaggelar
tschaggelar@dplanet.ch> wrote in
d8a593f9a0070578ab8201755480f4a3@news.teranews.com>:


NOSPAM@NOSPAM.invalid.com wrote:

Hello,
Please, does anybody know if there's any FPGA manufacturer
that will give a sample FPGA for free?

You're going to spend days and weeks with the free software,
to become familiar.
And you may have to build your own programmer, again a day of
layout and etching, so what does it help if you don't have to
pay 4$ for a 4$ part ?

That will buy you a huge peche melba here, nice if its 40 celcius.

Yes.
I'd get the peche melba by saving my time by not spending a
few hours on the internet looking for free samples of 4$ parts.

Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
 
Ray Andraka <ray@andraka.com> wrote in message news:<3F4DED0E.574A03F9@andraka.com>...
You sound like a good candidate to spend you time pursuing a perpetual motion machine.

Ray, maybe we can absorb some energy from a parallel universe and ...
:)

From the site referred by Philip:
"Hopefully, the discussion will discourage further attempts to
eliminate
this unavoidable characteristic"

I think a researcher should never say something like that. The right
phrase should be:
Hopefully, the discussion will encourage further attemps to better
understand and avoid this characteristic.

Nobody knows everything. Physics don't change (I hope), but the way we
model it is always evolving. Things considered impossible became
possible.


The physics stipulate that you'll have a probability of hitting a metastable state. As
processes improve, we can narrow the width of the window, but we can't eliminate it.
Narrowing the width reduces the probability of hitting it for a fixed clock rate. Trouble
is, as the process improvements occur that permit narrowing the window, the clock speeds
also increase, so unless the designer designs for metastbility, the odds may not improve.
I understood the problem. I've found some "solutions", but when I
tried to prove them I could only prove they don't work at all. But,
like Winston Churchill, I'll never surrender, not any time soon.

Anyway, thankyou. I always appreciate what you (Ray), Austin, Peter,
Rick, and everybody else that contributes here have to say. Well,
Peter's "Grrr" not included :).

Luiz Carlos.
 
Hi Peter:

the problem with metastability is probably best understood by looking
through some of the ieee papers by Dike and Burton - these guys did the
measurements and there is no solution - metastability requires thermal
noise on two nodes inside a flop(including the Xilinx model that I saw a
couple years ago) to force the output change, and that's a statistical
quantity - metastability can reign out to infinity, although the
probability is small. No solution known to us under device physics as
we know it now, just getting the probabilities smaller. This is why
hold time is just a statistic, and much like we qualify things under
BERT and jitter (more statistical quantities), we are human and guessing
our best.

Andrew

Peter Alfke wrote:

Luiz,
you need to read up on metastability.
There are things even in physics that have no solution. Perpetual motion
is one. If you want to get philosophical about metastability, read
Heisenberg's Uncertainty papers.

Phil Freidin has described the problem very well. He and I agree 100% on
the problem. But I have made quantitative tests and know the (very low)
probability. Everybody has an opinion, very few have performed measurements...

Peter Alfke
=================================
Luiz Carlos wrote:


Peter Alfke <peter@xilinx.com> wrote in message news:<3F4D17D9.5CFD8B91@xilinx.com>...


The output level of a flip-flop during its metastable time is
irrelevant. If it were in the middle ( which it isn't) we could easily
fix this with a zener diode.
The problem is timing. The Q output can - and will - change to the
opposite state at a totally unpredictable time. That's the problem:
unpredictable timing, not unknown levels.

Cascading flip-flops is the standard remedy, but it introduces latency.

Remember: Metastability causes an extra 3 ns of unpredictable delay once
in a billion years... Seems to be an affordable risk.

Peter Alfke


Peter, kind of disagree.

Of course for the designer, the problem is timing. But the timing
problem is caused by the voltage problem. If we had a well defined
voltage behavior (as I thought, but now I know I were wrong), we could
fix the timing problem (as you said for the "in the middle" problem).
Anyway, I undestood what you said.

I also disagree that the problem has no solution. As an engineer I
don't believe in no solution problems, we just don't know the
solutions yet. But this is philosophy!

Luiz Carlos
 
"Ray Andraka" <ray@andraka.com> wrote in message
news:3F4DED0E.574A03F9@andraka.com...
You sound like a good candidate to spend you time pursuing a perpetual
motion machine.
The physics stipulate that you'll have a probability of hitting a
metastable state. As
processes improve, we can narrow the width of the window, but we can't
eliminate it.
Narrowing the width reduces the probability of hitting it for a fixed
clock rate. Trouble
is, as the process improvements occur that permit narrowing the window,
the clock speeds
also increase, so unless the designer designs for metastbility, the odds
may not improve.

Really the problem is insisting on synchronous designs. Asynchronous
(self-timed) logic doesn't have this problem. Well, metastability is still
there, but the logic will wait, however long it takes, for it to resolve.

I used to hear stories, though I am not sure that I believe them, of people
seeing metastability effects on the PDP-10 (KA10), which used self timed
logic. Supposedly they could see it stop processing, and then start again
with no ill effect. How they know it wasn't in I/O wait, or some other such
state, I have no idea.

-- glen
 
In article <8471ba54.0308280308.232c7bfe@posting.google.com>,
Luiz Carlos <oen_br@yahoo.com.br> wrote:
Thankyou Philip.
But as I said, I don't believe "There is no cure for metastability",
or any other problem. It's just a question of time.
You can make the capture window small, but there is always a finite
chance that you will capture the metastable point.

Basic calculus: IF a curve has two local minima (the stable points),
there must be one local maximum (the metastable point) between the
two. If you happen to capture the input data when it is at the
metastable point, metastability/unstable equilibria happens.

--
Nicholas C. Weaver nweaver@cs.berkeley.edu
 
Philip Freidin <philip@fliptronics.com> wrote in message news:<9scskv82ee51brah4qefbqvefprvtra65r@4ax.com>...
Yep, you are right, it is just a matter of time. In this case
it is infinite.

When you do your designs do you

A) Do nothing special for async signals entering a synchronous
domain, because some day someone will solve this problem.

or

B) Use multistage synchronizers to move signals from one clock
domain to another, because some day someone will solve this
problem, but it hasn't happened yet.

or

C) Not sure, because I haven't ever seen this problem.


Philip

Actually I use the option B). Sorry if you are disappointed! (You were
sarcastic first!)

But I remember people saying CMOS is slow, copper can't be used as
metal layer, and a better example: "We are reaching the silicon
physical limits"!

This is a kind of religion, I don't believe in "not possible", only in
"I don't know how to do".

Anyway, I don't claim to know everything. If you get more persuasive I
can change my mind.

At last, I really liked your first post, I found it very elucidative
(really, no joke).

Luiz Carlos
 

Welcome to EDABoard.com

Sponsor

Back
Top