Getting Started with AMD Spartan™ 7 FPGA in Vivado™ 2023.2

With the overhaul of AMD Vitis™ software platform from the Vitis Classic IDE to the new Vitis Unified IDE starting with version 2023.2, I initially released a series of project tutorials on the Zynq-based Arty Z7 board and the Zynq UltraScale-based Kria K24 SoM so help get familiar with the new layout, feature, workflow, etc.

Then I recently picked up my AMD Spartan™ 7 SP701 FPGA again for a new project and realized I needed to round this tutorial series out by adding a soft-processor (MicroBlaze) based set of project write-ups to it. So in this project, I am covering how to create a base hardware design for the Spartan 7 SP701 FPGA development board and how to configure the MicroBlaze for no-OS (bare metal) C applications to run on, or a full Linux OS to run on.

This project write-up is specific toAMD Vivado™ design tools 2023.2 and later, and I am running it on an Ubuntu 22.04 host PC.

Create Vivado Project

Launch AMD Vivado™ design tools from the command line or applications directory and select the Create Project option from the Quick Start menu. Then specify the desired project title and directory location.

In the Project Type window, select RTL Project and check the option to not specify sources at this time.

For now, I am not planning on making an accelerated application for this hardware design so I left the option to make the project an extensible Vitis software platform unchecked.

For the Default Part Window, switch to the Boards tab and search for "SP701". Select the Spartan 7 SP701Evaluation Platform and click Next.

Review the project settings selected in the summary window before clicking Finish to create the new project.

Vivado will then automatically launch into a blank project targeted to the Spartan 7 SP701 FPGA development board.

Create Block Design

The Spartan 7 FPGA the AMD Spartan™ 7 SP701 development platform does not have a physical processor built into its programmable logic like its Zynq and Zynq UltraScale counterparts do, which is why we have to instantiate the MicroBlaze soft-processor in the design (a processor written in HDL).

There are two options to instantiate a MicroBlaze soft-processor IP (and any other IP) in a Vivado project:

1 ) A straight instantiation in HDL code in a source file.

2) In the graphical interface of Vivado design tools, the block design.

I highly recommend using the block design for IP such as the MicroBlaze as there are helpful tools such as block automation (applies basic settings according to project settings configuration) and connection automation.

Select the Create Block Design option from the Flow Navigator window. Specify the desired name for the block design file and click OK. Vivado will then automatically open the new, empty block design.

At this point, the base hardware design process does deviate depending on if the software that is going to run on the MicroBlaze requires a full Linux OS to run on or if it can run in a no-OS environment (ie - bare metal C code application).

The next section covers the configuration of the MicroBlaze soft-processor IP for a no-OS target application, the section following it covers how to configure the MicroBlaze soft-processor IP to be able to run a Linux image on it as well as the additional necessary IP to support it.

No-OS Block Design

Starting with the design for a target running bare metal C applications, click the + button in the block diagram window and search for "MicroBlaze".

Double-click the option that just says MicroBlaze to add it to the block design window.

After a few moments, a green banner will appear with the option to Run Block Automation.

Click the hyperlink to Run Block Automation to open the configuration window for it. Leave the Preset option set to None since it will be running no OS. Select the desired amount of local memory (the default is plenty for basic applications like Hello World and driving some GPIO).

I personally also always like to check the option to add the Interrupt Controller as well since I'll more than likely need interrupts in my target applications at some point.

After clicking OK on the block automation configuration window, Vivado will take a few moments to configure the MicroBlaze IP as specified and populate all of the supporting IP such as the interrupt controller, processor system reset, BRAM for local memory/cache, etc.

Another green banner will appear, but this time it'll be for connection automation to connect the system clock and reset of the SP701 to the MicroBlaze IP.

This time however, only check the option for connection automation to connect the system clock (clk_wiz_1). Click OK and give Vivado a few moments to make the connection.

Manually connect the ext_reset_in port of the Processor System Reset IP for the system reset. I make this connection manually because sometimes connection automation will try to add another processor system reset IP and make things weird.

Now, the block design might look like a bit of a mess of spaghetti at this point. Use the circular arrow icon (Regenerate Layout) at the top of the Diagram window to have Vivado shuffle everything into a neater order:

Another bonus feature of using the block design in Vivado when targeting a development board versus a discrete part is the Board tab that lists the available peripherals on the development board. It also filters out IP library to show just the compatible IPs for each peripheral.

Right-click on the desired peripheral to add to the design to bring up the connection options. The option for Auto Connect will run connection automation using the IP at the top of its relevant filtered IP list.

I usually use the Connect Board Component option which brings up the relevant filtered IP list for that peripheral so I can select it manually.

For example, with the user LEDs on the Spartan 7 SP701 board, the list shows the AXI GPIO IP at the top of the compatible IP list. Furthermore the selection of which of the two available channels on that AXI GPIO to connect the LEDs to can be made.

Once the desired IP to connect the peripheral to is selected, Vivado will then add the configured IP with external ports to the block design and the option to run connection automation will appear as normal.

Most of the time, the default selections for connection automation are the ideal connections because it is based off what will most likely meeting timing constraints for the design.

When selecting which peripherals on a development board like the Spartan 7 SP701 to add to the hardware design in Vivado, ones that are usually common to the majority of applications are a UART interface for serial terminal in/output, an Ethernet interface for a network connection, quad SPI interface to a flash memory chip for non-volatile external storage, and a memory generator interface (MIG) to DDR/SDRAM for volatile external storage.

For a basic example design to write basic hello world/GPIO driver bare metal C applications, I just added the user LEDs (AXI GPIO), UART (AXI UARTLite), and SPI flash (AXI Quad SPI 0 - where the bitstream will live when not debugging/running on JTAG).

