CN115357439A - Development system for processor board level debugging - Google Patents

Abstract

The invention provides a development system for processor board-level debugging. The system comprises a debugger tool and a debug access port DAP, wherein the DAP is connected with the debugger tool and accesses registers related to debugging in a processor through an advanced peripheral bus APB; the debugger tool is used for directly reading out the state inside the processor to the upper computer through the DAP; the processor comprises a plurality of processor cores and a second-level cache control L2C module, wherein each processor core comprises an instruction-fetching unit IFU module, a data processing unit DPU module, a read-write processing unit LSU module and a memory management unit MMU module, and available domains are distributed in the processor core modules and the L2C module respectively. The invention can efficiently position the hardware problem in the processor, has extremely small area and is easy to realize.

Description

Development system for processor board level debugging

This patent is a sub-patent that is separated from the earlier patent with application number 201811526758.3 and application date 2018.12.13, and claims to have corresponding priority.

Technical Field

The invention relates to the technical field of processor design, in particular to a development system for processor board-level debugging.

Background

With the continuous upgrading of chip manufacturing process and the continuous improvement of market demand, the design complexity of the chip is more and more large, and the working frequency is more and more high. After the chip is taped out, some functional problems inevitably occur. It is almost impossible to analyze only the hardware problems that may occur from the results of the test. This is especially true for processors. Although the processor architecture may define some Debug functions, these functions work on the premise that the processor has no hardware problems, and the objects they want to Debug are software rather than hardware. These functions are not useful if the hardware itself is problematic.

Currently, ARM corporation has proposed an ELA (Embedded Logic Analyzer) method on its latest processor, which can store signals inside the processor in an SRAM (static random Access Memory) by a trigger event. This solution has two disadvantages: firstly, the area of the ELA is large, and certain obstacles are caused to timing sequence convergence and rear-end layout and wiring of the processor; secondly, the trigger condition needs to be known accurately, which is not easy to do in the actual Silicon Debug (board level Debug). So that the effective utilization rate in the actual project is not high.

Disclosure of Invention

The development system and the development method for the board-level debugging of the processor can efficiently position the hardware problem in the processor, have extremely small area and are easy to realize.

In a first aspect, the present invention provides a development system for processor board level debugging, the system comprising a debugger tool and a debug access port DAP, wherein,

the DAP is connected with the debugger tool and accesses registers related to debugging in the processor through an Advanced Peripheral Bus (APB);

the debugger tool is used for directly reading the state inside the processor to the upper computer through the DAP;

the processor comprises a plurality of processor cores and a second-level cache control L2C module, wherein each processor core comprises an instruction fetching unit IFU module, a data processing unit DPU module, a read-write processing unit LSU module and a memory management unit MMU module, and available domains are distributed in the processor core modules and the L2C module respectively.

Optionally, the DPU module is configured to manage an execution process of an instruction in a processor core;

the IFU module is used for managing instruction fetching operation of instructions in the processor core, distributing part of custom domains in a register related to the DBG and a PMU register, collecting important signals for board-level debugging in the IFU, and generating IFU Auxiliarydebug Registers;

the LSU module is used for managing the execution process of a Load/Store instruction in a processor core, distributing a part of custom domains in a register related to a DBG and a PMU register, collecting important signals for board-level debugging in the LSU and generating LSUAuxiliary Debug Registers;

the MMU module is used for managing the conversion process of the page table in the processor core, distributing part of custom domains in the register related to the DBG and the PMU register, collecting important signals for board-level debugging in the MMU, and generating MMU Auxiliarydebug Registers.

Optionally, the L2C module comprises a CTI module and an L2C Autoxiliary Debug Registers module, wherein,

the CTI module is used for generating a trigger event and comprises CTI Oldregisters defined by ARMv8-A architecture but comprises a custom domain;

the L2C Autoxiliary Debug Registers module is used for collecting important signals for board-level debugging in the L2C by utilizing a CTI custom domain.

Optionally, the DPU modules include a DBG Old Registers module, a PMU Old Registers module, and an Auxiliary Debug Registers module, wherein,

the DBG Old Registers module is a DBG related register defined by an ARMv8-A framework and does not contain a custom domain;

the PMU Old Registers module is a PMU related register defined by an ARMv8-A framework and does not contain a custom domain;

the Auxiliary Debug Registers module collects important signals for board-level debugging in the DPU module by utilizing part of custom domains in the DBG register and the PMU register.

In a second aspect, the present invention provides a development method for processor board level debugging, including:

configuring a debugger tool, and selecting relevant registers in the processor through addresses;

after the debugger tool transmits the instruction to the debugging access port, selecting a corresponding 32-bit register in the processor through the debugging access port;

the results of the 2-bit register within the processor are returned to the debugger tool through the debug access port.

In a third aspect, the present invention provides a development system for board level debugging of a processor, wherein a processor core of the processor comprises a JTAG control module and an IFU, DPU, LSU, and MMU component module, wherein,

the JTAG control module comprises a test access port TAP and a JTAG chain, and important signals in the processor core are read out through the JTAG chain;

