System-on-chip debugging system and method

Abstract

The embodiment of the invention relates to the technical field of testing, and discloses a system-on-chip debugging system and method. The test system comprises a debugging host, at least one communicator, at least one message facility and at least one analysis module, each analysis module is sequentially connected with at least one message facility and one communicator in series and then is connected with the debugging host to form a debugging channel between the debugging host and each analysis module; and the debugging host sends debugging information to each analysis module through each debugging channel so as to control each analysis module to carry out debugging tracking on the kernel module, and receives debugging tracking data fed back by each analysis module through each debugging channel. According to the scheme, the analysis modules suitable for different types of kernel modules can be conveniently integrated, the working state of each kernel module on the system-on-chip is comprehensively monitored, the real-time performance of a debugging tracking function is ensured, and the expandability and convenient migration of the debugging system are ensured along with upgrading iteration of the system-on-chip.

Description

Technical Field

[0001] Embodiments of the present application relate to the field of testing technologies, and particularly to a debugging system and method for a system on chip. Background Art

[0002] With the development of system on chip (SOC) design technology, an SOC is not only an integration of various modules, but also an integration of various technologies, involving complex interactions in various types of design integrations. The complexity of the design increases the difficulty of chip debugging and tracing. For various types of intellectual property (IP) core modules, the debugging and tracing methods are also different. How to comprehensively monitor the working status of each module, conveniently integrate the debugging modules of different types of IPs, ensure the real-time performance of the tracing function, and ensure the scalability and convenient migration of the debugging system with the system upgrade and iteration are major challenges faced in current SOC designs. Summary of the Invention

[0003] The purpose of the embodiments of the present application is to provide a debugging system and method for a system on chip. This solution can conveniently integrate analysis modules applicable to different types of core modules, comprehensively monitor the working status of each core module on the system on chip, ensure the real-time performance of the debugging and tracing function, and ensure the scalability and convenient migration of the debugging system with the upgrade and iteration of the system on chip.

[0004] To solve the above technical problems, on the one hand, an embodiment of the present application provides a debugging system for a system on chip, including: a debugging host, at least one communicator, at least one message facility, and at least one analysis module;

[0005] Each of the analysis modules is connected to the debugging host after successively connecting at least one of the message facilities and one of the communicators in series, forming a debugging path between the debugging host and each of the analysis modules;

[0006] The debugging host is configured to send debugging information to each of the analysis modules through each debugging path to control each of the analysis modules to perform debugging and tracing on the core module, and receive the debugging and tracing data fed back by each of the analysis modules through each debugging path;

[0007] Wherein, the communicator on each debugging path is configured to perform transmission protocol conversion on the data transmitted between the debugging host and the analysis module, and the message facility is configured to route the data transmitted between the communicator and the analysis module.

[0008] On the other hand, an embodiment of the present application provides a debugging method for a system on chip, which is applied to the debugging system for a system on chip as described above, including:

[0009] The debugging host sends debugging information to each analysis module through each debugging path;

[0010] The analysis module debugs and traces the kernel module according to the debugging information to generate debugging trace data;

[0011] The analysis module sends the debugging trace data to the debugging host through the debugging path where it is located.

[0012] Compared with the related technology, the debugging system provided in this embodiment can flexibly generate new debugging paths by flexibly adding the message facility and analysis modules therein, so that the analysis modules applicable to different types of kernel modules can be conveniently integrated, comprehensively monitoring the working status of each kernel module on the system on chip. At the same time, by enabling different debugging paths, the debugging host can independently configure different analysis modules, thus ensuring the real-time performance of the debugging and tracing function. Moreover, with the upgrade and iteration of the system on chip, only by flexibly adding, reducing or adjusting the types of debugging paths and analysis modules, the scalability and convenient migration of the debugging system can be realized. Description of the Drawings

[0013] One or more embodiments are exemplarily illustrated by the pictures in the corresponding drawings. These exemplary illustrations do not limit the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements, unless otherwise stated, and the drawings in the figures do not constitute a proportional limitation.

[0014] Figure 1 is a schematic structural diagram of a debugging system for a system on chip according to an embodiment of the present application Figure 1 ;

[0015] Figure 2 is a schematic structural diagram of a debugging system for a system on chip according to an embodiment of the present application Figure 2 ;

[0016] Figure 3 is a schematic structural diagram of a debugging system for a system on chip according to an embodiment of the present application Figure 3 ;

[0017] Figure 4 is a schematic flowchart of a debugging method for a system on chip according to an embodiment of the present application. Detailed Embodiments

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the following will elaborate on each implementation manner of this application in conjunction with the accompanying drawings. However, those of ordinary skill in the art can understand that in the embodiments of this application, many technical details are provided to help readers better understand this application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical solutions claimed in this application can still be implemented. The division of the following embodiments is for convenience of description and should not constitute any limitation to the specific implementation manners of this application. The various embodiments can be combined and cross-referenced with each other on the premise of no contradiction.

