Reprogramming PLDs using embedded processors

1 Introduction

In addition to embedded processors, programmable logic devices are often used in embedded systems. Some programmable logic devices can also update their programs after being soldered to the printed circuit board. This feature is called "in-system reprogrammability" (ISR). In the single-board development stage, a download cable is usually used to reprogram the programmable logic device through the IEEE Standard 1149.1 JTAG interface. In the product prototype and manufacturing stage, the JTAG interface on the single board may no longer be connected to the download cable due to product appearance and internal structure design considerations. In this case, the programmable logic device cannot be reprogrammed through the download cable. Products based on embedded systems usually provide serial interfaces or Ethernet interfaces to the outside world. These interfaces are controlled by embedded processors [1]. Therefore, the update program of the programmable logic device can be sent to the processor through these interfaces, and the processor can reprogram the programmable logic device.

2 Implementation Method

2.1 Software

Serial interfaces are widely used in embedded systems because of their simple protocol implementation and low resource consumption. All that is needed is to use a serial interface cable to connect the serial interface of the host to the serial interface of the product, and then send the update program to the processor through the serial interface communication software on the host. The file transfer protocol generally uses the Xmodem protocol. For network products based on embedded systems, since they provide an Ethernet interface and the operating system has an embedded TCP/IP protocol stack, the Ethernet interface can be used to send the update program to the processor. The file transfer protocol generally uses the TFTP protocol. The embedded system runs the TFTP server program and the host runs the TFTP client program [2].

The update program of the programmable logic device received by the embedded processor through the serial interface or Ethernet interface is a Jam file, which is generated by converting a target file such as Programmer Object File (*.pof, with the file suffix pof) according to the requirements of Jam Standard Test and Programming Language (hereinafter referred to as Jam language) using a development tool such as Altera's Quartus II development tool [3]. The Jam file is an ASCII file that contains all the information for programming the programmable logic device, including programming algorithms and data. The details are as follows:

(1) The "Annotation Field" section stores relevant information about the Jam file, including the name of the programmable logic device, the creation time of the Jam file, the version of the Jam language used, etc.

(2) The "Variable Declaration/Initialization" section consists of programming/verification data and some variable declarations used in the Jam file.

(3) The "algorithm part" contains the commands and codes needed to program the programmable logic device, including blank check, erase, programming and verification, etc. All functions that can be performed on the programmable logic device. Branch or loop structures can be used in the code.

After receiving the Jam file, the embedded processor runs a Jam Player program to parse the Jam file, translate each instruction in the file, and read and write data to the JTAG port, thereby completing the update of the ISR program. Jam Player is a C language program, and its main program performs all basic functions, including parsing the contents of the Jam file and translating instructions. This part of the content is the same for all embedded systems and Jam files. The I/O functions of the Jam Player, including the addressing of I/O pins, delay programs, file I/O, and operating system-related functions are all included in the jamstub.c file. By modifying this file, the Jam Player can be applied to any system structure. When the Jam Player receives data, jamstub.c can retrieve data from the Jam file or read data from the TDO pin by shifting. jamstub.c can also send processed JTAG data to three JTAG pins (TDI, TMS, and TCK), and return error messages and related information to the calling program. Upgrading the program of the ISR programmable logic device only requires changing the Jam file.

Jam Player uses a jam_jtag_io function (int jam_jtag_io(int tms_tdi)) to control the read and write operations of the JTAG interface. Each time this function is called, the TMS and TDI output signals of the JTAG will be set to the required values, and the TDO input signal will be sampled and the value will be returned, and then the TCK clock signal will generate a falling edge. The tms_tdi parameter contains 3 bits of information, indicating the status of the TMS and TDI signals and whether the TDO output needs to be read (if the value of TDO is not needed, the reading operation of TDO can be skipped). The least significant bit represents the value of TMS, the second bit represents the value of TDI, and the third bit indicates whether to read TDO: if set, the value of TDO must be read, otherwise it is not necessary. If TDO is low, a zero value is returned, and a non-zero value is returned if it is high. A zero value is also returned if TDO is not read.

2.2 Hardware

There are two ways to connect an embedded processor to a JTAG device. One is to directly connect the embedded processor to the JTAG device. This method requires the processor to have four dedicated pins for the JTAG interface, which saves circuit board space but occupies four pins of the processor. The other method connects the JTAG device to the processor bus through an interface logic, and the processor reads and writes the JTAG device through the address corresponding to the JTAG device [4].

Figure 1 shows an example of the interface logic. When the interface logic receives the correct address and control signals, it will synchronize the TDI, TCK, and TMS signals and drive the output pins through the multiplexer. The download cable can also program or verify the JTAG chain through the multiplexer [5]. The synchronization of the TDI, TCK, and TMS signals is completed through the clock signal and register of the embedded processor. The TDO buffer can prevent bus contention. The TDI, TCK, and TMS buffers can also be used to read back the register values ​​during debugging. The AND gate in the figure controls the execution of read or write operations through the R/W signal, while the AS and DS signals can select and deselect the circuit at another level.

