Design of general-purpose JTAG debugger Based on FPGA

Design of general-purpose JTAG debugger Based on FPGA

[Date:]

Source: single-chip microcomputer and Embedded System Application Author: Ma junrehang, University of Electronic Science and Technology

[Font:Large Medium Small]

　

The development of the system based on the concept of System Virtual Machine (ANN) is a new development direction for the simulator. The so-called systems on a chip are implemented by using the programmable technology. In traditional design, hierarchical systems are integrated into an FPGA chip.
The reusability of the system is an advanced design concept. To reduce the burden on users and avoid repetitive work, some commonly used but complex functional modules in digital circuits, such as the SDRAM Controller, are designed as modifiable modules, you can directly call these modules when designing a system. These specific functional modules are called ipcore ). Because ipcore is usually very mature, it reduces the development risk.
In this paper, a general debugger is designed based on the characteristics of the system. Based on the CPU model of the target board to be debugged, compile the corresponding debugging ipcore and other general ipcore to generate an embedded debugging system, download it to FPGA, and implement a general debugger. When using the same hardware system, you can select different debugging ipcore to debug different CPUs, and different ipcore can be easily replaced with each other. This method has advantages in design flexibility, development cost, development cycle, and performance. The specific implementation uses the Cyclone Development Board and the Altera development kit.

1 JTAG debugging Principle
Currently, most debugging methods used in online simulation debuggers are based on the JTAG Standard. In 1986, the joint test Action Group published the earliest Boundary Scan Testing specification. After continuous improvement, it was approved as the IEEE Std 1149.1a standard (JTAG Standard) in 1990. Most complex IC chips now have JTAG debugging interfaces. The debugging method discussed in this article is also based on the JTAG Standard. The following describes the JTAG debugging principles.
The basis for JTAG debugging is the border scan test. It is implemented by attaching a BoundaryScan Cell (BSC) and some additional test control logic to each I/0 foot of the chip. Each BSC has two Data channels: one is the Test Data channel -- Test Data Input (TDI) and Test Data output TD0 (Test Data 0 utput ); the other is Normal Data tunnel-Normal Data Input NDI (Normal Data Input) and Normal Data Output ND0 (Normal Data Output ). In normal working status, input and output data can be freely transmitted through each BSC. Normal Working data is imported from NDI and output from NDO. In the test status, you can select the data flow channel: for the input pin, you can choose to input data from NDI or from TDI; for the output pin, you can select to output data from BSC to NDO or to TDO. The boundary scanning Register units on the input and output pins of the chip can be connected to each other to form a scanning chain around the chip. Using the border scan chain, you can control the input of the chip and observe the output of the chip. Generally, the chip provides several scanning links to complete the test. For example, the ARM7TDMI core provides three scanning chains.
The JTAG controller consists of the Test Access Port Controller (TAP), command registers, and data registers. Among them, the TAP controller is the core controller of JTAG and requires the following five control signals: TCK (border scan clock), TMS (JTAG test mode selection), TDI (Serial border scan input data), TDO (Serial boundary scan output data), and TRST (JTAG test logic reset ). The JTAG controller is able to control CPU operations through the constant change of the TAP controller status. The state machine 1 of the TAP controller is shown.

2 system design and implementation
2.1 hardware design and implementation
In this paper, the hardware structure shown in Figure 2 is realized by using the a1133 FPGA device.

