Last week, I wrote an article about Adam Taylor’s White Paper titled “Migrating Spartan 6 Design to 7 Series & Beyond.” In that White Paper, Taylor discusses many considerations for migrating from AMD-Xilinx Spartan-6 FPGAs to Spartan-7 FPGAs. The question arises because Xilinx introduced the Spartan-6 FPGA family in 2009, more than a decade ago, and because the 45nm process technology used to make Spartan-6 devices is getting rather long in the tooth. The company-recommended replacement, the Spartan-7 family, was announced in 2015 and went into full production in 2017. In addition, the ISE Design Suite used for Spartan-6 designs is no longer being updated. Xilinx published the latest version of ISE, version 14.7, two years ago. So, if you’re on the Spartan-6 FPGA bus, it’s time to think about a transfer.

One possible Spartan-6 alternative is another AMD-Xilinx FPGA. In its initial release of 28nm Series 7 devices back in 2010, Xilinx announced three FPGA tiers: Artix-7, Kintex-7, and Virtex-7. All three Series 7 device families were supported by multiple versions of the new Xilinx Vivado Design Suite while the company continued to support Spartan-6 designs with ISE. So if you’re contemplating a new path in FPGA design that uses am AMD-Xilinx Series 7 device, including Spartan-7 FPGAs, a tool change is definitely in your future. (Xilinx added the Vitis Unified Software Platform with support for the Zynq 7000 members of the Series 7 generation several years later.)

Given that background, it was to be expected that other FPGA vendors would start circling the waters around Spartan-6 users. And Microchip’s dorsal fin can now clearly be seen closing in with a blog titled “Protect your Future with a Microchip FPGA device in place of Spartan®-6,” published late last year on LinkedIn. The blog’s author, Martin Kellermann, is a Marketing Business Development Manager at Microchip, so there’s no question of where he’s coming from. Kellermann wastes no time in getting your attention. He writes:

“Is your revenue in danger and are you experiencing loss of business because you are not getting your electronic components? Unfortunately, you are in good company with lots of other users.”

If you design with Spartan-6 FPGAs, that headline combined with the blog’s first two sentences are going to suck you right in. Then, Kellerman asks a key question: How about “really protecting your future” by choosing an FPGA which is “low effort in migration,” and “is available with no-end-of-life practice”?

Clearly, Kellermann hungers for your business.

Call me a cynic (that’s OK, I am), but migrating from a development tool you know (Xilinx ISE) to a tool you don’t know (Microchip Libero SoC) is not going to require “low effort.” I don’t recall ever making any sort of tool switchover that required “low effort.” Switching from WordStar on CP/M, to WordPerfect on DOS in the 1980s, and then to Microsoft Word on Windows in the 1990s involved more than “low effort.” Engineering design tools are far more complex than word processors.

We spend years learning a design tool’s idiosyncrasies and the required workarounds, both for the tools and for the associated programmable-logic devices. When you switch to a new development tool, particularly a tool suite as complex as one intended for FPGA design, there’s going to be some effort. We’re engineers. That’s what we do.

However, I think Kellermann’s underlying question is valid: If you’re going to change tools anyway, isn’t it best to at least consider as wide a range of choices as is practical?

Kellermann and Microchip are at least trying to ease your way to Libero SoC:

“Miguel Idiago and I have created a Python-script that converts from one tool to the other. This script takes an ISE *.xise file and creates a TCL-script for setting up a project with your sources in Libero SoC. The conversion script is available upon request. The intent is to help with the initial steps of bringing something to life and have a first setup, however this is not meant to be a full conversion. A conscious limitation of the conversion-script is that only HDL-sources are transferred. IP-components are of different formats and need to be handled on an individual basis, the same applies for constraints.”

OK, so now we know that you will need to make any changes from AMD-Xilinx IP blocks to Microchip IP blocks by hand. In all likelihood, you’ll also need to learn about new peripherals, new buses, and their foibles.

Kellermann then gives a few examples of other manual changes you’ll be making, such as with the use of clock buffers and PLLs. You need to know the corresponding clocking IP blocks in Libero SoC. Of course, if you’re migrating to the Microchip design tool, then you won’t automatically know what’s available in the Libero SoC tool suite’s IP treasure chest. That’s what I mean when I say that changing tools requires more than “low effort.”

In addition, if your Spartan-6 designs include an AMD-Xilinx MicroBlaze soft processor, you won’t be able to migrate that processor to a Microchip FPGA (because MicroBlaze is a proprietary AMD-Xilinx IP block) and you won’t be able to directly port MicroBlaze software to whatever processor you end up using on a Microchip FPGA. If you pick a Microchip SmartFusion2 device, you’ll be migrating to a hardened Arm Cortex-M3 processor. If you pick a Microchip PolarFire device, you may be migrating to a hardened RISC-V core or a soft IP version of the RISC-V or Arm processors. No matter your choice, you’ll be making software changes.

Finally, I want to address Kellermann’s assertion that somehow Microchip programmable-logic devices won’t be obsoleted. Microchip PolarFire FPGAs are made using 28nm process technology. That process technology is not likely to go away for a long, long time. The 28nm node is the most economical semiconductor production node in the current stable of active manufacturing process technologies. However, Microchip SmartFusion2 and IGLOO2 devices incorporate a Flash-based programmable-logic fabric and are made using a 65nm process technology with on-chip Flash EEPROM. That’s a pretty mature process node. How long that process lasts will be anyone’s guess.

Here’s what Microchip’s Web site says about its “End of Life” (EOL) policy:

“At Microchip we have a 25-year practice of not putting our clients through the pain and cost of redesigning for end-of-life. We call it client-driven obsolescence, and the idea is very simple: we will supply a product as long as there is a customer somewhere who wants it. Five years? Ten Years? Twenty? You decide.

“It is one of the things that truly sets Microchip apart from other suppliers: We manage our business in such a way as to be able to assure our clients we will never leave them high and dry.

“Of course, there is always the rare situation where one of our suppliers makes it impossible to continue producing. In that rarest of situations we’ll help you to transition to another solution with the least disruption possible.”

I think there are two things to note here. The first is the caveat in the last paragraph: “…there is always the rare situation where one of our suppliers makes it impossible to continue producing.” Note it well. My second point is that there is an economic price to pay when buying chips made with process nodes that fabs really don’t want to make any more. The EOL policy above doesn’t mention the cost for continuing the supply of these old chips. At some point, you will decide that the cost of continuing with old parts is not worth the benefit.

This problem is not unique to Microchip. It’s an industry problem. No semiconductor vendor wants to subject you to an EOL situation because that’s bad business. But EOL situations are inevitable in the semiconductor business. Distributors like Rochester Electronics and Flip Electronics have built ongoing businesses by specializing in supplying obsolete parts to the electronics industry, for a price.

So where does that leave you if you’re a Spartan-6 FPGA user? It puts you at the beginning of a quest to find a new path. Good luck!

(Note: AMD recently purchased Xilinx, so several of the company references in this article have been changed to “AMD-Xilinx.” However, references to past events, when Xilinx wasn’t part of AMD, reflect that historical perspective.)