Figure 1 Interface logic

2.3 Memory Usage

The following discusses memory usage when reprogramming a programmable logic device using an embedded processor. In order to be compatible with embedded processors that do not have memory allocation services, Jam Player requires both program storage space and dynamic memory. Program storage space (such as hard drive or ROM) is used to store Jam Player executable binary files and Jam files; dynamic memory (such as RAM) will be used when calling Jam Player.

Jam Player uses memory in the following order:

(1) The embedded processor calls Jam Player from ROM;

(2) Jam Player reads the Jam file from ROM and stores it in RAM;

(3) Jam Player decompresses the compressed program data contained in the Jam file and stores the decompressed data into RAM;

(4) Jam Player initializes the symbol table, stack, and heap in RAM.

The symbol table contains the labels and variables of the Jam file; the stack is used for FOR loops, CALL and PUSH statements; the heap is used as temporary memory for the evaluation of mathematical expressions and the storage of fill data. When processing a Jam file, the stack and heap sizes will increase with each command, and the available dynamic memory will become less and less, while the dynamic memory space required for the Jam file, the decompressed data and the symbol table remains unchanged throughout the process.

Figure 2 shows the memory usage of Jam Player.

Figure 2 Jam Player memory usage [page]

2.3.1 Program storage space (ROM) usage

The required program storage space is:

The size of the Jam Player is determined by the embedded processor used and the complexity of the interface logic. The total program storage space of the Jam file is determined by the number of devices being programmed on the JTAG chain. If there is only one device on the JTAG chain, the size of the Jam file corresponding to that device is the size of the required program storage space. The size of the Jam file also depends on the target device and is generally between 26K bytes and 30K bytes after compression. Assuming there are 3 devices in the JTAG chain and all 3 devices are to be programmed, the required Jam file storage space will be the sum of the 3 Jam file sizes. Table 1 shows the program storage space required for a single device.

Table 1 Program storage space required for a single device

2.3.2 Dynamic Memory (RAM) Usage

The RAM space required is:

Jam files require the same amount of RAM as ROM, as discussed in Program Memory Usage. After the Jam Player reads the Jam file from ROM and stores it in RAM, it decompresses the compressed data in the Jam file and stores the decompressed data in RAM. The amount of RAM occupied by the decompressed data can be obtained by using the ACA variables in the Jam file. Each ACA variable is listed in the "Variable Declaration/Initialization" section, and the size of each array is determined by the value in the square brackets of the variable declaration. For example:

This indicates that the size of the decompressed ACA variable is 434460 bits, or approximately 53K bytes.

The size of the symbol table is given by:

The size of a variable or tag name is 48 bytes. JAM_C_MAX_SYMBOL_COUNT is defined in the jamdefs.h file and has a default value of 1021. In practice, most Jam files use a maximum of 400 variable and tag names. Changing JAM_C_MAX_SYMBOL_COUNT to 400 can save some dynamic memory.

Compared to the total RAM space used by the Jam Player, the stack and heap require very little RAM. The JAMC_MAX_NESTING_DEPTH constant in the jamdefs.h file defines the maximum depth of the stack. Table 2 shows the RAM space required for a single device.

Table 2 RAM space required for a single device

3 Conclusion

This article describes in detail a new method for reprogramming ISR devices using the Jam programming and testing language through an embedded processor, through the introduction of software, hardware, and memory usage. It provides a reference for reprogramming programmable logic devices during product prototype and manufacturing stages and has strong practical significance.

The author's innovation: During the prototype and manufacturing stage, the JTAG interface on the board may not be connected to the download cable due to the product's appearance and internal structure design. At this time, the programmable logic device cannot be reprogrammed through the download cable. This problem is solved by sending the update program of the programmable logic device to the processor through the serial interface or Ethernet interface, and the processor reprograms the programmable logic device.

References

[1] Du Yan, Liu Congyue. Embedded real-time system software testing practice[J]. Microcomputer Information, 2007, 4-2: 86-88.

[2] Kamal, Raj. Embedded Systems: Architecture, Programming and Design[M]. Tsinghua University Press, 2005.

[3] Zheng Yamin, Dong Xiaozhou. Programmable logic device development software Quartus II[M]. National Defense Industry Press, 2006.

[4] Stuart, R. Ball. Embedded Microprocessor System Design Examples (3rd Edition) [M]. Publishing House of Electronics Industry, 2004.

[5] Tian Ze. Embedded System Development and Application[M]. Beijing University of Aeronautics and Astronautics Press, 2005.