Method and system for instruction stuffing operations during non-intrusive digital signal processor debugging

RELATED APPLICATION

This application is related to the following United States patent application numbers: application Ser. No. 11/560,217, filed Nov. 15, 2006, entitled NON-INTRUSIVE, THREAD-SELECTIVE, DEBUGGING METHOD AND SYSTEM FOR A MULTI-THREADED DIGITAL SIGNAL PROCESSOR; U.S. patent application Ser. No. 11/560,323, now U.S. Pat. No. 7,657,791, filed Nov. 15, 2006, entitled METHOD AND SYSTEM FOR A DIGITAL SIGNAL PROCESSOR DEBUGGING DURING POWER TRANSITIONS; U.S. patent application Ser. No. 11/560,332, filed Nov. 15, 2006, entitled METHOD AND SYSTEM FOR TRUSTED/UNTRUSTED DIGITAL SIGNAL PROCESSOR DEBUGGING OPERATIONS U.S. patent application Ser. No. 11/560,339, filed Nov. 15, 2006, entitled EMBEDDED TRACE MACROCELL FOR ENHANCED DIGITAL SIGNAL PROCESSOR DEBUGGING OPERATIONS.

FIELD

The disclosed subject matter relates to data processing systems and processes such as may find use in data communications and similar applications. More particularly, this disclosure relates to a novel and improved method and system for instruction stuffing operations during non-intrusive digital signal processor debugging operations.

DESCRIPTION OF THE RELATED ART

Increasingly, telecommunications and other types of electronic equipment and supporting video, complex audio, videoconferencing and other rich software applications involve signal processing. Signal processing requires fast mathematical calculations and data generation in complex, but repetitive algorithms. Many applications require computations in real-time, i.e., the signal is a continuous function of time, which must be sampled and converted to digital signals for numerical processing. The processor must execute algorithms performing discrete computations on the samples as they arrive.

The architecture of a digital signal processor (DSP) is optimized to handle such algorithms. The characteristics of a good signal processing engine include fast, flexible arithmetic computation units, unconstrained data flow to and from the computation units, extended precision and dynamic range in the computation units, dual address generators, efficient program sequencing, and ease of programming.

One promising application of DSP technology includes communications systems such as a code division multiple access (CDMA) system that supports voice and data communications, as well as text messaging and other applications, between users over a satellite or terrestrial link. The use of CDMA techniques in a multiple access communication system is disclosed in U.S. Pat. No. 4,901,307, entitled “SPREAD SPECTRUM MULTIPLE ACCESS COMMUNICATION SYSTEM USING SATELLITE OR TERRESTRIAL REPEATERS,” and U.S. Pat. No. 5,103,459 entitled “SYSTEM AND METHOD FOR GENERATING WAVEFORMS IN A CDMA CELLULAR TELEHANDSET SYSTEM,” both assigned to the assignee of the claimed subject matter.

A CDMA system is typically designed to conform to one or more standards. One such first generation standard is the “TIA/EIA/IS-95 Terminal-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System,” hereinafter referred to as the IS-95 standard. The IS-95 CDMA systems are able to transmit voice data and packet data. A newer generation standard that may more efficiently transmit packet data is offered by a consortium named the “3^rdGeneration Partnership Project” (3GPP) and embodied in a set of documents including Document Nos. 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, and 3G TS 25.214, which are readily available to the public. The 3GPP standard is hereinafter referred to as the W-CDMA Standard.

Complex DSP operational software employing the W-CDMA Standard, for example, requires robust development tools. Such development tools may include those for code generation, integration, testing, debugging, and evaluating application performance. In developing and operating software or complex DSP applications, such as advanced telecommunications applications, there is the need for sophisticated, yet non-intrusive debugging software. That is, debugging software applications must be not only sufficiently robust to monitor, test, and support the correction of software defects and operational problems, but also they may operate so as not to interfere with the core processor software during debugging operations. Otherwise, any problems in the core processing software may not be detected or detected properly during the use of such debugging software.

Moreover, during or in association with non-intrusive debugging processes, there is frequently the need to operate a variety of diagnostic, analytical, and other processes for determining various aspects of core processor operations. Such diagnostic, analytical, and similar programs may vary according to the specific type and amount of information a use may desire or an associated debugging process may need. Accordingly, the ability to insert or stuff instructions into a debugging process dynamically could have significant advantages.

Presently, however, no known way to perform instruction stuffing operations exists for debugging core processes in association with a multi-threaded digital signal processor as has been here described. Yet further, no instruction stuffing process exists that may be thread-selective by performing the functions of operating stuffed instructions on one, two, or more threads of a multi-threaded digital signal processor. Moreover, no instruction stuffing process or mechanism is known that allows a debugging process to execute instructions on the core processor in conjunction with or in association with both the core processing functions and the non-intrusive debugging process.

Reasons for which instruction stuffing operations may be advantageous include for the purpose of reading and/or writing core registers and memory. Also, debugging process operations may be abstracted for user analysis, including the use of various analytical application programs. Moreover, instruction operations may allow a user to enter into the debugging process various instructions applicable to a specific type of debugging.

There is a need, therefore, for a debugging process and system for operation with a DSP, which debugging process and system provides the ability for instruction stuffing operations during non-intrusive digital signal processor debugging operations.

A need exists for an instruction stuffing process and mechanism that may be applicable to multi-threaded digital signal processor debugging operations.

A need exists for an instruction stuffing process and mechanism that may be thread-selective, by providing the ability operate stuffed instructions on one, two, or more threads of a multi-threaded digital signal processor.

Still a need exists for an instruction stuffing process or mechanism that allows a debugging process to execute instructions on the core processor in conjunction with or in association with both the core processing functions and the non-intrusive debugging process.

Also, a need exists for a non-intrusive software debugging process instruction stuffing operations for processing instructions and data on a core process during non-intrusive digital signal processor debugging operations.

SUMMARY

Techniques for providing non-intrusive, thread-selective, debugging method and system for a digital signal processor, including a multi-threaded digital signal processor, are disclosed, which techniques provide for instruction stuffing operations during non-intrusive debugging operations. The method and system here disclosed improve both the operation of a digital signal processor and the efficient use of digital signal processor instructions for increasingly powerful software applications, including applications operating in personal computers, personal digital assistants, wireless handsets, and similar electronic devices, as well as increasing the associated digital processor speed and service quality.

