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:
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?
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:
The free of charge license can be requested here:
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:
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:
Supporting 3.3V on 2.5 Volt inputs for Igloo2/SmartFusion2 can be achieved in the following way, documented in UG0445:
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!
I was trying to find an easy way for providing the conversion script to interested users and i have decided to use Microsoft Forms for that. If you are interested in getting the conversion script, please fill out this form: https://forms.office.com/r/LtTUMmyQgd
Senior camera designer at IMPERX
3 年Regarding to SmartFusion and Igloo devices. They are pretty old so DDR i/f could be a problem (supported DDR2/3 chips are becoming obsolete). Also there is no HW Deser so LVDS is limited to about 700 Mbps even for HSIO pins
FPGA@HBK. In addition to design for FPGA implementation, I work with cross-disciplinary teams to bring embedded systems to life!
3 年Very well summarized Martin.....the end user should note the advantage of using Flash based FPGAs. Also nice that you mentioned the part regarding the reset of signals when moving a design from Xilinx to Microchip FPGA. I only see a small disadvantage in the Libero tool. Working with a version control system with Libero is a bit frustrating due the tool's inflexibility in providing a user defined directory structure for the project files and IP cores used.