Project

General

Profile

Programming the FPGA

For the MityDSP-L138F, MityARM-1808F, and MityDSP-6748F, there are several ways to load the FPGA following boot-up, including:

  • Downloading Via Xilinx JTAG emulator Pod.
  • Loading (via CPU) during the u-Boot phase of execution.
  • Loading (via CPU) after the target OS has been loaded on the CPU.

You can check if the FPGA is loaded visually by examining the LED (D1 - TBC) which is tied to the FPGA Done signal asserted by the FPGA when it has successfully been configured.

JTAG loading

The JTAG connector for the FPGA is located on the MityDSP/MityARM SOM card. Users may load the FPGA via JTAG connector for initial testing and debugging using utilities such as the Xilinx Chipscope Tool (an in-fpga logic analyzer module). For the Revision A boards, the FPGA JTAG interface is a 2 mm dual row header that may be directly connected to a USB JTAG programmer provided by Xilinx. For the OMAP Rev B and later series modules the connector interface is a Hirose connector that combines the JTAG interfaces for both the CPU and the FPGA. A break-out board is available from Critical Link to interface this Hirose connector to the Xilinx (and TI) JTAG pods.

To load the FPGA via JTAG, simply run the Xilinx impact utility (available via Xilinx's webpack software downloads) and select your compiled bitstream (.bit file) and load it to the module.

Loading via CPU

The FPGA has been connected to the on board CPU such that the CPU asynchronous interface may be used to program it using the slave select mode of configuration (8-bit parallel mode using chip select 5). In slave select mode, the CPU loads the binary configuration data for the FPGA from non-volatile storage and transmits it to the FPGA. For details regarding slave select programming, please refer to the Xilinx Spartan-6 configuration guide. Critical Link provides two software mechanisms for loading the FPGA with this technique, via u-Boot or via Linux FPGA drivers (custom by critical link). Both require a .bin file (not an .mcs file) from the Xilinx Impact tool.

The easiest way to get started with non-volatile based loading would be to go through the modified u-Boot program supplied with the board (sources for which are in support.criticallink.com):

Using u-Boot to load the FPGA

(!) For Artix-7 variants, when programming the FPGA via uBoot you must always pass in a filesize. The default filesize used by uBoot software will be for the Spartan-6 LX16 bitstream, which is not the correct size for Artix-7 or Spartan-6 LX45 images. It is recommended to use the ${filesize} argument when loading the FPGA image from a filesystem. Bitstream sizes for the FPGA are listed below:

FPGA Size to pass to loadfpga command (hex) Notes
Spartan-6 LX16 0x080000
Spartan-6 LX25 0x0C8000
Spartan-6 LX45 0x170000
Artix-7 15KLE 0x21728C Use the filesize of the binary
Artix-7 35KLE 0x21728C Use the filesize of the binary
Artix-7 50KLE 0x21728C Use the filesize of the binary

Download the .bin file to memory and then test the loading procedure:

uBoot> tftp 0xC0700000 yourserver:/path/to/fpga.bin
uBoot> loadfpga 0xC0700000 ${filesize}

To auto load the FPGA on power up, first you must get the file onto the unit:

Example loading the .bin file using a TFTP server:

uBoot> tftp 0xC0700000 yourserver:/path/to/fpga.bin

Example loading the .bin file over the serial port using Kermit:

U-Boot > loadb 0xC0700000
## Ready for binary (kermit) download to 0xC0700000 at 115200 bps...
## Total Size      = 0x00071544 = 464196 Bytes
## Start Addr      = 0xC0700000

Then store the image off to SPI flash:

Example for LX16 FPGA bin file:

uBoot> sf probe 0
uBoot> sf erase 0x580000 0x80000
uBoot> sf write 0xC0700000 0x580000 ${filesize}

Example for LX45 FPGA bin file:

uBoot> sf probe 0
uBoot> sf erase 0x580000 0x170000
uBoot> sf write 0xC0700000 0x580000 ${filesize}

To automatically load the the FPGA from FLASH at startup, create a u-Boot script variable the load the FPGA image from FLASH and load up the fpga. You can then run this "script" as part of the bootcmd environment script.

Example for the LX16:

uBoot> setenv progfpga "sf probe 0; sf read 0xc0700000 0x580000 0x80000; loadfpga 0xc0700000 0x80000" 
uBoot> setenv bootcmd  "run progfpga; ... other commands to load and boot software ..." 
uBoot> saveenv

Example for the LX45:

uBoot> setenv progfpga "sf probe 0; sf read 0xc0700000 0x580000 0x170000; loadfpga 0xc0700000 0x170000" 
uBoot> setenv bootcmd  "run progfpga; ... other commands to load and boot software ..." 
uBoot> saveenv

Example for any Artix-7 device:

uBoot> setenv progfpga "sf probe 0; sf read 0xc0700000 0x580000 0x21728C; loadfpga 0xc0700000 0x21728C" 
uBoot> setenv bootcmd  "run progfpga; ... other commands to load and boot software ..." 
uBoot> saveenv

Alternatively, the bootloader can then be configured to automatically load the FPGA on startup (prior to the u-Boot running other boot commands) by setting the environment variable "bootfpga", as shown below. Critical Link does not recommend this approach as a bad FPGA load (e.g., one that drives the NMI pin high) can "brick" a unit as control is not transferred to the UART prompt until after the bootfpga variable is run. However, for legacy systems, the command is supported.

Example for Spartan-6 LX16 FPGA bin file:

U-Boot > setenv bootfpga "sf probe 0; sf read 0xc0700000 0x580000 0x80000; loadfpga 0xc0700000 0x80000" 
U-Boot > saveenv

Example for Spartan-6 LX45 FPGA bin file:

U-Boot > setenv bootfpga "sf probe 0; sf read 0xc0700000 0x580000 0x170000; loadfpga 0xc0700000 0x170000" 
U-Boot > saveenv

Example for any Artix-7 FPGA bin file:

U-Boot > setenv bootfpga "sf probe 0; sf read 0xc0700000 0x580000 0x21728C; loadfpga 0xc0700000 0x21728C" 
U-Boot > saveenv

Using Linux drivers to load the FPGA

To load from linux requires installing our fpga driver module. The advantage to the driver is that they can reconfigure on the fly via a shell script if they so choose. To load the FPGA requires the following steps:

  1. Load the fpga driver module.
  2. Issue the reset sequence to the FPGA
  3. Send the driver the FPGA configuration image.
  4. <optional> Command the driver to poll for "cores"
  5. <optional> Load necessary drivers to control the polled "cores".

The FPGA driver has been written to support all of these operations via simple scripting utilizing devices files created in the sysfs filesystem. Here is a typical set of commands to program the FPGA:

root@mitydsp# insmod fpga_ctrl.ko
root@mitydsp# echo "1" > /sys/devices/fpga_ctrl/cmd  # configure the FPGA driver to reset the module
root@mitydsp# echo "2" > /sys/devices/fpga_ctrl/cmd  # configure the FPGA driver to program the FPGA
root@mitydsp# cat my_fpga_image.bin > /sys/devices/fpga_ctrl/image # write the FPGA configuration to the FPGA

At this point, the FPGA is configured (the FPGA done LED should be illuminated), but the driver has not yet been told to poll and enumerate the FPGA cores as devices to the linux device framework. If you are using the EMIF infrastructure provided by Critical Link and/or IP cores available from Critical Link, you need to command the FPGA to poll for the cores.

root@mitydsp# echo "3" > /sys/devices/fpga_ctrl/cmd  # scan for FPGA cores, enumerate to linux device framework

Checking Version Number

To check the version number of the FPGA, type the following command:

cat /sys/devices/fpga_ctrl/version

Sample FPGA File

Example .bin files for the Industrial IO board can be found in the latest MDK release.

Artix7 example .bin files uploaded to LCD_configuration

Go to top
Add picture from clipboard (Maximum size: 1 GB)