Lists all types of ipcores required, most of which can be found in the Altera development kit, including:
Niosii/f CPU, 50 MHz, the free soft-core CPU provided by Altera.
Aveon bus for data communication.
Flash Controller, used to control and operate flash chips. The flash chip stores the operating system, 1 WIP protocol stack, and other debugging code statically. The flash chip used in the system is am29lvl60d with a capacity of 2 MB.
The SDRAM controller is used to control and operate the SDRAM chip. The SDRAM chip is used to dynamically execute debugging programs. The SDRAM chip used in the system is Samsung's k4s640432 with a capacity of 8 Mb.
Ethernet controller, used to control and operate the NIC chip. The simulator uses this Ethernet port to communicate with the integrated development environment of the PC. The NIC chip used in this system is lan91c111.
ARM7TDMI JTAG ipcore, which is used for simulation and debugging, must be developed independently. Its internal logic is implemented in the language of OpenGL, and then the ipcore description file is compiled according to the Altera ipcore standard, and finally mounted on the three-state bus to complete all the debugging functions.
TCK generator, tck pulse generation logic, needs independent development. The TCK signal is generated by using the Nios clock and used as the clock to drive ARM7TDMI JTAG ipcore. It is made into a small functional module and communicates with the three-state bus through Pio.
The ipcore described above is compiled using the development tool Altera us II of Altera, and finally downloaded to Altera FPGA. The cpga chip used in this system is the cyclone series eplcl2. The chip consists of 12 060 logical units, with 239 616-bit Ram, Two Phase-Locked Loops are integrated on the chip, and a maximum of 249 user I/O pins are provided.
The hardware structure is a good embodiment of the concept of the system. All IPcore (including the release and self-developed by Altera) are integrated into one FPGA. A single on-chip system basically contains the vast majority of online simulator functions. Any changes in hardware structure design are on the FPGA, which enables the concept of a general online simulator to be realized. For online simulation of other chips, you only need to change the ARM7TDMI JTAG IPcore module and download it to FPGA again to perform online simulation of another processor chip. This IPcore is implemented in the language of OpenGL and saved as the armjtag. v file. You can generate a component of the file through the system Builder in SOPC us II, and then add the component to the system. After the device pins are allocated, it is fully compiled in Quartus II and finally the ice. pof file is generated. Write the file to the configuration chip EPCS4 through the programmer. This completes the hardware system.
2.2 Software Design and Implementation
The software part of the system includes two modules: one is the PC-side development debugging interface, and the other is the control program in the debugger. The two modules communicate through the TCP/IP protocol.
The main function of the PC-side development debugging interface is to receive user Debugging commands and display debugging results. This is the only way for the system to interact with users. The development and debugging interface provides you with a unified debugging function interface and a unified debugging command for the debugger. The system is developed using Visual C ++.
The main function of the control program in the debugger is to convert upper-level user Debugging commands into a specific JTAG command sequence, control IPcore to send it out, and receive JTAG feedback and send it back to the user interface. The system is developed using the nioside. Add the LwIP and μC/OS components to the engineering properties of the nioside. The main program first initializes μC/0 S, initializes the LwIP protocol stack, and then starts μC/OS. All program control is placed in the OSStart () task of μC/OS. This task first establishes a socket and waits for data to arrive in an endless loop. After receiving the debugging command from the PC, extract the command words and parameters from the data packet, convert the command words into the Debugging commands required by IPcore, and send them to IPcore through the aveon bus, wait for the IPcore to complete. Finally, package the data returned by IPcore and send it back to the PC.
Common Debugging commands currently provided are listed in Table 1.

Valid data in TCP/IP packets is 12 bytes. 1st to 4 bytes are the command code, 5th to 8 bytes are the command parameter 1, and 9th to 12 bytes are the command parameter 2. Whether command parameter 1 and command parameter 2 are valid depends on the command code. After receiving the data packet, the main control program sends the command code to the command port address of JTAG IPcore, and sends command parameter 1 to the parameter port address according to the command code. If the command code requires command parameter 2, it will be sent in the next cycle.
In the hardware system design of the system, all peripherals are centrally located. Set the command port address and parameter port address of JTAG IPcore to 0x00938550 and 0x00910860 respectively, and the port width is 32 bits. Therefore, in the program, to send commands to IPcore, you only need to write 32-bit data to address 0x009000050; To send parameters to IPcore, you only need to write 32-bit data to address ox009000060. The feedback data port address is set to ox00942570, and the port width is 32 bits. Therefore, in the program, to read the JTAG feedback data, you only need to read the 32-bit data at the address 0x00942570.
2.3 Implementation of JTAG IPcore
JTAG IPcore is the core of the debugger. The following describes the implementation of this part.
IPcore Interface 3.

The external interface of this IPcore consists of two parts: one is the interface part that communicates with the aveon bus, that is, the left part in the figure; the other is the interface part that communicates with the CPU to be debugged, that is, the right part of the graph. In addition, some important registers are defined throughout the implementation.
"Reg [3000: O] tms, tdo" are used to store the tms and tdo sequences that complete the current operation respectively. Operations such as accessing the memory require a long tms sequence and a tdo sequence, and therefore 3001 bits are used. Each time IPcore reads one bit from these two registers, it sends data to the corresponding pins. The tdi Register uses only 134 bits, because not every tdi input is useful for JTAG debugging. The parmreg register is used to store the parameters uploaded by the bus. The tdidata register is used to store valid data read from the tdi pins and will be sent to the aveon bus. The tdicolJnter register is used to count the input data of tdi.
Commands on the aveon bus are sent to the ins [31: 0] port. Determine the command in the main program of the debugger and make corresponding actions. After IPcore reads a command, it searches for the corresponding TMS command sequence based on the command code and sends the command sequence to the tms register. At the same time, read the command parameters through the parm [31: O] Port, generate the corresponding TDO Sequence Based on the command parameters, and send it to the tdo register. When the content of the two registers is ready, the TCK clock is used to control the output through the TMS pin and the TD0 pin. Check the TDI pin at the same time as the TDO pin output, and read the data on the TDI pin into the IPcore at the appropriate time. After processing, the data is sent back to the bus.
Because the TMS sequence is long and its corresponding to each debugging command is fixed, in this design, the TMS sequence is made into a table and stored in IPcore, instead of sending messages through the bus. When necessary, read the data according to different command codes. This saves time and increases debugging speed.

Knot
This article introduces the design scheme and implementation process of a General debugger based on FPGA. In the development process, advanced embedded design ideas such as IP Reuse and software/hardware collaborative design play a very good role in shortening development time and reducing development risks. At the same time, the self-developed ARM7TDMIJTAG IPcore and C8051 JTAG IPcore reflect the versatility of the debugger. Next, we will introduce IPcore based on other ARM series and PowerPC series. The application value of this debugger will be further improved.