[0019] One embodiment of the present invention relates to a debugging system for a system-on-chip. The debugging system includes: a debugging host, at least one communicator, at least one message facility, and at least one analysis module; each analysis module is connected to the debugging host after successively connecting at least one message facility and one communicator in series, forming a debugging path between the debugging host and each analysis module.

[0020] For example Figure 1 , is the basic structure of the debugging system for the above system-on-chip. Refer to Figure 1 , only one communicator, one message facility, and one analysis module are provided. That is, the analysis module 40 is connected to the debugging host 1 after successively connecting the message facility 30 and the communicator 20 in series, thereby forming a debugging path between the debugging host 1 and the analysis module 40.

[0021] Based on the basic structure diagram shown in Figure 1 , the number of communicators, message facilities, and analysis modules in this embodiment can be arbitrarily expanded to form multiple debugging paths as shown in Figure 1 . For example, refer to Figure 2 , the number of communicators can include but is not limited to 4 (communicators 20 to 23); the number of message facilities can include but is not limited to 3 (message facilities 30 to 32), and the number of analysis modules can include but is not limited to 6 (such as analysis modules 40 to 45). For each analysis module, it first connects at least one message facility in series, and then connects a communicator and finally connects to the debugging host 1, so that a debugging path can be formed from the debugging host 1 to each analysis module for each analysis module.

[0022] Among them, for each debugging path, the direction from the debugging host 1 to the analysis module can be defined as the upward direction, and the direction from the analysis module to the debugging host 1 can be defined as the downward direction. The downward direction of each communicator is connected to the debugging host 1, and the upward direction can be connected to at least one message facility, and there may be a situation where at least two communicators are connected to the same message facility at the same time. For example Figure 2Among them, communicators 20 to 23 can all be connected to the same message setting 30. The downstream direction of each message facility is either connected to a communicator or to a message facility (one of the two cases). For example, the downstream direction of message setting 30 is connected to communicators 20 to 23, while the downstream direction of message setting 31 is only connected to one message setting 30. The upstream direction of each message facility can be connected to at least one message facility and at least one analysis module simultaneously, or can only be connected to at least one message facility, or can also only be connected to at least one analysis module. For example, the upstream direction of message setting 30 is connected to one message facility (message facility 31) and two analysis modules (analysis module 40 and analysis module 41) simultaneously, while message facility 32 is only connected to two analysis modules (analysis module 44 and analysis module 45).

[0023] In summary, in this embodiment, the connection method between the communicator, the message facility, and the analysis module is not limited, as long as it satisfies that after connecting at least one message facility and one communicator in series starting from each analysis module, it is connected to the debug host 1, forming a debug path from the debug host 1 to each analysis module.

[0024] The debug host 1 is used to send debug information to each analysis module through each debug path to control each analysis module to perform debug tracing on the kernel module, and receive the debug tracing data fed back by each analysis module through each debug path.

[0025] Among them, a debug program is built into the debug host 1, and the debug host 1 is an off-chip PC. The PC can be connected and communicate with various different types of communicators through various adapter boards, communication interfaces, etc. For example, it can be connected to an on-chip JTAG communicator through a JTAG adapter board, access the off-chip Aurora receiver through a USB interface, and the off-chip Aurora receiver can be connected to an Aurora communicator. This debug program is used to configure each analysis module in the debug system of this embodiment (send debug information), and receive the message data (debug tracing data) sent by the on-chip debug system (the debug system is divided into an off-chip debug system and an on-chip debug system according to whether it is located in the system-on-chip. Among them, the debug host belongs to the off-chip debug system, and the communicator, the message facility, and the analysis module belong to the on-chip debug system), and parse the data record to generate a visual SOC system work report.

[0026] The function of the debugging host 1 is to send debugging information to each analysis module on the corresponding debugging path through each debugging path. The debugging information can configure the function of each analysis module for performing debugging tracking operations to control each analysis module to perform debugging tracking on the kernel module. Among them, the kernel module can be the kernel module on the system-on-chip to be debugged, and the number of analysis modules can be the same as and in one-to-one correspondence with the number of kernel modules. Each analysis module is used to perform debugging tracking on the corresponding kernel module under the drive of the debugging information, generate debugging tracking data, and feedback the generated debugging tracking data to the debugging host 1 through the debugging path.

[0027] Among them, the communicator on each debugging path is used to perform transmission protocol conversion on the data transmitted between the debugging host 1 and the analysis module, and the message facility is used to route the data transmitted between the communicator and the analysis module.

[0028] For example, the function of the communicator is to perform transmission protocol conversion on the data transmitted between the debugging host 1 and the analysis module. That is, the debugging information sent by the debugging host 1 is converted into a data format recognizable by the analysis module and then sent to the analysis module through the message facility. At the same time, the debugging tracking data uploaded by the analysis module forwarded by the message facility is converted into a data format recognizable by the debugging host 1 and then sent to the debugging host 1.

