Abstract:
A System-on-Chip (SOC) debugging system comprising a plurality of SOCs connected to a shared bus, at least one of the plurality of SOCs being a master SOC and comprising a master/slave debug interface, wherein the master/slave debug interface is a bidirectional debug interface configured to initiate transactions on the shared bus and operable to send and receive debug data between the SOCs, wherein the debug data comprises trace data.

Description:
RELATED APPLICATION 
     This is a reissue application of U.S. applicaton Ser. No. 13/528,140 filed on Jun. 20, 2012, now U.S. Pat. No. 8,347,158, which is a continuation application of U.S. application Ser. No. 12/913,236 filed on Oct. 27, 2012, Oct. 27, 2010, now U.S. Pat. No. 8,234,531, which is a continuation application of U.S. application Ser. No. 11/954,362 filed on Dec. 12, 2007, now U.S. Pat. No. 7,870,455. 
     More than one reissue application has been filed for the reissue of Pat. No. 8,347,158. The reissue applications are the present application and application Ser. No. 15/136,065, filed Apr. 22, 2016. 
    
    
     FIELD OF THE DESCRIPTION 
     The present description relates generally to data processing and debug systems, and, in particular, to a System-on-Chip (SOC) configuration that captures and transfers debug data directly from multiple system SOCs using an on-chip Master/Slave debug interface. 
     BACKGROUND 
     System-on-Chip (SOC) technology operates and controls various types of systems. In general, SOC technology is the assembling of all the necessary electronic circuits and parts for a system (such as a cell phone or digital camera) on a single integrated circuit (IC), generally known as a microchip. SOC devices greatly reduce the size, cost, and power consumption of the system. 
     During SOC development, debuggers are connected to the debug interfaces (e.g. JTAG port) of the SOCs. To allow synchronous debugging and to save connector pins, all SOCs of the system typically share one debug bus (e.g. CJTAG) and one connector to the debug tool hardware for debugging and testing procedures. Using the debug bus, the system can be debugged (control, status and trace) through a single connector. 
     Because of the very high degree of integration on a single IC, in many cases, the number of Input/Output (IO) signals off the SOC device are reduced. Furthermore, as chip sizes increase, the number of transistors on a chip increases much faster than the possible number of IO signals off the chip. In many modern chip designs the chip is said to be pad or IO limited, which means that based on the size of the chip, there is insufficient room for all the IO signals that the designers would like, or need, to have routed off the chip. In such environments, in order to lower costs, conserve space, and provide enhanced security, SOCs and Systems in Packages (SiPs) can be configured without debug interfaces making testing and debugging operations problematic. In such cases, analysis is either infeasible or significant effort is needed to solder a debug connector to the board at a time when analysis is needed. 
     SUMMARY 
     A System-on-Chip (SOC) debugging system comprising a plurality of SOCs connected to a shared bus, at least one of the plurality of SOCs being a master SOC and comprising a master/slave debug interface, wherein the master/slave debug interface is a bidirectional debug interface configured to initiate transactions on the shared bus and operable to send and receive debug data between the SOCs, wherein the debug data comprises trace data. 
     These and further objectives, features and advantages will become more apparent from the following description when taken in connection with the accompanying drawings 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates an exemplary SOC IC debugging system in accordance with a preferred embodiment; and 
         FIG. 2  is a flow diagram illustrating a method for debugging multiple SOC ICs through a user interface of a master SOC IC in accordance with a preferred embodiment. 
     
    
    
     DETAILED DESCRIPTION 
       FIGS. 1 and 2 , discussed below, are by way of illustration only and should not be construed in any way to limit the scope of the claims. While described with respect to SOCs, those of skill in the art will understand that the principles may be implemented in any suitably arranged IC or system-in-package device. 
     Well-known circuits have been shown in block diagram form in order not to obscure the present description in unnecessary detail. Certain details regarding components of the SOCs described herein have been omitted insomuch as such details are not necessary to obtain a complete understanding of the present description and are within the skill of a person of ordinary skill in the relevant art. 
       FIG. 1  shows a printed circuit board (PCB) system  100  for debugging, testing and monitoring the performance information of several SOCs  102 ,  104 ,  106 . While not explicitly shown in the figures, SOC  102  can include a processor core, a bus interface, and a system bus for communicating information. SOC  102  may further incorporate a digital signal processing engine, a general purpose microprocessor to provide control functionality, an on-chip memory  126  and a memory controller (not shown) for accessing memory  126 . SOCs  104  and  106  may also include each of the above elements discussed with respect to SOC  102 . 
     SOCs  102 ,  104  and  106  are connected to a shared debug bus  108 . PCB system  100  is connected to host a system  110  directly via SOC  102 . While host system  110  is shown independent of system  100 , for purposes of debugging and testing a plurality of SOCs, connection with host system  110  can be considered an integral part of debug system  100 . The host system  110  can be any type of computer (e.g., personal, mainframe, mini, networked, workstation, etc.) running host software that allows a user to target one or more components on SOCs  102 ,  104 ,  106  for debugging and to specify triggering parameters for tracing their processing cores. 
     SOC  102  includes a user interface  116  for connecting and communicating with host system  110 . User interface  116  can be any type of user interface (e.g., serial port, USB, etc.). Host system  110  communicates with SOC  102  through user interface  116  and with the SOCs  104  and  106  through debug bus  108 . 
     SOC  102  passes debug data, such as trace data, debug control signals and status data, to host system  110  through user interface  116 . SOCs  104  and  106  to be debugged by host system  110  pass their debug data through Master/Slave debug interface  120  of SOC  102 . Accordingly, SOC  102  takes on the role of a “Master” SOC and hereinafter will be referred to as Master SOC  102 . Likewise, SOCs  104  and  106  act as slaves to Master SOC  102 . The Master/Slave debug interface  120  is configured to initiate transactions on the debug bus  108 . These transactions can include, but are not limited to, instructions to store data in memory, to read data from memory and to transfer data to and from host system  110 . 
     Master/Slave debug interface  120  is for instance a two-pin bidirectional debug interface as defined in IEEE 1149.7 (CJTAG) consisting of a bi-directional Debug Data pin and a Debug Clock pin. Such an interface allows transferring commands to the device to control the on-chip debug system and to read and write data. 
     As mentioned briefly above, the debug data which is gathered by monitoring one or more of SOCs  102 ,  104 , and  106  can include trace data. A trace is useful when analyzing the behavior, or misbehavior, of an SOC or the SOCs processing core or cores. The trace can show problems in the programming of an SOC processing core and point to errors in the SOC hardware. The trace can be thought of as an external recording of the activity of the SOC that a user can play back with software tools on the host system  110  in order to understand specific internal operations the SOC took and why. 
     The trace of external IO signals of an SOC can be augmented with other data to give a user additional visibility into SOCs  102 ,  104 ,  106  internal operations. Bringing selected internal signals of SOCs  102 ,  104 ,  106  to the outside of the system  100  as additional output signals accomplishes this augmentation. 
     System  100  includes an arbitrary number of SOCs with each SOC sharing a single debug bus  108  (e.g. CJTAG). With SOCs  102 ,  104 ,  106  connected to one shared debug bus  108 , a single SOC (i.e. SOC  102 ) can take the role of a tool hardware front-end for the debug bus  108 . Referring to  FIG. 1 , SOC  102  plays this role and hence can be referred to as “master SOC  102 ”. On the physical level the direction of all signals is reversed for the master SOC  102  compared to a conventional setup, where all SOCs including the master SOC are accessed from the debug tool over the on-board debug connector. In accordance with a preferred embodiment, the debug interface of the master SOC  102  is operable in two different modes: In a default mode (e.g. reset value) it is a slave and operates like the debug interface of any other SOC controlled from the debug tool over a hardware interface, board connector and debug bus; in the second mode it is a master, which is enabled internally, the signal directions are reversed (e.g. clock output instead of input) and this master controls the slave debug interfaces of all other SOCs. In the later mode, a debug tool need not be attached at the debug connector on the board. 
     Master SOC  102  acts as a bus bridge between the host system  110 , connected over the user interface  116 , and the debug bus  108 . Thus, the host system  110  accesses the SOCs  104  and  106  indirectly through Master SOC  102 , with reversed direction of its debug interface. Master SOC  102  effectively replaces the need to connect conventional debug tool hardware to the PCB to carry out testing and debug procedures. Instead, Master SOC  102  is equipped with a debug monitor (not shown). The debug monitor is preferably software running on Master SOC  102 . 
     This debug monitor is for instance a process running on the processor of Mater SOC  102 . It is activated by the operating system. When debug requests arrive at the User Interface  116 , the debug monitor analyzes the requests, schedules transfers over the Debug Bus  108  and sends back the results over the user interface  116 . To limit the impact on the real-time behavior of the system these tasks can be distributed over different Interrupt Service Routines and real time processes. Those of skill in the art will realize that other implementations with less software and more hardware parts of the bus bridge functionality are also possible. 
     System  100  is functional without restrictions for debug control and status data exchange, which has low to medium latency and bandwidth requirements. Trace data requires much higher bandwidth. If the available bandwidth of the user interface  116  is on average lower than is needed for the trace data, an on-chip trace buffer (not shown) on Master SOC  102  can be used to capture such traces from the other SOCs  104  and  106  for a short period of time. If the available bandwidth of the user interface  116  is on average higher than needed for the trace data, then the full trace can be output over user interface  116 . 
       FIG. 2  shows a method of debugging system  100  of  FIG. 1 . The method begins with connecting a host system  110  to the user interface  116  of the master SOC  102  (step  210 ). Next, debug data representing the activity of one or more SOCs  104 ,  106  is received by master SOC  102  via debug bus  108  (step  220 ). This data can be temporarily stored by master SOC  102  (step  230 ). Master SOC  102  transfers the debug data via its user interface  116  to the host system  110  for analysis (step  240 ). Finally, the data is received by host system  110  where it can be analyzed by the end user (step  250 ). 
     One skilled in the art will appreciate that additional variations may be made in the above description without departing from the spirit and scope of the description which is defined by the claims which follow.