According to one aspect of the disclosed subject matter, a method and system for stuffing instructions in a processing pipeline of a multi-threaded digital signal processor provide for improved software instruction debugging operations. The method and system provide for operating a core processor process within a core processor associated with the digital signal processor and a debugging process within a debugging mechanism of the digital signal processor. The debugging mechanism is associated with the core processor. The disclosed subject matter includes writing a stuff instruction into a debugging process registry associated with the debugging process and a stuff command in a debugging process command register associated with the debugging process registry in response to the stuff instruction. The stuff command provides for identification of a predetermined thread of the multi-threaded digital signal processor in which to execute the stuff instruction. The present disclosure issues a debugging process control resume command from the core processor during a predetermined stage of executing on the predetermined thread and directs the core processor to perform the stuffed instruction during the debugging process. The present disclosure provides the stuffed instruction to the core processor for executing the stuffed instruction in association with the core processor process and the debugging process.

These and other advantages of the disclosed subject matter, as well as additional novel features, will be apparent from the description provided herein. The intent of this summary is not to be a comprehensive description of the claimed subject matter, but rather to provide a short overview of some of the subject matter's functionality. Other systems, methods, features and advantages here provided will become apparent to one with skill in the art upon examination of the following FIGURES and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the accompanying claims.

BRIEF DESCRIPTIONS OF THE DRAWINGS

The features, nature, and advantages of the disclosed subject matter may become more apparent from the detailed description set forth below when taken in conjunction with the drawings in which like reference characters identify correspondingly throughout and wherein:

<figref idrefs="DRAWINGS">FIG. 1</figref> is a simplified block diagram of a communications system that may implement one of the various embodiments here disclosed;

<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates a DSP architecture for carrying forth the teachings of the present disclosure;

<figref idrefs="DRAWINGS">FIG. 3</figref> provides an architecture block diagram of one embodiment of a multi-threaded digital signal processor;

<figref idrefs="DRAWINGS">FIG. 4</figref> shows further an architectural diagram of the process flows for the control unit, the instruction unit, and other functional components of the present digital signal processor;

<figref idrefs="DRAWINGS">FIG. 5</figref> discloses certain aspects of a digital signal processor core applying the ISDB/JTAG interface features of the present disclosure;

<figref idrefs="DRAWINGS">FIG. 6</figref> shows an aspect of an ISDB JTAGSync circuit for performing certain aspects of the debugging procedures here disclosed;

<figref idrefs="DRAWINGS">FIG. 7</figref> presents a process flow diagram applicable to the operating modes of the digital signal processor, including the debugging mode of operation to which the present disclosure pertains;

<figref idrefs="DRAWINGS">FIG. 8</figref> depicts a breakpoint processing scheme applicable to the embodiment of the present disclosure;

<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates the ISDB command register contents for one embodiment of the disclosed subject matter, including an instruction stuffing register for disclosing the disclosed process; and

<figref idrefs="DRAWINGS">FIG. 10</figref> presents a processing timing cycle chart for depicting the disclosed process for instruction stuffing in association with a non-intrusive debugging process.

DETAILED DESCRIPTION OF THE SPECIFIC EMBODIMENTS

The disclosed subject matter for a non-intrusive, thread-selective, debugging method and system for a multi-threaded digital signal processor has application for multi-threaded processing of any type for which the benefits here presented may be advantageous. One application appears in telecommunications and, in particular, in wireless handsets that employ one or more digital signal processing circuits. For explaining how a wireless handset may be used, <figref idrefs="DRAWINGS">FIG. 1</figref> provides a simplified block diagram of a communications system <b>10</b> that may implement the presented embodiments of the disclosed interrupt processing method and system. At a transmitter unit <b>12</b>, data is sent, typically in blocks, from a data source <b>14</b> to a transmit (TX) data processor <b>16</b> that formats, codes, and processes the data to generate one or more analog signals. The analog signals are then provided to a transmitter (TMTR) <b>18</b> that modulates, filters, amplifies, and up converts the baseband signals to generate a modulated signal. The modulated signal is then transmitted via an antenna <b>20</b> to one or more receiver units.

At a receiver unit <b>22</b>, the transmitted signal is received by an antenna <b>24</b> and provided to a receiver (RCVR) <b>26</b>. Within receiver <b>26</b>, the received signal is amplified, filtered, down converted, demodulated, and digitized to generate in phase (I) and (Q) samples. The samples are then decoded and processed by a receive (RX) data processor <b>28</b> to recover the transmitted data. The decoding and processing at receiver unit <b>22</b> are performed in a manner complementary to the coding and processing performed at transmitter unit <b>12</b>. The recovered data is then provided to a data sink <b>30</b>.

The signal processing described above supports transmissions of voice, video, packet data, messaging, and other types of communication in one direction. A bi-directional communications system supports two-way data transmission. However, the signal processing for the other direction is not shown in <figref idrefs="DRAWINGS">FIG. 1</figref> for simplicity. Communications system <b>10</b> may be a code division multiple access (CDMA) system, a time division multiple access (TDMA) communications system (e.g., a GSM system), a frequency division multiple access (FDMA) communications system, or other multiple access communications system that supports voice and data communication between users over a terrestrial link. In a specific embodiment, communications system <b>10</b> is a CDMA system that conforms to the W-CDMA Standard.

<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates DSP <b>40</b> architecture that may serve as the transmit data processor <b>16</b> and receive data processor <b>28</b> of <figref idrefs="DRAWINGS">FIG. 1</figref>. We emphasize that DSP <b>40</b> only represents one embodiment among a great many of possible digital signal processor embodiments that may effectively use the teachings and concepts here presented. In DSP <b>40</b>, therefore, threads T<b>0</b>:T<b>5</b> (reference numerals <b>42</b> through <b>52</b>), contain sets of instructions from different threads. Circuit <b>54</b> represents the instruction access mechanism and is used for fetching instructions for threads T<b>0</b>:T<b>5</b>. Instructions for circuit <b>54</b> are queued into instruction queue <b>56</b>. Instructions in instruction queue <b>56</b> are ready to be issued into processor pipeline <b>66</b> (see below). From instruction queue <b>56</b>, a single thread, e.g., thread T<b>0</b>, may be selected by issue logic circuit <b>58</b>. Register file <b>60</b> of a selected thread is read and read data is sent to execution data paths <b>62</b> for SLOT<b>0</b>:SLOT<b>3</b>. SLOT<b>0</b>:SLOT<b>3</b>, in this example, provide for the packet grouping combination employed in the present embodiment.