[0029] In some embodiments, the types of the above communicators may include but are not limited to: at least one type of AXI communicator, JTAG communicator, and Aurora communicator.

[0030] The AXI communicator provides an AXI slave interface, enabling the background software running on the internal processor of the chip of the system-on-chip to monitor itself through the AXI interface. The specific solution is that the debugging host 1 writes formatted message data to the AXI communicator according to the memory mapping port of the AXI communicator. These data are forwarded by the AXI communicator to the specific analysis module in the upper layer to perform corresponding debugging work. The debugging trace data is sent to the cache in the AXI communicator, and the debugging host 1 then reads the debugging trace data from the AXI communicator.

[0031] The JTAG communicator is connected to an off-chip JTAG adapter board through the dedicated JTAG port of the chip of the system-on-chip. A simple link layer protocol is defined on the physical layer instructions defined by the IEEE1149.1 standard, enabling the debugging host 1 to access the analysis module in the debugging system through the JTAG communicator, thereby realizing interaction with the analysis module.

[0032] The Aurora communicator packs the message data in the debugging system, generates CRC checksums, and performs 8b10b encoding based on the Xilinx Aurora protocol, and sends the data to the Aurora off-chip receiver via 4 high-speed serial lines, and then the Aurora off-chip receiver transfers the data to the debugging host 1.

[0033] In the Aurora communicator scenario, a data collection tool can be used to receive the message data sent by the on-chip debugging system. The specific operation is to use the Aurora off-chip receiver as the slave interface of the Aurora communicator, connect it to the Serdes transmitter in the on-chip Aurora communicator via a high-speed serial link, receive the high-speed data stream, and complete deserialization of the data stream, 8b10b decoding, CRC checksum verification, extraction of the valid data of the Aurora frame and splitting it into multiple message data frames, extraction of the valid data from the message data frames, and collection of the valid data and storing it in a non-volatile memory for the debugging host to view at any time via the USB interface.

[0034] In some embodiments, the analysis types of the above analysis module include but are not limited to at least one of the following: JTAG processor analysis module, processor trace module, direct memory access module, and bus monitoring module.

[0035] The JTAG (Joint Test Action Group) interface processor analysis module is used to connect to the JTAG debugging port of the internal processor core of the system-on-chip, providing a method to access the TAP of the internal processor JTAG through the debugging system, rather than from the chip pins. The specific implementation method is to send the debugging message to the JTAG processor analysis module through the communicator, and the JTAG processor analysis module converts the debugging message into the corresponding JTAG state sequence based on the IEEE1149.1 standard. In practical applications, 8 JTAG processor analysis modules can be instantiated through this embodiment, so as to realize parallel access to the JTAG debugging interfaces of 8 processor cores.

[0036] The processor trace module is used to connect to the trace port of the internal processor core of the system-on-chip, receive the trace data stream of the processor core based on the ARM AMBA4 ATB v1.1 protocol, encapsulate the trace data stream into a message to form debugging trace data, and transmit the debugging trace data to the communicator through this debugging system. The debugging host 1 receives the debugging trace data through the communicator and completes data parsing to restore the instruction execution state of the internal processor core being traced. 8 processor trace modules can be instantiated through this embodiment to realize parallel access to the trace ports of 8 processor cores.

[0037] A direct memory access module that supports direct access to memory blocks of a system-on-chip, issues transactions to the on-chip network using a system bus such as AXI4 or AHB, and the on-chip network accesses a specified memory range according to the physical address. The specific operation is that the debug host 1 configures any channel in the direct memory access module through the debug path, specifies the starting address of the memory access, the data block space, the bus transfer type, the trigger condition, the transaction completion notification message, etc. for this channel, and then sends an event message to trigger the start of this channel. The event message can also be automatically generated by other analysis modules within the debug system, thus enabling cross-triggering operations. After the channel completes the transaction, a notification message is generated to report the completion of the read / write transaction.

[0038] A bus monitoring module for monitoring the transaction type, performance, and transaction data of the master and slave bus nodes of the on-chip network. The specific solution is that the debug host 1 configures the relevant parameters of the bus monitoring module through the debug path, sets the monitoring conditions, and starts the bus monitoring module. The bus monitoring module identifies the transaction type transmitted on the bus, collects performance metric data using a counter, captures the waiting cycles of relevant transactions using a tracker, and the bus monitoring module transmits the collected data to the communicator through the debug path of the debug system at fixed time intervals or in real time. The debug host 1 generates a performance report of the bus based on the data received from the communicator. Five bus monitoring modules can be instantiated through this embodiment to achieve parallel monitoring of five buses within the chip.

