Realizing ARM FPGA online configuration based on JTAG interface

With the development of communication technology, more and more wireless access technologies have emerged. In order to solve the intercommunication and compatibility between different standards, people have proposed software defined radio (SDR) technology. SDR technology requires that the communication terminal has the ability to be reconfigured, and dynamically change the modulation/demodulation, encoding/decoding, interleaving/deinterleaving schemes according to the specific communication network conditions. The implementation of SDR terminals is often based on reconfigurable hardware environments, such as field programmable gate arrays (FPGAs) and digital signal processors (DSPs), rather than specific hardware circuits and chips such as application specific integrated circuits (ASICs). In Sys-tem Programming (ISP) or dynamic configuration of FPGA is an important SDR implementation technology. This article introduces a method developed by the author to dynamically configure FPGA through the JTAG interface under ARM-based embedded Linux.

The system uses Samsung's S3C2410 processor chip based on ARM9 and Altera's CycloneII series EP2C70 FPGA chip. The ARM processor runs an embedded Linux system tailored based on S3C2410, with a kernel version of 2.4.18.

1 FPGA configuration method and configuration file

Altera's CycloneII series FPGA chips are low-cost FPGAs based on 90 nm technology, mainly targeting cost-sensitive applications such as digital terminals and handheld devices. EP2C70 has 68,416 logic units, 115,200 bits of RAM, and 150 multiplier modules, making it the most powerful chip in the CycloneII series. Like most FPGAs, the configuration information of the CycloneII series FPGAs is stored in SRAM, which loses the configuration information after power failure and needs to be reconfigured after each power-on. The CycloneII series FPGAs support three configuration methods: active serial (AS), passive serial (PS), and JTAG.

In both active serial and passive serial modes, the FPGA chip supports decompression of configuration data during the configuration process, that is, the configuration data can be stored in a compressed format; when using JTAG configuration, the FPGA chip does not support the decompression process and cannot use compressed configuration data.

Different configuration methods often require configuration files in different formats. Using the QuartusII integrated development environment provided by Altera, you can generate various configuration files. QuartusII generates configuration files in .sof and .pof formats by default. To perform JTAG downloads on FPGAs in ARM-based embedded Linux, you must use configuration files in .jam or .jbc formats.

2 JTAG interface working mode

The JTAG interface is an industry standard, mainly used for chip testing and configuration, using the IEEE Std 1149.1 joint boundary scan interface pins. JTAG was originally used to test chip functions. Its working principle is to define a test access port (TAP) inside the device and test and debug internal nodes through a dedicated JTAG test tool. TAP is a universal port, through which an external controller can access all data registers and instruction registers provided by the chip. Now the JTAG interface is also commonly used for online configuration of chips, to configure devices such as PLD and Flash. In order to complete the debugging of the system, any prototype system supports the JTAG configuration method, so JTAG configuration has become the most widely supported configuration method. Most FPGA chips of different manufacturers and models support the JTAG configuration method. In Altera's FPGA chips, the JTAG configuration method has a higher priority than any other configuration method. JTAG allows multiple devices to be connected in series through the JTAG interface to form a JTAG chain, so that each device can be tested and configured separately.

The JTAG interface consists of four required signals, TDI, TD0, TMS, and TCK, and one optional signal, TRST.

3 Jam STAPL Kit

In an embedded Linux environment, when configuring FP-GA using the JTAG interface, the Standard Test And Programming Language (STAPL) standard must be used. STAPL is a programming language specifically used to describe programmable logic device (PLD) configuration files, and the standard is established by the EIA/JEDEC organization. Configuration files described using STAPL are universal and independent of PLD manufacturers.

Jam STAPL is a STAPL-supported suite provided by Altera. Configuration using Jam STAPL consists of two parts, Jam Player (Jam interpreter or Jam virtual machine) and Jam configuration file. Jam Player runs in the microprocessor, reads the Jam file and parses the content expressed in the Jam file, generates a binary data stream for configuration on the JTAG interface and reads the feedback data.

The working method of Jam STAPL is shown in Figure 1. Using the integrated development environment Jam Composer provided by the PLD manufacturer, a Jam configuration file can be generated (the file contains complete configuration information such as target device and application data, which is independent of the manufacturer and configuration platform). Then use Jam Player to interpret and generate JTAG configuration data to configure each device in the JTAG chain.

When using Jam STAPL for configuration, you only need to change the Jam configuration file for different applications and different target devices (different models or different manufacturers), without changing the Jam Player. Because the Jam Player does not contain any information related to the application or device, it is only responsible for parsing the contents of the Jam configuration file. It works very similarly to the Java programming language. The Jam Player is equivalent to the Java virtual machine, and the Jam file is equivalent to the compiled Java bytecode file (.class file). There are two formats of Jam configuration files:

①ASCII text format file, that is, the configuration source file described by STAPL, the file suffix is ​​.jam. This format is easy to read and understand, but because it uses ASCII text encoding, it is relatively large. [page]

② Byte-Code format file, the byte-code file after the STAPL source file is compiled, the file suffix is ​​".jbc". For the same configuration information, this format is smaller than the .jam format and saves storage space; its disadvantage is that the configuration information cannot be read directly.

Correspondingly, there are two types of Jam Player: the ordinary Jam Player, which is responsible for interpreting .jam files; and the Jam Byte-Code Player, which is responsible for interpreting .jbc files. You can download the source code of the two Players written in C language for free from Aitera*****.

4 System Design and Implementation

4.1 System Hardware Design

