Spartan-7 Deep Dive: What You Need to Know for Updating Your Design

If you're a Spartan-6 user, you've probably been noticing quite a bit of content and news encouraging migration to its successor, the Spartan-7. Element14 even launched an FPGA competition for 7 Ways to Leave Your Spartan-6. The Spartan-6 is and was a great FPGA chip, and every engineer knows that if a good design "isn't broke, don't fix it". However, as the Spartan-6 follows Moore's Law in its evolution to the Spartan-7, it is really tough to ignore some of the performance and flexibility improvements that have come along with it.

Over the past 13 years since the Spartan-6 was introduced, not only has the semiconductor technology vastly evolved, the FPGA development tools have come a long way as well. Upgrading from the Spartan-6 also entails moving to the next generation of improved FPGA development tools. The AMD-Xilinx ISE (Integrated Synthesis Environment) was a very solid toolset with features for analyzing a design's timing, a handy schematic diagram view of the RTL, simulation for system-level testing with ModelSim, and target FPGA programming.

The Spartan-7 is a part of AMD-Xilinx's 7 Series lineup of FPGAs that now utilizes Vivado ML and Vitis toolset. While Vivado is a different workflow, it still encompasses the features that made ISE so solid with the addition of features for development of current technologies for hardware acceleration, machine learning, and artificial intelligence.

The purpose of this article is to take a deep dive into the key differences between the Spartan-6 and the Spartan-7 in an effort to help define what the migration process will look like for users. While upgrading to the latest technology is exciting, the work that migration process requires cannot be ignored. And the best first step to making that migration as smooth as possible is to fully understand the task ahead.

Performance

The Spartan-6 devices were at the top of the 45nm technology game when they were released in 2009. And as Moore's law would have it, the Spartan-7 has capitalized on 28nm technology to deliver a 30% boost in performance speed.

Along with the performance speed boost, the 28nm Spartan-7 devices also consume 50% lower total power compared to their Spartan-6 predecessor. To encompass what this performance increase is and where it is coming from, a closer look into the infrastructure changes from the Spartan-6 to the Spartan-7 is necessary including the block RAM, clocking structure, and DSP slices.

• Block RAM

The block RAM in the Spartan-7 has increased in size from its previous 18-Kbit blocks configurable as two 9-Kbit blocks in the Spartan-6, to 36-Kbit blocks configurable as two 18-Kbit blocks. With each block RAM capable of a higher capacity, this obviously is an improvement in and of itself but the Spartan-7 block RAMs also have built in error correction coding (ECC), FIFOs, and the capability to harden cascade them in a design.

The Vivado synthesis tool will automatically handle retargeting the majority of Spartan-6 designs to utilize the larger block RAM size, but there is a chance some designs may consume more block RAM resources in the Spartan-7 than expected without some extra intervention.

• Clocking Structure

The more simplistic clocking structure in the Spartan-7 also boosts its performance with dedicated global and regional I/O and clocking resources such as the clock management tiles (CMT) that provide clock frequency synthesis, deskew, and jitter filtering. The CMTs also contain resources such as mixed-mode clock managers (MMCMs) and phase-locked loops (PLLs). By ditching all of the various buffer types previously found in the Spartan-6, the Spartan-7's clocking structure is able to achieve better timing performance and cut back on power draw some.

• DSP Slices

There is also an upgrade in DSP slices, from 18 x 18 in Spartan-6 to 25 x 18 in Spartan-7. Being the key behind the implementation of mathematical and signal processing functions, the Spartan-7 shows a dramatic performance boost with the capability of the DSP48E1 being able to implement an ALU (arithmetic logic unit) and a single instruction multiple data (SIMD) mode for higher throughput.

Again, the Vivado synthesis tool will automatically handle translating a Spartan-6 design to the 7 series architecture, then language templates are provided for implementing the SIMD mode and/or ALU.

Board Layout

Just as import as the internal differences between the Spartan-6 and Spartan-7 chips, is the external package differences. Unfortunately PCB designers won't have the luxury of the Spartan-7 being a drop-in replacement for the Spartan-6.

The immediate impact to PCB layout is the different pinouts for comparable Spartan-6 and Spartan-7 packages. This impact then spreads externally to the power distribution design as the power requirements of the Spartan-7 is capable of a lower core voltage at 0.95V. However this ultimately leads to the up to 50% reduction in power draw from the Spartan-6 to the Spartan-7.

The Spartan-7 does still maintain that small compact form factor as the Spartan-6, so while signal routing will have to be redone, there is a high likelihood of maintaining the PCB's overall dimensions. Overall, the Spartan-7 will ultimately have the lowest impact on migration tasks coming from the Spartan-6 as compared to other 7 Series chips such as the Artix-7 or Zynq-7000 chips.

Peripherals