Output from execution data paths <b>62</b> goes to register file write circuit <b>64</b>, also configured to accommodate individual threads T<b>0</b>:T<b>5</b>, for returning the results from the operations of DSP <b>40</b>. Thus, the data path from circuit <b>54</b> and before to register file write circuit <b>64</b> forms a processing pipeline <b>66</b>. The present embodiment may employ a hybrid of a heterogeneous element processor (HEP) system using a single processor with up to six threads, T<b>0</b>:T<b>5</b>. Processor pipeline <b>66</b> has six stages, which matches the minimum number of processor cycles necessary to fetch a data item from circuit <b>54</b> to registers <b>60</b> and <b>64</b>. DSP <b>40</b> concurrently executes instructions of different threads T<b>0</b>:T<b>5</b> within a processor pipeline <b>66</b>. That is, DSP <b>40</b> provides six independent program counters, an internal tagging mechanism to distinguish instructions of threads T<b>0</b>:T<b>5</b> within processor pipeline <b>66</b>, and a mechanism that triggers a thread switch. Thread-switch overhead varies from zero to only a few cycles.

DSP <b>40</b>, therefore, provides a general-purpose digital signal processor designed for high-performance and low-power across a wide variety of signal, image, and video processing applications. <figref idrefs="DRAWINGS">FIG. 3</figref> provides a brief overview of the DSP <b>40</b> architecture, including some aspects of the associated instruction set architecture for one manifestation of the disclosed subject matter. Implementations of the DSP <b>40</b> architecture support interleaved multithreading (IMT). In this execution model, the hardware supports concurrent execution of multiple hardware threads T<b>0</b>:T<b>5</b> by interleaving instructions from different threads in the pipeline. This feature allows DSP <b>40</b> to include an aggressive clock frequency while still maintaining high core and memory utilization. IMT provides high throughput without the need for expensive compensation mechanisms such as out-of-order execution, extensive forwarding networks, and so on. Moreover, the DSP <b>40</b> may include variations of IMT, such as those variations and novel approaches disclosed in the commonly-assigned U.S. patent applications by M. Ahmed, et al, and entitled “Variable Interleaved Multi-threaded Processor Method and System” and “Method and System for Variable Thread Allocation and Switching in a Multi-threaded Processor.”

<figref idrefs="DRAWINGS">FIG. 3</figref>, in particular, provides a core processing architecture <b>70</b> block diagram for DSP <b>40</b> as applied to a single thread that may employ the teachings of the disclosed subject matter. Block diagram <b>70</b> depicts shared instruction cache <b>72</b> which receives instructions via Bus interface (I/F) <b>73</b> from AXI Bus <b>74</b>, which instructions include mixed 16-bit and 32-bit instructions. These instructions reach to sequencer <b>76</b>, user control register <b>78</b>, and supervisor control register <b>80</b> of threads T<b>0</b>:T<b>5</b>. The core-level system architecture of the disclosed subject matter also includes in-silicon debugging system (ISDB) <b>82</b>, which interfaces core processor <b>70</b> via JTAG interface <b>84</b>, both of which are described in more detail below.

Sequencer <b>76</b> provides hybrid two-way superscalar instructions and four-way VLIW instructions to S-Pipe unit <b>86</b>, M-Pipe unit <b>88</b>, LD[Load]-Pipe <b>90</b>, and LD/ST[Store]-Pipe unit <b>92</b>, all of which communicate with general registers <b>94</b>. AXI Bus <b>74</b> also communicates via Bus I/F <b>73</b> with shared data cache <b>96</b> LD/ST instructions to threads T<b>0</b>:T<b>5</b>. Optional L2 Cache/TCM <b>98</b> signals include LD/ST instructions with shared data TCM <b>100</b>, which LD/ST instructions further flow to threads General Registers <b>94</b>. From AHB peripheral bus <b>102</b> MSM specific controller <b>104</b> communicates interrupts with T<b>0</b>:T<b>5</b>, including interrupt controller instructions, debugging instructions, and timing instructions. Global control registers <b>106</b> communicates control register instructions with threads T<b>0</b>:T<b>5</b>.

DSP <b>40</b>, therefore, includes six virtual DSP cores, each containing global control registers <b>106</b> and private supervisor control registers <b>80</b>. Global control registers <b>106</b> are shared between all threads. Each thread shares a common data cache and a common instruction cache. Load, store, and fetch operations are serviced by a common bus interface. High performance AXI bus <b>74</b> and a lower performance AHB bus <b>102</b> are used to connect the data and instruction traffic to off-core memory and peripherals. An integrated level two memory (cache and/or TCM) input <b>98</b> is optional. Peripheral access may be through memory-mapped loads and stores. The physical address partition between AHB and AXI may be configured at the MSM level.

Clearly, the presented architecture for DSP <b>40</b> may evolve and change over time. For example, the number of instruction caches that DSP <b>40</b> may use could change from six to one, or other numbers of caches. Superscalar dispatch, L1 data at TCM <b>100</b>, and other architectural aspects may change. However, the present subject matter may have continued relevance in a wide variety of configurations and for a large family of modifications of DSP <b>40</b>.

ISDB <b>82</b>, through JTAG interface <b>84</b>, provides a hardware debugging process for DSP <b>40</b>. ISDB <b>82</b> provides software debug features through JTAG interface <b>84</b> by sharing system or supervisor-only registers, that are divided into supervisor control registers <b>80</b> on a per thread basis, as well as global control registers <b>106</b> between all threads. The system control registers are used for per thread interrupt and exception control and per thread memory management activities. Global registers allow interacting with the ISDB <b>82</b> for debugging operations.

ISDB <b>82</b> enables software developers to debug their software while DSP <b>40</b> operates. ISDB <b>82</b> hardware, in combination with a software debugging process program operating in ISDB <b>82</b>, may be used to debug the DSP <b>40</b> operating system software. ISDB <b>82</b> supports debugging hardware threads individually. Users may suspend thread execution, view and alter thread registers, view and alter instruction and data memory, single step threads, stuff instructions to threads, and resume thread execution.

