production life of Spartan3A ?

[Jon Elson]

Hello,

Anybody have any idea how much longer the Spartan 3A will be
in production? I'm hoping a good while, yet, as it appears to
be the cheapest modest-size FPGA from Xilinx right now, about
$8 for the XC3S50A in the TQFP144 package.

Thanks much in advance,

Jon

 

[Jon Elson]

Jon Elson wrote:

Hello,

Anybody have any idea how much longer the Spartan 3A will be
in production? I'm hoping a good while, yet, as it appears to
be the cheapest modest-size FPGA from Xilinx right now, about
$8 for the XC3S50A in the TQFP144 package.
So, nobody has any ideas for about how long the Spartan 3A

will be available? I'm just redoing a board to move up from
the Spartan 2E. The Spartan 6 gives me no advantages at all,
costs more, and needs a (much) bigger config ROM.

Jon

 

[Rob Gaddi]

On Wed, 24 Oct 2012 14:08:39 -0500
Jon Elson <jmelson@wustl.edu> wrote:

Jon Elson wrote:

Hello,

Anybody have any idea how much longer the Spartan 3A will be
in production? I'm hoping a good while, yet, as it appears to
be the cheapest modest-size FPGA from Xilinx right now, about
$8 for the XC3S50A in the TQFP144 package.
So, nobody has any ideas for about how long the Spartan 3A
will be available? I'm just redoing a board to move up from
the Spartan 2E. The Spartan 6 gives me no advantages at all,
costs more, and needs a (much) bigger config ROM.

Jon

I don't know anything anyone else doesn't, but it seems to me like
Xilinx has been pretty clear that the targetting of the S3A and the S6
are very different; the S6 is meant to be a fundamentally higher end
product that won't be competing in the sorts of pseudo-CPLD arena that
the S3A does. And so I'd be shocked if they phased out the S3A any time
soon; it seems like it would royally tick off a lot of volume customers.

All that said, I don't know what the realignment to 3 lines instead of
2 that they're doing with the -7 series stuff means for all that; they
may be positioning something in the Artix-7 line as the S3A killer.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[rickman]

On 10/24/2012 3:08 PM, Jon Elson wrote:

Jon Elson wrote:

Hello,

Anybody have any idea how much longer the Spartan 3A will be
in production? I'm hoping a good while, yet, as it appears to
be the cheapest modest-size FPGA from Xilinx right now, about
$8 for the XC3S50A in the TQFP144 package.
So, nobody has any ideas for about how long the Spartan 3A
will be available? I'm just redoing a board to move up from
the Spartan 2E. The Spartan 6 gives me no advantages at all,
costs more, and needs a (much) bigger config ROM.

Jon

Yeah, I don't like the direction Xilinx is headed. I would have thought
they might see that the old school philosophy of "bigger, faster, more
expensive" might be coming to an end. But in the short term, I guess not.

If you are looking for something that small for a new design, check out
the Lattice parts, especially the iCE40 devices. They are VERY cost
competitive, at least if the iCE65 devices are indicative. I got quotes
for them at about $3. They don't have all the bells and whistles, but
they do have OTP config memory.

As to the S3 parts, Xilinx does have a track record of keeping old
devices in production nearly forever. After some years the price may
rise, but you won't have to respin your design because you can't get them.

Rick

 

[Gabor]

rickman wrote:

On 10/24/2012 3:08 PM, Jon Elson wrote:
Jon Elson wrote:

Hello,

Anybody have any idea how much longer the Spartan 3A will be
in production? I'm hoping a good while, yet, as it appears to
be the cheapest modest-size FPGA from Xilinx right now, about
$8 for the XC3S50A in the TQFP144 package.
So, nobody has any ideas for about how long the Spartan 3A
will be available? I'm just redoing a board to move up from
the Spartan 2E. The Spartan 6 gives me no advantages at all,
costs more, and needs a (much) bigger config ROM.

Jon

Yeah, I don't like the direction Xilinx is headed. I would have thought
they might see that the old school philosophy of "bigger, faster, more
expensive" might be coming to an end. But in the short term, I guess not.

If you are looking for something that small for a new design, check out
the Lattice parts, especially the iCE40 devices. They are VERY cost
competitive, at least if the iCE65 devices are indicative. I got quotes
for them at about $3. They don't have all the bells and whistles, but
they do have OTP config memory.

As to the S3 parts, Xilinx does have a track record of keeping old
devices in production nearly forever. After some years the price may
rise, but you won't have to respin your design because you can't get them.

