Original (5V) Xilinx Spartan ?

Hi Jon - of course somebody from Xilinx can confirm this. However, I know for sure that it is well in production and still shipping volumes to many customers.

--Neeraj

Jon,

Still in production, still shipping to customers.

Contact your local sales rep to talk about stocking and pricing. The fact that the newer parts cost a lot less is because they are smaller die for the same functionality. If you think about it, the $ per FPGA gate has been dropping pretty drastically now for many years. In Spartan 3, we are now down to ~100 uCents per gate range. The XCS30 can no hope to compete for this being in such an old technology. Seven years ago, ~$40 for 30K "gates" was a great price....

Aust> Hello,

I think that Farnell stocks them at a reasonable price, for small quantities.

Leon

Oh, I understand this! For electrical reasons, I felt that I needed 5 V compatibility, so designed it with the 5V parts.

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

Avnet has some of them in stock - but they are expensive. Does anyone know of a comprehensive site for obsolete Xilinx part numbers (I used to remember where the obsolete - EOL - parts were listed on the xilinx web page). I would guess they are not makeing many, so die fab time is expensive and the parts are thus expensive - I can't find a LTB notice at

Also, does anyone know who they sell their dies to - Rochester?

Andrew

J> Hello,

Austin,

I'm not tryin to quibble, I just want to understand what your dollar (or cents) figure means. At 0.0001 cents per gate, I get $0.40 for the XC3S400. That is a lot less than the quote I got a few weeks ago. Were you counting "real" gates instead of "user" gates?

Rick,

I was counting what we count as "gates". And the number was for the largest part.

Forget it. The price quote is where the rubber hits the road. Sorry I confused everyone. But plotting the price per gate is an interesting academic exercise that does show a huge price per gate reduction in the last 5 years.

Aust> Aust> >

Here are my 2 cents worth, the way I explained it at FPL2003 in Europe last week:

When I jo>

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

I agree.

Luiz Carlos

Peter, se você quiser, nós podemos rediscutir o assunto. Que tal começarmos pelas figuras enviadas pelo Philip?

Luiz Carlos

Le mot juste...

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

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

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

Aust> Luiz Carlos wrote:

Whoops. Just playing with words. I have no real idea what Luiz said. Faux pas, hein? Nil desperandum. C'est la vie. Che sera sera. (quoted from an old Stoppard play)

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.

Someone care to explain in simple words for an idiot like me?

Nothing.

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

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.

So, >

When I was at Agilent I analysed the causes of failures in some FPGA developments.

About half of all FPGA design related bugs (weighted by the time spent finding them) were associated with asynchronous logic and clock domain crossings. I guess that's not too surprising.

What you may find surprising is that 0% of the clock domain crossing bugs had anything to do with metastability. Glitches and races were the cause.

My interpretation: I think that most designers have heard of metastability, so they put retiming flip flops everywhere. Consequently, metastability related problems don't occur often.

YMMV.

Regards, Allan.