production life of Spartan3A ?

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.

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

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

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

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

Jon Elson wrote: (snip)

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

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.

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

-- glen

Yeah, that is clear to me NOW!

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

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

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

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