Rick

The problem with "nearly forever" is that the end date isn't actually
set by Xilinx, but by the end-of life for the fab process. Xilinx at
one point announced a general EOL for Spartan 2, then changed
their mind. Not that long ago, Spartan 2e was actually the lowest
priced Xilinx part per IOB. For many small applications the IOB count
limits the device selection. So even after Spartan 3 came out with
great fanfare as the lowest cost device (per LUT), Spartan 2e still
had better per-IOB price.

Lattice hasn't been in the FPGA business long enough to know its track
record for length of product life. On the other hand their older CPLD
lines are very long-lived (again EOL probably dictated by fab rather
than Lattice). So if you're looking for long product life in a low-
cost part you're probably best finding a part with the most recent
fab process node that still fits your budget, as long as the FPGA
vendor is one of the more stable companies (I would include Lattice
in this group, as well as Xilinx, Altera and MicroSemi).

-- Gabor

 

[Jon Elson]

Gabor wrote:

The problem with "nearly forever" is that the end date isn't actually
set by Xilinx, but by the end-of life for the fab process. Xilinx at
one point announced a general EOL for Spartan 2, then changed
their mind. Not that long ago, Spartan 2e was actually the lowest
priced Xilinx part per IOB. For many small applications the IOB count
limits the device selection. So even after Spartan 3 came out with
great fanfare as the lowest cost device (per LUT), Spartan 2e still
had better per-IOB price.

Thanks all (Rob, Rick and Gabor) for your guesses - yes, I know all

you can do is guess on this, but you might have better "ear to the ground"
sources of info than I do.

Yes, I am JUST moving some products from Spartan 2E to the 3A, as 2E cost
is going up and I don't want to get caught scrambling for trailing-edge
parts.

I figured out how to use SST serial-PROMs on the 2E with just a couple
SSI chips. These are FAR cheaper than Xilinx's offerings. The Spartan
3A supports these chips with no additional logic.

I have some legacy designs that compile on iSE 10.1, and I only needed
the slightest tweaks to get them to compile for the S3A, other than
completely remapping the UCF pin assignments.

Knowing the quirks of the design package and having a design that already
is acceptable on that package made the change pretty easy. Moving to
a different vendor is a last resort. Compatibility issues, learning
new software, learning the quirks of a new vendor's chips, etc. Even
learning how to navigate through different data sheets would be some
amount of effort.

So, I'd need a fairly big push to move to another vendor right now,
but thanks for the info. I really ought to look at Lattice again.

Jon

 

[rickman]

On 10/25/2012 3:17 PM, Jon Elson wrote:

So, I'd need a fairly big push to move to another vendor right now,
but thanks for the info. I really ought to look at Lattice again.

Jon

That is one big reason why I don't make an effort to use vendor specific
features. If the tools automatically generate the bits to use SRLs or
other vendor specific features then fine, go with it. But if I have to
jump through hoops, I leave them alone. Even if you don't port a
design, it is not uncommon to reuse existing code on new designs.

Rick

 

[Jon Elson]

rickman wrote:

That is one big reason why I don't make an effort to use vendor specific
features. If the tools automatically generate the bits to use SRLs or
other vendor specific features then fine, go with it. But if I have to
jump through hoops, I leave them alone. Even if you don't port a
design, it is not uncommon to reuse existing code on new designs.

Other than pull-ups and the method of implementing a tri-state I/O pin,
I'm not doing anything that could be considered vendor specific. No
location locking, specifying carry chains or anything. But, I HATE
learning new software, after all the trouble of learning ALL the quirks
on one program. I hate even changing versions, as there are all new
quirks to discover.

Some of the designs are descended from mostly schematic entry projects
that were done in 2001. I have them all converted to a mix of behavioral
and architectural VHDL, and the architectural stuff is a horrible
nightmare. I hated the old Aldec shematic editor in Xilinx Foundation,
and went and patched up Protel's libraries so I could create the schematics
in Protel 99SE's schematic editor and export as VHDL. Well, looking back,
that was one of the worst ideas I ever had! If you want to edit the
schematic, you have to then hand-edit the architectural VHDL to make it
compatible with Xilinx, so I just edited the VHDL files, which are a huge
jumble. When they get bad enough, I finally break down and convert them
to behavioral VHDL, which I should have done from the beginning.

So, I have no idea how these architectural VHDL files would work on
anybody else's tools. But, I wouldn't be surprised if there were
problems.

Jon

 

