WO2006000943A2

WO2006000943A2 - System for debugging software and hardware components

Info

Publication number: WO2006000943A2
Application number: PCT/IB2005/051952
Authority: WO
Inventors: Vishal Suresh; Evert-Jan Pol; Lokesh Gupta; Mahesh D. Channabasavaiah
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2004-06-21
Filing date: 2005-06-14
Publication date: 2006-01-05
Also published as: WO2006000943A3

Abstract

The invention relates to a debug system for debugging software components and hardware components on an integrated circuit. The layered architecture of the debug system according to the invention ensures that the debug framework is generic, because only the debuggers and the target adapter need to be changed, depending on the specific components which should be debugged. Any change in the status of a component affected through a debugger or through execution of the target system, can be reflected in the status of other components present in the target system. A set of Application Programming Interfaces (API’s) comprising of software layers enable the interconnection of the debuggers and the software and hardware components. They also enable synchronization of debug requests, which facilitates the simultaneous debugging of various software and hardware components.

Description

System for debugging software and hardware components

The invention relates to a debug system for debugging software components and hardware components on an integrated circuit.

The concepts related to Systems-on-Chip (SoCs) have become very important in the development of complex, high-performance integrated circuits. According to these concepts, integrated circuits are built from a plurality of relatively independent modules. These modules may implement either general-purpose functions or dedicated functions. An example of a module performing general-purpose functions is a central processing unit (CPU). An example of a module performing dedicated functions is a graphics coprocessor. It should be clear that some of these modules may be more software-oriented (such as the CPU) and that other modules may consist entirely of hardware (such as a graphics accelerator). The development of these complex systems on integrated circuits is a big challenge in today's industry. The building blocks or modules of the systems, which are the software and hardware components, are often standardized components, which can be deployed in different SoCs. The success of development of such systems depends on the successful integration of the standard building blocks; this integration must be done relatively rapidly in order to reduce the time-to-market of the systems. However, fast integration of components also requires fast debugging. The debugging of complex systems like SoCs is far from trivial and can therefore be time-consuming. Due to the increasing complexity of SoCs debugging becomes more and more difficult. In particular, simultaneous debugging of various components is hardly supported by state-of-the-art debug tools. These components can be both software components and hardware components, which complicates adequate debugging. US 6,065,078 discloses a debugger interface which includes interface circuitry to interface a plurality of processors to a debugger. The debugger interface includes means for receiving a debugger command from the debugger. Debugger command directing means determines from the debugger command for which of at least one of the plurality of processors the debugger command is intended, directs the debugger command, via the interface circuitry to the at least one intended processor. A processor command is received from one of the plurality of processors, and processor command directing means directs the processor command, received from the one processor, via the interface circuitry to the debugger. This system is intended for debugging software that is executing on the plurality of processors. However, the interface circuitry does not enable a dynamic connection of various debuggers to a target system comprising a plurality of hardware and software components. The technique according to US 6,065,978 provides means to direct debug requests to a specific processor, but it does not allow simultaneous debugging of hardware and software components. The debuggers are equipped to debug software instead of hardware.

