Over the last few weeks, I have had several emails and messages about mitigating the impact of the component shortage by transitioning from Spartan-6 implementations to 7 Series or UltraScale+ devices. Although there are still challenges with 7 series and UltraScale/UltraScale+ deliveries, I am informed that more modern nodes exhibit a better long-term supply situation.
Obviously, I cannot cover everything on Spartan-6 migration in a single blog. My plan is to create several detailed tech notes and maybe even host a webinar early next year to show how to translate a Spartan-6 design into a 7 series device.
There are, however, some good pointers that I can make in a blog which may help people understand the process. For simplicity sake, I am going to focus on the Spartan-6 design itself and not on the board design differences.
So, let’s start at the beginning. The first thing we need to do is identify an equivalent device. This requires looking across the product selection guides. There is no 1:1 path for device migration. Instead, it depends on your driving requirement like IO, logic cell density, or package size, for example.
There are, however, some nice rules of thumb that can be used to help guide us in the right direction. If the targeted Spartan-6 device used the LX variant, we can consider the Spartan-7 series of devices since there are no transceivers used. If, however, the target S6 device is from the LXT family and the transceivers are used, then we need to consider the Artix-7 range of devices. After the most suitable component family is identified, we are then able to look through the device portfolios to determine the most appropriate device.
Key differences between Spartan-6 and 7 Series devices can be summarized as follows:
DSP – 25x18 DSP in 7 Series compared to 18x18 in Spartan-6.
BRAM – 7 Series BRAMs are 36Kb compared to 18Kb in Spartan-6. However, the 36Kb can be arranged as 18Kb by two.
Clocking – CMT in Region vs Bank.
IO – Advanced IP structures such as IO DELAY and I/OSERDES need to be manually implemented.
DDR Support – 7 series uses soft memory controller compared to previous hard memory controller.
These challenges need further analysis and discussion in detailed tech notes, however, the Xilinx 7 Series FPGAs Migration Guide UG429 is a good starting point.
Outside of the device selection, we also need to address the change of development tool which comes with migrating from Spartan-6 to 7 Series devices. Vivado is a step change in capability from ISE, however, we are still able to bring across RTL and generate programming files. Exactly how much of the design can migrate depends upon the design itself. For example, a pure RTL design will provide a high level of migration, while a MicroBlaze solution may result in a re-architecting of the MicroBlaze solution, by leveraging IP integrator and pulling in specific RTL modules from the previous design.
One of the main changes between ISE and Vivado is, of course, the constraints. Before Vivado, these were captured in a UCF file but now Vivado uses an expansion of Synopsis Design Constraints, called Xilinx Design Constraints.
If you are coming from an ISE background, you can get a better understanding of the new Vivado design flow by reading the ISE to Vivado Design Suite Migration Guide (UG911).
Of course, this barely scratches the surface of migration from Spartan-6 to 7 Series devices. I do, however, hope it provides some pointers and tips while I create more in-depth technical examples.
I would be interested to know your pain points if you have gone through this process.
Comments