In terms of peripherals, the Spartan-7 has gained some handy peripherals available to the programmable logic as compared to the Spartan-6. The first of which is the embedded analog to digital converter in the FPGA, the XADC. The XADC is a dual 12-bit, 1 MSPS analog-to-digital converter with on-chip sensors that enables analog mixed signal (AMS) functionality which is new to the 7 series FPGA line-ups. The ADCs and sensors within the XADC are fully tested and specified. The XADC is capable of being externally triggered, as well as supports simultaneous sampling on both ADCs. Some key use cases for the XADC is the measurement of internal die temperature and the monitoring of internal core voltage.

Another new feature of the 7 series FPGA chips is the capability to encrypt the bitstream with 256-bit AES encryption and HMAC/SHA-256 authentication to protect from unauthorized copy of the design. The decryption of which is done during configuration using an internally stored 256-bit key that can be stored in battery-backed RAM or in nonvolatile eFUSE bits.

The Spartan-7 also possess the capability of partial reconfiguration of modules in the programmable logic during operation. This is something new to the 7 series line-up as a whole and thus the software tools for setting it up are only in Vivado (further detail of Vivado vs. ISE is discussed in the next section). Partial reconfiguration does require the implementation of the multiple configurations which results in full bitstreams for each configuration, and then partial bitstreams for each Reconfigurable Module. All configurations use the same top-level place and routing results.

While the Spartan-6 FPGAs contain GTP transceivers capable of a maximum rate of 3.2 Gb/s, the Spartan-7 FPGAs do not contain any GTP transceivers. GTP transceivers are available in the other 7 series FPGAs such as the Artix-7 and have a higher data rate of 6.25 - 6.6 Gb/s.

Vivado vs. ISE

The ISE development tools have been officially archived by AMD-Xilinx and the last full native installer for ISE is only supported up to Windows 7 (last released nearly 10 years ago in October 2013). There is an ISE VM available for Windows 10 (Enterprise and Professional versions only), but the last update for that is nearly two years old and its only a matter of time before Windows and Linux OS have upgraded too far past what's patchable/maintainable for a software tool like ISE.

While Vivado is a powerful toolset with great flexibility/configurability from a project standards perspective, there is no way to sugarcoat that it entails some work to make the migration from ISE as Vivado is a different workflow. Overall, you still have the core FPGA design flow of synthesis, place & route (implementation), and finally bitstream generation so you can use those core steps to keep yourself oriented while getting to know the Vivado workflow.

Vivado offers a sense of standardization through a few different key methods. The first of which is the use of the Advanced eXtensible Interface (AXI). AXI was first introduced by Arm® back in 2003 as the Advanced Microcontroller Bus Architecture (AMBA). With the introduction of System on Chip (SoC) and System on Module (SoM) parts that have physical processors embedded into the programmable logic of the FPGA, AMD-Xilinx saw the need to provide a standard interface definition to streamline development for designs that required interaction between the programmable logic (PL) and processing system (PS). Thus AMD-Xilinx adopted this free and open on-chip interconnect specification as it provided the a data bus connection as well is communication standard for any and all functional IP blocks in a design regardless of their location in the design (PS vs. PL).

It's not only for communication across the boundary between the PS and PL, the AXI standard interface can be used for IP blocks all within the PL to communicate. This predetermined standard interface means custom IP blocks can be packaged and placed in a common repository for future reuse by other FPGA developers/engineers. Vivado is even equipped with an AXI IP packaging tool to help convert existing IP. See my following tutorials for how to use this AXI wrapper tool in Vivado and interfacing between the PS and PL via the AXI protocol:

• AXI4-Lite Interface Wrapper for Custom RTL in Vivado 2021.2
• Custom AXI4-Stream FIR filter IP in Vivado 2021.2
• Interfacing with AXI Peripherals in RTL

Overall, there are three main implementations of the AXI4 interface in the latest versions of Vivado: Full AXI4, AXI4-Lite, and AXI4-Stream. Each type suits different use cases better.