[0039] The message facility is used to route the data transmitted between the communicator and the analysis module.

[0040] In this embodiment, the number of message facilities on each debug path is not limited, and the data routing by the message facility can adopt a broadcast method.

[0041] In addition, in order to enable the smooth transmission of the transmitted data in the message facility, the debug system in this embodiment may further include: a memory buffer unit for reading out, buffering, and packing the debug trace data generated after the analysis module on each debug path debugs and traces the kernel module from the system memory, and sending the packed data to the debug host through the debug path.

[0042] Among them, the memory buffer unit is used to buffer and store message data in the debug system memory to achieve smooth processing of message data transmission. The specific operation is to allocate a certain memory area for the memory buffer unit in the debug system in advance. The memory buffer unit receives input message data (debug trace data generated by each analysis module), and then packs these data into the debug system memory according to the trigger conditions configured in the debug information sent by the debug host 1 before. The memory buffer unit can read the message data stored in the debug system memory according to the warning conditions, and then transmit the message data to the communicator through the message facility, and then the communicator transmits it to the debug host 1. The memory buffer unit can also be configured to only store message data, and then the debug host 1 reads the message data according to the write pointer of the memory buffer unit.

[0043] Compared with the related technology, the debug system provided in this embodiment includes a debug host, at least one communicator, at least one message facility, and at least one analysis module; each analysis module is connected to the debug host after sequentially connecting at least one message facility and a communicator in series, forming a debug path between the debug host and each analysis module; the debug host sends debug information to each analysis module through each debug path to control each analysis module to perform debug tracing on the kernel module, and receives the debug trace data fed back by each analysis module through each debug path; among them, the communicator on each debug path is used to perform transmission protocol conversion on the data transmitted between the debug host and the analysis module, and the message facility is used to route the data transmitted between the communicator and the analysis module. By flexibly adding message facilities and analysis modules in the debug system of this solution, new debug paths can be flexibly generated, and thus the debug components for debugging different types of IP can be conveniently integrated to comprehensively monitor the working status of each kernel module (IP) on the system-on-chip; at the same time, by enabling different debug paths, independent debug configuration of different analysis modules by the debug host can be realized, so as to ensure the real-time performance of the debug tracing function, and as the system-on-chip is upgraded and iterated, only by flexibly adding, deleting or adjusting the types of debug paths and analysis modules, the scalability and convenient migration of the debug system can be realized.

[0044] Another embodiment of the present invention relates to a debug system for a system-on-chip, and this embodiment is a supplementary description of the structure of the above debug system.

[0045] In some embodiments, as Figure 2 shown, one of the at least one message facility includes a main message facility, and the remaining message facilities except the main message facility are denoted as sub-message facilities;

[0046] In each debug path, the communicator first connects to the main message facility, and then connects to the analysis module through at least one sub-message facility connected in series; and / or the communicator directly connects to the analysis module after connecting to the main message facility.

[0047] For example Figure 2 In [example], the message facility 30 is the main message facility, and the message facilities 31 to 31 are sub-message facilities. In the debugging path from the debugging host 1 to the analysis module 44, any one of the communicators 20 to 23 can first connect to the message facility 30 and then connect to the analysis module 44 after connecting the sub-message facilities 31 and 32 in series; in the debugging path from the debugging host 1 to the analysis module 40, any one of the communicators 20 to 23 can first connect to the message facility 30 and then directly connect to the analysis module 40.

[0048] When building each debugging path, in this embodiment, all communicators are first connected to the same main message facility in the upward direction, and then connected to the analysis module through at least one series-connected sub-message facility, or directly connected to the analysis module. In this way, the main message facility can be used as a unified transfer node to uniformly forward and manage the messages on the subsequent debugging paths. When it is necessary to set the debugging path due to adding, reducing, or adjusting the analysis module, etc., only the debugging path part between the main message facility and the analysis module in the upward direction needs to be set, and there is no need to adjust the connection relationship between the communicators in the downward direction and the host 1, thus facilitating the expansion of the entire debugging system.

[0049] In some embodiments, the above at least one message facility and at least one analysis module have a tree-like topological structure, where the main message facility is the root node, each sub-message facility is a sub-node, and each analysis module is a leaf node.

[0050] For example Figure 2 In [example], a tree-like topological structure is formed with the message facility 30 as the root node, the message facilities 31 to 32 as sub-nodes, and the analysis modules 40 to 45 as leaf nodes. Among them, each message facility (including the main message facility and the sub-message facility) can connect to at least one analysis module and at least one message facility in the upward direction, or only connect to at least one analysis module, or only connect to at least one message facility. The specific connection method is not limited in this embodiment. For example Figure 2 In [example], the message facility 30 can connect to the analysis modules 40 and 41 in the upward direction and simultaneously connect to a message facility 31; the message facility 31 can connect to the analysis modules 42 and 43 in the upward direction and simultaneously connect to a message facility 32; the message facility 32 can only connect to the analysis modules 44 and 45 in the upward direction.

