AMD Spartan™ 7 FPGA Stamp Bring Up

Introduction

A few weeks ago I outlined the design of an AMD Spartan™ 7 FPGA stamp, this project examined the front end stages of board design. This included creating the requirements, architecture, power analysis and completed with the schematics.

Once the schematics for the project were finished and the project published, we completed the layout and manufactured 20 prototypes. (With a split of 10 XC7S6 and 10 XC7S25 devices).

The only difference between the variants is the FPGA that was fitted.

Comparing the 3D diagram against the final product shows that the 3D model bares significant resemblance to the actual product.

Let's take a look at these in detail as bringing up a board and deciding to apply power to it can also be daunting.

Approach

When we first get a board back, we need to determine if it is safe to apply power, and begin more functional checks.

My approach to bringing up new boards is therefore broken into a couple of stages before I decide to apply power.

My first step is to ensure that each of the boards to be tested are serialized and identifiable - I do this as I want to keep records of what I have done with each board and should one get damaged I need to be able to identify it.

Having ensured each board is serialized the next step is to check if I have the necessary wherewithal to begin commissioning. This includes not only test equipment, but also tools, software applications, and a plan of expected outcomes for each stage.

For this bring up I needed:

• Power supply capable of supplying between 4.5V and 18V at 1A.
• HS2 JTAG programmer
• Soldering iron and solder
• 0.1 inch headers
• Oscilloscope - bandwidth needs to be at least 200 MHz
• Multi Meter
• Joule Scope - optional
• USB cable with flying leads for USB / JTAG testing.
• Cables for powering from the power supply to the Stamp

With the necessities in place, I was able to begin bringing up the design.

To do this and ensure I could check every possibility, I created the following table:

The first stage is to ensure the boards have been assembled correctly. We cannot check every R and C, etc. however, we are able to check the polarized components and the pin one location of all components is correct.

Board Preparation

With the initial check completed, I prepared the board for testing.

• Solder headers on to Pin 1 and 2 for power input and ground
• Soldered headers on to pins 10, 11, 12, 13, 14 providing JTAG access
• Soldered headers on to pins 28 and 29 for UART access
• Soldered headers on to pins 30 and 32 for I2C access
• Soldered headers on pins 26, 31 and 81 foe ground references
• Soldered the USB flying lead cable to pins 5, 6, 7 and 8 for USB access

I soldered the I2C and RS232 pins for creating a demo application. The pins were selected for ease of access on my board.

An image of the completed stamp with the headers and wires attached is below.

With that, I was ready to begin testing.

Initial Testing

Having visually checked these against the assembly diagrams, I was happy that the components looked to be correctly assembled.

The next step is to use a multi-meter in continuity mode to measure the resistance between the selected power rail and ground.

When we created the stamp, we also included some test points on the board and marked them with the voltages associated (or so we thought).

With the board powered off, measuring between the test points and ground did not show any direct shorts. As such, I decided to apply a small voltage (0.8V) with a low current to the board to also ensure there were no power issues.

The theory here is that 0.8v is more than a diode drop, and a small current limit will show if there are any shorts. I learned this trick developing space flight hardware, where the components cost many hundreds of thousands of dollars, so you want to ensure the system is safe.

We would also have 0 ohm links isolating the power supply from downstream components until the voltages were checked as correct, but we cannot due to space.

The low voltage test was OK, so the power supply is set to the current limit of 5V and 150mA.

I turned on the power supply and observed the reported current was 0.1A and the voltage rails read as follows against the marked test points:

• 3v3 Test Point = 1.001V
• 1v8 Test Point = 1.789V
• 1v0 Test Point = 3.276V

This was a little concerning, as it appears we have supplied the FPGA core with a 3v3 in place of 1v0.

However, as the current did not immediately hit its current limit, and the magic smoke did not escape, there was obviously more to this. Upon investigation, I noticed that we had moved the test points for ease of layout, but did not update the silk screen. We avoided a potential disaster with this finding.

The next element is to check if the clock is operating.

Clock

Although the IO on the stamp provides several global clock and clock capable IO pins, the stamp also provides a 100 MHz oscillator on board. As such, we need to be able to ensure it is working and in tolerance.

I fired up my trusty Tektronix TDS744A, which has a 500MHz bandwidth and probed the clock.

I saved the trace to a floppy disk, which can be seen below - it looks pretty good at 100MHz.

FPGA Bring Up

The next stage is to see if the FPGA is present and if we are able to program it. To do this, I initially used the discrete JTAG lines and the Digilent HS2 JTAG adaptor.

With this connected into the system, I was able to see the FPGA and its XADC (I was bringing up the XC7S25 variant).

