Protect your Future with a Microchip FPGA device in place of Spartan?-6

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.

I had several conversations recently with FPGA-users that had their design done on competitors’ devices, like for example, the Spartan-6, and they are now facing the situation of an immediate stop of delivery. No devices at all anymore and redesign-options which are leading to either very large devices being used, require taking care about a boot-process of a processor or force migration to a new tool. Even then, you may only buy yourself a few years of availability.

How about really protecting your future and choose an FPGA which:

• Is low effort in migration
• Is available with no-end-of-life practice

This is the perfect time to turn an absolute crisis into a chance and Microchip is available to help you to get running again. Just like with the users that I talked with, they are planned to be back up and running in production within about half a year.

In this article I will show you a decision-tree for choosing an appropriate Microchip FPGA, how to migrate the existing design from a software-perspective and some important differences and commonalities between Spartan-6 and the selected Microchip FPGAs.

Migration Decision

The immediate question on any migration from my perspective is the evaluation on an “if yes”, “what then” and “how”. For Spartan-6 some paths within the devices are circulated, e.g. the blog from Adam Taylor. Adam has a valid decision tree; however, it stays completely within the Spartan-6 devices which may seem “natural” but is limiting your options. Additionally, you will either end up with FPGAs of either 100.000 or 200.000 logic cells (Artix?-7 100T, Artix?-7 200T) supported by ISE or Zynq?-SoCs where you must handle the boot-process as an essential part of the FPGA bring-up. And at this step a major redesign from a design built around a bus-centered MHS-file to a block-diagram based approach is required.

?An alternate decision-tree that brings you into a no-end-of-life world is the following:

I start with the decision-point where you are looking into moving towards Microchip. Depending on your experience and development-expertise a microcontroller may be appropriate, which may not have been available at the design-time of the original project. Me being an FPGA-person I will not dive into that topic.

The next step is mainly determining the main architecture. Is your design “larger” then you may get some additional benefit during the migration, however if you immediately require a redesign as your production-line is down then the right branch is for you.

One common use-case in FPGA-designs is the use of soft processors, like MicroBlaze. If your design contains one (or maybe multiple) of these then you have the choice of migrating to either a soft RISC-V or a soft ARM Cortex M1 for PolarFire? FPGA or to use the hardened quad-core RISC-V in PolarFire SoC. Yes, this is a significant lift in performance, and it is your choice if you want or require this lift.

For immediate “1:1” replacements the right main branch is important. Also, here we have the decision point of the MicroBlaze as soft processor. If you do not have that soft processor then the path is towards Igloo2 devices with or without transceivers as your design requires it. With an existing MicroBlaze you can benefit from the hardened ARM? Cortex M3 present in the SmartFusion2 devices. As additional benefit of this processor cluster you also receive several hardened peripherals that traditionally you had to build in FPGA fabric. So, you may be able to select a device with a smaller logic complexity and with that improve your system on power-consumption and everything that comes with it.

What are examples of these peripherals?

• DDR memory controller
• SPI / I2C / UART / Timer (two each)
• CAN
• Watchdog Timer
• Ethernet
• DMA

Additionally, SmartFusion?2 and Igloo?2 devices feature embedded non-volatile memory (eNVM) of up to 512kB, depending on the device size.

Based on this decision-tree you have an impression on which device-family to use. The next step is judging the effort of a port to that family. As most of my recent conversations have centered around an immediate need, I will show what some conversion steps are to use a SmartFusion2 SoC or Igloo2 FPGA.

Design Migration ISE to Libero SoC

A doubt-less requirement of migrating from Spartan-6 to anything else, including Spartan-7, is the tool-migration. Spartan-6 was and is ISE, Spartan-7 is Vivado?, Microchip FPGAs are Libero? SoC.

For Spartan-6 usually a free-of-charge ISE WebPack? version was used, for Libero SoC the equivalent free-of-charge version is a silver license. Libero SoC can be downloaded here:

https://www.microchip.com/en-us/products/fpgas-and-plds/fpga-and-soc-design-tools/fpga/libero-software-later-versions

The free of charge license can be requested here:

https://www.microchip.com/en-us/products/fpgas-and-plds/fpga-and-soc-design-tools/fpga/licensing

The good news is, Libero SoC is not too different from ISE, you will easily find your way around:

The images above show the same design loaded into ISE and Libero SoC. Both tools have project management capabilities for implementation and simulation. The screenshots show the hierarchy of the design and allows navigation in the design. Additionally, the design-flow is also accessible from these GUIs, taking the designs from VHDL/Verilog? with IPs and constraints to the bitstream for the FPGA.

As Spartan-6 users may not be entirely familiar with Libero SoC as a tool my colleague 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 live 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 format and need to be handled on an individual basis, the same applies for constraints.?

When you run the script, you will also encounter that not only IP-components are missing but also base-components as the instantiations of the Unisim?-library like Digital Clock Managers (DCMs), global clock-buffers (BUFG) or similar.

For clocking the required rework is pretty straight forward. One can often simply replace the component instantiation of BUFGs by a CLKINT-component. To get the correct architectural macros, their instantiations and port-maps please refer to the Macro Library User Guide:

