Original (5V) Xilinx Spartan ?

[Jon Elson]

Hello,

What is the status of the old, 5V Spartan family from Xilinx?
I have 2 current products that use them. (XCS10-3PC84 and
XCS30-3TQ144) I suddenly noticed all the distributors either
no longer list these parts or indicate they are special order.
Newark has a part that matches the part number, but lists
the manufacturer as Mux-Lab Inc, and the price is outrageous,
$42.48, with no discount at any quantity. I got them just a couple
of months ago for $16 in small quantity.

I was assured by somebody at Xilinx, possibly Peter Alfke, that
the 5 V Spartan line would continue to be available for a long
time. I suppose if they sold off the masks to an obsolete chip
supplier, that is "still available".

Jon

 

[Neeraj Varma]

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 Elson" <elson@pico-systems.com> wrote in message
news:3F58C665.4070503@pico-systems.com...

Hello,

What is the status of the old, 5V Spartan family from Xilinx?
I have 2 current products that use them. (XCS10-3PC84 and
XCS30-3TQ144) I suddenly noticed all the distributors either
no longer list these parts or indicate they are special order.
Newark has a part that matches the part number, but lists
the manufacturer as Mux-Lab Inc, and the price is outrageous,
$42.48, with no discount at any quantity. I got them just a couple
of months ago for $16 in small quantity.

I was assured by somebody at Xilinx, possibly Peter Alfke, that
the 5 V Spartan line would continue to be available for a long
time. I suppose if they sold off the masks to an obsolete chip
supplier, that is "still available".

Jon

 

[Austin Lesea]

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

Austin

Jon Elson wrote:

Hello,

What is the status of the old, 5V Spartan family from Xilinx?
I have 2 current products that use them. (XCS10-3PC84 and
XCS30-3TQ144) I suddenly noticed all the distributors either
no longer list these parts or indicate they are special order.
Newark has a part that matches the part number, but lists
the manufacturer as Mux-Lab Inc, and the price is outrageous,
$42.48, with no discount at any quantity. I got them just a couple
of months ago for $16 in small quantity.

I was assured by somebody at Xilinx, possibly Peter Alfke, that
the 5 V Spartan line would continue to be available for a long
time. I suppose if they sold off the masks to an obsolete chip
supplier, that is "still available".

Jon

 

[Leon Heller]

"Jon Elson" <elson@pico-systems.com> wrote in message
news:3F58C665.4070503@pico-systems.com...

Hello,

What is the status of the old, 5V Spartan family from Xilinx?
I have 2 current products that use them. (XCS10-3PC84 and
XCS30-3TQ144) I suddenly noticed all the distributors either
no longer list these parts or indicate they are special order.
Newark has a part that matches the part number, but lists
the manufacturer as Mux-Lab Inc, and the price is outrageous,
$42.48, with no discount at any quantity. I got them just a couple
of months ago for $16 in small quantity.

I was assured by somebody at Xilinx, possibly Peter Alfke, that
the 5 V Spartan line would continue to be available for a long
time. I suppose if they sold off the masks to an obsolete chip
supplier, that is "still available".

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

Leon
--
Leon Heller, G1HSM
leon_heller@hotmail.com
http://www.geocities.com/leon_heller

 

[Jon Elson]

Austin Lesea wrote:

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.

Oh, I understand this! For electrical reasons, I felt that I needed 5 V

compatibility,
so designed it with the 5V parts.

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


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

 

[Andrew Paule]

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 http://www.xilinx.com/bvdocs/notifications/chronology.pdf, so I would
guess that they are still making them.

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

Andrew

Jon Elson wrote:

Hello,

What is the status of the old, 5V Spartan family from Xilinx?
I have 2 current products that use them. (XCS10-3PC84 and
XCS30-3TQ144) I suddenly noticed all the distributors either
no longer list these parts or indicate they are special order.
Newark has a part that matches the part number, but lists
the manufacturer as Mux-Lab Inc, and the price is outrageous,
$42.48, with no discount at any quantity. I got them just a couple
of months ago for $16 in small quantity.

I was assured by somebody at Xilinx, possibly Peter Alfke, that
the 5 V Spartan line would continue to be available for a long
time. I suppose if they sold off the masks to an obsolete chip
supplier, that is "still available".

Jon

 

[rickman]

Austin Lesea wrote:

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

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

 

[Austin Lesea]

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.

Austin

rickman wrote:

Austin Lesea wrote:

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

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

 

[Peter Alfke]

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

When I joined Xilinx in 1988, we charged about one dollar per
flip-flop/LUT combination.
Today that price in Virtex is about one cent, and in 2004 in Spartan3 in
high volume it is heading towards 0.2 cents.
Size, package, speed-grade and purchase volume do of course change these
numbers considerably...

Peter Alfke, just back from Lisbon.
I gladly missed all the discussions on how to "eliminate" metastability.
What a waste of engineering effort and internet bandwidth...
===================
Austin Lesea wrote:

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.

Austin

rickman wrote:

Austin Lesea wrote:

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

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

Peter Alfke wrote:

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

When I joined Xilinx in 1988, we charged about one dollar per
flip-flop/LUT combination.
Today that price in Virtex is about one cent, and in 2004 in Spartan3 in
high volume it is heading towards 0.2 cents.
Size, package, speed-grade and purchase volume do of course change these
numbers considerably...

Peter Alfke, just back from Lisbon.
I gladly missed all the discussions on how to "eliminate" metastability.
What a waste of engineering effort and internet bandwidth...

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

 

[Luiz Carlos]

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

I agree.

Luiz Carlos

 

[Luiz Carlos]

Peter Alfke, just back from Lisbon.
I gladly missed all the discussions on how to "eliminate" metastability.
What a waste of engineering effort and internet bandwidth...

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

Luiz Carlos

 

[Tim]

Luiz Carlos wrote:

Peter Alfke, just back from Lisbon.
I gladly missed all the discussions on how to "eliminate"
metastability. What a waste of engineering effort and internet
bandwidth...

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

Luiz Carlos

Le mot juste...

 

[Austin Lesea]

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

Austin

Tim wrote:

Luiz Carlos wrote:
Peter Alfke, just back from Lisbon.
I gladly missed all the discussions on how to "eliminate"
metastability. What a waste of engineering effort and internet
bandwidth...

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

Luiz Carlos

Le mot juste...

 

[Tim]

Austin Lesea wrote:

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

Austin

Tim wrote:

Luiz Carlos wrote:
Peter Alfke, just back from Lisbon.
I gladly missed all the discussions on how to "eliminate"
metastability. What a waste of engineering effort and internet
bandwidth...

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

Luiz Carlos

Le mot juste...

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)

 

[Peter Alfke]

Sorry, Luiz. I can handle German, French, Italian and Scandinavian.
But Spanish and Portuguese are not my forte...
What is it you want to discuss?
Peter

Luiz Carlos wrote:

Peter Alfke, just back from Lisbon.
I gladly missed all the discussions on how to "eliminate" metastability.
What a waste of engineering effort and internet bandwidth...

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

Luiz Carlos

 

[Nicholas C. Weaver]

In article <3F5E22C2.78DCFDF0@xilinx.com>,
Austin Lesea <Austin.Lesea@xilinx.com> wrote:

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

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?
--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[Jim Granville]

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]

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

 

[Allan Herriman]

On Tue, 09 Sep 2003 11:58:10 -0700, Austin Lesea
<Austin.Lesea@xilinx.com> wrote:

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

Austin

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.