I then added the configuration flash device to the design, and although I did not yet have a program for it, I commanded the AMD Vivado™ Design Suite to erase the device to demonstrate that the device could be accessed and controlled. This also programs the FPGA with a design which controls the flash.

This has the benefit of ensuring the Done LED also works.

Once erased, you will see the alert below appear:

Now is also a good time to press the reset button and see if the FPGA program is reset and if the Done LED goes out.

USB JTAG

The next step is to program the FTDI device such that we can use it for USB JTAG programming.

With the flying leads from the USB soldered on to the stamp, we can open the Vivado Design Suite and use it to program the FTDI Device using the commands:

program_ftdi -write -ftdi FT232H -serial adv2019 -vendor "Adiuvo" -board "Leonidas Tile" -desc "Leonidas Tile"

The Vivado Design Suite reports the successful programming of the FTDI chip

However, having programmed the FTDI chip successfully, the Vivado Design Suite was unable to detect the FPGA.

After some investigating, it showed that the TDI and TDO pins had been swapped on the output of the FTDI chip.

Luckily, we have 0 Ohm links fitted on these signals so we can get a modification made. I am sure it will work as expected once this change is made, as the discrete JTAG lines which it connects to works perfectly. The main risk on this was on the FTDI device itself, and that programmed OK.

Simple Application

The next step is to create a simple AMD MicroBlaze™ V processor application which can be used to help us test the rest of the board.

This application will provide a RS232 UART which we connect over the IO pins, AXI IIC device, (unused in this project) and GPIO connected to the two LED pins.

The AMD Vitis™ Unified Software Suite application runs our command line interpreter and enables us to toggle the states of the LEDs over the RS232 interface.

Issuing the commands below we can turn on and off the LEDs:

w 0 1
w 0 2
w 0 3

Where “w” means write, “0” is the address offset based off the address of the AXI GPIO, and “1, 2, 3” is the value to be set.

The CLI echoes these back, and we can see the LEDs change state.

This application also confirms if the IO is working, and that we have the 100 MHz clock correctly configured.

To support this application, I created a Vivado Design Suite board definition for the stamp, which can be included in Vivado Design Suite to get started developing with designs.

Boot from QSPI

The next step was to ensure that the FPGA can boot from the configuration memory. This needs jumpers to be placed across the header pins to change the boot mode from JTAG to QSPI.

We also need to change the Vivado Design Suite project to generate a bin file as part of the bit stream generation along with the bit file.

We can then use the hardware design manager to program the QSPI device on the board.

Once this is completed, we should be able to press the reset button and see the FPGA load configuration from the QSPI memory.

However, this was not the case. Pressing the reset resulted in nothing happening. Looking at the schematics, I noticed that resistors R1 and R2 should have been defined as ‘no-fit’ however, they were populated.

To correct this issue, I needed to remove R1 and R2.

With the resistor removed, the design booted correctly as expected and the application ran the MicroBlaze V processor from boot. See the video clip below, when I press reset and the FPGA configuration is erased and reloaded from the QSPI memory.

Power

To observe the power profile of the stamp, I decided to connect a Joule scope to it and log the power.

In normal operation, running the MicroBlaze V processor application consumed about 90 mA on average.

Results

Following the testing of the board, I am happy to say we can tick of most elements of the design, except the JTAG to USB. Although the fix is simple, the boards are out for modification as I write this.

Engineering Change Order

For the next revision of the AMD Spartan™ 7 FPGA stamp, we will be making the minor modifications below:

• Update the solder mask to reflect 3v3 and 1v0 test points correctly.
• Switch TDO and TMS on U4.
• Set R1 and R2 to be no fit.

As a list goes for a prototype, this is not too bad. We have a functional board and are able to start developing applications with it. We will make small changes and there will be a production run for those interested.

Wrap Up

The Spartan 7 FPGA stamp works, and we can start developing applications for it. This is a great solution for a range of applications from:

• System controller – Power supply sequencing, power monitoring, configuration management, board management, and supervision / communication interface
• Protocol conversion – Convert to and from bespoke / legacy protocol
• Sensor aggregation – Aggregate of several different sensor types for easy access by processor
• IO expansion – Provides additional interfaces e.g. QSPI, SPI, I2C etc.
• Processing offloading – e.g. control algorithm e.g. PID, filtering, co processing, encryption / decryption of data streams entering and leaving system
• Health and usage monitoring systems – Integrates with sensors e.g. accelerometer, pressure, humidity etc. to monitor the environmental operating conditions
• Rapid prototyping – Quickly demonstrates the concept required in a FPGA
• Reduces risk of FPGA integration / removes obsolescence management issues

If you want to know more about the Spartan 7 FPGA stamp, you might be interested in the video interview below:

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