ISDB <b>82</b> may interface with a debugging process interface card to communicate with ISDB <b>82</b> debugging software residing on a program counter, yet all through JTAG interface <b>84</b>. Host debugging process software may interact with the ISDB <b>82</b> by reading and writing ISDB control registers. Communication, for example, may be through a 40-bit packet which identifies the ISDB register to which read/write is to occur, as well as a 32-bit data payload. A packet format supporting this operation may be up to 64 control registers which may be 32 bits wide each.

<figref idrefs="DRAWINGS">FIG. 4</figref> presents a diagram of the micro-architecture <b>110</b> for DSP <b>40</b> including control unit (CU) <b>112</b>, which performs many of the control functions for processor pipeline <b>46</b>. CU <b>112</b> schedules and issues instructions to three execution units, shift-type unit (SU) <b>116</b>, multiply-type unit (MU) <b>118</b>, and load/store unit (DU) <b>120</b>. CU <b>112</b> also performs superscalar dependency checks. Bus interface unit (BIU <b>114</b>) <b>122</b> interfaces IU <b>114</b> and DU <b>120</b> to a system bus (not shown). SLOT<b>0</b> and SLOT<b>1</b> pipelines are in DU <b>120</b>, SLOT<b>2</b> is in MU <b>118</b>, and SLOT<b>3</b> is in SU <b>116</b>. CU <b>112</b> provides source operands and control buses to pipelines SLOT<b>0</b>:SLOT<b>3</b> and handles GRF and CRF file updates. CU <b>112</b> accepts external inputs such as interrupts and reset, and supports ISDB/ETM <b>122</b>. CU <b>112</b> also handles exceptions due to protection violations occurring during address translations.

ISDB <b>82</b> interfaces with three domains: host debugging software through JTAG <b>84</b>, DSP <b>40</b> core through IU <b>114</b> and CU <b>112</b>, and other cores present in the system through a Multi-Core Debug (MCD) signal interface. The primary interface between the host debugging software and DSP <b>40</b> core is a set of JTAG accessible registers referred to as ISDB <b>82</b> registers. The host debugging software performs various debugging process tasks by executing a sequence of ISDB <b>82</b> register reads and writes.

ISDB <b>82</b> communicates with the test environment (in this case a POD or debugging process interface card communicating with the debugging process software residing on a PC) through JTAG interface <b>84</b>. The host debugging process software interacts with the ISDB by reading and writing ISDB control registers. Communication occurs through a 40-bit packet which identifies the ISDB register in which to read and/of write and a 32-bit data payload for the various ISDB command, including the present instruction stuffing process.

<figref idrefs="DRAWINGS">FIG. 5</figref> shows important aspects of ISDB/JTAG interface <b>110</b> between the debugging mechanism and the core processor of the disclosed subject matter. In association with DSP <b>40</b> core architecture <b>70</b>, ISDB <b>82</b> communicates with JTAG <b>84</b> via path JTAG interface path <b>112</b>, from ISDB JTAG circuit <b>114</b>. ISDB JTAG circuit <b>114</b> processes data flows between JTAG <b>84</b> and ISDB <b>82</b>. ISDB JTAG circuit <b>114</b> further interfaces ISDB JTAGSync circuit <b>116</b>. ISDB JTAGSync circuit <b>116</b> communicates further with ISDB controller <b>118</b>, IU <b>114</b> and CU <b>112</b>. Particularly, ISDB JTAGSync circuit <b>136</b> interfaces IU <b>114</b>, ISDB logic circuit <b>144</b>, and CU ISDB Controller <b>146</b> of CU <b>112</b>. CU ISDB controller <b>146</b> communicates with CU ISDB logic circuit <b>148</b>, as well as ISDB controller <b>138</b>. Control outputs from ISDB controller <b>138</b> include ISDB data output <b>154</b>, ISDB reset signal <b>150</b>, and ISDB interrupt <b>152</b>. Further interfaces to ISDB controller <b>138</b> include MCD interface <b>156</b> and ETM break trigger <b>158</b>.

ISDB <b>82</b> provides hookups for multi-core debug at the MSM level through MCD interface <b>156</b>. The MCD interface <b>156</b> consists of a pair of input signals which trigger break or resume of core processor <b>70</b> and a pair of output signals which indicate that core processor <b>70</b> is entering a debugging process or resuming program execution. The MCD break triggers may follow an edge-based protocol such that when a rising edge is detected on an external breakpoint trigger, the threads indicated in external breakpoint thread number mask suspend execution and enter debug mode. Similarly, when a rising edge is detected on the MCD external resume trigger, the threads indicated in external resume thread number mask, if in debug mode, resume normal program execution.

ISDB <b>82</b> control logic is spread across two blocks: ISDB controller <b>138</b> in ISDB <b>82</b> and CU ISDB controller <b>146</b> in CU <b>112</b>. ISDB controller <b>138</b> handles the tasks of implementing ISDB enable, ISDB version, and ISDB general purpose register registers. MCD external break and resume triggers <b>156</b> and ETM break trigger <b>158</b> are synchronized to the core processor <b>70</b> clock before they are forwarded to CU <b>112</b> for further processing. ISDB controller <b>138</b> also generates MCD break trigger and the MCD resume trigger based on debug mode status of core processor <b>70</b>. ISDB controller <b>138</b> adds a pipeline stage for signals sent out to DSP <b>40</b>, such as an ISDB interrupt, break event, and other signals. The rest of the control logic which includes breakpoint processing, micro-command generator, mailbox and status logic is handled by CU ISDB controller <b>146</b>.

CU <b>112</b> includes circuitry and instructions capable of handling the tasks such as (a) processing breakpoints and generating break triggers to each thread; (b) generating micro-break and micro-resume commands; (c) maintaining ISDB <b>82</b> status and mailbox registers; and (d) implementing the certain ISDB <b>82</b> registers. CU <b>112</b> includes a breakpoint processing logic (BPL) block as appears in <figref idrefs="DRAWINGS">FIG. 8</figref> for processing all the breakpoints and generating a macro break request to a micro-command generator of CU ISDB controller <b>126</b>. The micro-command generator processes the macro break request along with instruction stuff commands, instruction step and resume commands and issues micro-break and resume commands to CU <b>112</b> for pipeline control.

