Lattice Announces EOL for XP and EC/P Product Lines

Actually just had this conversation with my Xilinx people. They're not recommending Spartan 3 for new designs, and are talking (speculatively) about obsoleting it in 2018.

And yet, Xilinx recently updated the Spartan 3 data sheet to remove the "not recommended for new designs" banner and indicated that they in fact *are* recommended for new designs.

Still all of these manufacturers are at the mercy of their foundries and have to pull the plug on devices that can no longer be manufactured due to the process going away at UMC, TSMC, ...

At this point it's hard to say whether the FPGA manufacturer's previous track record on supporting old devices is any indication of future performance.

Another point on Xilinx parts in small packages - I seem to remember that Lattice gave you more usable IO in the same package / pin count than Xilinx. So the fact that you could get a Spartan 3 in a TQ100 doesn't necessarily mean it will have enough IO to replace the Lattice XP device.

The other obvious options are:

2) Stick you head in the sand and deal with the grey market for parts until you can't get any more, then redesign. (This seems to be the approved method here)

The thing I'm finding really concerning with Xilinx at the moment is that they've got this big investment in yet another entirely new toolchain (Vivado), and they're saying it's the way of the future. And it doesn't even support Spartan 6, let alone anything older.

I switched years ago from X to A when my continuing problems with ISE finally became too much to deal with. I applauded the decision to scrap ISE's dodgy old codebase and take a new crack at it. But if the software they're pushing going forward doesn't support a given chip, then I can't possibly consider that chip to be going forward with them.

If "nice" = 100 pin QFP, then yes, except for ancient Cyclone-I, Altera does not have anything nice. But if 144 pin QFP is also o.k. then there are relatively modern Cyclone III devices. Voltage and the rest is more or less the same as Xilinx.

MAX2/MAX5 are not for you - too few LUTs.

Spartan 3AN has internal flash. I don't recall if there is a 100-pin version, I am using the 144-pin version in a couple products. I refuse to go to BGAs until there are no leaded parts remaining available.

Jon

I'm pretty sure that the 144-pin package is the smallest with flash. In any case it's not a big win over an external SPI flash part. The difference in footprint between 100 TQFP and 144 TQFP is more than the flash footprint. Not to mention there's a price premium for that multi-die package.

There's some Cyclone IVs in 144ish QFP too.

Theo

Right, unless I have a pretty strong reason to use the 3AN, I use the Spartan 3, and the SST flash chips, which are insanely cheap. I wrote my own programmer code for those. Spartan 2E needed some interface fooling around to command the memory to start dumping at location zero, but the 3A knows how to do it by setting some config pins.

Jon

Before making any decisions I will do my due diligence as well as have any decision approved by my customer. They will be designing my board into their new product, so they are free to make the decision for me. Actually, 2018 might work for me if not for my customer. I expect I'll be fully retired in 5 more years.

In this case the count is higher in the Spartan 3 part and is a *lot* higher in nearly any other part since most won't be in the same package.

Not mine to estimate. I tried buying just 10 boards ahead and ended up with 10 rev 1.1 boards after we did the 2.0 design. The demand is

No, this is too important to me any my customer. We will work it out one way or the other. Thanks for your comments.

I would love to use a 144 pin QFP, but they don't fit on the board. It is a very narrow daughtercard, only 0.85" wide and the 144 QFP is 0.86" wide without counting the pad over hang. A 17x17mm 256 BGA is the best of the rest so far. It has a 1 mm pitch although I haven't looked at what it takes to get vias between the balls. I expect I will need to be willing to push below the comfort zone of 6/6 mil space/trace and maybe below 10 mil drill.

One nice thing about the 256 BGA is that I only need to reach the power and ground pins and the outer ring or two to get my 62 I/Os. I can ignore the rest of the balls.

No S3AN in 100 pin QFP, this may be because it is a dual die configuration or more likely they just don't expect to sell a lot of this size. I haven't bothered to check the price either. They do have a FTG256 which might do the job. I expect I can find the space for a very small 8 pin flash part if I go QFN. Again, I need to dig more. I've just started looking...

Actually my main concern with the external flash is the whole JTAG programming at the factory and/or lab thing, but there are likely many ways to deal with that including having them programmed before assembly. It is just that I've been using these Flash FPGAs for some time now and I'm very used to them.

This is the stuff I'm concerned about with the external flash. But it is just a mater of figuring out how to do it and then doing that... Too bad I don't have space for an MCU. The design could use one, but if it happens it will be *inside* the FPGA. Just no board space at all.

In fact, I'm skipping Altera for the moment and skipping over to MicroSemi and Cypress to see if their combination CPU/Logic devices might do the job well and let me eliminate the stereo CODEC to (another part that could go obsolete at any time). I seem to recall that the Cypress part might be just the ticket but the MicroSemi part runs some $50 at the low point. The current Lattice part is running under $10.

Although, if the CODEC could be absorbed inside an MCU, there is some board space at that point, about 6.5mm sq. But how many MCUs can do 16 bit, CD quality audio on two channels? Maybe Analog Devices, but their MCU parts don't give me confidence in their longevity. It also has to read the external flash and dump it into the FPGA so those tiny audio DSPs are out.

says 6/6 and 12mil drill is doable

-Lasse

If you have some reasonable time that you can bridge with your LTB parts, I think you should really contact your local Altera FAE to see if he has some news for you.

Personally, I like Quartus the most by far when comparing it with the software from the other vendors (just look at SignalTap, for example). (I have no Vivado experience, however...)

Regards,

Thomas

The smaller Spartan 6 parts do come in a 144 pin TQFP package. Too small?

Rob.

The smallest Spartan 3A is under $10, the 3AN is about $15.

The 3AN can be programmed by JTAG, the SST serial EPROM I use on the 3A is not JTAG, although a flexible programmer or tester could easily be "taught" the protocol. I chose this device so I could have field-replaceable firmware. I had to make an SO-8 to DIP converter board though, as the SST chip is only available in a couple SMT packages.

Jon

Apparently the 144 TQ package is too big (physically). And once you look at a 256-ball 1mm BGA you could find any number of devices including those from Lattice (XP2?). For internals, the smallest Spartan 6 is about the size of the original XP part he was using.

As to price, we never pay anything near list for Xilinx parts, but we don't get the same steep discount on Spartan 6 as we do on other series.

Thanks for the link, that saved me a little bother. But I'll still need to run through the calcs myself. A quick check says this works. Still, I'm not crazy about using a 256 ball part when I only need 62 I/O... lol Better than no choice at all.

Yeah, I am supposed to provide JTAG programmability through the equipment this daughtercard is plugged into. That is, I provide the JTAG port, it is up to them to do the software to program it. That is one of my concerns with an external seral prom. May not be easy to do in an 8 pin package... But if they can learn the protocol, maybe that would work too. We'll see. After 5 years we still have not required this functionality. But I'll be pushing for increased capability in the new version to allow it to be sold into new areas. So remote updates may be more important then.