The system hardware connection scheme is shown in Figure 2. Only JTAG configuration is used in the system, so the nCONFIG, MSELO and MSEL1 pins related to AS and PS are not used, and nCONFIG is pulled high, and MSELO and MSEL1 are grounded. The DATA0 and DCLK pins can be configured arbitrarily and are grounded here. The general pins GPB7, GPB8, GPB9, and GPB10 of S3C2410 are used as TMS, TDl, TCK and TDO of the JTAG interface respectively.

4.2 System Software Design

4.2.1 Generate Jam configuration file

To use Jam STAPL for JTAG configuration, you need a Jam configuration file. The default configuration files generated by the integrated development environment QuartusII are in .sol and .pof formats. To generate .jam and .jbc files, you can use two methods:

The first method is to set the QuartusII configuration file generation option before compiling the project. In the QuartusII main menu, select [Assignments] → [Device] menu, enter the [Setting] window, click the "Device & Pin Options..." button, select the "Programming Files" tab in the pop-up dialog box, select the .jam or .jbc file format in this tab, and click the "OK" button.

The second method is to use the file format conversion tool that comes with QuartusII after the compilation is completed to convert the .sof or .pof file to the .jam or .jbc file type. In the main menu of QuartusII, select the [File] → [Convert Programming Flies] menu to enter the [Convert Programming Files] window. In the "Programming file type\'' of this window, select the .jam or .jbc type, specify the file save path and file name in "File name" (the default is to use the same path and name as .sof or .pof), and finally click the "OK" button to generate the .jam or .jbc configuration file.

4.2.2 Porting Jam Player

The Jam Player source files provided by Altera include code for three platforms: DOS, Windows, and Unix. To use it on a Unix-like Linux platform, it must be customized and ported.

The organization structure of the Jam Player source program is shown in Figure 3. The functions related to the I/O processing of the configuration platform are arranged in the jbis-tub.c file. Users of Jam Player only need to modify the functions in jbistub.c according to the platform and hardware environment, without modifying other files.

Porting Jam Player to embedded Linux mainly involves the following customizations:

①Change the platform predefined environment, add preprocessing statements, and remove unnecessary source code;

②Map JTAG signals to specific hardware pins;

③Customize the error information output method;

④Customize the delay function according to the processing capability of the specific microprocessor.

For more detailed customization and porting process, please refer to references [7] and [8].

To help the Jam Player migration process, Altera provides an idcode file for debugging and verification. The file has .jam format and .jbc format, which are used for migration of ordinary Jam Player and Jam Byte-Code Player respectively. Their functions are to read the IDCODE of the target device (each type of FPGA chip has a corresponding IDCODE, which can be found in the chip data sheet). If the migration is successful, Jam Player will print out the read IDCODE and the corresponding chip model; otherwise, it will output detailed related error information for debugging.

4.2.3 JTAG Driver

Since Jam Player runs in an embedded Linux environment, it cannot directly access the pin registers of the ARM chip, nor can it directly operate the input and output of the pins. Therefore, it is necessary to write drivers for the pins used for the JTAG interface and encapsulate them into character files that Jam Player can read and write.

This driver complies with the common Linux character file driver writing rules. It does not need to apply for interrupts to the system and implement interrupt functions. The most important thing is to comply with the timing control of the JTAG interface pins when reading and writing pins. The pin timing of the JTAG interface is shown in Figure 4. As can be seen from the figure, for the ARM JTAG interface, the TDI and TMS output signals are latched on the falling edge of the TCK clock signal, while the TDO feedback signal is valid on the rising edge of the TCK clock signal. [page]

In the driver, the jtag_write and jtag_read functions corresponding to the write and read calls of the operating system are as follows (these two functions implement the specific operation process of JTAG input and output signals):

When the driver is called in Jam Player, only TMS and TDI signals are provided in the buffer, as shown in Figure 5(a). According to the hardware design, the system uses pins 7, 8, 9, and 10 of the GPB port of S3C2410. The structure of the GPB data register (GPBDAT) is shown in Figure 5(b). Therefore, when writing the content of buffer[0] to the GPBDAT register, it needs to be shifted left by 7 bits; when reading the TDO signal, only the 10th bit of data needs to be returned.

4.2.4 JTAG Online Configuration Performance and Timing

Since JTAG configuration does not support the compressed form of configuration information, the time of JTAG configuration is only related to the model of the target chip, but not to the specific application. We have verified in the PC system that the time to download the configuration is the same for an AND gate operation application with a source program of 10 lines and an IEEE802.16 physical layer implementation application with a source program of more than 6,000 lines when using JTAG download in QuartusII.

According to the above embedded system design, Jam Player runs in a Linux environment based on the S3C2410 processor with a clock frequency of 200 MHz. It takes about 70 seconds to configure EP2C70 once. Under the same Jam Player operating environment, although the sizes of Jam files of different applications are different, their configuration time is the same. There are three ways to reduce the configuration time: one is to increase the CPU speed of the Jam Player system; the second is to modify the code of the JamPlayer source program to make it more efficient; the third is to reduce the delay operation of the driver according to the system design and meet the JTAG pin timing.

Conclusion

This design implements a solution for online configuration of FPGA through JTAG interface based on ARM processor in embedded Linux system. This method is simple in design, only needs to connect the four necessary pins of JTAG; it is low-cost and does not require additional configuration chips and equipment (such as Altera EPC series and EPCS series); it is flexible to use, and FPGA can be configured online through ARM; the system can dynamically update FPGA applications without restarting. In our experimental system environment, the time for one configuration is about 70s.

References:

[1]. EP2C70 datasheet http://www.dzsc.com/datasheet/EP2C70_1438351.html.
[2]. Device datasheet http://www.dzsc.com/datasheet/Device_1397784.html.