CU ISDB controller <b>128</b> maintains the state of ISDB <b>82</b> based on the break and resume acknowledge signals received back. The mailbox functions of CU ISDB controller <b>146</b> maintain mailbox registers used for communication between the host debug software and the DSP <b>40</b> core processor. These mailbox functions also contain ISDB <b>82</b> status registers.

To demonstrate illustrative circuitry for performing the presently disclosed instruction stuffing operations in association with non-intrusive debugging operations, <figref idrefs="DRAWINGS">FIG. 6</figref> includes ISDB JTAGSync circuit <b>160</b>. ISDB JTAGSync circuit <b>160</b> includes an ISDB test data register <b>162</b> which DSP <b>40</b> may use to read and write the ISDB control registers. ISDB JTAGSync circuit <b>160</b> provides the synchronization logic between the ISDB test data register <b>162</b> operating on DB_tck and the ISDB control registers <b>164</b> operating in the DSP <b>40</b> clock domain. By reading and writing the ISDB control registers, DSP <b>40</b> performs various debugging process tasks as may be supported by the ISDB <b>82</b>, including the presently disclosed instruction stuffing operations.

In the implementation of <figref idrefs="DRAWINGS">FIG. 6</figref>, ISDB JTAGSync circuit <b>160</b> receives JTAG_isdb_chain_in signal <b>164</b> into ISDB Test Data Register <b>204</b> to generate JTAG_isdb_chain_out signal <b>166</b>. ISDB Test Data Register <b>162</b> includes read/write (R/W) bits <b>167</b>, Address bits [6:0] <b>168</b>, and Data bits [31:0] <b>170</b>. Values in R/W bits <b>167</b> go to AND gate <b>172</b>, as do Sync circuit output <b>174</b> and CU <b>112</b>_trustedDebug input <b>176</b>. JTAG_isdb_chain_update_tkl signal <b>178</b> and ISDB_CLK signal <b>180</b> control the operation of Sync circuit <b>174</b>. Address information from Address bits <b>168</b> may be received by Address Decode circuit <b>176</b>, which feeds ISDB Registers <b>184</b>. ISDB Registers <b>184</b> transfer data with Data bits [31:0] in response to a write enable signal <b>186</b> from AND gate <b>172</b>.

ISDB JTAGSync circuit <b>130</b> acts as the synchronization bridge between the TAP controller running on JTAG TCK in DB_JTAG block and ISDB registers <b>184</b> running on DSP <b>40</b> core clock distributed in ISDB controller <b>138</b>, CU <b>112</b>_ISDBCtrl <b>146</b> and IU <b>114</b>. The ISDB controller <b>138</b> and CU ISDB controller <b>146</b> contain the control logic of ISDB <b>82</b> which consists of a micro-command generator, breakpoint processing logic and various ISDB registers <b>184</b> (configuration, mailbox, command etc.). These blocks execute different debugging process tasks initiated by host debugging software on the DSP <b>40</b> core. The ISDB interrupt signal is sent out to the DSP subsystem where it is merged with other interrupt sources and sent back to the DSP core <b>70</b>. Similarly an ISDB <b>82</b> reset is merged with other reset sources (power-on reset, software reset etc.) to trigger a reset to the core. ISDB <b>82</b> interfaces with external systems (e.g., an MSM system external to DSP <b>40</b>) through an MCD signal interface. Two pairs of break and resume triggers are provided to support simultaneous debugging of DSP <b>40</b> and other cores in external system.

<figref idrefs="DRAWINGS">FIG. 7</figref> presents a processing mode diagram <b>190</b> for the various mode control aspects of DSP <b>40</b>, including operations of ISDB <b>82</b> during debugging processes. In <figref idrefs="DRAWINGS">FIG. 7</figref>, DSP <b>40</b> supports processing modes that are both global to all threads and local to individual threads. Each DSP <b>40</b> hardware thread individually supports two execution modes, USER mode <b>192</b> and SUPERVISOR mode <b>194</b>, and three non-processing modes of WAIT mode <b>196</b>, OFF mode <b>198</b>, and DEBUG mode <b>200</b>, all as may appear in <figref idrefs="DRAWINGS">FIG. 7</figref>. The mode of a thread is independent of other threads, for example one thread may be in WAIT mode <b>196</b> while another is in USER mode <b>192</b>, and so on.

The per-thread mode state diagram of <figref idrefs="DRAWINGS">FIG. 7</figref> is supported by various instructions or events. These include “Except” or internal exception event, an “Int” or external interrupt event, an “RTE” or software return instruction from exception mode, and “SSR” or update to SSR register instruction, a “Stop” or software stop instruction that may be entered from any mode, a “Start” or software Start Instruction that also may be entered from any mode, a “trap” or software Trap Instruction, a “Wait” or software wait Instruction, a “Resume” or software Resume Instruction, a “DE” or Debug Event, and a “DR” or Debug Instruction. While the functions in different implementations of the claimed subject matter may vary slightly from those here presented, the meanings of “Start,” “Wait,” “Resume,” “DE,” and/or “DR” may be given their broadest interpretations consistent with the scope of the claimed subject matter.

Registers are available in DSP <b>40</b> in both USER mode <b>192</b> and SUPERVISOR mode <b>194</b>. The user-mode registers are divided into a set of general registers and a set of control registers. General registers are used for all general purpose computation including address generation, scalar and vector arithmetic. Control registers support special-purpose functionality such as hardware loops, predicates, etc. General purpose registers are 32 bits wide and may be accessed as single registers or as aligned pairs of two registers. The general register file provides all operands for instructions, including addresses for load/store, data operands for numeric instructions, and vector operands for vector instructions.

DEBUG mode <b>200</b> provides a special state where the thread is waiting for commands from ISDB <b>82</b>. Whenever an ISDB Debug Event occurs, such as by the execution of a software breakpoint instruction, a break command from ISDB <b>82</b>, or occurrence of a hardware breakpoint, indicated threads may enter DEBUG mode <b>200</b>. While in DEBUG mode <b>200</b>, the core is controlled by ISDB <b>82</b> via commands from JTAG interface <b>84</b>. When the ISDB <b>82</b> releases the thread due to execution of a resume command, the thread may resume operation according to their current mode settings. When a thread is in DEBUG mode <b>200</b>, it is controlled by ISDB <b>82</b> and cannot be controlled by other threads. Such control may include the execution of various instructions as may be provided through the presently disclosed instruction stuffing operations. A Wait, Resume, Start, or Stop instruction from a running thread, targeting a thread in DEBUG mode <b>200</b>, may be ignored. Similarly, a Non-Maskable Interrupt (NMI) may be ignored by threads in DEBUG mode <b>200</b>.