[glen herrmannsfeldt]

Jon Elson <jmelson@wustl.edu> wrote:

(snip)

Some of the designs are descended from mostly schematic entry projects
that were done in 2001. I have them all converted to a mix of behavioral
and architectural VHDL, and the architectural stuff is a horrible
nightmare. I hated the old Aldec shematic editor in Xilinx Foundation,
and went and patched up Protel's libraries so I could create the schematics
in Protel 99SE's schematic editor and export as VHDL. Well, looking back,
that was one of the worst ideas I ever had!

Conversion from schematic entry is nice, but the results
aren't usually very human readable.

If you want to edit the
schematic, you have to then hand-edit the architectural VHDL to make it
compatible with Xilinx, so I just edited the VHDL files, which are a huge
jumble. When they get bad enough, I finally break down and convert them
to behavioral VHDL, which I should have done from the beginning.

I don't know VHDL well enough to say, but except for registers
and state machines, I prefer strutural (mostly continuous assignment)
verilog to behavioral verilog.

So, I have no idea how these architectural VHDL files would work on
anybody else's tools. But, I wouldn't be surprised if there were
problems.

I don't know either, but if they follow the standard, then
they should work on any implementation that follows the standard.

-- glen

 

[Jon Elson]

glen herrmannsfeldt wrote:

Jon Elson <jmelson@wustl.edu> wrote:

in Protel 99SE's schematic editor and export as VHDL. Well, looking
back, that was one of the worst ideas I ever had!

Conversion from schematic entry is nice, but the results
aren't usually very human readable.

Yeah, that is clear to me NOW!

So, I have no idea how these architectural VHDL files would work on
anybody else's tools. But, I wouldn't be surprised if there were
problems.

I don't know either, but if they follow the standard, then
they should work on any implementation that follows the standard.
Well, I think they WON'T, because they make extensive use of the

Xilinx library unisim.vcomponents, which has all sorts of components
made out of standard primitives, like 3-input and gates with one inverted
input, multi-channel D-flops with all possible combinations of
clock enable, async or sync clear, etc. I'm sure other tools
have similar libraries, but I'll bet they are all different, either
a little or a lot. You can also build a design out of all 74xx
components from this library, but I didn't do that.

Jon

 

[Gabor]

Jon Elson wrote:

Hello,

Anybody have any idea how much longer the Spartan 3A will be
in production? I'm hoping a good while, yet, as it appears to
be the cheapest modest-size FPGA from Xilinx right now, about
$8 for the XC3S50A in the TQFP144 package.

Thanks much in advance,

Jon

Just to kick up the dust a bit, today Xilinx announced that
Spartan 3 and 3E are not recommended for new designs. 3A
is safe for the moment...

-- Gabor

 

[rickman]

On 10/31/2012 11:02 AM, Gabor wrote:

Jon Elson wrote:
Hello,

Anybody have any idea how much longer the Spartan 3A will be
in production? I'm hoping a good while, yet, as it appears to
be the cheapest modest-size FPGA from Xilinx right now, about
$8 for the XC3S50A in the TQFP144 package.

Thanks much in advance,

Jon

Just to kick up the dust a bit, today Xilinx announced that
Spartan 3 and 3E are not recommended for new designs. 3A
is safe for the moment...

Certainly I can't speak for Xilinx, but in the past they have kept parts
in production for many, many years. I would bet that listing them as NR
for new designs simply means they won't be supporting the parts in the
new versions of the tools. That is the first step to obsolescence. The
prices of these chips will rise considerably. It typically is many
years after that when the chips are discontinued and even then they turn
the mask sets over to companies that specialize in producing old chips.
You could still buy XC3000 parts the last time I remember this being
discussed here a few years ago.

Rick

 

[jg]

On Thursday, October 25, 2012 7:59:56 AM UTC+13, Jon Elson wrote:

So, nobody has any ideas for about how long the Spartan 3A
will be available? I'm just redoing a board to move up from
the Spartan 2E. The Spartan 6 gives me no advantages at all,
costs more, and needs a (much) bigger config ROM.

Ask Xilinx which packages are the most popular ?
Vendors can sometimes prune niche, low volume packages before they prune the die.
I see the 3A and 3E are in the Automotive line as well, which helps lifetime.

You could also check you can compile for variants, like the 3AN, and also one-size-up, as that gives you more 'alternate sources'.
Another effect to watch for, as devices hit the volume tail, is a large user vacuum effect, so some alternate part codes is a good idea.

-jg