It is an object of the invention to provide a debug system for debugging software components and hardware components on an integrated circuit, which debug system enables simultaneous debugging of the software components and the hardware components. This object is achieved by providing a debug system characterized by the characterizing portion of claim 1. The layered architecture of the debug system according to the invention ensures that the debug framework is generic, because only the debuggers and the target adapter need to be changed, depending on the specific components which should be debugged. Any change in the status of a component affected through a debugger or through execution of the target system, can be reflected in the status of other components present in the target system. A set of Application Programming Interfaces (API's) comprising of software layers enable the interconnection of the debuggers and the software and hardware components. They also enable synchronization of debug requests, which facilitates the simultaneous debugging of various software and hardware components. The invention has a technical effect in that it significantly improves the debugging techniques for modeled integrated circuits, prototypes and hardware ICs. In the embodiment according to claim 2, the second software layer is further conceived to receive a plurality of debug results of the debug functions, to interpret the debug results and to derive debug response packets compliant with the protocol of the communication channel from the debug results, the second software layer also being conceived to send the debug response packets via the communication channel to the first software layer; the first software layer also being conceived to receive the debug response packets, to interpret the debug response packets and to derive debug responses from the debug response packets, the first software layer further being conceived to send the debug responses to the debuggers. In this manner the debug responses corresponding to particular debug requests can be directed to the correct external debuggers. In the embodiment according to claim 3, the debug system further comprises a plurality of first adapters, the first adapters being arranged to connect the debuggers to the first software layer. This has the advantage that the external debuggers may be third-party debuggers which need not be compliant with the communication protocol(s) deployed by the debug systems; the first adapters will translate debug requests from particular third-party debuggers to the communication protocol of the debug system. In the embodiment according to claim 4, the debug system further comprises a second adapter, the second adapter being arranged to connect the second software layer to the software and hardware components. The second adapter enables connection of the debug system to specific target system components and enables the retrieval of architecture information from those components, for example. In the embodiment according to claim 5, the second adapter is also arranged to allocate unique identifier values to the software and hardware components, to identify a component from the software and hardware components to which a debug request is made, and to send the debug request to the component using an identifier from the unique identifier values. This has the advantage that target system components can be uniquely identified in the debug system, and that debug requests are routed to the correct components. > In the embodiment according to claim 6, the second software layer is conceived to be triggered by the second adapter if a static breakpoint is hit in a hardware component of the target system, and the second software layer is conceived to collect information regarding the state of execution of the target system if the said static breakpoint is hit. This has the advantage that information concerning the state of execution of the target system as a whole is available when a static breakpoint in one particular hardware component is hit; this information is very valuable during a debug session. In the embodiment according to claim 7, step types are defined for the hardware components in the target system, and the debug system is conceived to request that a step of a particular type is executed in a hardware component, which results in the execution of a plurality of instructions in the hardware component. The debug system can present a list of step types available in the target system by querying the target system at runtime. By selecting and executing a step of a particular type the target system will advance from a first state of execution to a second state of execution, which state transition can be examined for correctness. In the embodiment according to claim 8, the external debuggers are dynamically connected to the debug system, and the external debuggers are dynamically disconnected from the debug system. This has the advantage that hardware debuggers can be connected and disconnected to the debug system (and via the debug system to a particular hardware component) even in the middle of a debug session. In the embodiment according to claim 9, the second software layer is further conceived to retrieve architecture information from the target system, the architecture information comprising information about the clock domains present in the target system. Hence, the debug system is capable of supporting step operations on different clock domains. In the embodiment according to claim 10, the first software layer is also conceived to synchronize the debug requests received from the external debuggers. This has the advantage that debug sessions can pass off smoothly and in an orderly manner. It also makes sure that the results of debug functions performed on the target system can be reflected in the state of execution of the target system on a step-by-step basis.

The present invention is described in more detail with reference to the drawings, in which: Fig. 1 illustrates an example of an architecture of the debug system according to the invention; Fig. 2 illustrates an external debugger which does not need a first adapter to translate between its own protocol and that of the first software layer; Fig. 3 illustrates examples of functions from the DAPI-I layer; Fig. 4 illustrates examples of functions from the DAPI-2 layer; Fig. 5 A and 5B illustrate an example of a data structure comprising pointers to SD_COM interface functions; Fig. 6 illustrates an example of a data model for a hierarchy of components.

Fig. 1 illustrates an example of an architecture of the debug system according to the invention. The debug system 112 comprises a first software layer 114, also referred to as the DBGCLIENT layer, which software layer has as primary tasks: - receiving a plurality of debug requests from external debuggers 100, 104, 108; - deriving debug request packets from the debug requests, which packets are compliant with a protocol of the communication channel 128 between the first software layer 114 and a second software layer 116; - sending the debug request packets via the communication channel 128 to the second software layer 116. In a preferred embodiment of the invention, the first software layer 114 also implements functionality to implement among others: - receiving and interpreting debug response packets from the second software layer 116 via the communication channel 128, the result of which is a number of debug responses; - sending the debug responses to the external debuggers 100, 104, 108; - displaying a front-end for debugging in order to increase user friendliness of the debug application; - managing debugger connections, via the use of first adapters 102, 106, 110 if required; - keeping the connected external debuggers 100, 104, 108 synchronized. The debug system 112 further comprises the second software layer 116, also referred to as the DBGSERVER layer. The second software layer 116 has as primary tasks: - receiving the debug request packets which are sent over the communication channel 128 by the first software layer 114; - interpreting the debug request packets and calling functions from a plurality of debug functions dependent on the result of this interpretation; - sending the functions via a second adapter 118 to the software and hardware components 122, 124, 126 in the target system 120 on which the functions should be performed. According to a preferred embodiment of the invention, the second software layer 116 has also the following tasks: - receiving responses from the debug functions performed on the software and hardware components 122, 124, 126; - deriving debug response packets from those responses and sending the debug response packets to the first software layer 114 via the communication channel 128. It is assumed that the software and hardware components 122, 124, 126 are arranged to execute a debug function as it is intended by the debugger corresponding to that debug function. The results of the debug function are reported back to the debugger through the debug system 112 as explained above. The second adapter 118, also referred to as the TGTADAPTER layer, provides a level of abstraction of the target system 120, in the sense that the specifics of the software and hardware components 122, 124, 126 in the target system 120 are hidden to the DBGSERVER layer of the debug system 112. The second adapter 118 implements functionality to support the following: - it maintains target system 120 architecture information including hierarchy information; - it performs bookkeeping of debug related data; - it allocates identifiers to the software and hardware components 122, 124, 126 and ensures uniqueness of identifiers across these components; - it identifies the software or hardware component 122, 124, 126 to which a debug request is directed and propagates the debug request to that particular component. The use of the first adapters 102, 106, 110 between the external debuggers 100, 104, 108 and the first software layer 114 depends on whether the communication protocol used by the external debuggers matches with the communication protocol deployed by the first software layer. In other words, it depends on whether the protocol used to communicate over the communication channels 130, 132 respectively 134 is equal to the protocol used to communicate over the communication channels 136, 138 respectively 140. This could be the case if, for example, the debugger software is developed by the same company as the debug system itself. However, more often the debuggers consist of third- party software, in which case an adapter is usually required to translate between the different communication protocols. In Fig. 2 an external debugger 200 is shown which does not need a first adapter to translate between its own protocol and that of the first software layer 114: it makes use of the same Application Programming Interface (API) as the first software layer. The data transfer takes place over a single communication channel 202. The data transfer over the communication channels 130, 132, 134 between the first adapters 102, 106, 110 and the first software layer 114 is based upon an Application Programming Interface, developed as a module or a part of the debug system 112. As an example, the debug system 112 operates as follows when it is deployed. First, a user issues a command to start up the target system 120. All software and hardware components 122, 124, 126 are initialized, and all software and hardware components are registered with the debug system 112. This allows that the debug system 112 has access to the hierarchy of software and hardware components 122, 124, 126 and may perform debug functions on them. Subsequently, the DBGSERVER layer waits until a connection is established between itself and the DBGCLIENT layer. The DBGCLIENT layer requests a connection with the DBGSERVER layer via the communication channel 128, using for example a simple text-based protocol or some API. When the connection has been successfully established, the DBGCLIENT layer sends out a query request for the target system 120 architecture information; then it waits for this information. In the target system 120 a call to a function which receives the next debug request from the DBGCLIENT layer is made. Because the latter function is blocking, the target system 120 waits until a new debug request is made; meanwhile the execution of the target system 120 is blocked. The DBGSERVER layer is conceived to implement this function, so it will receive the next debug request from the DBGCLIENT layer. The DBGSERVER layer receives the query request for the target system 120 architecture information, and because the components 122, 124, 126 have been properly initialized, the TGTADAPTER layer already has this information available. The DBGSERVER layer fulfills the query request of the DBGCLIENT layer; it does so by propagating the query request to the TGTADAPTER layer via communication channel 142. The DBGSERVER layer then derives debug response packets and sends the debug response packets to the DBGCLIENT layer via the communication channel 128. The function also checks whether the last debug request (i.e. the query request) was a control command such as 'run' or 'step' or an access command such as 'register read' or 'memory read'. There is a difference between control commands and access commands in that the control commands require that the execution of the target system 120 proceeds, contrary to the access commands. The function returns control back to the target system 120 only if the last debug request was a control command, in which case the target system 120 must proceed with its execution. In this case, the query request is clearly an access command, so the function goes into read mode again and waits for the next debug request from the DBGCLIENT layer; it does not allow the target system 120 to proceed with its execution. After receiving the requested architecture information in the form of debug response packets, the DBGCLIENT interprets the packets and derives a debug response from them. It then displays the debug response, e.g. as a list of the available debug-able software and hardware components 122, 124, 126 in the target system 120. Subsequently, the user may want to connect to a particular software or hardware component to retrieve debug information from it and analyze its behavior. To connect to a particular component 122, 124 or 126 the user should issue a 'component connect' debug request. A separate thread gets invoked on which the connection with the external debugger 100, 104, 108 for that particular component will be handled. In this manner, the external debuggers which are attached to the debug system 112 can remain mutually independent. The DBGCLIENT layer handles synchronization between the debug requests originating from different external debuggers 100, 104, 108. The DBGCLIENT layer 'knows' how many and which external debuggers 100, 104, 108 are connected to the debug system 112. A control command is not allowed to be passed to the DBGSERVER layer unless all connected external debuggers relinquish control; the DBGCLIENT layer blocks all control commands issued by any of the debuggers until all debuggers have issued a 'run' command and have relinquished control to the debug system 112. After all debuggers have relinquished control to the debug system 112, the DBGCLIENT layer keeps all debug requests blocked except the first one of the debug requests. Only the first one of the debug requests is allowed to be passed on to the DBGSERVER layer and cause the execution of the target system 120 to advance. When the debug response comes back to the DBGCLIENT layer via the DBGSERVER layer, the DBGCLIENT layer first allows the blocked debug requests to return to the external debuggers 100, 104, 108, so that the debuggers can take back control from the debug system 112. Finally, the DBGCLIENT layer sends back the debug response to the particular debugger which made the first one of the debug requests. As explained above, the debug response is derived from the debug response packets created and sent by the DBGSERVER layer via the communication channel 128. It is noted that the synchronization described in this example applies to control commands; in the case of access commands the state of execution of the target system 120 does not change and therefore multiple debug requests can be handled in parallel. When the DBGSERVER layer receives a debug request comprising a control command, it performs a function which returns control to the target system 120, thereby allowing the target system to proceed with its execution. A hardware breakpoint (also referred to as a static breakpoint) is defined as a hard-coded point in a hardware component where the execution is stopped for the purpose of debugging. If a breakpoint in a software component or a static breakpoint in a hardware component is hit in the target system 120, then it notifies the TGTAD APTER layer of this fact. The TGTAD APTER layer in turn notifies the DBGSERVER layer, which then collects information regarding the state of execution of the target system 120 and performs an API function. The API function sends a debug response to the DBGCLIENT layer in the form of debug response packets. The DBGSERVER layer also blocks the execution of the target system 120 by calling another API function; the DBGSERVER layer waits for a new debug request comprising a control command. For the purpose of integrating the external debuggers 100, 104, 108 with the debug system 112 a number of so-called Debug Application Programming Interfaces (DAPFs) have been developed. The following DAPF s (also referred to as DAPI layers) can be distinguished: - DAPI-I layer: this is a debug interface which exists between the external debuggers 100, 104, 108 and the DBGCLIENT layer. If the communication protocol used by the external debuggers 100, 104, 108 is different from DAPI-I (for example when third-party debuggers are deployed), then adapters 102, 106, 110 are required to translate the requests from the debuggers to DAPI-I compliant requests, and to translate DAPI-I compliant responses to responses suitable for the debuggers. In the case of proprietary debuggers, such adapters 102, 106, 110 would not be required because the debuggers would implement their communication mechanism with the DBGCLIENT layer using only DAPI-I layer functions. The DAPI-I layer is also referred to as the SD_DBG interface. The DAPI-I layer applies to the communication via channels 130, 132, 134 and 202. Fig. 3 illustrates examples of functions from the DAPI-I layer. - DAPI-2 layer: this is a debug interface which exists between the DBGSERVER layer and the target system 120 via the TGTADAPTER layer. This interface allows the debug system 112 to be independent from the target system 120. If the target system 120 changes, only the TGTADAPTER layer needs to be changed. The DAPI-2 layer is also referred to as the SD_TGT interface; it applies to the communication via channel 142. Fig. 4 illustrates examples of functions from the DAPI-2 layer. - DAPI-3 layer: this is a debug interface at the component level. The functions comprised in this interface should be implemented by the software and hardware components 122, 124, 126 to allow debugging on them. Each component 122, 124, 126 can restrict the amount of debugging which it allows on itself by appropriately implementing the functions of the DAPI-3 layer. The debug system 112, in particular the TGTADAPTER layer 118, calls these functions to perform debug operations on the software and hardware components 122, 124, 126. The DAPI-3 layer is also referred to as the SD_C0M interface; it applies to the communication via channels 144, 146 and 148. Fig. 5A and 5B illustrate an example of a data structure comprising pointers to SD_COM interface functions. The pointers must be updated by the software and hardware components 122, 124, 126, such that they point to suitable implementations at runtime. The TGTADAPTER layer 118 calls these SD_COM interface functions in order to perform debug operations on the components 122, 124, 126. Thereafter, the debug operations will be performed by the components 122, 124, 126 themselves in accordance with the implementation of the functions. The results of the debug operations are routed back to the external debugger 100, 104, 108 which made the debug request through the debug system 112. The debug system 112 also permits simultaneous debugging of a hierarchy of software and hardware components 122, 124, 126. In that case, there are top-level components and sub-components. The sub-components may have further sub-components, such that the target system 120 is built up as a complete hierarchy of components. Fig. 6 illustrates an example of a data model for a hierarchy of components 122, 124, 126; the DAPI-3 layer comprises pointers to classes of functions which should be implemented by sub-components. It is remarked that the scope of protection of the invention is not restricted to the embodiments described herein. Neither is the scope of protection of the invention restricted by the reference symbols in the claims. The word 'comprising' does not exclude other parts than those mentioned in a claim. The word 'a(n)' preceding an element does not exclude a plurality of those elements. Means forming part of the invention may both be implemented in the form of dedicated hardware or in the form of a programmed general- purpose processor. The invention resides in each new feature or combination of features.

Claims

CLAIMS:

1. A debug system (112) for debugging software components and hardware components (122, 124, 126) on an integrated circuit, characterized in that the debug system comprises: - a first software layer (114); - a second software layer (116); - a communication channel (128) between the first software layer (114) and the second software layer (116); wherein the first software layer (114) is conceived to receive a plurality of debug requests from debuggers (100, 104, 108), the debuggers (100, 104, 108) being external to the debug system, the first software layer (114) also being conceived to derive debug request packets compliant with a protocol of the communication channel (128) from the debug requests, and to send the debug request packets via the communication channel (128) to the second software layer (116); wherein the second software layer (116) is conceived to receive the debug request packets, the second software layer (116) also being conceived to interpret the debug request packets and to call functions from a plurality of debug functions dependent on the debug request packets, the debug functions being performed on the software and hardware components (122, 124, 126).

2. A debug system (112) as claimed in claim 1, wherein the second software layer (116) is further conceived to receive a plurality of debug results of the debug functions, to interpret the debug results and to derive debug response packets compliant with the protocol of the communication channel (128) from the debug results, the second software layer (116) also being conceived to send the debug response packets via the communication channel (128) to the first software layer (114); wherein the first software layer (114) is further conceived to receive the debug response packets, to interpret the debug response packets and to derive debug responses from the debug response packets, the first software layer also being conceived to send the debug responses to the debuggers (100, 104, 108).

3. A debug system (112) as claimed in claim 1, the debug system (112) further comprising a plurality of first adapters (102, 106, 110), the first adapters being arranged to connect the debuggers (100, 104, 108) to the first software layer (114).

4. A debug system (112) as claimed in claim 1, the debug system (112) further comprising a second adapter (118), the second adapter (118) being arranged to connect the second software layer (116) to the software and hardware components (122, 124, 126).

5. A debug system (112) as claimed in claim 4, wherein the second adapter (118) is also arranged to allocate unique identifier values to the software and hardware components (122, 124, 126), to identify a component from the software and hardware components (122, 124, 126) to which a debug request is made, and to send the debug request to the component using an identifier from the unique identifier values.

6. A debug system (112) as claimed in claim 4, wherein the second software layer (116) is conceived to be triggered by the second adapter (118) if a static breakpoint is hit in a hardware component of the target system (120), and wherein the second software layer (116) is conceived to collect information regarding the state of execution of the target system (120) if the said static breakpoint is hit.

7. A debug system (112) as claimed in claim 1, wherein step types are defined for the hardware components in the target system (120), and wherein the debug system (112) is conceived to request that a step of a particular type is executed in a hardware component, which results in the execution of a plurality of instructions in the hardware component.

8. A debug system (112) as claimed in claim 1, wherein the external debuggers (100, 104, 108) are dynamically connected to the debug system (112), and wherein the external debuggers (100, 104, 108) are dynamically disconnected from the debug system (112).

9. A debug system (112) as claimed in claim 2, wherein the second software layer (116) is further conceived to retrieve architecture information from the target system (120), the architecture information comprising information about the clock domains present in the target system (120).

10. A debug system (112) as claimed in claim 1, wherein the first software layer (114) is also conceived to synchronize the debug requests received from the external debuggers (100, 104, 108).