• SmartFusion2 / IGLOO2: https://www.microsemi.com/document-portal/doc_download/130906-smartfusion2-and-igloo2-macro-library-guide
• PolarFire: https://www.microsemi.com/document-portal/doc_download/1245849-polarfire-macro-library-guide-for-libero-soc-v2021-2

To use the Digital Clock Manager or PLL of Spartan-6 you typically had some IP-instantiation created using a GUI for setting the appropriate features in ISE:

For Libero SoC the approach is similar, one can select an IP for the Clock Conditioning Circuit from the catalog-window:

In both cases the user is guided through the GUI to enter the design-requirements. Based on that the base-components are configured and show the closest possible matches. When all configurations are done then IP-components and HDL-instantiations are created for instantiation in the overall design.?

Constraints

Libero SoC uses SDC-based constraints and allows both a text- and GUI-based approach for creating these. The image below shows the GUI of the Constraints Editor which is used to build the SDC-commands for entering the clock-constraints but also for false paths or multicycle-constraints.

Using this GUI you can filter your design-components to select the appropriate clock- or enable-sources and with that set up the timing.

For IO-constraints similar GUIs exist that allow drag- and drop assignment of individual ports or of complete interfaces as for DDR-memories. This makes using Microchip FPGAs very straight forward.

For those of the readers that prefer a script-based approach on their design for exact reproduction of design-runs, the design-flow in Libero SoC is completely scriptable.

Embedded Processing

The common embedded processor in Spartan-6 is the MicroBlaze soft-processor, implemented using FPGA-fabric, often running at clock-frequencies between 66 MHz and 100 MHz. As SmartFusion2 SoCs already contain a microcontroller sub-system (MSS) the suggested way of converting a MicroBlaze is to use this MSS with its ARM Cortex M3.

To port from MicroBlaze to M3 a manual setup of the MSS is required. The Bus-Interface view of the Xilinx Platform Studio aids on this:

In this view one can see the various components and their connection. In Libero SoC one only needs to configure the MSS with its existing peripherals using a SmartDesign block:

The available peripherals are part of the hardened MSS and hence no address-setup is required. Selecting or deselecting a peripheral is performed via the little tick-box on the bottom right of each function-block. Next to this tick-box you have an additional icon for setting up properties of the IPs and whether they are routed out of the device via the dedicated MSS-IOs or via FPGA-fabric.

This SmartDesign block with its MSS-configuration can be used either on a block-based SmartDesign or be instantiated into an HDL-design. Depending on your original design you may prefer one or the other option.

Important differences

The main difference between a Spartan-6 and a Microchip FPGA is the handling of the bitstream. Microchip-FPGAs have the programming-information of their active components directly stored in Flash-cells and hence do not require a configuration at each power-cycle. Based on this, an external SPI-flash may not be required anymore.

With the benefits of the Flash-process some side-effects are introduced which may influence designs:

• Flipflops in Microchip FPGAs require a reset at power-up for a defined state. Potential INIT-values based on signal-declarations in the HDL cannot be used for implementation and the synthesis-tool will issue an appropriate warning. Designs without reset are discouraged.
• LSRAMs in SmartFusion2 and Igloo2 cannot be initialized at power-up but need to be loaded if to be used as ROM. AC392 (https://www.microsemi.com/document-portal/doc_download/129978-ac392-smartfusion2-soc-fpga-sram-initialization-from-envm-libero-soc-v11-7-application-note) contains examples how this can be achieved using the eNVM as storage for initialization-data and how to load the LSRAMs either via the M3 or fabric logic.
• Spartan-6 IOs are all capable of 3.3V operation where SmartFusion2 and Igloo2 have a combination of IOs ranging up to 3.3V and up to 2.5V for higher performance on lower power. If you are using lots of 3.3V IOs you may need to put some extra consideration into your new package. This table gives an overview of the number of 3.3V and 2.5V IOs in the various device- and package combinations:

Supporting 3.3V on 2.5 Volt inputs for Igloo2/SmartFusion2 can be achieved in the following way, documented in UG0445:

https://www.microsemi.com/document-portal/doc_download/132008-ug0445-smartfusion2-soc-fpga-and-igloo2-fpga-fabric-user-guide

UG0445 in chapter 6.12 gives suggestions on resistors and their influence on the maximum data-rate usable with them.

The resistors work both as a voltage-divider and a current limiter into the IO.

No End of Life

Microchip has an established and proven no-end-of-life practice, our FPGAs are not obsoleted. This allows you to confidently look into the future with communicated and supported availabilities of SmartFusion2 and Igloo2 devices of at least 15 years from today and for at least 20 years for PolarFire. This bold statement is proven by history, devices that were introduced at the end of the last millennium are still available for purchase today.

Going for Microchip FPGAs will provide you with long term confidence and ease concerns about device-obsolescence.?

Summary?

Moving from Spartan-6 to Microchip FPGAs, especially SmartFusion2 and Igloo2 is straight forward and possible with reasonable effort. In case conversion support is required then multiple levels are possible ranging from turn-key conversion from Microchip Design Services or Design Partner to simple conversations of what is the correct device to select.

Start your future today!