A HARDWARE RESET mode (not shown in <figref idrefs="DRAWINGS">FIG. 7</figref>) and DEBUG mode <b>200</b> are global to all threads. Whenever the hardware reset pin is asserted, regardless of any thread's processing state, DSP <b>40</b> may enter HARDWARE RESET Mode. In HARDWARE RESET mode, all registers are set to their reset values. No processing may occur until the hardware reset pin is de-asserted. When the reset pin is asserted, the processor may transition into reset mode and all registers may be reset to their HARDWARE RESET values. After the reset pin is de-asserted, thread T<b>0</b> may be given a soft reset interrupt. This may cause thread T<b>0</b> to enter SUPERVISOR mode <b>194</b> and begin executing at the reset vector location. All other threads may remain off. At this point, the software is free to control mode transitions for each thread individually.

In <figref idrefs="DRAWINGS">FIG. 8</figref>, it is seen that BPL circuit <b>210</b> of CU ISDB controller <b>146</b> includes break triggers from six different sources, including hardware breakpoints <b>0</b>/<b>1</b> (HWBKPT<b>0</b><b>212</b> and HWBKPT<b>1</b><b>214</b>), software breakpoint (SWBKPT <b>216</b>), JTAG interface <b>84</b> breakpoint (JTAGBKPT <b>218</b>), ETM (embedded trace macro) breakpoint (ETMBKPT <b>220</b>), and external breakpoint (EXTBKPT <b>222</b>). Break trigger <b>212</b> through <b>222</b> and debug mode status input <b>214</b> go to encode break encoder <b>216</b> to cause DSP <b>40</b> to operate in DEBUG mode <b>200</b>. Output from encoder <b>226</b> includes three (3) breakpoint information bits <b>228</b> and a breakpoint valid bit <b>230</b>. Breakpoint information data <b>228</b> enters breakpoint information circuit <b>232</b> to cause a breakpoint information JTAG interface command <b>234</b>. Breakpoint bit <b>230</b> also generates OR gate input <b>236</b> and reset circuit <b>238</b> input. Reset circuit <b>238</b> receives either a UCG resume thread number or a reset input <b>242</b> to generate reset control output <b>244</b> into OR gate <b>246</b>. Either valid bit <b>236</b> or reset output <b>244</b> may cause OR gate <b>246</b> to generate BPL breakpoint output <b>248</b>.

The break triggers in BPL circuit <b>210</b> are processed along with the corresponding thread number mask to generate macro break trigger to each of the threads. The macro break trigger <b>248</b>, bpl_breakTnum_ANY[0], is maintained until the corresponding thread is resumed. The number of pipeline stages that may be used in BPL circuit <b>210</b> is driven by hardware breakpoints which are precise breakpoints, i.e., the instruction that triggers hardware breakpoint match must not be executed. The thread switches to debug mode after executing the program until that instruction. The disclosed embodiment provides a macro break trigger one cycle after the break triggers arrive. For that reason the breakValid input <b>226</b> is logically OR'ed with its latched version input <b>242</b> to generate bpl_breakTnum_ANY[0] output <b>248</b>.

Through the use of breakpoints, the six threads of DSP <b>40</b> may individually enter and exit DEBUG mode <b>200</b>. A breakpoint trigger may come from five sources which correspond to the five different types of breakpoints supported in ISDB <b>82</b>. Upon hitting a breakpoint, a thread transitions from its current mode (e.g., WAIT/RUN) to DEBUG mode <b>200</b>. In DEBUG mode <b>200</b>, the thread waits for commands from ISDB <b>82</b>. A thread in OFF mode <b>198</b> is powered down and may not accept any commands from ISDB <b>82</b>. The latency of entering DEBUG mode <b>200</b> is implementation defined, such as in the present disclosure as relating to the event a power collapse. For example, an implementation may choose to complete a given operation, for example finish an outstanding load request, before entering DEBUG mode <b>200</b>. In one embodiment, a thread identifier register contains an 8-bit read/write field and is used for holding a software thread identifier. This field is used by the hardware debugging process to match breakpoints.

ISDB <b>82</b>, therefore, has four operations: break, resume, stuff instruction, single step. From the micro-architecture point of view, there are two basic operations: break and resume. The micro-break command and micro-resume command to refer to operations of break, stuff instruction and single step. For example, the stuff instruction operation may be viewed as a micro-break command followed by micro-resume command after the stuff instruction operations. Breakpoint operations may be triggered from five sources, as herein described. Each break source may break multiple threads as specified in its corresponding tread number mask value.

<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates the ISDB command register contents for one embodiment of the disclosed subject matter. These ISDB control registers may be used by the host system to configure ISDB <b>82</b> to perform different debugging process tasks and communicate with the processor. These registers are accessible through the JTAG interface. The ISDB status register (ISDBST) indicates the current status of ISDB, including the stuff command status bits for which a “0” values indicates a stuff instruction is successful, whereas a “1” value indicates the stuff instruction caused an exception. The host system may use the ISDB configuration registers <b>0</b> and <b>1</b> (ISDBCFG<b>0</b>, ISDBCFG<b>1</b>) register to enable or disable various features of the ISDB <b>82</b>. The breakpoint info register (BRKPTINF<b>0</b>) indicates, for the threads in debug mode, which trigger caused the breakpoint. The breakpoint PC register <b>0</b> and <b>1</b> (BRKPTPC<b>0</b>, BRKPTPC<b>1</b>) is identical to BRKPTPC<b>0</b>, control hardware breakpoint <b>0</b> and <b>1</b>, respectively. The breakpoint configuration registers (BRKPTCFG<b>0</b> and BRKPTCFG<b>1</b>) are used to configure breakpoint <b>0</b> and <b>1</b>, respectively. The stuff instruction register (STFINST) allows for a 32-bit stuff instruction. The ISDB mail box registers (ISDBMBXIN and ISDBMBXOUT) are used to exchange data between the ISDB and core processor <b>70</b>. The ISDB command register (ISDBCMD) is used by DSP <b>40</b> to issue various commands to the ISDB <b>82</b>. This ISDB enable register (ISDBEN) enables ISDB operations and allows checking the status of the “security” ISDB enable bit and the ISDB clock. The ISDB version register (ISDBVER) reads the version of the ISDB design present in the chip. ISDB general purpose register (ISDBGPR) provides storage for general functions associated with ISDB <b>82</b>.