Since my planned applications are pretty "light weight" I'm just going to use the BRAM that is the local memory of the MicroBlaze instead of adding the MIG to connect to the DDR on the Spartan 7 SP701 for now.

Once the design is complete, a design check can be run to verify there are no gross errors in the design. Using the check box icon at the top of the Diagram window, run block design validation.

Once the block design is complete and free of errors, save it before proceeding on.

Linux Block Design

While the design flow is the same, the configuration of the MicroBlaze soft-processor IP is bit different for a design to be able to run a full Linux OS on it. A few extra peripheral IPs are also required (ie - are no longer optional like they were in the no-OS application design):

• MIG to connect to DDR/SDRAM since Linux will need more memory than can be instantiated BRAM and still meet timing.
• Triple Timer Counter (TTC) using the AXI Timer IP for Linux to use as its timebase.

Furthermore, the preset in the MicroBlaze IP itself is changed to one of the Linux presets. Typically the Linux with MMU (memory management unit) is the preset used unless some other special optimization is being done to the design.

Now a hack I discovered for AMD FPGA development boards that have a PetaLinux BSP released for them is that when a PetaLinux project is created from the BSP, the Vivado project that creates the base hardware design the BSP project uses is populated in the Petalinux project directory under ./hardware.

So instead of creating a new Vivado project from scratch and configuring everything for the MicroBlaze by hand to run Linux on it, I simply use the pre-built Vivado project in ./<PetaLinux project directory>/hardware/<BSP name>/. to add any additional things I might need in the hardware design. This saves me a lot of time, especially since I'm using the PetaLinux BSP to get the default PetaLinux project settings for my target FPGA board anyways.

Note: See PetaLinux 2023.2 tutorial for Spartan 7 SP701 here for how to create a PetaLinux project from its BSP.

If I do need to create a new Vivado project for a Linux-based design on the Spartan 7 SP701 for whatever reason, I can simply use the write_bd_tcl command from the TCL console to create a TCL script I can call from a new Vivado project to automatically rebuild this block design.

write_bd_tcl ./desired_output_directory/desired_file_name.tcl

I also used these reference hardware designs from PetaLinux BSPs to initially get an idea for how to configure the MicroBlaze IP to run Linux.

A big reference is seeing how to configure the TTC and interrupts for Linux to be able to boot properly:

The only part that is a bit confusing is the configuration preset is a custom one from AMD that they have optimized. However in a situation where you might not be using the entire block design exactly but just looking at it as a reference, just use the Linux with MMU option then copy the rest of the settings if need be.

Another big timesaver is the MIG configuration for the DDR since setting that up can be kind of tedious.

I have written up a tutorial in the past for setting up a Linux-based MicroBlaze design from scratch on the Arty A7. From the perspective of Vivado, not a lot has changed so I'll link it here to provide another perspective for reference.

Create HDL Wrapper

Once the block design is completed, it needs to be instantiated in the Vivado project in a top level HDL source file. This can either be done by hand, or there is an option in Vivado to generate this HDL wrapper automatically.

Right-click on the block design file in the Sources window and select Create HDL Wrapper.

There is an option for Vivado to create the HDL wrapper then never touch it again to allow user edits, or the default option to allow Vivado to automatically update the HDL wrapper as edits are made to the block design.

This choice depends on the preferred design flow, but usually letting Vivado automatically update the HDL wrapper is the way to go.

After a few moments, the file hierarchy will update in the Sources tab, showing the HDL wrapper source file instantiating the block design file.

Constraints File

In this particular design, since I am not adding any additional peripherals and I am using the default pinouts, there is not need to manually add a constraints file and specify the pinout because the default pinouts for the peripherals are built into the board preset files for the Spartan 7 SP701 development platform in Vivado.

Generate Bitstream

At this point, the design is complete and ready to be compiled into a bitstream. Start by running synthesis on the design (which converts all of the HDL into logic cell configuration).

Once complete, run implementation which is the place & route process in Vivado for the target FPGA.

And finally, once successful synthesis and implementation runs have been completed, generate a bitstream for the target.

Export Hardware

Now that the hardware design is complete and a bitstream generated for the target FPGA, the final step is to package up the bitstream up with other relevant design files to import into Vitis Unified and PetaLinux in order to develop the software to run on the hardware design.

Select File > Export > Export Hardware...

This will bring up the export wizard for configuration which hardware files are packaged into the XSA file that Vitis Unified and PetaLinux import to build software for:

The first selection to make is to include the bitstream in the exported XSA file:

Then select the desired XSA file name and export location. The default location is in the Vivado project's top level directory, which is also where I personally like to create a directory to use as my corresponding Vitis workspace and a directory to create the corresponding PetaLinux project. This is just a personal preference to keep all of my projects organized.

Review the selections before clicking Finish to export the XSA file.

Software Development

At this point, the XSA file is ready to be imported into the Vitis Unified IDE to development either the no-OS C application code to run on it or the Linux based application if a Linux image is being built with PetaLinux. See my next project tutorial here for this workflow in Vitis Unified 2023.2 for the Spartan 7 SP701 development platform.

This same XSA file is also what PetaLinux pulls in to be able to have the hardware hooks for that Linux image builds as well. See my next project tutorial here for this workflow in PetaLinux 2023.2 for the Spartan 7 SP701 development platform.

Disclaimer/Disclosure

Whitney Knitter is an independent engineer, hired as an independent contractor by AMD. Although AMD sponsored this project write-up, including engineering hours and writing production, the opinions expressed are those of Whitney Knitter, which may not reflect the positions, strategies, or opinions of AMD. GD-5.

AMD, the AMD Arrow logo, Spartan, Vitis, Vivado and combinations thereof are trademarks of Advanced Micro Devices, Inc. Other product names used in this video are for identification purposes only and may be trademarks of their respective companies.