the JTAG control module is based on a standard JTAG protocol, and internally realizes a state machine, a DR register and an IR register, wherein the DR register is used for storing signals to be derived, and the IR register is used for selecting which signals to be derived;

the IFU, the DPU, the LSU and the MMU form a module, internal important signals are divided into a plurality of groups with the width of 32-bit as a unit respectively, and the multiple groups are output to a JTAG chain through a multiplexer;

and a JTAG interface in the processor core is connected with a JTAG on the SoC outside the processor core, and finally, the debugging signal is led out of the chip.

In a fourth aspect, the present invention provides a development system for board level debugging of a processor, a processor core of the processor comprising a bus interface unit and a plurality of system registers, wherein,

the bus interface unit is used for interacting with the outside, and a read address, a read request type, a write address and a write request type signal are arranged on an interface between the bus interface unit and the outside;

the first self-defined system register is used for setting the lowest address of the read address interval;

a second custom system register, which sets the highest address of the read address interval;

the third custom system register is used for capturing the type of the read request when the read address is in the interval between the first custom system register and the second custom system register;

a fourth self-defined system register for setting the lowest address of the write address interval;

a fifth self-defined system register, which sets the highest address of the write address interval;

and the sixth self-defined system register is used for capturing the type of the write request when the write address is between the fourth self-defined system register and the fifth self-defined system register.

Alternatively, the registers for the read request type and the write request type cannot be reset.

Optionally, the read request type register and the write request type register are provided with capture flag bits, the flag bits are automatically cleared when the address register is set each time, and the flag bits are set to 1 when the address to be monitored is captured.

According to the development system and method for board-level debugging of the processor, provided by the embodiment of the invention, the board-level debugging auxiliary design is added in the design of the processor, so that an efficient debugging means is provided for the processor after the processor is taped, the hardware problem in the processor can be helped to be positioned, and the development system and method for board-level debugging of the processor are particularly helped to deadlock and abnormal access of a memory. The method provided by the invention is easy to realize, has small area and has little influence on the timing sequence convergence and the layout and wiring of the processor. The method provided by the invention can be directly combined with a debugger tool of the chip, and is convenient to debug.

Drawings

FIG. 1 is a schematic structural diagram of a development system for processor board level debugging according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of a development system for processor board level debugging according to another embodiment of the present invention;

fig. 3 is a schematic structural diagram of a development system for processor board level debugging according to still another embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The development system and method for processor board level debugging provided by the embodiment of the invention comprise several different sub-methods. These sub-methods are described separately below.

(1) Monitoring processor internal state using custom field of Architecture Debug register

The ARMv8-A Architecture defines the Architecture framework of Architecture Debug, in which an Externaldebug (DBG) register, a Performance Monitor Unit (PMU) register, and a Cross Trigger Interface (CTI) register, etc. are defined. Some fields architecturally DEFINED for these registers are IMPLEMENTATION DEFINED, meaning that they are self-defining and the number of available are shown in Table 1 (in units of a single processor core).

TABLE 1

Register with a plurality of registers	Number of
		PMU	224x32-bit＝7168-bit
DBG	96x32-bit＝3072-bit
		CTI	32x32-bit＝1024-bit

These domains can be used to monitor signals internal to the processor. In addition, the internal state of the processor can be directly read out to the upper computer by using the existing debug Tool, and the structural block diagram is shown in fig. 1. Generally, a processor is composed of a plurality of cores (processor cores) and an L2C (second level cache control module), for convenience of illustration, fig. 1 only includes one Core and one L2C, and the Core is divided into four modules, i.e., an IFU (Instruction Fetch Unit), a DPU (Data Processing Unit), an LSU (Load/Store Unit), and an MMU (Memory Management Unit). The available domains are then distributed into the Core intra-module and L2C, respectively.

The DPU module 101 is mainly responsible for managing the execution process of instructions in the Core, and itself includes a DBG0ldRegisters module 102 and a PMU OLd Registers module 103. After the Auxiliary Debug design is added, an Auxiliary Debug Registers module 104 is also included.

The DBG Old Registers module 102 is a DBG related register DEFINED by ARMv8-A architecture and does not contain an IMPLEMENTATION DEFINED field.

The PMU Old registers module 103 is PMU related registers DEFINED by ARMv8-A architecture, and does not contain IMPLEMENTATION DEFINED fields.

The Auxiliary Debug Registers module 104 collects important signals for board level debugging in the DPU module by using the fields of IMPLEMENTATION DEFINED in the DBG register and the PMU register.

The IFU module 105 is responsible for managing instruction fetching operations of instructions in the Core, distributing the Registers related to the DBG and the impinentation defmed fields in the PMU Registers, collecting important signals for board-level debugging in the IFU, and generating IFU automatic Debug Registers (Auxiliary Debug Registers).

The LSU module 106 is responsible for managing the execution process of Load/Store instructions in the Core, distributing the impact Debug domains in the Registers related to the DBG and the PMU Registers, collecting important signals for board level debugging in the LSU, and generating LSU automatic Debug Registers.

The MMU module 107 is responsible for managing the Core page table translation process, distributing the impact Debug domain in the Registers related to the DBG and the PMU Registers, collecting important signals for board level debugging in the MMU, and generating the mmuaxiliary Debug Registers.