The ISDB command register provides, in the disclosed embodiment, a 32-bit register whose value is output into DSP <b>40</b>. The ISDB command register may be used to control external hardware, and in an MSM-specific manner. The ISDB control registers are accessed by the debugging process host software via JTAG interface <b>84</b> and are distributed across three units: ISDB <b>82</b>, IU <b>114</b> and CU <b>112</b>. Instead of placing all the registers in ISDB <b>82</b>, the registers are placed locally in the unit where the register values are used primarily.

The ISDB registers of <figref idrefs="DRAWINGS">FIG. 9</figref> are distributed among ISDB <b>82</b>, IU <b>114</b> and CU <b>112</b> the following way: ISDB <b>82</b> includes the ISDB enable register; ISDB version register; and ISDB general purpose register. The CU <b>112</b>, wherein are the ISDB control mailbox, breakpoint logic, and micro-command generator blocks, includes ISDB configuration registers (ISDBCFG<b>0</b> &amp; ISDBCFG<b>1</b>), the command register (ISDBCMD), breakpoint configuration registers (BRKPTCFG<b>0</b> &amp; BRKPTCFG<b>1</b>), breakpoint information register (BRKPTINF<b>0</b>), breakpoint status register (ISDBST), breakpoint mailbox in register (ISDBMBXIN, ISDBMBXOUT). The IU <b>114</b><b>112</b> register block includes breakpoint command registers (BRKPTPC<b>0</b>, BRKPTPC<b>1</b>), breakpoint configuration registers (BRKPTCFG<b>0</b>, BRKPTCFG<b>1</b>), and, as is relevant to the present disclosure, the stuff instruction register (STFINST).

Instruction stuffing, as here disclosed, provides a method and system for ISDB <b>82</b> to execute instructions on the core. Instructions are stuffed for various reasons. These may include for the reasons of reading and/or writing core registers and memory, as well as for debugging process operations abstracted for the user and user-entered instructions. To stuff an instruction, the user first programs the STFINST register of the ISDB command register with the 32-bit instruction to be executed. The ISDB command register is then written, beginning with setting the command field to the STUFF code. Then, the process sets the thread number field to the thread to receive the instruction. Preferably, one bit in the thread number field may be set. The selected thread must be in DEBUG mode <b>200</b> before the instruction may be stuffed. If more than one bit in thread number is set or the selected thread is not in debug mode, the results are undefined. Then, the instruction stuffing process includes setting the privilege level of the stuffed instructions (either for use in USER mode <b>192</b> or SUPERVISOR mode <b>194</b>). After issuing the STUFF command, the instruction may be executed on the chosen thread with the chosen privilege level. During instruction stuffing, the program counter (PC) does not advance. Stuffed instructions which use the PC for branches, or instructions that cause an exception may use the current PC value for the thread on which the stuffed instructions execute.

In the case that a stuffed instruction causes an exception, the ISDB status register, ISDBST, may indicate that an exception occurred. The thread may remain in debug mode. The architected registers for the specific may reflect the exception state. For example, if a LOAD instruction is stuffed that causes a TLB miss exception, then an exception register (ELR) may be set to the current PC, the PC may be changed to exception vector, and a status register (SSR) may hold the correct cause code and status information. The debugging process software may query the ISDBST after stuffing an instruction that could cause an exception to see if an exception occurred. If it did, then the SSR register may be read, via stuffing a control register transfer instruction, to determine the exception cause.

Once an exception has been recognized, the debugging process has a number of choices as to how to handle the situation. For example, the debugging process may choose to program a software or hardware breakpoint at the exception return point and resume the thread in order to run the handler. Also, the debugging process could redirect a thread to an operating system “helper” function, as well as to step through the handler using a single-step function. Furthermore, the debugging process may manually fix the problem (e.g., reload the TLB). The exact strategy is left to the operating system and/or debugging process implementation.

Registers, cache, and memory may be accessed by stuffing the appropriate instruction sequences. The debugging process software may read/write thread registers by stuffing the appropriate control register transfer instruction to move data between a core register and the ISDB mailbox. This instruction may be stuffed using supervisor privilege level to ensure no exception occurs. Cache contents (data and cache tag value) may be read and/or written by stuffing the appropriate cache maintenance and load instructions.

Memory may be read/written by stuffing the appropriate LOAD/STORE instruction. When the MMU is enabled, Loads and Stores always execute using a virtual address. The MMU provides the information may be stored in a cache memory, such as signaling as cacheable, uncacheable, etc. If it is desired to access memory from a particular source, for example, to read from a device in uncached memory, then the debugging process software ensures that the MMU is properly configured for this access. For certain debug scenarios, the debugging process software may engage the help of the operating system to configure a specific scenario.

Cache contents are affected as if the stuffed instruction came from normal program flow. For example, a cacheable load that misses in the data cache may cause a line replacement. In the case that one thread is in debug mode and others are running, the cache contents may change accordingly. In the case of a load that misses in the cache or an uncached load, the stuff command may not be reported as complete in the ISDB status register until the load data returns and the operations completes normally.

To read instruction memory, a similar procedure as reading data memory may take place. To write instruction memory, for example to set software breakpoints, the debugging process software may first stuff a STORE instruction to write the instruction memory. Then, the process includes stuffing a data cache clean address instruction to force the data into external memory, stuffing a barrier instruction to ensure that the change is observable in external memory, and an instruction cache invalidate address instruction to remove the old entry from the instruction cache.