[0051] By presenting the connection relationships between each message facility and analysis module in a tree - like topological structure, it is possible to better manage, expand, and migrate the debugging path. For example, multiple branches extending upward from the same disappearing facility can be regarded as a relatively complete debugging hardware system, and all the analysis modules on the branches extending from the same disappearing facility are related. For example, these analysis modules perform relatively independent debugging functions, or the debugging objects they face are relatively independent. In the tree - like topological structure, the analysis modules on the branches extending from the previous - level disappearing facility have a weaker relationship compared to the analysis modules on the branches extending from the next - level disappearing facility. For example, the analysis modules 44 and 45 extended from the message facility 32 can be used to debug some closely - related debugging items for a certain IP core as a whole, while the analysis modules 42 and 43 extended from the disappearing facility 31 and the analysis modules 44 and 45 are used to debug all the debugging items for this IP core as a whole. The reason for placing the analysis modules 44 and 45 after the message facility 32 is to show that the debugging items of these two analysis modules have a stronger relationship compared to the analysis modules 42 and 43.

[0052] In some embodiments, at least one child node is included in the next - level node of the above - mentioned root node; at least one leaf node is included in the next - level node of each child node.

[0053] For example, in some debugging scenarios, in order to conveniently set that each debugging path has a relatively independent debugging and being - debugged relationship with the corresponding debugging object (such as a kernel module), in this embodiment, each branch extending from the root node (main disappearing facility) is used as a subsystem, and the debugging paths on each subsystem are relatively dedicated to a similar type of debugging item or debugging object. That is, no leaf nodes (analysis modules) are set in the next - level node of the root node (main disappearing facility), but at least one child node (sub - disappearing facility) is set; and these child nodes directly connected to the root node are used as the starting nodes of a relatively complete subsystem to be expanded, and all the leaf nodes (analysis modules) included in the next - level of each child node correspond to the specific debugging functions in this subsystem. For example, the debugging functions of the analysis modules in each subsystem are the same or similar, or the debugging functions of the analysis modules in each subsystem are different debugging functions for the same debugging object (kernel module).

[0054] In some embodiments, in the next - level node of the above - mentioned root node, the tree - like topological structure formed with each child node as the root node is used as a subsystem, and all the analysis modules included in each subsystem correspond to debugging and tracking the same kernel module.

[0055] For example Figure 3As shown in the figure, in the on-chip debugging system, the message facility 33 serves as the main message facility (root node). Among its subordinate nodes (message facilities 34 to 37), a tree-like topology structure formed with each child node as the root node serves as a subsystem (subsystems 50 to 53). All the analysis modules included in each subsystem (the types of analysis modules include: JTAG processor trace, data trace, direct memory access, bus monitoring) correspond to debugging and tracing the same kernel module. For example, the four subsystems 50 to 53 respectively correspond to debugging and tracing four kernel modules (IPs). Among them, subsystem 50 is responsible for performing JTAG processor trace and data trace functions on the corresponding IP, subsystem 51 is responsible for performing JTAG processor trace, data trace, and direct memory access functions on the corresponding IP, and both subsystem 52 and subsystem 53 are responsible for performing bus monitoring functions on the corresponding IP.

[0056] Another embodiment of the present invention relates to a debugging method for a system-on-chip, which is applied to the debugging system of the system-on-chip as described above, as Figure 4 shown, and this debugging method includes the following steps.

[0057] Step 101: The debugging host sends debugging information to each analysis module through each debugging path.

[0058] The debugging host can send the debugging information for configuring the debugging operation of the analysis module to the communicator through the passive message interface of the communicator for parsing to obtain the debugging information recognizable by the analysis module after parsing. The communicator sends the parsed debugging information to the designated analysis module through at least one serially connected message facility.

[0059] In some embodiments, this step can be implemented through the following steps: Step a: The debugging host sends a control data frame to the communicator on the debugging path where the analysis module to be controlled is located. The frame header of the control data frame carries the first index number of the analysis module to be controlled, and the data part of the control data frame carries the start trigger condition for starting the analysis module to be controlled; Step b: The communicator parses the received control data frame and forwards the control data frame recognizable by the analysis module after parsing to the analysis module corresponding to the first index number through the message facility.

[0060] In step a, the debugging host first determines the first index number of the analysis module to be configured. In this embodiment, each first index number can uniquely identify an analysis module. Then, debugging information for configuring the analysis module to complete the debugging function is formed, and this debugging information can be sent to the communicator in the form of a data frame, which is also called a "control data frame". The debugging host adds the first index number to the frame header of the control data frame and adds the start trigger condition (the trigger condition can be an event) for starting the analysis module to the data part of the control data frame, thus forming the control data frame.