CTI module 108, responsible for generating Debug Trigger, itself contains CTI Old Registers DEFINED by ARMv8-A architecture, but does not contain IMPLEMENTATION DEFINED field.

The L2C automatic Debug Registers module 109 collects important signals for board level debugging in L2C using the impinentationdefefined domain of CTI. The reason why the L2C selects the CTI register is that CTI is usually in a Power Domain with L2C.

The DAP module 110 is a standard Debug Access Port (Debug Access Port), and can be connected to a Debug tool on one hand, and can Access a register related to the Debug via an APB (Advanced Peripheral Bus) on the other hand.

The debug tool module 111 may be a general debugging tool, such as Trace-32 and DS-5, which are commonly used at present.

The steps for performing board level debugging are as follows:

first, a debogger tool is configured, and a relevant register is selected through an address.

The debogger tool then passes the instruction to the DAP, which selects the corresponding 32-bit register.

And finally, returning the result of the 32-bit register to the Debugger through the DAP.

(2) Method for deriving important signals in processor by using JTAG

The architecture of the Core is shown in fig. 2, in which a TAP (Test Access Port) controller is integrated inside the Core, and important signals inside the Core are read out through a JTAG chain.

The JTAG Control module 301, based on the standard JTAG protocol, implements a state machine, a DR register, and an IR register therein. The DR register is used to hold the signals to be derived and the IR register is used to select which signals to derive.

The IFU, DPU, LSU and MMU constitute a module 302, which divides the internal important signals into several groups with 32-bit width as unit, and outputs them to JTAG chain through MUX.

The JTAG interface in the Core can be connected with the JTAG on the SoC outside the Core, and finally the Debug signal can be exported to the outside of the chip.

(3) Method for capturing Speculative Memory access inside processor

Speculative execution is a common method in processor design, and can significantly improve the performance of a processor. However, a Speculative Memory access may access an area on the system that is not allowed to be accessed, which may cause unpredictable problems. To be able to quickly locate such problems, some system registers may be defined within the processor, the range of area addresses to be monitored may be set, and the details of the request to access this segment of address space may be recorded. Implementation access specifically within Core is shown in fig. 3.

The Bus Interface Unit module 401 is a Bus Interface module which interacts with the outside in the Core, and signals such as a read address, a read request type, a write address, a write request type and the like are provided on an Interface between the Bus Interface module and the outside.

The Sys Reg0 self-defines the system register 402 and sets the lowest address of the read address interval.

The Sys Reg1 self-defines the system register 403 and sets the highest address of the read address interval.

The Sys Reg2 customizes the system register 404 and if the read address is between 402 and 403, the type of read request is grabbed, as shown in table 2. This register can only be updated once after the monitored address is captured.

TABLE 2

The Sys Reg3 self-defines the system register 405 and sets the lowest address of the write address interval.

The Sys Reg4 self-defines the system register 406 and sets the highest address of the write address interval.

The Sys Reg5 customizes the system register 407 and if the write address is between 405 and 406, the type of write request is grabbed, as shown in table 3. This register can only be updated once after the monitored address is captured.

TABLE 3

The custom system register design needs to follow the following principles:

1. the registers for the read request type and the write request type cannot be reset. Thus, when the system hang is in place, the processor is reset to obtain the read-write request type.

2. The request type and write request type registers are to set a fetch flag bit. The flag bit is automatically cleared when an address register is set each time, and is set to 1 when an address to be monitored is fetched.

The development system and the development method aiming at the board-level debugging of the processor, provided by the embodiment of the invention, have the advantages that the board-level debugging auxiliary design is added in the design of the processor, an efficient debugging means is provided for the processor after the flow sheet, the positioning of the hardware problem in the processor can be helped, and the development system and the development method especially help deadlock and abnormal access of a memory. The method provided by the invention is easy to realize, has small area and has little influence on the timing sequence convergence and the layout and wiring of the processor. The method provided by the invention can be directly combined with a debugger tool of the chip, and is convenient to debug.

It will be understood by those skilled in the art that all or part of the processes of the embodiments of the methods described above may be implemented by a computer program, which may be stored in a computer readable storage medium and executed by a computer, and the processes of the embodiments of the methods described above may be included in the programs. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.

The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the present invention are also within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims (1)

1. A development system for board-level debugging of a processor, wherein a processor core of the processor comprises a JTAG control module and IFU, DPU, LSU and MMU constituent modules, wherein,

the JTAG control module comprises a test access port TAP and a JTAG chain, and important signals in the processor core are read out through the JTAG chain;

the JTAG control module is based on a standard JTAG protocol, and internally realizes a state machine, a DR register and an IR register, wherein the DR register is used for storing signals to be derived, and the IR register is used for selecting which signals are derived;

the IFU, the DPU, the LSU and the MMU form a module, internal important signals are divided into a plurality of groups with the width of 32-bit as a unit respectively, and the multiple groups are output to a JTAG chain through a multiplexer;

and a JTAG interface in the processor core is connected with a JTAG on the SoC outside the processor core, and finally, the debugging signal is led out of the chip.

Images