Instruction stuffing, as herein disclosed, may also be of use in association with resetting DSP <b>40</b>. Note that executing an ISDB RESET command forces a hardware reset and causes the entire DSP <b>40</b>, i.e., all threads, to reset. This may set all registers to initial values, power off threads T<b>0</b>:T<b>5</b> and send a reset interrupt to thread T<b>0</b>. If, on the other hand, it is desired to reset just certain threads, this can be done using instruction stuffing. The steps include stuffing a “START” instruction with appropriate mask settings. This may cause a reset interrupt to be pending to the indicated threads. Then, the sequence includes executing an ISDB RESUME instruction on the desired threads. Performing such a sequence, therefore, makes possible an advantageous process of thread-selective resetting, without resetting all of DSP <b>40</b>.

<figref idrefs="DRAWINGS">FIG. 10</figref> presents a processing timing cycle chart for depicting the disclosed process for instruction stuffing in the disclosed non-intrusive debugging process. The signal behavior during a stuff operation on a particular thread, as depicted by <figref idrefs="DRAWINGS">FIG. 10</figref>, shows the sequence of events on a single thread of DSP <b>40</b>. Similar behavior may be seen by each thread in their corresponding pipeline stages. The stuffed instruction is provided by writing to the STFINST register of the ISDB command registers. To execute the stuffed instruction, debug software writes to the ISDB command register with the stuff command. The command also provides the specific thread for the stuffed instruction to execute. ISDB control register <b>138</b> issues a micro-resume command in the EX3 stage of thread pipeline processing for the thread on which the stuff instruction is to execute. At this point, the CU ISDB micro-resume type EX3 register is set to “0x2.” This indicates that the issued micro-resume command is to perform a stuff operation. CU <b>112</b> asserts a CU debugging exception instruction at the WB stage of the following cycle. Upon receiving the CU debugging exception instruction, IU <b>114</b> clears off the old instruction buffer state and prepares to fetch from a new location similar to regular exception.

CU <b>112</b> sends a stuff instruction request to IU <b>114</b> in the following RF stage and asserts a CU next issue pointer instruction in the WB stage. Upon receiving the CU next issue point instruction, IU <b>114</b> provides the stuffed instruction to CU <b>112</b> in a similar way as an UC instruction. It may be multiplexed with BU return data inside IU <b>114</b> once, instead of multiplexing on a per-thread basis. This feature saves multiplexing cost, as well as routes congestion over and instruction cache. The micro-resume command is associated with a side-band signal to indicate the privilege level of the stuffed instruction. This permits executing in either USER mode <b>192</b> or SUPERVISOR mode <b>194</b>.

While the stuffed instruction is being executed, CU <b>112</b> sends another instruction request to IU <b>114</b> to restore the instruction buffer with the regular program instruction. When the stuffed instruction is committed, CU <b>112</b> needs to return micro-resume status in the WB processing stage, whether the resume status is success or not, along with an acknowledgement. ISDB controller <b>138</b> then issues a micro-break command in the following RF stage to prevent CU <b>112</b> from executing the next instruction. If the resume status is not success, CU <b>112</b> may instruction IU <b>114</b> to handle the exception in normal ways. Note, however, that the only reason is that the stuffed instruction causes an exception. The current program counter may be pushed to ELR and then updated to the except handler entry point. The thread may be stopped due to the micro-break command. After receiving micro-break command acknowledge, stuff instruction may be complete. Accordingly, the micro-break command status may be always success in this case.

In summary, the disclosed subject matter provides a method and system for stuffing instructions into a processing pipeline of a multi-threaded digital signal processor for improved software instruction debugging operations. The method and system provide for writing a stuff instruction into the debugging process registry. The disclosure includes writing a stuff command in a debugging process command register for executing the stuffed instruction. A predetermined thread of the multi-threaded digital signal processor in which the execution of the stuff instruction is to be executed is identified by the stuff instruction. The process and system issue a CU <b>112</b> debugging process control resume command during a predetermined stage, i.e., the EX3 stage, of executing the thread on the multi-threaded digital signal processor and set the CU <b>112</b> debugging process resume type to the predetermined stage of executing the thread for indicating that the issued resume command is to perform a stuff operation. The present disclosure also asserts a CU <b>112</b> exception command in the WB stage of following cycle and clears off the old instruction buffer state upon assertion of the CU <b>112</b> exception command. Then, the method and system prepare to fetch from a new location similar to a regular exception, while maintaining ELR notwithstanding a debugging process exception.

Also, the present embodiment sends a stuff request from the CU <b>112</b> to IU <b>114</b> in a subsequent processing stage and asserts a CU <b>112</b> next issue pointer the following cycle. The stuffed instruction is provided to the CU <b>112</b> upon receiving the CU <b>112</b> next issue pointer, whereupon IU <b>114</b> provides the stuffed instruction to CU <b>112</b> in a similar way as an UC instruction. The stuffed instruction is then multiplexed with BU return data inside the IU <b>114</b> only once, instead of on a per thread basis. The micro-resume command is associated with a side-band signal to indicate the privilege level of the stuffed instruction (execute in user/supervisor mode). While the stuffed instruction is being executed, CU <b>112</b> sends another instruction request to IU <b>114</b> to restore the instruction buffer with the regular program instruction. Then, when the stuffed instruction is committed, CU <b>112</b> needs to return micro-resume status in WB, whether the resume status is success or not, along with an acknowledgement. The CU ISDB controller then issues a micro-break command in the following RF stage to prevent CU <b>112</b> from executing the next instruction. If the resume status is not success (i.e., when the stuffed instruction causes an exception), the CU <b>112</b> may control the IU <b>114</b> to handle the exception in normal ways. Then, the current PC may be stored in the ELR register of DSP <b>40</b> and the PC may be updated to the except handler entry point. The thread may then be stopped due to the micro-break command. After receiving micro-break command acknowledge, the stuff instruction is complete.

The processing features and functions described herein for instruction stuffing operations in association with non-intrusive, thread-selective, debugging in a multi-threaded digital signal processor may be implemented in various manners. For example, not only may DSP <b>40</b> perform the above-described operations, but also the present embodiments may be implemented in an application specific integrated circuit (ASIC), a microcontroller, a digital signal processor, or other electronic circuits designed to perform the functions described herein. Moreover, the process and features here described may be stored in magnetic, optical, or other recording media for reading and execution by such various signal and instruction processing systems. The foregoing description of the preferred embodiments, therefore, is provided to enable any person skilled in the art to make or use the claimed subject matter. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without the use of the innovative faculty. Thus, the claimed subject matter is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.