[0061] The debugging host sends the formed control data frame to the communicator through the passive message interface of the communicator. When there are multiple communicators with different communication protocol conversion functions, the debugging host can flexibly select a communicator according to the communication protocol format adopted by the control data frame.

[0062] In step b, after receiving the control data frame, the communicator parses the data frame to obtain a control data frame recognizable by the analysis module and sends it to the first message facility (such as the main message facility) close to the communicator on the debugging path where the target analysis module is located through the upstream message interface of the communicator. This message facility forwards the control data frame to the target analysis module according to the first index number indicated in the control data frame, so as to write the data of the start trigger condition for starting the analysis module into the relevant registers inside the target analysis module to control the start of the analysis module. Among them, during the forwarding process, the data frame can reach the target analysis module through the serial connection routing method of at least one other message facility, or can be directly forwarded to the connected target analysis module after the first message facility receives the control data frame. Which forwarding method is specifically adopted depends on the layout setting of the debugging path between the target analysis module and the debugging host.

[0063] It should be noted that during the process of sending the control data frame along the upstream direction of the debugging path, the data frame routing and forwarding between message facilities can adopt but is not limited to the broadcast method.

[0064] In addition, the method of configuring the analysis module through the control data frame is also applicable to configuring the message facility and the communicator by sending other control data frames.

[0065] Step 102: The analysis module performs debugging and tracing on the kernel module according to the debugging information, and generates debugging and tracing data.

[0066] After receiving the debugging information, the analysis module can perform debugging and tracing operations on the corresponding kernel module according to the configuration requirements of the debugging information, and generate corresponding operation result data, that is, debugging and tracing data.

[0067] In some embodiments, as a continuation of step b above, this step can be implemented through the following steps: Step c: The analysis module starts debugging and tracing the kernel module according to the startup trigger condition carried in the received control data frame, and generates debugging and tracing data when the startup trigger condition is met.

[0068] After receiving the control data frame, the analysis module can, according to the startup trigger condition carried in the control data frame, such as when the startup trigger condition is a certain specified event, start debugging and tracing the kernel module after receiving the notification of the specified event, and generate corresponding debugging and tracing data. For example, after the kernel module corresponding to the above analysis module in the system-on-chip works, the analysis module starts the debugging and tracing process for the kernel module based on the set startup trigger condition, and captures the debugging and tracing data from the corresponding kernel module.

[0069] In this embodiment, the trigger condition for starting the analysis module is not limited, and it can be a notification of generating a specified event or specified data, etc.

[0070] Step 103: The analysis module sends the debugging and tracing data to the debug host through the debug path where it is located.

[0071] After completing the debugging of the kernel module, the analysis module will feedback the generated debugging and tracing data to the communicator through the debug path where it is located, and then provide it to the debug host. For example, the communicator can send the feedback data frame to the off-chip part of this debug system through its own active message interface, such as sending it to an off-chip adapter board, and then provide it to the debug host. After receiving the feedback data frame, the debug host extracts the data part from it, and then generates a work report on the system-on-chip based on the parsed debugging and tracing data above.

[0072] In some embodiments, as a continuation of step c above, this step can be implemented through the following steps: Step d: The analysis module sends a feedback data frame containing the debugging and tracing data to the message facility on the debug path where it is located, and the second index number of the target communicator is carried in the frame header of the feedback data frame; Step e: The message facility forwards the feedback data frame to the target communicator corresponding to the second index number according to the second index number carried in the feedback data frame; Step f: The target communicator parses the received feedback data frame and sends the parsed debugging and tracing data recognizable by the debug host to the debug host.

[0073] In step d, the analysis module pre-packages the debugging and tracing data into the feedback data frame as the data part in the feedback data frame. At the same time, the second index number of the target communicator is added to the frame header of the feedback data frame, and each second index number can uniquely indicate a communicator. After forming the feedback data frame, the analysis module sends the feedback data frame to the disappearing facility directly connected to the analysis module on the debug path where it is located.

[0074] In step e, after the disappearing facility receives the feedback data frame, according to the second index number in the frame header of the data frame, it is forwarded to the downlink negative interface of the target communicator corresponding to the second index number through at least one other message facility in series for routing, so as to provide the feedback data frame to the target communicator.

[0075] In step f, after the target communicator receives the feedback data frame, it parses the data frame to obtain a feedback data frame recognizable by the adjustment host, and provides the parsed feedback data frame to the debug host.

[0076] In some embodiments, the second index number of the target communicator can be indicated by the debug host, that is, the second index number of the target communicator to be carried in the feedback data frame by the analysis module to be controlled is also carried in the frame header of the control data frame sent by the debug host. In this way, after the target analysis module generates the debug trace data, it can add the second index number to the feedback data frame, so as to inform each message facility responsible for routing the target communicator to which the current feedback data frame needs to be sent.