In a case where all that is needed is to read/write to some values to a set of control registers (so not a ton of data being transferred and there aren't too strict timing requirements) the paired down AXI4-Lite interface is the ideal choice. On the other hand, when dealing with the implementation of something like a FIR filter that is being fed in and outputting a constant flow of data with known packet boundaries and flow control requirements, an AXI4-Stream interface is the way to go. And you can fill in the gaps between use cases with the full AXI4 interface.

One of the biggest changes from ISE to Vivado, is the transition from the schematic workflow to the block design workflow. Vivado does still offer a schematic view for designs post-synthesis and post-implementation (place & route), but the assembly of the design has moved to the block design.

The block design is a GUI where IP blocks from the built-in AMD-Xilinx library, specified user repository, or valid modules/entities from HDL source files in the project are added as block graphics and connected/configured as desired for functionality. Some features of the block design that are super handy is the connection automation and block automation capabilities.

Because there is a standardized connection interface between IP blocks with the AXI interface, the block design can detect certain features of each AXI interface (ie type, clock domain, etc.) and then automatically connect the IP blocks. The connection automation tool is a huge asset for mitigating timing issues due to clock mapping/distribution, and any custom IP can be wrapped in AXI to take advantage of the connection automation in the block design.

I personally like to break the design flow in Vivado down into the following steps (in sequential order):

• Create new Vivado project
• Create a new block design
• Add IP and connect/configure as desired
• Validate & save block design
• Create top-level HDL wrapper to instantiate block design in the project
• Add any other custom HDL files
• Run synthesis
• Open synthesized design to add initial pinout and timing constraints
• Save & close synthesized design
• Rerun synthesis
• Run Implementation (place & route)
• Open implemented design to analyze, verify, and fix (if necessary) any timing errors.
• If changes were made in implemented design, save & close it then rerun synthesis/implementation as needed (if not, skip to next step)
• Generate a bitstream
• Export bitstream and hardware platform for software development in Vitis and/or PetaLinux.

Another really valuable tool in the block design is a tab that outlines the physical peripherals on an FPGA development board with compatible IP suggestions. When a new Vivado project is created, there is the option to target a specific FPGA chip, or an FPGA development board. When the latter is specified, this tab in the block design appears to help streamline design development for it.

For example, the Spartan-7 FPGA development board, the SP701, has 8 user-drivable LEDs on it. In the block design of a Vivado project targeted towards the SP701, this Board tab calls out these 8 user LEDs. Right-clicking on the 8 user LEDs from this list provides options that will tell Vivado to either automatically connect the LEDs with whatever IP block it deems best (an AXI GPIO in this case) or present a list of all compatible IP blocks to select from. I have written a very detailed description of this process and the overall design flow in Vivado for the SP701, see that here for a demonstration.

Giving up schematic view/design flow in ISE is the most common objection/hesitation I’ve personally heard for migrating away from ISE to Vivado, but the block design is an improved form of the schematic design flow that still offers the schematic view. Upon opening the synthesized design or implemented design, various parts of the design (or the top level of the design) can be selected, then through a right-click menu there is an option to open it in a schematic view. So users who want to verify their designs in a familiar way still have that option.

The implemented design in Vivado also offers a lot in terms of design analysis. Along with the standard, very detailed timing analysis that is done, a power consumption analysis report is also done on each implementation run. Bonus is these reports can be exported in various formats such as CSV for design documentation and reporting standards.

Finally, stepping back to a high-level view: the Vivado GUI is ultimately just a shell for executing TCL commands, in other words, every button click and action is ultimately translated into a TCL command. This means that the Vivado GUI is not only customizable (there is an option to create your own toolbar icons and specify the TCL commands for them to execute) but you can also script the entire generation and compilation of a Vivado project. Avnet has done this for the base Vivado projects for their development boards and is an excellent example of this. This means that a user can simply clone a TCL script(s) from a repository then run them to generate, configure, and compile a Vivado project to the point of having a completed bitstream to upload to a board.

Conclusions

Overall, the upgrade to the new AMD-Xilinx's 7 series of chips offers a lot of gain in terms of performance speed, power draw, and features/peripherals. As seen with the Spartan-6 to Spartan-7 a 50% reduction in power draw and 30% faster performance in the transition from 45nm technology to 28nm technology is quite the boost. Plus the gain of built-in peripherals such as the XADC, encryption, and partial reconfiguration capabilities paves the way for users to keep their designs on the leading edge. The Spartan-7 also very importantly maintains the same lost-cost price-point of the Spartan-6.

With the switch from ISE to Vivado, much is gained through elements such as the standard interface like AXI is used in the AMD-Xilinx catalog of prepackaged IP library in Vivado allows for easy/seamless integration with custom IP and streamlines design flow with the IPs from the library. Expansion into the Vivado development environment provides obsolesce mitigation, interface standardization, and the ability to expand your technology into the hardware acceleration realm Vitis currently offers.

While there will definitely be some growing pains in the upgrade from the Spartan-6 to Spartan-7, hopefully the outlined benefits and the foresight of the challenges along with the following resources will help ease the process. To get started with the Spartan-7 chip specifically, the SP701 development board is ideal and I've recently done a series of project tutorials for it:

• Getting Started with SP701 in Vivado 2021.2
• Getting Started with lwIP on the SP701
• Automated Control of SP701 Over LAN using lwIP
• DSP for FPGA: Custom AXI4-Stream FIR filter IP in Vivado

All of the AMD-Xilinx-based project tutorials on my Hackster profile are a part of the cost-optimized portfolio 7 series family (Zynq-7000, Artix, etc.) if the Spartan-7 isn't the right fit for a design. Also see the white paper written by Adam Taylor and the Spartan-7 product page on AMD-Xilinx's website.