[0077] In the above embodiment, the debug host can directly send a notification of the trigger condition (such as an event) for starting the analysis module to the analysis module. In this way, as long as the kernel module corresponding to the analysis module starts to work, and after the analysis module receives the notification of the trigger condition, it can execute the debug trace process on the corresponding kernel module to obtain the debug trace data.

[0078] In addition, another trigger condition for starting the analysis module can be generated by other analysis modules, and the notification of the trigger condition is broadcast in the debug system through the message facility to let the corresponding target analysis module know. In this way, it can be realized that one analysis module executes the debug trace process to start another analysis module to execute the debug trace process. This way of triggering and starting the analysis module is also called cross-triggering.

[0079] That is, in some embodiments, when the debug host sends a control data frame to the communicators on the debug paths of multiple analysis modules to be controlled, the start trigger conditions corresponding to the analysis modules to be controlled include: the end of the debug trace process executed by other analysis modules or obtaining specified data during the execution of the debug trace process.

[0080] For example, the debug host configures analysis modules 0 to 2 in sequence through the communicator, specifies that the start trigger events of analysis modules 0 to 2 are event a, event b, and event c respectively, and specifies that when analysis modules 0 to 2 complete the debug tracking work or capture specific data during debug tracking, notifications are generated respectively: notifications for event b, event c, and event a in sequence. At this time, analysis modules 0 to 2 are in a waiting state, waiting for event notifications to trigger the debug tracking process; then the debug host sends a notification of event a to analysis module 0 through the communicator, and event a is broadcast to all analysis modules 0 to 5 through message facilities 0 to 2. Since only the start condition of analysis module 0 is set to event a, only analysis module 0 starts the debug tracking process after receiving event a; when analysis module 0 completes the debug tracking process or captures specific data during debug tracking, event b is generated, and event b is broadcast to all analysis modules 0 to 5 through message facilities 0 to 2. Since only the start condition of analysis module 1 is set to event b, only analysis module 1 starts the debug tracking process after receiving event b.

[0081] And so on, after analysis module 1 receives event b, it starts the debug tracking work, then generates event c, and then triggers the start of analysis module 2. Through the above method, the sequential start of each analysis module is realized, and the on-site restoration of the debug system to ensure the continuity of the working time of each module in real time is realized.

[0082] Compared with the related technology, the debug method of the system-on-chip provided in this embodiment has the following technical effects:

[0083] 1. Parallel debugging. The present invention uses the concept of distributed data capture. There is a parallel debugging path between each analysis module and the debug host. Therefore, the debug tracking data can be sent back to the communicator concurrently and then provided to the debug host. Custom events are used to trigger and synchronize the operations of each analysis module simultaneously, such as simultaneously starting or stopping the debug tracking functions of multiple processor cores, simultaneously starting or stopping the tracking operations of multiple bus monitoring modules, simultaneously starting the direct memory access module to capture memory data, and simultaneously outputting all data information from the analysis modules in the SOC.

[0084] 2. Cross-triggering. The analysis modules in the present invention support being triggered based on custom events. Each analysis module captures and tracks specific scenarios, such as JTAG processor instructions, bus transaction types, completion of memory area access, etc., and can generate defined events in real time to trigger the start of other analysis modules in real time. Through cross-triggering between different types of analysis modules, the on-site real-time performance of the debug tracking function is ensured, which is beneficial to restoring the working scenarios of different modules in the SOC system.

[0085] 3. Simple structure. The design uses a tree structure, which is divided into a root and leaf nodes. It is simpler than the CoreSight architecture. The main message facility and the communicator module can be used as the root, and the analysis module as the leaf nodes. In this structure, messages are transmitted unidirectionally. The messages flowing from the analysis module to the main message facility and the communicator module are called downstream messages, and vice versa, upstream messages. In a typical debugging system, the information flow is asymmetric. The data going to the analysis module (upstream messages) is less, mainly used to load the configuration program of the analysis module. The data from the analysis module contains a large amount of trace information (downstream information) and is of a large volume. In response to this asymmetry of upstream and downstream message flows, the present invention simplifies the design for upstream messages. Configuration information (debugging information) can be sent through the on-chip SOC embedded axi interface or the off-chip JTAG low-speed serial interface, reducing the hardware overhead and software configuration work. For the downstream messages with a higher data flow, an Aurora high-speed serial port is used to send them off-chip. This design can match the high-speed data flow of the debugging system and reduce the number of chip pins.

[0086] 4. Flexible scalability. The data transmitted by the message facility and the analysis module is packaged into messages in a unified encoding format. By configuring the parameters of each analysis module to adapt to the kernel modules to be traced, the embedded analysis modules can be combined into a subsystem, which can be independently verified, and interact through a limited range of events without interfering with the broader system, promoting design reuse achieved by modifying macro definition parameters when instantiating modules. Each subsystem can be close to each IP scattered in the SOC system. The subsystems are connected to the main message facility of the debugging system through a simple message interface. As the SOC system is upgraded and iterated, only the corresponding analysis modules and sub-message facilities need to be added to form a subsystem and then connected to the main message facility, greatly reducing the pressure of designing a complex chip debugging system.

[0087] Those of ordinary skill in the art can understand that the above embodiments are specific examples for implementing the present invention, and in actual applications, various changes can be made in form and details without departing from the spirit and scope of the present invention.

Claims

1. A debugging system for a system-on-chip, characterized in that, Comprising: A debug host, at least one communicator, at least one message facility, and at least one analysis module; Each of the analysis modules is connected to the debug host after successively connecting at least one of the message facilities and one of the communicators in series, forming a debug path between the debug host and each of the analysis modules; The debug host is configured to send debug information to each of the analysis modules through respective debug paths to control each of the analysis modules to perform debug tracing on a kernel module, and receive debug tracing data fed back by each of the analysis modules through the respective debug paths; Wherein, the communicator on each debug path is used to perform transmission protocol conversion on the data transmitted between the debug host and the analysis module, and the message facility is used to route the data transmitted between the communicator and the analysis module.

2. The debugging system according to claim 1, wherein One of the at least one message facilities is a main message facility, and the remaining message facilities except the main message facility are denoted as sub-message facilities; In each of the debug paths, the communicator first connects to the main message facility and then connects to the analysis module through at least one of the sub-message facilities connected in series; and / or the communicator directly connects to the analysis module after connecting to the main message facility.

3. The debugging system according to claim 2, wherein The at least one message facility and the at least one analysis module have a tree-like topology structure, wherein the main message facility is the root node, each of the sub-message facilities is a sub-node, and each of the analysis modules is a leaf node.

4. The debugging system according to claim 3, wherein The next-level nodes of the root node include at least one sub-node; the next-level nodes of each sub-node include at least one leaf node.

5. The debugging system according to any one of claims 2-4, characterized in that, Among the next-level nodes of the root node, the tree-like topology structure formed with each sub-node as the root node is used as a subsystem, and all the analysis modules included in each subsystem correspond to debug tracing the same kernel module.

6. The debugging system according to claim 1, wherein The types of the communicator include at least one of an AXI communicator, a JTAG communicator, and an Aurora communicator.

7. The debugging system according to claim 1, wherein The types of the analysis module include at least one of a JTAG processor trace module, a data trace module, a direct memory access module, and a bus monitoring module.

8. The debugging system according to claim 1, wherein Further comprising: A memory buffer unit, configured to read out, buffer, and package the debug tracing data generated by the analysis module on each debug path for debug tracing the kernel module from the system memory, and send the packaged data to the debug host through the debug path.

9. A debugging method for a system-on-chip, applied to the debugging system of the system-on-chip as described in any one of claims 1-8, characterized in that, Comprising: The debug host sends debug information to each analysis module through respective debug paths; The analysis module performs debug tracing on the kernel module according to the debug information, generating debug tracing data; The analysis module sends the debug tracing data to the debug host through the debug path where it is located.

10. The method according to claim 9, wherein The debug host sends debug information to each of the analysis modules through respective debug paths, including: The debug host sends a control data frame to the communicator on the debug path where the analysis module to be controlled is located, and a first index number of the analysis module to be controlled is carried in the frame header of the control data frame, and a start trigger condition for starting the analysis module to be controlled is carried in the data part of the control data frame. The communicator parses the received control data frame and forwards the parsed control data frame recognizable by the analysis module to the analysis module corresponding to the first index number through the message facility.

11. The method according to claim 10, characterized in that, The analysis module debugs and traces the kernel module according to the debug information, generating debug trace data, including: The analysis module starts debugging and tracing the kernel module when the startup trigger condition carried in the received control data frame is satisfied, generating the debug trace data.

12. The method according to claim 10, characterized in that, The analysis module sends the debug trace data to the debug host through the debug path where it is located, including: The analysis module sends a feedback data frame containing the debug trace data to the message facility on the debug path where it is located, and the second index number of the target communicator is carried in the frame header of the feedback data frame; The message facility forwards the feedback data frame to the target communicator corresponding to the second index number according to the second index number carried in the feedback data frame; The target communicator parses the received feedback data frame and sends the parsed debug trace data recognizable by the debug host to the debug host.

13. The method according to claim 12, characterized in that, The second index number of the target communicator to be carried in the feedback data frame by the analysis module to be controlled is also carried in the frame header of the control data frame.

14. The method according to any one of claims 10 - 13, characterized in that, When the debug host sends the control data frame to the communicators on the debug paths where multiple analysis modules to be controlled are located, the startup trigger conditions corresponding to the analysis modules to be controlled include: the end of the debug tracing process executed by other analysis modules or obtaining specified data during the execution of the debug tracing process.

Images