JP2003150403A - Observation method for data processor and device thereof - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a trace structure and a method improved to use in one or more data processors and providing accurate and non-forced trace and debug functions. SOLUTION: One embodiment includes a trace unit applied in such a way that data and information are obtained from an operating processor to generate a plurality of data packets related to various aspects of processor operation. In an exemplifiable embodiment, the trace unit is applied to generate commands encoded as a plurality of data packets having a specific function, respectively, data, and timing trace. The packet is stored in one or more buffers, and these buffers can be accessed by an exclusive packet port related to a debug port and a device. The trace unit, the processor, and the buffers are arranged in a single integrated circuit device. In another embodiment, a multiprocessor core and the trace unit are proposed. A structure for data packet compression is also disclosed.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION This application was filed on Nov. 6, 2001, and the title of the invention is US Provisional Patent Application No. 60/3, entitled "Data Processor Observation Method and Apparatus".
Claims No. 38,869 as priority.

Copyright The disclosed portion of this patent document contains material which is subject to copyright protection. This copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the disclosure of the patent as it appears in the patent and trademark office patent files or records, but in all cases all copyrights Owned.

BACKGROUND OF THE INVENTION The present invention relates to the field of digital data processors and, more particularly, to data and code observations and traces associated with the operation of such processors and associated structures. .

[0004]

2. Description of Related Art Trace functions are used, inter alia, to enable designers or users to observe the results of executing software operations that occur within one or more digital processors or other integrated circuits. The trace function generally refers to the state of a selected portion of memory, the program counter (PC), and / or the processor's register at selected intervals after execution of each instruction or a predetermined number of instructions of a program, for example. I will provide a. By recording the state of these various components, the trace facility provides the user with detailed information about the internal operation of the processor and the execution of the program. By using such information,
Many forms of design or coding errors can be identified and corrected later. This is particularly useful during processor design and development, as the negative impact of architecture or transcoding can be easily determined before the design process progresses further.

The so-called "breakpoint" function also provides a means for identifying and preventing problems in the processor architecture or code. Breakpoint functions are often implemented in one instruction, causing the processor to suspend execution of further instructions without any form of direct intervention when normal operation is requested. Once the breakpoint instruction is executed by the pipeline, the processor suspends further processing until it receives some external signal, such as an interrupt indicating that execution should resume. During breaks, data is stored and / or retrieved to determine the state of the pipeline, memory, various registers, or programs, facilitating the identification of errors within the element.

Both the trace and breakpoint functions described above have been integrated within prior art data processors (and associated systems). To use the trace facility, software that uses the processor in such prior art applications typically must provide an interface with a fault handling procedure or debugging monitor program. Software is also required to process the registers and control bits of the registers to enable various trace modes and selectively enable or disable the trace function.

The debug capabilities of these prior art devices often require the processor to interrupt normal operation and enter a particular debug mode or exception routine. In such a mode, the processor does not behave as it would during normal operation, so (i) the failures observed during such a mode may not occur during “normal” processor operation; ) Failures that occur during normal operation may not be observed or captured. This is an important obstacle for the debug processor.

In addition to this, many prior art approaches require an internal debug program executed by the processor to provide control of the program during operation of the trace and breakpoint functions. Such a control structure is very "mandatory" in nature and thus not suitable for observing normal operation of the processor and any faults or bugs associated therewith.

Another obstacle to existing processor trace technology relates to the need for a complete trace to be present before information about the trace can be decoded. In particular, if the start of the trace is lost for any reason, the rest of the trace cannot be decoded due to the lost information present at the start of the trace.

Moreover, since trace data consumes a huge amount of memory space, the on-chip memory requirements associated with existing trace techniques are high. Similarly, transmitting trace data off-chip requires a large amount of bandwidth, which slows down the trace operation and requires a huge amount of chip buffering for the data.

Accordingly, there is a need for improved trace structures and methods for use with one or more data processors that provide accurate and non-forced trace and debug capabilities. Such structures and methods enable real-time observations with minimal chip memory and bandwidth requirements, and significant events in one or more processors, including events related to PC, memory, and periodic execution of instructions. Should be possible to duplicate. Such improved structures and methods are very flexible in configuration, allowing the user to tailor the trace to a particular application.

[0012]

SUMMARY OF THE INVENTION In a first aspect of the invention, an improved apparatus for acquiring and storing data traces from one or more digital processor devices is disclosed. In one exemplary embodiment, the device is
At least one trace element associated with the processor (s), the debug element or the like having at least one trace element adapted to generate a number of trace data associated with the operation of the processor (s); A data port and a host device in data communication with said port and processor (s), the host device adapted to store a number of trace data generated by trace element (s). including. Also, a data buffer is provided, the trace data is temporarily stored in this data buffer before being read and output by the host device. In a second exemplary embodiment, the device is
Further included is a data capture / analyzer unit in data communication with the trace element via a second data port (eg, a "packet" port).

In a second aspect of the invention, an improved integrated circuit device is disclosed. This device typically includes one or more dice (di
e) (eg silicon or equivalent semiconducting substrate). In an exemplary embodiment, the device is arranged with at least one processor core, at least one trace unit, a debug port in data communication with the at least one processor core, and a packet port in data communication with the trace unit. Single die ic
Includes (such as ASIC or FPGA). Also provided is a memory controller with associated memory ports, such memory controller being in data communication with the processor core.

In a second exemplary embodiment, the IC device includes a number of processor cores and a trace unit, and further includes a multicore trace interface (MTI) in communication with the trace unit, the MTI being the number of trace units. Arbitrate (and associated processor cores) to interface with a smaller number (eg, one) of packet ports located on the device. This device is
It also includes a multi-core debug interface (MDI) device that allows a smaller number of debug ports (and associated debug program hosts) and no multi-core / trace unit interfaces.

In a third aspect of the invention, a method of acquiring trace data from one or more processors during program execution is disclosed. The method generally comprises providing a trace unit adapted to receive data from the processor, generating a number of packets associated with the operation of the processor based on the received data, and Storing at least some of the packets in the storage device and analyzing at least some of the stored packets to obtain information related to the operation of the processor. In one exemplary embodiment, the trace unit includes four distinct traces (ie,
Applied to the generation of instructions, data, timing and miscellaneous or selective instructions, data, events and timing traces. One or more internal monitors control the acquisition of processor data for provision to the trace unit. The trace unit is OFF, RUN and TRIGGERED based on inputs received from the processor being monitored (for example, records to the trace unit register space) and selective external and user inputs.
Switched between operating states. The packets generated by the trace unit are uniquely formatted by the morphology of the information and the traces generated and other inputs received from the user / designer to facilitate subsequent analysis of the packet stream provided by the storage device. To

In a fourth aspect of the invention, an improved method and apparatus for compressing data associated with one or more of the traces described above is disclosed. The use of such compression advantageously reduces the required buffer size and the required trace pin bandwidth (storage cost). In one exemplary embodiment, a variable length encoding technique is used where a limited size code is used to represent high frequency values based on a determined or pre-stored probability distribution of frequency values. Large codes are used to represent low frequency values. In one modified embodiment,
The RTT code is selected as the number of "nibbles" (eg, 4 bits) of data.

In the second embodiment, delta encoding is used to store only a portion of a value. This stored portion is used in the trace for reference to the previously encoded value. Only the reference value and other nibbles (ie deltas) are encoded.

In the third embodiment, the run length (r
un-length) encoding is used. In such an implementation, each individual event is separately identified and stored, while repeated events are identified and counted. Such techniques are most useful when there are sequences or executions of the same type of event.

In the fourth embodiment, the source-code reference technique is adopted. In such an implementation, no information that can be derived by testing the compiled source code is stored, thus reducing storage overhead.

In a fifth aspect of the present invention, an improved method of data packet loading is disclosed. In one embodiment, the bits of the data nibble are padded to a predetermined value to produce the desired processing characteristics.

In a sixth aspect of the present invention, an improved monitor structure for use in the aforementioned trace unit is disclosed.

In a seventh aspect of the present invention, an improved packet port structure for use in the aforementioned trace unit is disclosed.

[0023]

DETAILED DESCRIPTION OF THE INVENTION A description will be given below with reference to the drawings.
Like reference numerals in the drawings denote like elements.

As used herein, the term "processor" refers to ARCtangent and AR Compact manufactured by the assignee of the present invention.
User-configurable, reduced instruction set cores (RISC) processors such as cores, central processing units (CPUs), and digital signal processors (DSPs), including but not limited to at least one instruction word. It is meant to include any integrated circuit or other electronic device (or collection of devices) that is capable of performing an operation. The hardware for such devices can be integrated on a single substrate (eg, a silicon die) or distributed between two or more substrates. Moreover, various functional characteristics of a processor may be implemented solely as software or firmware associated with the processor.

The ARCtangent processor is a user-customizable 32-bit RISC core for ASIC, system on chip (SoC), and FPGA integration. It is compositable, configurable and extensible, allowing developers to modify and extend the structure more appropriately for their particular application. The ARCtangent microprocessor has a three-stage execution pipeline with three
Includes 2-bit RISC structure. Instruction sets, register files, condition codes, caches, buses, and other structural features are user configurable and extensible. The microprocessor comprises a 32x32 bit core register file, which can be duplicated if the application requires it. In addition, a number of auxiliary registers (up to 2E32) can be used. The functional elements of such a processor core are arithmetic logic circuits (A
LU), register file (eg, 32 × 32), program counter (PC), instruction fetch (i-fetch) interface logic circuit and various stage latches.

ARCompact is an innovative processor and instruction set structure (ISA) that allows designers to mix 16 and 32-bit instructions on a 32-bit user-configurable processor. . ISA's key strength is to significantly reduce memory requirements on SoCs (system-on-chip) to enable low power consumption and low cost devices in widely used applications such as wireless communications and high volume home appliances. Ability.

Also, while the following description refers to design synthesis based on the VHSIC Hardware Description Language (VHDL), Verilog
It should be noted that other hardware description languages (HDLs) such as can be used to successfully describe various embodiments of the present invention. In addition, one exemplary Synopsys, such as Design Compiler 2000 (DC00)
Although the synthesis engine is used to synthesize the various embodiments described thus far, other synthesis engines such as Buildgates, which are specifically available from Cadence Design Systems, Inc., can be used. IEEE Standard 1076-3-
1997, IEEE Standard VHDL Synthesis Package, describes an industry-acceptable language for defining the design and synthesis performance of hardware description language platforms that can be foreseen by one of ordinary skill in the art.

Overview A real-time trace (RTT) device and method of the present invention comprises:
It provides non-forced observation support for one processor (or multiple processors) during program execution. In one exemplary embodiment, RTT captures four distinct forms of trace information: (i) instruction trace, (ii) data trace, (iii) timing trace, and (iv) miscellaneous trace.

The instruction trace records the progress of the program counter (PC) to trace the flow of instructions within the processor. The data trace records load / store memory addresses and memory data. The timing trace records the cycle of instruction execution. Miscellaneous traces are
Record selected processor state changes that correspond to trace functionality.

In the present invention, the trace information is encoded in the form of a variable length packet containing, for example, one or more "nibbles". The term "nibble" as used herein refers to a set of 4 bits, even though other increases in the number of bits may be successfully substituted, subject to the process-specific structure investigated below. The variable length packets are stored in a buffer memory on chip, which is a general form well known in the art. However, buffer memory is applied to transmit packets through both the RTT packet port and the debug port. The buffer memory "drains" packets using the RTT packet port and debug port to avoid filling the buffer completely at any time. The present invention provides buffer size / storage capacity, number of pins for the RTT packet port (which can be set to 0 if desired), RTT packet port pins dedicated or shared with other functions (eg general purpose I / O).
, And it is advantageous for the designer to select a number of parameters related to the RTT and buffer configuration, including the clock frequency associated with the packet port. Packet port clock output pins are available if the clock signals driving the clock output pins are not derived from other devices or pins on the ASIC.

Next, in an exemplary embodiment, described further below, the RTT unit of the present invention produces a trace with the following characteristics. (i) All normal hood sequences are captured, (ii) If the compiled source code of the executable is visible
(Generally, self-modifying code does not meet such requirements, so it is not supported), program flow can be reconstructed from instruction traces, (iii) capture, compression and transmission methods do not rely on triggering or filtering. (Iv) Trace information that does not impose any restrictions
Stored in limited memory (on-chip or off-chip). If the memory is full, obsolete trace information is discarded (i.e.FIFO) so that new trace information is stored, or more recent trace information is preferentially discarded (i.e.LIFO), or Traces are broken, (v) traces are advantageously used to minimize the bandwidth required to transfer the traces off-chip and to minimize the required size of on-chip and / or off-chip memory. Compressed. Multiple RTTs as shown in Fig. 22 described after there are not enough pins enabled for RTTs
Bandwidth minimization is especially important for devices with (microprocessors), (vi) this trace is decoded even if the start of the trace is lost, (vii) with multiple processor cores. The device is supported.

The RTT of the present invention includes many user-selectable choices, some of which are core or ASIC.
/ FPGA is set when configuring (“build-time”), others are set when running the configuration core / RTT (s). Device designers can edit the parameters (e.g. constants) in the register transfer language (RTL) source code associated with the design configuration, or set configuration parameters during the installation process, or both. By doing so, you set the configuration options. The device user sets run-time options by running a program on the processor that records the auxiliary registers of the RTT, or by using the debug port with an external host to record the auxiliary registers. Records to the RTT auxiliary registers by the processor (eg, ARC) are qualified by a lock mechanism in one embodiment. Such a locking mechanism ensures that the processor program does not accidentally record in the RTT register. Most run-time options are
It is handled automatically by a debug program residing on the host or external capture device to simplify the interface to the user.

Accordingly, one exemplary embodiment of the present invention
The RTT system contains four main functional units. That is, (i) synthesizable logic blocks integrated into an existing core design, (ii) data capture hardware with a host control interface, (iii) a graphical user interface for configuring the capture session and viewing the results. And (iv) a software driver for interfacing between the capture hardware and the GUI.

Single Processor Configuration Referring to FIG. 1, a first exemplary embodiment of the RTT device of the present invention will be described in detail. The following discussion is basically a single RI
Although made in the concept of an SC-based processor core configuration, many characteristics and attributes are present in other configurations of the device (such as the multi-core example described later in this specification with respect to FIG. 22) and morphology (eg, DSP core). , CISC, etc.).

As shown in FIG. 1, a device 100 generally comprises an RTT unit 102, a processor core unit 105.
-Specific integrated circuit ASIC or field programmable gate array FPGA including memory controller 117 and memory controller 117
Such integrated circuit device 101 (or multiple distributed device) is included. The device 100 includes a debug port / interface 107 and a memory port / interface 11
3 and a packet port 109. The RTT unit 102 is a trace capture unit 140,
It includes various functional units including a monitor unit 142, a generation unit 144, a control unit 146 and a shared buffer 112. Processor state information generally flows directly from the processor core unit 105 to the capture and monitoring units 140, 142 and to the control unit 146 to the action point trigger generator 14.
Indirectly through 8. The auxiliary register read / write operation is directly performed between the processor core unit core 131 and the RTT control unit 146, as shown in FIG. The control unit 146 includes auxiliary registers and state machines used to control the operation of the RTT unit 102. The trace capture unit 140 is
Changes in the form of traces that receive processor state information from the core unit 105 (and any external inputs such as program counters, condition code registers and other processor state information via the external input interface 160). The trace signal 152 that is detected and is input to the RTT monitoring unit 142.
To generate. The monitoring unit 142 dynamically filters the trace information before transmitting it to the generating unit 144. The monitoring unit also generates a trigger and / or enable signal that is communicated to the RTT control unit 146 to implement various functions within the RTT, as described in detail below.

The monitoring unit 142 provides the trace signal 152 to the generation unit 144, which records the trace information by updating internal state information (eg counters) or by generating packets. The packet is generated by the protocol described later and provided to the RTT shared buffer 112. The shared buffer 112 includes a buffer memory of a form well known in the semiconductor industry to allow packets to be captured by the capture device (described in detail below) in the packet port 109 (or, alternatively, an "internal" described in detail below).
"Emission via debug port (using mode operation)
The packet generated by the generation unit 144 is stored until it is “drained”. The overflow interrupt signal is generated by buffer 112 (eg, based on a “high water” mark or other condition present in the buffer) and provided to interrupt controller 133 of core unit 105, where The core 131 pipeline is selectively stopped, or
If not, the behavior of the core is modified to reduce or mitigate buffer overflow conditions.

The instruction trace, data trace and timing trace are individually, statically and dynamically enabled. To be enabled,
These need to be statically enabled and also dynamically enabled. The fourth trace (Miscellaneous) is only statically enabled. Every enable bit, as shown in FIG.
6 is stored. The static enable bits are recorded by the user, and the dynamic enable bits are recorded by the monitor unit 142 or the user.

In either a single configuration or a multiprocessor configuration, the RTT of the present invention uses two storage modes, internal and external. The mode determines how the RTT shared buffer emits, as described in detail below. The storage mode of the RTT is controlled by the user via the user interface or via one or more inputs to the device.

(I) Internal storage mode --with reference to FIG.
A first exemplary embodiment of the invention configured to operate in an "internal" storage mode is described. As shown in FIG. 2, the device 200 is as previously described herein with reference to FIG. 1, and is an integrated circuit such as an ASIC or FPGA that integrates at least one processor core 105 and at least one RTT unit 102. The circuit device 101 is included. Integrated circuit device 101 is located on circuit board 203 (eg, a motherboard or development board), as is well known in the computer industry. The external host 211 drives a debug program (for example, See Code debugger), and the program reads the registers of the processor core 105 and the RTT 102 using the debug port 107 of the device 101 and writes them. In the illustrated embodiment, the host 211 includes a personal or desktop computer, a laptop computer,
Other devices, including handheld devices such as networked minicomputers, or handheld computers or PDAs can also be successfully used. As yet another alternative, the host 211 may be a microprocessor of a well-known form in the art (eg, Intel's Pentium® III or IV series, or AMD's, located on the same board or another board). Other processors or collections of processors, such as K-series devices). Debug port 107
Are effectively provided by the assignee of the present application as a "standard debug port (eg IEEE standard 1149 J
TAG, or parallel port) or any other port configuration provided by the consumer / user. The present invention uses any number of techniques, including standard wiring data paths, wireless interfaces, or even photoconductors, for host 211 and device 10.
Although data transfer between debug ports 107 of 1 can be observed, data communication techniques are well known and therefore will not be described further here.

In the internal storage mode, the device 101
The shared buffer 112 connected to the device is not released in real time, and the packet port connected to the device is not used. Rather, the buffer 112 is released after the trace is captured by the external host 211 reading the RTT register via the debug port 107. In addition, the traced processor core 105 is shared buffer 1
The RTT register can be read to effect the release of packets from 12.

(Ii) External Storage Mode-The external storage mode of the present invention will be described with reference to FIG. In the external storage mode, the shared buffer 112 is ejected in real time to the external capture device 320 via the packet port (unlike the non-real time ejection of the buffer by the host 211 in the internal mode of FIG. 2). There are two basic options for the buffer 112 not being able to emit fast enough to follow the acquisition / recording of new trace information. That is, (i) buffer overflow is tolerated and overflowed data is lost, or (ii) the processor core pipeline passes through the overflow interrupt logic of Figure 1 to reduce the rate of new data generation. Stop. These options are chosen by the user (or designer) to be more appropriate. External capture device 3
20 may be configured to store all traces,
Normally only part of the trace is stored and the initial trace information is discarded when it is no longer needed or appropriate.

As in the internal storage mode of FIG. 2, the external host 211 of the apparatus of FIG. 3 uses the debug port 107 to read / write the processor core and RTT registers. Drive a debugger (eg SeeCode program). The external host 211 communicates with the external capture device 320 to download the captured trace. External host 211 and capture device 3
Communication between the 20 is in the illustrated embodiment an IEEE standard including a network interface card (NIC) in the host 211 for data communication and a corresponding interface adapter (not shown) in the capture device 320.
This is accomplished using 802 "Ethernet" coupling. However, it will be appreciated that a variety of other means of data communication between the host and the capture device may be used, including, for example, wireless LAN according to IEEE standard 802.11a or 802.11b, Bluetooth, or an IrDA interface. Should be. The external capture device 320 is (i) a logic analyzer, or
(ii) Besides the trace capture unit, any number of other devices known to those skilled in the art can be included. The present invention is a single capture device 320.
Although adapted to operate with (eg, a logic analyzer or capture unit), capture device 320 may include multiple devices with more or less functionality, depending on the needs of a particular application. It should be recognized. In one variation, the logic analyzer stores trace data in an internal buffer memory (not shown), performs simple triggering, and does not perform trace data filtering. Conversely, the trace capture unit envisioned by the present invention is a custom-designed unit specially adapted to support the operation of RTT. The trace capture unit uses DRAM buffer memory to store the trace data and can provide arbitrarily complex trigger and filter functions.

The RTT unit of the embodiment shown in FIG.
It is placed in one of the three operation modes of FF, RUN and TRIGGERED. Reset the RTT unit 102
Is turned off. The traced host or processor core writes to an auxiliary register in the RTT unit to change to the RUN state. When a trigger occurs, the RTT unit will transition to the TRIGGERED state. When the RTT is in the external store mode described above, the RTT will generate packets to alert the external capture device (eg analyzer or trace capture unit) of the change in state. O
In the FF state, RTT does not record trace information. Nothing is added to the shared buffer 112, nothing is removed / released from the buffer, and nothing is transmitted to the packet port 109.

An external input signal (or write to a particular programmable register in the RTT) causes the RTT unit 102 to
Switch from FF to RUN. In the RUN state the RTT records trace information for the enabled trace configurations,
Store the packets for the enabled traces in the shared buffer 112. In the internal storage mode, the shared buffer is released on demand to create space for new packets and the dropped packets are discarded. In the external storage mode, the shared buffer 112 is continuously released, and the removed packets are transmitted to the external storage device via the packet port 109.

The trigger is to run the RTT unit 102 from RUN
Switch to TRIGGERED mode. In the illustrated embodiment, the trigger comprises one of (i) an action point trigger event, (ii) a monitor trigger event, (iii) an external input signal event, or (iv) a recorded RTT control register event. . Further, in the present embodiment, all possible trigger sources are commonly logically ORed in order to generate one trigger signal. One trigger fires only once per trace execution. Therefore, the RTT unit 102 must be reset before the execution of another trace is started.

When the RTT unit first enters the TRIGGERED state, the user can control which part of the pre-triggered shared buffer is retained as pre-triggered history. If the user wishes to see the trace before the trigger event occurs (“before the trigger”), the contents of the entire buffer are retained. If the user wishes to see the trace after the trigger event ("after the trigger"), none of the contents of the shared buffer will be retained. If the user wishes to see the trace near the trigger or irregularly (“trigger center”), only a portion (eg half) of the buffer content is retained.

In the TRIGGERED state, the RTT unit records the trace information for the enabled trace configurations and stores the packet in the shared buffer 112. In the internal storage mode, the buffer is not released, and when the buffer is full, the RTT unit 102 switches to the OFF state. In the external storage mode, the buffer is continuously released and the removed packets are transmitted to the external storage device via the packet port 109. However, the user can specify that the RTT unit should transition to the RUN state when the shared buffer overflows even in storage mode. Buffer overflow / operating mode /
It should be appreciated that other combinations of states can be used consistent with the present invention.

The RTT unit 102 of the present invention includes a designer specified number of internal monitors. Each monitor observes the processor core and selects an external signal to dynamically control the trace capture. In the illustrated embodiment, each monitor is individually enabled by the user. The user programs a monitor for each enable having parameters including (i) form, (ii) action, and (iii) condition. The morphological parameter specifies whether the monitor operates as a trigger or a filter. The form of "trigger" changes the operating state of RTT from RUN to TRIGGERED. The "filter" form allows the user to capture only the trace information of interest (see detailed description of filters below).

The action parameter specifies the response of the RTT unit 102 when the monitor is active. The trigger action is to change the operation state from RUN to TRIGGERED. Each monitor has a trigger signal that is used when the monitor is programmed as a trigger. The trigger output signal is transmitted to the RTT trigger facility. The trigger signal is set to "1" mid-week when the condition is true, after which the monitor is enabled.

Each monitor has an enable signal for each trace configuration used when the monitor is programmed as a filter. Filtering is applied to the dynamic trace enable bits of up to three forms of trace, including instruction trace, data trace and timing trace.

One filter is designated as two independent choices in the illustrated embodiment: dynamic trace enable and level / edge response.
Have one of your actions. The four actions are shown in Table 1.

[0052]

[Table 1]

If more than one filter is activated in the opposite operation, the enable is often set to '1'. However, in general, users should avoid programming filters that have conflicting behavior. Care must also be taken with the instruction trace and associated filters, as there is packet cost associated with converting between enabled and unenabled states. Ideally, the dynamic instruction trace enable bits are changed at a slow enough rate to avoid buffer overflow.

The monitor condition parameter specifies the input condition for activating the monitor. The user programs each monitor to observe one condition. The condition parameters of this embodiment are (i) a constant (for example, a 32-bit integer), (ii) a nibble mask (for example, an 8-bit integer), (iii) a source (specifying a value for the constant to be tested), and (iv ) It consists of four elements of the relationship (specify the test form).

Possible sources associated with such a structure include instruction addresses, data addresses, data values, and select external signals. The source of the data address and data value is further specified by the direction of operation (eg load or store) and address space (eg memory or auxiliary register). Possible relationships are greater or equal (≧), lesser
Includes (<), same (=), and different (≠). In the illustrated embodiment, the value is logically ANDed with the nibble mask and compared to the source element using applicable relationships.

When a monitor is used as a level-responsive filter (allow or prevent), once the condition becomes true, it remains true until the monitored value changes to a new value that makes the condition false. Should be noted.

In the illustrated embodiment of the internal monitor, the filters are combined (logically AND'ed) together to produce more complex tests if they are programmed as the same "morphology" and "action" parameters. Calculation)
And can be informative. Any address range is
For example, it can be tested by combining filters with a greater or the same (≧) relationship with filters with a smaller (<) relationship. The data value for a particular data address is tested by combining the filter with the data address and the filter with the data value. Adjacent filters have filter pairs (i = 0,
2, 4, etc., can be combined with i and i + 1). Adjacent filter pairs can be combined into four pairs of filters (i, i + 1, i + 2, i + 3 when i is 0, 4, 8, etc.).

To disable the trace during one function, but not the called function,
A pair of filters are combined. They are programmed with preventive actions, instruction address sources, and address ranges from the first instruction of the function to the last instruction of the function. In order to de-enable tracing and any called function during one function, the present embodiment
Use a filter for function input points and a filter for each function exit point. The input point filter is programmed to the address of the first instruction of the stop action, instruction address source and function. The exit point filter is programmed with a start action, an instruction address source, and an exit point address.

In addition to the internal monitor of RTT 102 previously described herein, the present invention may also be configured such that an external capture device embodies the external monitor. Compared to the internal monitors, these external monitors observe the real-time packet stream emitted from the RTT unit, and the external capture device 320 (see FIG. 3).
Do a filter and trigger action for. External filters do not have any direct effect on the RTT unit 102, they filter packets stored in the memory (eg DRAM) of the external capture device. The external trigger can indirectly affect the operation of the RTT unit 102 by driving a selective external input signal to the RTT.

The external capture device 320, which provides the external monitor, is a relatively complex device. The device must be able to recognize packet boundaries,
It must be possible to decompress the compressed packet stream in real time (described in detail below). In the illustrated embodiment, the packet length is not encoded as a field within the packet, so the external capture device must test each generated packet to determine the length. External capture devices with such capabilities are typically implemented using FPGAs or ASICs, and logic analyzers are generally impractical. However, it should be appreciated that packet length encoding can be used in conjunction with the present invention, reducing the need for such complexity in external capture devices. However, in this case, there is a trade-off between the RTT structure and the increased complexity of the program. Because
There is a need for a mechanism where (i) the packet length is determined and (ii) the determined packet length is encoded on each packet (or a subset of packets).

The trace information of the present invention is selectively compressed when stored in packets. The use of compression is effective in reducing the required buffer size and required trace pin bandwidth. The following compression techniques are described in detail here: (i) variable length encoding, (ii)
Delta-encoding, (iii) run-length coding, and (iv) source-code criteria can be used individually or in conjunction with the trace unit of the invention, as described in detail below, but in other forms. It should be recognized that the trace / packet compression of can also be used in conjunction with the present invention.

(I) Variable length encoding -Variable length incoding uses small codes to represent high frequency values and large codes to represent low frequency values. As used herein, a "small" code is a smaller number of bits than a whole codeword stored for a specified purpose, and a "large" code is a larger number of bits. . Thus, if the codeword size is 8 bits, for example a "small" code may contain 2 bits in one structure and a "large" code may contain 6 or 7 bits. The number of bits required under such a structure of codeword size depends on the number of items represented. Variable length coding is generally similar to the well-known Huffman coding in the prior art, but the RTT code of the present invention is more nibbles than the bits in Huffman coding. The use of variable length coding is
Depends on knowledge of foreseen probability distribution of values. Variable length coding algorithms are generally well known in the data processing arts and are therefore easily applied by the person skilled in the art to the RTT of the invention.

(Ii) Delta Encoding -Delta encoding stores only a portion of the value. This coding refers to a single value that was previously encoded in the trace. Only the reference value and other nibbles are encoded. Delta encoding relies on a value that represents the temporal position of a value (a value that slowly changes over time). To reduce the size of the packet, only the unique or "delta" part of the instruction or data address is recorded in the packet. In particular, the complete address to be encoded is compared with the previously recorded complete address of the same form (instruction or data) to identify the unique part. Of the two addresses, many nibbles have the same value due to the spatial and temporal location of instruction and data access. Only non-zero nibbles are recorded in the packet from the least significant nibble to the most significant nibble. Therefore, the unique part is typically less (potentially much less) than the complete address. The unique part is known as the partial address. Figure 4
Graphically illustrates such a compression methodology.

The recorded address can be full or partial, and the partial address is variable in size, so the address is encoded in the packet with a size field following the address. In the illustrated embodiment, the complete instruction address is 24 bits,
The complete data address is 32 bits long, but other instruction / data address lengths can be used if desired. The value encoded in the packet is the complete address if the size is the same as the size of the complete address, else it is a partial address.

RTT unit 102 of the illustrated embodiment
Has four registers (ie, the oldest address) to store the oldest address for each form of address currently stored in the shared buffer on the chip and the full address of the most recent address. 2 registers for the oldest and the latest instruction address and the other two registers for the oldest data address and the latest data address). The most recent address is used to calculate the unique part for the next recorded address. The oldest address has a complete address that has the same form as the partial address, the trace decoder to determine the complete address of the partial address located in the packet in the buffer that is older than the oldest packet. Used in internal storage mode by (see above). The oldest complete address is updated appropriately because the packet with the address is removed from the buffer.

(Iii) Run Length Encoding -Run Length In Coding (RLE) counts repetitive events and stores the count value of the events instead of storing each event separately. Run-length encoding relies on the execution of the same type of sequential events. In particular, every stream formed of the same data value (a repeat value known as a "run")
It is replaced by an index (count number) and a single value. Such principles are optimally applied to particular data forms in which repeated sequences of data values occur. For example,
RLE is effectively applied to data files containing multiple consecutive occurrences of the same byte pattern. The RLE can be used for any kind of data regardless of its content, but the data compressed by the RLE determines the size of achievable gain (compression ratio). The run-length encoding technique should be easily understood by those skilled in the art and will not be described further here.

(Iv) Source-Code Reference -The source-code reference approach achieves data compression by obviating the storage of information that can be induced by testing the compiled source code. For example, the target address of a processor branch instruction does not need to be stored in the trace because it is encoded in the branch instruction opcode (which can be useful in compiled source code).

The trace data of the present invention is composed of a series of segments. Each segment can be decoded independently. One segment starts with a SEGSTART packet and ends with a SEGEND packet if necessary (see Appendix I and packet protocol discussion below). The SEGSTART packet contains the complete 24-bit address of the first instruction executed within the segment. The first packet in the segment containing the data address uses the full 32-bit address. Recording these complete addresses prevents subsequent partial addresses from referencing addresses prior to the current segment. The SEGSTART packet is preceded by a number of zero nibbles (eg, at least four nibbles in this embodiment) and can be easily located in the trace by the external capture device 320 or trace decoder.

When the segment ends and the counter is non-zero, SEGEND packets are generated with a counter value based on one or more of the following conditions, which are user-defined in the (i) (a) segment: The specified instruction limit is reached (external storage mode only), (b) buffer overflow, (c) timing trace is enabled after being temporarily disabled, (d) by selective external input signal A segment ends and a new segment starts for one or more of the reasons required and / or (e) by recording the control register in the RTT;

(Ii) (a) Instruction trace starts, (b)
The operating state is RUN or TRIGGERED and instruction trace is enabled for the first time or after being temporarily disabled by the filter, and / or (c) the operating state is OFF and converted to RUN or TRIGGERED, A segment starts with one or more of the instruction traces enabled (external store mode only); and / or

(Iii) (a) End of instruction trace, and / or
(b) The operation state is RUN or TRIGGERED, and the instruction trace is switched from enable to non-enable.

In the external storage mode (FIG. 3), if the trace size exceeds the size of the external capture device's enabled memory, the obsolete trace information is discarded. The external capture device 320 discards the start phase of the trace without knowledge or consideration of segment boundaries. This means that the oldest segment in memory mainly misses the SEGSTART packet and is not decoded because it is a delta address encoding. Therefore, in this embodiment, the segments are deliberately made small enough to limit the amount of traces that cannot be used for this reason.

In the internal storage mode (FIG. 2), the old trace information is discarded if the trace size exceeds the size of the shared buffer 112 on the chip. But the SEGSTART packet is not needed in this case,
This is because the RTT stores the oldest complete instruction address and current data address in the buffer. Each complete address is stored in its own auxiliary register, but other storage structures can be used if desired.

The RTT unit 102 of the present invention further includes a 15-bit segment instruction counter (not shown) that is reset to 0 at the start of a new segment and increments each time an instruction is executed. The counter is used to generate an instruction offset within a segment and limit the maximum number of executed instructions for a segment while instruction trace and / or data trace is enabled.

Packet port 10 of RTT unit 102
9 may be dedicated to one internal buffer 112, or alternatively a device with multiple RTTs (see FIG. 2).
It can be shared among multiple internal buffers in (see 2). The bandwidth of the packet port 109 is the buffer 1
12 must be large enough so that it rarely overflows. When the buffer overflows, the user can
Alternatively, the buffer controls whether packet capture is disabled until a certain number (probably 0) of nibbles are allowed to be emitted. In both cases, a new segment starts before packet capture resumes.
The user also controls whether the overflow will generate an interrupt, which interrupts the pipeline of one or more cores associated with the RTT. The user can also clear the buffer by writing to the RTT unit control register.

As described above, the packet related to the RTT of the present invention is composed of one or more nibbles. When packets are emitted from the shared buffer 112 using the packet port 109 (eg external mode), they form a nibble stream. In the exemplary packet port 109 of the embodiment of FIG. 1, the number of pins is 1, 2, 4,
It has 8, 16 or 32 pins. Also, a clock pin synchronized with the packet data is required. It is possible to choose to provide one input signal. The designer selects the appropriate number of pins based on bandwidth and pin count requirements and related considerations.

Packets are generally transmitted in order from the start field to the last field. If one field is larger than one nibble, the lowest nibble is transmitted first (the packet header is in the lowest nibble). One nibble for a packet port (ie 1
Or 2 bits), the least significant bit of the nibble is transmitted first. One zero nibble (all four bits are zero) is driven on packet port 109 during a packet when there is no packet to transmit. Such a technique is known as "padding". No such padding is allowed within a packet. If the packet port is narrower than a single nibble, multiple periods are required to transmit the zero nibble. If the packet port is wider than one nibble, then enough "pad" nibbles are transmitted that all zeros on the packet port are zero.

A sequence of "X" or more pad nibbles (X = 4 in this embodiment) confirms that the following first non-zero nibble is the start of the first packet of the following packet sequence. . In order to make it easier to detect packet boundaries for a particular packet format (eg TRIG and SEGSTART) on packet port 109, some packet formats are optionally prepended with four or more pad nibbles. . But X
It has to be noted that more than one sequence of zero nibbles can naturally occur within one trace packet.
To prevent such a sequence from being mistakenly identified as the beginning of a packet, the RTT unit of the present invention performs nibble stuffing before transmitting the packet on packet port 109. As used herein, the term "nibble stuffing" means assigning a predetermined value to the bits of a nibble. For example, for X = 4, if three consecutive zero nibbles occur in a packet, the RTT outputs three zero nibbles followed by a special nibble of all 1s (for "stacked nibbles" In certain cases).
The external capture device 320 does not remove the stacked nibbles because they are needed by the trace decoder to decode the packet stream. The pad nibbles that follow the four first pad nibbles in the data stream are discarded by the external capture device 320. After any sequence of four or more pad nibbles, the first non-zero nibble is the least significant bit (LS) of the rtt_pkt port 109.
B) Appears on.

The packet port 109 uses the selective rtt_w
It can include an ait input signal. As long as this input signal remains high, RTT unit 102 cannot drive a new value on packet port 109. Packet port 109 may include a start of packet signal for each nibble. These start signals indicate that when their corresponding nibble is the first nibble in the packet,
Asserted. These port start signals are a separate expense (eg 25%) for the pin count value of the packet port.
It is usually not driven off-chip due to the added expense). Instead, they are used by the MTI 204 to allow easy detection of packet boundaries from multiple RTT units (see Figure 2). Table 2 below summarizes these signals.

[0080]

[Table 2]

Referring to FIGS. 5a and 5b, the RT of the present invention
The packet format supported by T is described. Specific packet encodings are discussed later in connection with Appendix I.

In the present embodiment, the packet type is set as the first field in a given packet. The packet format of the present invention is generally divided into two categories based on the frequency of occurrence: (i) frequent and (ii) rare. Frequent packet forms use a nibble to encode these packet forms. Rare packet forms use two nibbles to encode these packet forms. Such an approach reduces costs since more frequently occurring packets need only one nibble.

The frequent packet form of the illustrated embodiment uses one or more specific codes, eg 0000 and 10.
00 is used. Code 0000 is used for padding between packets. Code 1000 specifies the rare packet morphology and the second nibble specifically identifies the rare packet morphology. Some frequent packet forms are encoded in 4 bits or less and the remaining bits are used to encode part of the packet content, or
It can be used for other purposes if desired.
When a packet field occupies more than one nibble, the lowest nibble is stored in the packet first.

The packet form code is shown in FIGS. 5a and 5b.
Illustrated in. The eight columns in each drawing are the bottom three nibbles.
Represents the possible binary values for a bit. The two rows in each figure represent the possible values for the most significant bits of the nibble. RS
V represents a reservation combination. It should be noted that the STALL is located at two sites in Figure 5a. Such a property is beneficial as it allows the two most significant bits of the packet form to be used to encode other information.

As mentioned above, there are four types of trace events captured by the RTT unit of the present invention: (i) instruction trace, (ii) data trace, (iii) timing trace and (iv) miscellaneous trace. To do.
These traces are described in more detail.

(I) Instruction trace -Instruction trace records the value of the program counter (PC) of the core of interest. Non-sequential changes to the PC occur either synchronously with instruction execution (branch, jump, loop, conditional sequential) or asynchronously with instruction execution (zero overhead loop trigger or acceptance of interrupt).

Regarding sync trace, the sync PC encoding varies depending on the form of the instruction. The command format is (1)
It is written using a combination of conditions (for example, conditional / unconditional) and (2) instruction function (for example, sequential / loop / branch / direct jump / indirect jump).

Conditional instructions execute only when they pass the condition code test. Unconditional part instructions have no condition code tests and therefore always execute.
Sequential instructions increase the PC by the size of the instruction (eg 4 or 8 bytes in this embodiment). Branch instructions (for example, Bc
c, BLcc and LPcc) add a signed immediate neighbor offset to the PC value. Loop instruction (eg LPcc) is LP_S
Record in TART and LP_END register, and fail the condition (fai
If l), branch to the first instruction at the end of the loop.
Direct jump instructions (eg Jcc / JLcc to immediate value)
Load the immediate goals into. An indirect jump instruction (eg Jcc / JLcc for a register) loads the PC with the target from the processor core register.

In the illustrated embodiment, to generate a packet, the user selects one of two types of synchronous instruction trace structures: (i) maximum compression and (ii) outer filter. 6a and 6b graphically illustrate each of these two types of structures. It should be noted that in both FIG. 6a and FIG. 6b, the parenthesis values include supplementary symbols for the generated packet morphology.

As shown in FIG. 6a, the maximum compression structure produces only the minimum number of packets needed to record an instruction trace. Based on the evaluation performed by the assignee of the present invention, such a structure is suitable for most applications. The outer filter structure (FIG. 6b) produces a single packet (IA) with the target address for any executed or unconditional branches and jumps. The external filter is generally suitable when the external capture device 320 is used, for example when the external capture device 320 tests packets in real time to determine functional boundaries for external trigger and / or filter applications. It is a structure. However, it must also be recognized that the external filter structure actually increases the required packet port bandwidth to avoid buffer overflows.

When the maximum compression encoding of FIG. 6a is selected for a backward conditional branch instruction, the user selects one of two alternative encoding methods. The first encoding method generates one PF (pass / fail status) packet to record the success / failure (pass / fail) result. The second encoding method includes a multi-bit counter (eg, 4 or 8 bits), but the counter is incremented each time the conditional backward branch instruction succeeds, and its value is each the conditional backward branch instruction fails. Is recorded in the BCBIC (backward conditional branch instruction counter) for the case. The second (ie counter) method provides much better compression than the first method.

The counter structure of this embodiment is based on the assumption that the backward conditional branch's success probability is significantly higher than its failure probability. If the branch is successful, the counter is incremented and no packet is generated. If the branch fails, a BCBIC packet that records the current counter value is generated and the counter is set to zero. Additionally, the following packet types: IA, STF, STV, LD
After A, PF, LPEND, and INT are generated (counter value is 1
If so, the counter is set to 0 (see the discussion of packet morphology below). If the counter overflows, a BCICOV packet will be generated. If the value of the counter is not 0 and the segment ends for one of the following reasons, a SEGEND packet with the counter value is generated and the counter value is cleared to zero, because (a) the segment User-specified command limit is reached, (b) required by a selective external input signal, (c) required by recording in a control register in the RTT, and / or d) selective. This is because the active state is RUN or TRIGGERED and the instruction trace is switched from enabled to unenabled.

For asynchronous instruction tracing, the encoding of asynchronous PC changes depends on the form of the event.

The instruction trace of the present invention further includes a zero overhead loop mechanism. In particular, the loop mechanism is triggered when the PC reaches the last instruction in a zero overhead loop (LP_END-1). For example, LP_CO
If the UNT register is not 1, then PC is not loaded via the LP_START register, otherwise PC is incremented. If the last instruction in the loop is a branch or jump instruction, the loading of the PC by the loop mechanism only affects the selection of delay slot instructions for the branch or jump.

The RTT records the result of the zero overhead loop trigger by processing with a conditional branch instruction to LP_START. The loop trigger is not used to enter the function, so the maximum compression structure is used. Any generated packet is located in the trace after any packet generated by the last instruction in the loop.

The trace decoder uses LP_START and LP_E
If the value of ND is recorded in the current segment by a loop instruction or SR instruction, the value will be known. If the trace decoder does not know the values of LP_START and LP_END and a zero overhead loop is used, the RTT will record the values of LP_START and LP_END, and the RTT will follow the LPEND packet to record them.
Generate a packet.

Each time the interrupt is used, the RTT generates an interrupt (INT) packet. Such a packet records the current PC value and the new PC value. In the illustrated embodiment, even if a new PC value is stored /
The new PC value is stored in the interrupt vector table, even if it comes to the knowledge that the other mechanisms provided can be used in conjunction with the present invention.

(Ii) Data Trace : The data trace of the RTT unit of the present invention captures data values and data addresses for loading and storing instructions. The user independently selects whether load data, load address, storage address and storage address capture are enabled or not enabled. Also, the user independently selects the address space (memory and auxiliary register) to be activated for capture.

The load address (LDA) packet is a load instruction (LDB, LDW, LD, LR) when the load instruction is executed.
Generated for. The load data (LDD) packet is
It is generated when the data is recorded again in the register file. Fixed data size store (STF) or variable data size store (STV) packets are generated for memory store instructions (STB, STW, ST, SR) when the store instructions are executed. If SR is a USER register, a USER packet will be generated instead of an STF packet. USER, LP_STAR
The data trace for T or LP_END register is
Always enabled; static and dynamic data trace enable values are ignored.

If data filtering (as described earlier in this specification) is used, only part of the load / store instructions can be recorded. In particular, if there is at least one enable filter with an action parameter set to perform a data trace and a source parameter set to a "data address" or a "data value", the trace decoder is present. Cannot determine the captured load / store PC even if instruction trace is enabled. If data filtering and instruction tracing are enabled, additional information confirms their PC value by being added to the STF / STV / LDA packets. In external store mode, this is accomplished by recording the value of the segment instruction counter. In internal storage mode, the segment counter cannot be used as a reference because the segment counter is not used. Therefore, the instruction count from the oldest instruction entry in the buffer is used instead.

(Iii) Timing Trace- The RTT unit 102 of the present invention favorably supports recording of fine-grained timing. Fine-grained timing traces are enabled so that the trace decoder can detect the cycle in which each instruction is issued and the events synchronized with instruction execution.
You can determine the cycle at which (including returning the load data) occurs.

External capture device 320 (FIG. 3)
Supports coarse-grained timing recording, so the device is only supported in external capture mode. The general timing allows the trace decoder to determine the period in which each packet was sent on the packet port. The external capture device records the period associated with each packet as it appears on the packet port. In the exemplary embodiment, this has a strong correlation with the period in which the packet was generated.

The RTT supports the fine timing described above by generation of an additional packet form and EL combination of timing information and timing stamping. Enabling fine timing increases the amount of packets generated. The timing information generated when fine timing is enabled is used by the trace decoder when instructions are dispatched, load data is recorded in the register file, and when synchronous events occur in instruction execution. Be able to determine the cycle.

When the fine timing is statically switched from non-enabled to statically enabled, 16-bit time-
The stamp is deleted. In this embodiment, the time-stamp is incremented every period in which fine timing is statically enabled. The time stamp is stored in the SEGSTART packet and the packet generated to record the event synchronized with the instruction execution (described above). time
-When a stamp overflows, a Time-Stamp Overflow (TSOV) packet is generated; see FIG.

When fine timing is enabled and instruction trace is enabled, the RTT unit
Generate TALL and SICOV packets. The STALL packet is generated in each cycle in which the traced processor core (105) cannot issue an instruction. Of the exemplary embodiment
A STALL packet may be 4-, even if it becomes aware that other STALL packet structures and protocols may be used.
Includes bit period count, 4-bit instruction count, and optionally stall reason. The 4-bit period count of the STALL packet is calculated by the processor coder (10
5) includes the number of consecutive cycles that stop. The 4-bit instruction count includes the number of instructions issued since the last packet generated by the instruction or data trace was generated. If the instruction counter overflows, a SICOV packet is generated. The instruction count will be present in the Load Data (LDD) packet described earlier in this specification. Such instruction count information in the LDD packet allows the trace data to determine the period at which the load data was recorded in the register file when instruction trace is enabled. For this reason, instruction trace is optionally enabled when data trace is enabled.

(Iv) Miscellaneous Traces- EXTSIG packets are generated when one or more signals outside the RTT change value.
The designer limits what signals are monitored. In the USER packet, the program is the RTT unit 102.
It is generated when executing the SR instruction for the USER auxiliary register in. The recorded value is stored in the USER packet. Such a packet is sent by the processor coder (1
05) Allow the program running above to place a marker in the trace.

The APE packet indicates that an action point has occurred.

The next enable function is controlled by the programmable registers associated with the RTT unit 102 of the exemplary embodiment; the function determines what form of trace information is potentially captured. Allow user control: (i) instruction trace (exclude interrupts); (ii) interrupts; (iii) load data;
(iv) Stored data; (v) Load address; (vi) Stored address;
(vii) memory or auxiliary register or both address spaces; (vii
i) fine timing; (ix) time-stamping; (x) recording of selective external signal changes; and (xi) recording of action point events.

Appendix I now provides a more detailed description of an exemplary embodiment of packets associated with the RTT of the present invention. The packet of the present invention includes only one row for each possible field in the packet, and the field size ("b" designations represent bits and "n" designations represent nibbles). Instead, it is described in Appendix I using a tabular format containing one column that describes the name / function of the field. The fields in such a tabular format are cataloged sequentially from the first (first) nibble to the last nibble. If the nibble of a packet contains various fields, the fields are cataloged in order from least significant bit to most significant bit. Bit 0 is the least significant bit for purposes of this description. The nibble boundaries are represented by expanded row (horizontal) lines in each table. If the nibble is only partially used, the unused bits are treated as preliminary and encoded with zero.

Bits can also be used to indicate whether there is a "next size" field in the packet. If not present, the size is selected as the default value (depending on the size morphology). The default instruction address size for the exemplary embodiments described herein is 2 nibbles. Similarly, the default data address size is 1 nibble and the size of the default data value is 1 nibble, even if other values can be used instead. The size field located after the “next size” field in the packet is set by the user for some packets.
(For example, for STF packets, the Data Address Size field). In this case, the "next size field present" flag refers to whatever size field comes next. In some cases this does not exist at all. This packet size is coded as a smaller number of nibbles in one embodiment. This is a 3-bit size field from 1 to 8
Allows you to specify nibbles.

The STF, STV, and LDA packets may further include a segment instruction count field.
In an exemplary embodiment, such a field may be (i) a complete 15-bit segment instruction count value, or (ii)
Encoded as one of the 3-bit differences (always positive) between the current instruction segment count and the last encoded segment instruction count. One bit flag included in the packet specifies what encoding method was used. The full value is encoded at the first moment the segment instruction count is encoded in the segment.

Other Embodiments Referring to FIG. 7, a second exemplary embodiment of the present invention is described in detail. Such a second embodiment has a number of features in common with the previously described embodiments of Figures 1 to 6b, and also incorporates additional features and improvements. The following discussion details these additional features and improvements. However, the desired features from the two embodiments (and substantially other embodiments) are readily apparent to one of ordinary skill in the art from the tailor made embodiments of the RTT invention, given the disclosure provided herein. It will be appreciated that it can be merged.
Therefore, the embodiments of FIGS. 1 and 7 are merely illustrative of the many possible permutations to the features and attributes of the present invention that have been expanded.

In the embodiment shown in FIG. 7, the RTT unit (70
2) is (i) instruction trace, (ii) data trace, (iii)
4 types of trace information including an event trace and (iv) timing trace are provided. As described below, the "event" trace of this embodiment records selected core state changes that are unrelated to instruction execution. Also,
Timing traces are divided into two components, such as instruction timing traces and event timing traces. The instruction timing trace records the cycle of instruction execution. The event timing trace records the cycle of the event.

RTT (702) produces a trace in which any legal code sequence (SR excluded for LOOPEND and zero-cost loop limm) is captured.

Also, a program that loads an interrupt vector table with a store instruction, such as under the category of self-modifying code, is a code where the first instruction of each vector entry is located in the compiled source code. Assisted in case of an unconditional direct jump to.

With the RTT of FIG. 7, the size and content of each packet can advantageously be determined without access to the compiled source code.

Like the RTT of FIG. 1 described above, the RTT of FIG.
(702) has many choices such as some settings at build-time and other settings at run-time. The designer sets the configuration time choices by editing the constants in the RTL source and setting the configuration during configuration. The user sets the run-time selections by running the program on the core that records in the RTT auxiliary registers or by using the debug port with an external host that records in the RTT auxiliary registers. Recording to the RTT auxiliary register via the core is further authorized via the locking mechanism (RTT_LOCK register) as described above, but it can also be prevented entirely (NAW bit in the RTT_HOST_CTL register). ). Locking reduces the probability that the core program will erroneously record in the RTT register. Most run-time choices are debugs to simplify the interface to the user (eg SeeCode debugs described above)
Automatically processed by.

In operation, if the RTT trace buffer cannot be drained fast enough to subsequently keep a record of new trace information, the buffer will overflow. RTT can be configured to interrupt the core when the buffer overflows (RTT_BUF_CTL register I / O bit). Full trace mode can be selected (RTT_EN_DI) to completely prevent the buffer from overflowing and to ensure that every instruction is traced.
FT bit of S_CTL register). In full trace mode, the core stalls to prevent buffer overflows.

In addition, the embodiment of FIG.
latten) "unit (770). The flatten unit (770) observes the processor and determines when instruction, interrupt, loop trigger and load data events occur.
The details will be described below.

The packet port of the present invention transmits a packet (signal rtt_pkt_data) to the storage device. If the buffer overflows, the interrupt is selectively transmitted to the core.

In operation, when a hardware reset occurs, RTT (702) is set to be non-enabled, ie, set to the non-triggered state and its buffer is cleared. . Only when RTT is enabled, the generation unit (744) records the trace information and the monitor unit (742) monitors the trigger. The buffer (712) discharges the packet in the buffer to the packet port. When RTT transitions from the non-enabled state to the enabled state, the buffer is erased,
The trigger is cleared (unless set at the same moment when RTT is enabled) and any internal state of the generation unit (744) used to record the trace information is cleared. When a trigger occurs, the RTT records the trigger in the output packet stream so that the capture device (722) can change its behavior when the trigger occurs. If the capture device detects a trigger from the RTT, post-trigger (post-trigge
r), the minimum mode is RTT_DIS_CT
It can be enabled by setting the MM bit in the L register to 1. In minimal mode, the RTT will generate packets at a very low rate when it is not triggered and then normally when it is triggered. This mode effectively guarantees that the buffer will not overflow before the trigger occurs.

The EN bit of the RTT_STAT auxiliary register is
Indicates whether is currently enabled. RTT is
It is enabled or disabled by the core or host recording the appropriate instruction in the RTT_CMD register, or by the rtt_en_on and rtt_en_off input signals turning from 0 to 1. The monitor can also disable RTT when a programmed situation occurs.

The TR bit of the RTT_STAT auxiliary register is RTT
Indicates whether is currently triggered. RTT is, for example, (a) a core or host that records an appropriate instruction in the RTT_CMD register, (b) a monitor that detects the trigger status, (c) an action point trigger, or (d) an rtt_trig_on input signal that changes from 0 to 1. Triggered by.

If full trace is not enabled, RTT will
It brakes the capture of trace information and the buffer has a programmable empty value.
Resume when the ess value) is reached. The OV bit of the RTT_STAT auxiliary register indicates whether the buffer is in an overflow condition. If full tracing is enabled, RTT stalls the core pipeline to prevent buffer overflow. this is,
It may not be desirable for some applications.

The RTT of this embodiment (FIG. 7) also includes a certain number of internal monitors. Each monitor dynamically controls the trace capture and observes the trace information from the Flatton unit (770) to detect the trigger. The monitor consists of triggers, filters, or both. The filter allows the user to reduce the amount of trace information captured by tracing the executing program portion instead of the entire program.

Each monitor is programmed with a dynamic enable mask, sources, correlations, actions and triggers. The monitor is programmed when RTT is de-enabled. Hereinafter, such features will be described in more detail.

When the monitor performs a filtering operation, it uses a dynamic enable mask that specifies what dynamic enable is affected by the filter. There is one bit for each dynamic enable including instruction trace dynamic enable; instruction timing trace dynamic enable; data trace dynamic enable. If the instruction timing trace dynamic enable and the data trace dynamic enable are “1”, the instruction trace dynamic enable is “1”.
Is forced to become. If any filter is configured to affect the data trace, data filtering is activated. When the data filtering is activated, the RTT should be configured to include the segment command offset in the DATA packet. This is what the trace decoder program loaded / loaded
It is done so that it can be decided whether the storage is associated with a DATA packet.

The user should be aware of the filters associated with the instruction trace and instruction timing trace as packets will be generated when enabled. In particular, the SEGSTART packet is generated each time the instruction trace is enabled, the ITTDEN packet is generated each time the instruction timing trace dynamic enable changes value, and the STALL packet is flushed the stall period counter. Generated when the instruction timing trace dynamic enable is de-enabled, if needed. SEGSTART packets are much larger than ITTDEN packets and therefore SE
GSTART packets will have a major negative impact on buffer overflow.

The monitor source of this embodiment includes an instruction address, a data address and a data value (ST, SR, LR instructions only). Data addresses and data values are further specified in direction (load, store, and / or) and address space (memory, auxiliary registers, and / or one).

As in the embodiment of FIG. 1, the allowed monitor relationships are as follows: greater than or equal (≧), less than (<), the same (=) and different (≠). The relationship compares the source value to the 32-bit programmable value associated with each monitor. However, the monitor action in this embodiment includes the contents of Table 3.

[0131]

[Table 3]

Each monitor provides start, brake, allow and prevent signals for each dynamic enable. If various monitors require reciprocal motion (start / stop or allow / prevent),
The monitor with the lowest index is dominant
(The monitors are numbered from zero to the number of monitors less than or equal to 1 in this embodiment, although it will be appreciated that other schemes can be easily substituted).

If the allow / prevent action is activated, this action ignores the current value of the dynamic enable. When the allow / prevent operation is deactivated, the value of the dynamic enable returns to the value that existed before the allow / prevent was activated.

Each monitor can also be configured as a trigger. The RTT is triggered when the "trigger" condition associated with the monitor is true. Figure 1
Like the embodiments of the above, the situations of the monitors in this embodiment can be combined together (logical AND) to generate more complex tests. Either each pair (index 2n and 2n + 1) is selectively combined, or each quad (index 4n, 4n + 1, 4n + 2 and 4n + 3) is selectively combined. You can When monitors are combined, the condition for each monitor is true only if all other monitors in the pair or quad are also true. All other monitors in a pair or quad have unique actions and trigger the same programmed field. The source and related fields may be different from each other.

Any address range can be tested by combining one monitor with a "greater than or equal" relationship with a second monitor with a "less than" relationship. The data value for a particular data address is tested by combining the monitor with the data address and the monitor with the data value. Other test methods can also be used.

Monitor pairs are combined to deactivate traces in the middle of a function (but do not deactivate the called function). The monitor is programmed in the address range from the address of the first instruction to the last instruction in the function in preventive action, instruction address source and function.

To deactivate tracing mid-function (and to deactivate any function it calls), monitor is used for the function entry point and monitor is for each function exit point. To use. The entry point filter is programmed with the address of the first command in braking operation, command address source and function. The exit point monitor is programmed with a start action, an instruction address source, and an exit point address.

Under the data encoding, the RTT module 702 of this embodiment stores two (4) addresses in order to store all addresses of the most recently encoded address among the addresses (command and data) of each format. Register). These addresses are used to calculate the unique part for the next recorded address.

As before, the trace is organized as a segment with each segment independently decoded. A segment starts with a SEGSTART packet and ends with the next SEGSTART packet. Typically,
The SEGSTART packet is the complete two instructions that are executed or interrupted first in the segment.
Contains a 4-bit address. The exception is the SEGSTART packet generated when RTT is deenabled. This SE
The GSTART packet contains the next instruction address in the pipeline (not yet executed or interrupted).

First in segment containing data address
Packet is a complete data address (other determinants can be used, but in this case, the extension (e
xtutil) use the size specified by the ext_a_width parameter in the RTL source file. Due to the recording of these complete addresses, the subsequent partial addresses do not reference the addresses before the current segment. This SEGSTA
The RT packet can be easily located in one trace by an external capture device or trace decoder by leading it by at least four zero nibbles.

SEGSTART is generated by RTT under the following conditions: (i) A segment specified by the user is reached in the segment (RTT_SEG_CTL.SEGMAX); (ii) Buffer overflow is cleared; ( iii) It is requested by a selective external input signal (rtt_new_seg); (iv) It is requested by recording in the CMD_NS instruction RTT_CMD register; (v) RTT is triggered; (vi) RTT is De-enabled; (vii) instruction trace begins; (viii) RTT
Is enabled and is enabled after the instruction trace is started or temporarily de-enabled by the filter; or (ix) RTT is enabled and the instruction trace is also enabled.

In this embodiment, SEGSTART generated for all cases (excluded when RTT is not enabled)
Cannot start with the instruction located in the delay slot. The start of the segment is the first not in the delay slot
Is delayed until the instruction is executed or the instruction is interrupted. The SEGSTART generated when RTT 702 is de-enabled has no restrictions on delay slots.

The storage device generally discards existing trace information if the trace size exceeds its storage capacity size. The storage device is unaware of the segment boundaries and discards the start of the trace. This means that the oldest segment in memory usually misses its SEGSTART packet and cannot be decoded. The user configures the RTT so that the segment is small enough to limit the size of non-enabled traces. However, it goes without saying that a system in which segment boundaries are determined and taken into consideration can also be implemented in conjunction with the present invention.

The RTT of this embodiment also includes a 15-bit segment instruction offset counter, which is reset to zero when a new segment is started and incremented each time an instruction is executed. . The counter is used to generate the instruction offset in the segment and to limit the maximum number of executed instructions taken by the segment while instruction trace and / or data trace is being enabled.

The packet port protocol of the embodiment of FIG. 7 will be described in detail.

As described above, the packet port 709
Are used to drain the packet buffer 712. The bandwidth of the packet port 709 should be large enough so that the buffers almost never overflow. When the buffer is overflowed, packet capture will give the buffer a certain number of free nibbles.
It is temporarily delayed while allowed to be discharged (may be zero). The new segment begins before packet capture resumes. The user controls whether the overflow causes an interrupt to the core. The user can erase the buffer by recording the CMD_CB instruction in the RTT_CMD register.

The packet port width for this embodiment is
It is 32 bits. However, packet port widths of 4, 8, and 16 or other numbers of bits can be used. The designer selects an appropriate number of bits based on considerations of bandwidth and pin count value. Packet data is RT
The T output signal is transmitted to rtt_pkt_data. This signal is 32 bits in size but has a port width of 3
If less than 2 bits, every bit is used.
The bits not used in this embodiment are the most significant bits.

The packet port protocol of this embodiment is designed such that there will never be a predetermined number of "X" (eg, 4) or more consecutive zero nibble sequences within the packet. If the trace decoder finds 4 or more consecutive zero nibbles,
It will know that the next non-zero nibble is the start of a new packet. To allow the start of a SEGSTART packet to be detected, even if the packet boundaries are unknown, the SEGSTART packet is
Prefix with at least 4 zero nibbles.

In order to prevent 4 or more consecutive zero nibble sequences appearing in a packet,
So-called "nibble stuffing" is performed as described herein above. In particular, every time there are three consecutive zero nibbles in the packet, RT
T adds one or more nibbles after the three zeros. The last nibble added has a value of 0xf, and any other nibble added before it is 0x8.
Has a value of. The trace storage device does not remove stuck nibbles, but rather the trace decoder program removes them.

The packet port 772 of this embodiment is rt
Supports a port stop input signal called t_pkt_hold. As long as this signal is high, RTT702
Unable to drive new value on packet port 709. The packet port also contains a start of packet signal for each nibble called rtt_pkt_start. These signals are asserted when their corresponding nibble is the first nibble in the packet. The start of such a port signal is typically not carried off-chip due to the additional overhead in packet port pin count (eg, 25%). Instead, they use M to easily detect packet boundaries from various RTTs.
Used by ATI (discussed below in connection with FIG. 22).

Tables 4 and 5 provide exemplary packet form codes for the packet forms used in this embodiment.

[0152]

[Table 4]

[0153]

[Table 5]

Appendix II provides additional details on such packets. For Appendix II, the complete instruction address is a 24-bit length-word address. The size of full data address is ext_a_width in ext_util RTL source file (minimum 32 bits)
It is specified by the parameter. The data address is a byte address. The common scheme is to represent when there is a next sized field in the packet:
Is to use a bit. If it doesn't exist,
The size is a default value according to the size form. The size of the default instruction address is 2 nibbles, the size of the default data address is 1 nibble, and the size of the default data value is 1 nibble. The size field located in the packet after the next size field may depend on the user set for some packets (eg, the size of the data address for DATA packets). In this case, the next size field present flag indicates what size field is next. In some cases, other size fields may not be present at all and the flag should be ignored. The size is typically encoded as the number of nibbles less than one. This allows the 3-bit size field to specify a size of 1-8 nibbles. The DATA packet may include a segment command offset field. This field is encoded either as a maximum 15-bit segment instruction offset value or a 3-bit difference between the current instruction segment offset and the last encoded segment instruction offset (always positive). The 1-bit flag in the packet specifies what encoding method was used (1 is the same as the 3-bit value and 0 is the same as the 15-bit value). SEGSTART
The packet generation sets the segment instruction offset to zero. The SRSPEC packet contains a segment command offset field. It is encoded as a complete 15-bit value.

As mentioned above, there are four forms of trace events captured by the RTT of the embodiment of FIG. 7 as follows: 1) instruction trace, 2) data trace, 3) event trace, and 4). Timing trace.

For synchronous instruction tracing, this embodiment takes advantage of the fact that conditional instructions have a "Q" field within them, which is "alway".
Set to any value except s "(0x00). Unconditional instructions have no Q field in the instruction,
It optionally has a Q field, but is set to the value for "always". The extension instructions use the least significant 5 bits of the instruction in stage 3, the non-standard coding of the xshimm signal, to inform the core pipeline that such instructions are not conditional. The RTT considers every extension instruction to have a Q field by ignoring the xshimm signal (unless they use short proximity data).

There are two synchronous instruction compression modes, high and low. The LCM bit of the RTT_PKT_CTL register controls what mode is activated. These two compression modes are generally similar to the maximum / minimum modes described earlier herein with respect to the embodiment of Figure 1 (see discussion regarding Figures 5a and 5b).

Similar to the embodiment of FIG. 1, if high-compression encoding is selected for the backward conditional branch instruction, then the UPC bit of the RTT_PKT_CTL register in the embodiment of FIG. Select one of the encoding methods (ie, the multi-bit counter recorded in the PF packet or BCBPC packet). Similar to the embodiment of FIG. 1, the counter method provides significantly better compression by using PF packets. In this embodiment, the counter is IA, PF, DATA, SRSPEC, LPPC, LP.
After a PCOV, LPTRIG, or STALL packet is generated,
Set to zero. If the counter overflows, a BCBPCOV packet is generated.

If the counter is not zero and the segment ends, the counter value is recorded in the next SEGSTART packet and reset to zero. If an INT packet is generated to record the interrupt,
The counter value is recorded in the INT packet and reset to zero.

In this embodiment, the loop mechanism is triggered when PC + 4 reaches the last instruction in the zero overhead loop (LP_END). If the last instruction in the loop is a branch or jump instruction that was used, the loading of the PC by the loop mechanism only affects the selection of delay slot instructions for the branch or jump, and the PC uses the branch or jump used. It is set as the target of the jump instruction.

If the loop fails, an LPPC packet recording the counter value is generated and the counter is set to zero. The counters are IA, PF, DATA, SR
Set to zero after a SPEC, BCBPC, BCBPCOV, LPTRIG, or STALL packet is generated. If the counter overflows, an LPPCOV packet is generated.

The trace decoder uses LP_START and LP_E
If the value of ND is currently recorded in the segment by a loop or SR instruction, we know those values. If the trace decoder does not know the values of LP_START and LP_END and a zero overhead loop is used, the RTT will generate an LPTRIG packet to record those values.

In the embodiment of FIG. 7, it is assumed that the first instruction executed after the interrupt or the first instruction in the segment is executed.
If the instruction is an unconditional jump, the first instruction is recorded using an IA packet. This is done to aid the decoder if the compiled source code contains no instructions in the interrupt vector table (ie self-modifying code). The decoder assumes that the first instruction executed in the table is an unconditional direct jump to the interrupt coordinator, but the interrupt coordinator is located in the compiled source code. If the program does not follow such rules, it should provide the interrupt vector table in the compiled source code.

For date trace, when a memory load instruction (LDB, LDW, LD) is executed, a DATA packet is generated to record the data address (if data address capture is enabled). When the delayed load data is recorded again in the register file, a DLDD packet is generated to record the data value (if data value capture is enabled).

When the load auxiliary register instruction (LR) or the store memory instruction (STB, STW, ST) is executed, the DATA packet is generated to potentially record the data address and the data value.

When the store auxiliary register instruction (SR) is executed, the RTT confirms the address to determine the packet form. If the address is for a particular register then an SRSPEC packet is generated, otherwise
SR is processed like an ST instruction. Specific register is RTT
_USER, RTT_PKT_CTL, LPSTART and LPEND. RTT
An SR to the _USER or RTT_PKT_CTL register will generate an SRSPEC packet regardless of static and dynamic enable. An SR to the LPSTART or LPEND register will generate an SRSPEC packet if instruction trace is enabled.

If data filtering is used, only part of the load / store can be recorded. In particular, if there is at least one enabled filter with the behavior set to affect the data traces, the trace decoder will not be able to load the captured load / store PC even if instruction traces are enabled. Can't decide. If data filtering is activated, the user configures the RTT to add the segment command offset to the DATA packet.

Event traces record core state changes unrelated to instruction execution.

In this embodiment, the timing trace is composed of (a) instruction timing trace and (b) event timing trace. The instruction timing trace allows the trace decoder to determine the period when each executed instruction is evicted (the period at which the end of the core pipeline is reached) and the delayed load-data recording period to the register file. Become. Event timing tracing allows the trace decoder to determine the period at which asynchronous events occur in instruction execution. For such an asynchronous event, (1)
Action point trigger, (2) External signal change, (3)
There are interrupts taken and (4) new segments. Instruction timing and event timing may be individually enabled statically in the RTT_PKT_CTL register. Also, command timing is controlled by a dynamic enable from the monitor facility.

RTT supports timing tracing by two types of mechanisms: time stamps and timing packets. Instruction timing trace uses both mechanisms, while event timing trace uses only the timestamp mechanism.

(I) Timestamp -When instruction timing is statically enabled or event timing is statically enabled, the time stamping mechanism is
It will be enabled. When time stamping is enabled, the 15-bit time stamp register is erased. The time stamp is incremented each time time stamping is enabled. If time stamping is enabled, the time stamp is APE, E
Stored in XTSIG, INT, SEGSTART and SRSPECRTT_PKT_CTL packets. When the time stamp is overflowed, a TSOV packet is generated unless a packet containing the time stamp is generated in the same cycle. In the latter case, the packet containing the tie stamp will contain the timestamp-overflowed bits, but
The bit is set to 1.

(Ii) Timing Packets -When instruction timing trace and instruction trace are enabled (two traces are statically and dynamically enabled), RTT uses a 4-bit stall period counter. Counts the stall period between evicted instructions.
RTT is set when the stall cycle counter overflows, that is, when the instruction timing trace is disabled (d
isable) and the counter needs to be flushed, it outputs a STALL packet containing the stall period counter value in the period before the arrival of the next evicted instruction. Generation of STALL packets is prevented if INT or SEGSTART packets are generated in the same cycle to reduce hardware cost. The stall period counter value is lost, but the timestamp values in the INT and SEGSTART packets provide equivalent information.

The STALL packet of this embodiment is configured to include a 4-bit stall count, and the trace decoder determines that the PC (that is, INT, DATA, PF, IA, BCBPC, B).
CBPCOV, LPPC, LPPCOV, SRSPEC, SEGSTART, LPTRIG and
STALL), and optionally includes a 4-bit stall reason, as the increasing last packet was generated for each evicted instruction. The stop instruction count is the number of instructions that have been evicted. The exact instruction that causes the stall to be performed by this field will be able to be determined, even if every instruction that was evicted does not generate a packet. By the stop instruction counter,
The trace decoder can determine the PC and is reset to zero after any packet is generated. A SICOV packet is generated every time the instruction counter overflows.

There are many incidents that can cause stalls, which include (a) vegetative delay (eg I
-Cash loss); (b) Load used; (c) Load return
(For example, use only 3 port register files); (d) Load / store queue full; (e) Multi-cycle instruction; (f)
Dependencies (eg non-shortening registers, conditional jumps /
(PELLEKE set followed by a branch); (g) Interrupt;
(h) long-proximity data; (i) killed delay-slot command; (j) extended command stop with xholdup12 or xholdup123 signal; (k) brake command or action point trigger; or (l) single. Includes the processor in one-step or instruction-step mode. As an instruction moves into the core pipeline, it encounters various stall reasons. Recording a stall count and a complete history of stall reasons for each instruction is often very large. The 4-bit stall reason field of the present embodiment captures the following possible stall reasons: (a) Beth stall (invalid = 0); (b) Load-use stall; (c) Load-return stall; And (d) load / store matrix full stall (in use by memory controller,
Or full scoreboard). If the instruction had its stall performed, each reason would be allocated one bit as long as it was set to one. If the instruction was stalled, but did not meet any of these reasons, the stall reason field will be zero.

The four stall reasons mentioned above were chosen because they offer a solution for reducing stalls. Especially for Betisutols, increase the I-cache size. For load-use stalls, increase the D-cache size or add instructions between load and use. For load-return stop, use 4-port register file. Increase memory bandwidth for load / store queue full stalls. However, it will be appreciated that other stall parameters and bit numbers can be used in conjunction with the present invention, and the scheme described above is merely exemplary.

The DLDD packet contains a stall instruction count value and a stall period count value when instruction-timing trace is statically enabled. These values are
Only meaningful when instruction timing and instruction timing trace are enabled (both static and dynamic). Such an additional value of the DLDD packet allows the trace decoder to determine the recording cycle of the load data in the register file.

Appendix III provides R related to embodiments of the present invention.
The TT extension auxiliary register will be described in detail.

Description of Buffer and Packet Pipeline The configuration and operation of the above-mentioned buffer unit 712 will be described in more detail.

The primary purpose of buffer 712 is to provide short-term and intermediate-term flexibility in the ability to transmit packets from generation unit 744 to external capture device 772. When performing a trace capture, packets are only generated when a particular instruction is encountered, and then the monitor is only generated when it allows it. This can cause very non-uniform variations in the amount of data generated over time. The width of data that can be simultaneously generated by the generation unit is the width of the capture device port (minimum 1 nibble)
Very large compared to (eg, approximately 70 nibbles maximum in the exemplary single-core embodiment described above). this is,
Overflow can occur frequently if no buffers are installed to make the data stream smooth (thus losing trace information)
Means

The buffer 712 of the exemplary embodiment is divided into two parts: (i) a packet pipeline; and (ii) a FIFO. The packet pipeline section is register-based and is used to buffer a short duration data bust from the generation unit. The FIFO unit is based on RAM and buffers the intermediate period data bust from the packet pipeline.

The buffer 712 provides the following functions and features; (i) the ability to accommodate the maximum output from the generation unit in a short time; (ii) the high bandwidth to generate the code part in a long time. Ability to accommodate; (iii) Configuration ability to allow the exchange of gate count (and thus IC cost) and buffering ability; and (iv) Simple conversion to a descriptive language (eg, Verilog) using a translation tool.

The packet pipeline of buffer 712 buffers the output from generation unit 744 and effectively "funnels down" the output to the width of the FIFO.
This is achieved in the illustrated embodiment with a relatively large register array, the width and depth of which are made configurable at the device configuration instant.

With the full data and timing trace configurations selected, the output from the generation unit 744 is approximately 70 nibbles wide in the illustrated embodiment. Such outputs are classified into the following four packet types: (1) segment start, (2) instruction execution, (3) loop trigger, and (4) delayed load data.

It is possible (though not desirable) for a total of four packet categories to be generated in one clock period. When a packet is generated, the packet itself, the size of the packet, and the “new” flag are output from the generation unit 744. If one or more packets are generated at the same time, the packets are input to the packet pipeline in the specified order. That is, the segment start is input first, then the instruction execution is input, then the loop trigger is input, and the delayed load data is finally input.

Each packet may be wide (up to 23 nibbles in the illustrated embodiment) or relatively narrow (4 nibbles or less) to maximize resource use and to allow packet pipeline array The registers (described below) are
It is grouped into the eight nibble blocks referred to herein as the packet part. Also, along with the 32-bit data, the packet portion includes information regarding the number of effective nibbles in the packet portion and controls information regarding packet boundaries.

As shown in FIG. 8a, the first embodiment of the packet pipeline 800 of the present invention comprises a packet part array 802. The number of rows 804 and columns 806 are advantageously made configurable by the user at the device configuration instant.

The control logic maintains a pointer in the first row 807 to determine which of the columns 806 should receive the next packet portion from the production unit. Also, pointers are maintained in the output rows to determine from which column to extract the data. The pointer in this embodiment changes sequentially, wrapping when the pointer reaches the last column, even though other approaches can be used instead.

When it is displayed in the next row but the portion in the same column is vacant, that is, the data is FI from the row.
When being sent to the FO, the effective part flows to the packet pipeline 800.

The minimum width of the packet pipeline is (i) FIF
Greater than O width, or (ii) created with a maximum width of a single packet. The width of the maximum packet pipeline is the same as the maximum width of any packet category with which it was created. The depth can vary from one row to any size (eg 32), but the only limitation is the number of gates that the consumer can provide to the final IC device.

Further, each packet category of the present embodiment has an associated flag indicating that a new packet has been generated when set. When such packets arrive, the racket is assigned a multi-bit (eg, 2-bit) timestamp to ensure that the packets enter the packet pipeline in the correct order. Overflow occurs when stale packets are dropped and new packets arrive at the output of the production unit before they are placed in the packet pipeline.

Referring to FIG. 8b, an alternative embodiment to the packet array structure of the present invention is illustrated.
Obviously, the resource usage in the array structure of FIG. 8a described above is optimal in that overflow only occurs when every packet part is used the same and every part is in use. However, one disadvantage is the relatively large size of multiplexing required at the packet pipeline input. Each packet portion has a 32-bit width, and each bit is 10: 1 in the illustrated embodiment.
A multiplexer (10: 1 mux) is required. Such multiplex intensive designs can potentially cause problems when the designer seeks to generate placements for the design.

Thus, the embodiment of FIG. 8b merges two separate packet pipelines. Simulations by the assignee of the present invention show that the frequency at which segment start and route trigger packet morphologies are generated is significantly lower than the frequency at which instruction execution and delayed load data packet morphologies are generated. Therefore, in one configuration, a “low” frequency packet of frequencies,
The "high" frequency frequency packets are split into separate pipeline arrays, effectively halving the amount of multiplexing required at the packet pipeline inputs.

Referring to FIG. 9, packet pipeline FI
An example structure 900 for a FO is described. The FIFO 902 of this embodiment uses on-chip RAM to greatly increase the buffer size. RAM is substantially "narrower" than the packet pipeline, so its main function is to buffer medium-frequency and medium-length data busts. As shown in FIG. 9, the FIFO 902 uses a correct synchronous dual port RAM of the form well known in the art. The recording logic of RAM operates at the same clock as the rest of the RTT unit and core 705, and the read logic operates at the same clock as the packet port 709 and capture device 772.

The FIFO 902 has a fixed width, ie two packet parts in the illustrated embodiment, but the depth is configurable at build-time. Also, the depth is selectively configured to contain a value of zero, which completely removes the FIFO from the design.

It should be noted that by referring to the packet pipeline array structure of FIG. 8b, control information indicating when to extract information from a smaller array is also used between the multiplexer and the FIFO. This is accomplished in this embodiment with a counter that represents how many parts are read from the main array before being read from the smaller array. However, it should be understood that other approaches together with the present invention can be used successfully.

It should also be appreciated that the embodiment of FIG. 8b can generally be optimized when there is a mechanism for determining the relative size of two arrays. In particular,
In order to achieve optimal use for packet pipeline hardware, the two arrays are designed so that even if the relative speed at which they are filled varies with trace.
Must be overflowed at about the same time. Therefore, a simulation performed before the build time is useful in determining the optimal relative size.

The FIFO 902 is not always present in the RTT system, so the interface between the packet pipeline and the FIFO can be made to exactly match the interface between the FIFO and the packet port.
This is because the packet pipeline does not need a FIFO (with the FIFO acting as a rename block signal).
Allowed to connect directly to the packet port.

The packet pipeline consists of two optional array sections. One array stores packets from the high bandwidth category and the other array stores packets from the low bandwidth category.
The size of such an array is perfectly configurable with a fixed size. High bandwidth arrays are typically very large when required to buffer more packets. The order in which packets enter and exit the pipeline array is the same as the order in which they arrive at the output of the generator unit.

As mentioned above, it is possible to generate up to 4 packets at any period, which only occurs in very rare cases. Every packet belongs to a particular category, and only packets from other categories can be generated at the same time. Any output from the generate unit must have their value unless it comes out of the register directly and a new packet arrives.

Table 6 is a list listing exemplary port interface signals between the generation unit and the packet pipeline of this embodiment.

[0201]

[Table 6]

Packets are extracted from two parts of the pipeline array at a time and applied to the output register FIFO. Table 7 below lists all port interface signals between the packet pipeline and the FIFO block.

[0203]

[Table 7]

In the described embodiment, the only configuration register that affects the packet pipeline is the buffer control register. The Disable Buffer Overflow (DBO) bit in this register has no effect on the packet pipeline during normal operation, but is used only for verification purposes to block the buffer overflow signal.

Table 8 is a cataloged list of port interface signals between the appropriate modules and packet pipelines in the core according to the present invention.

[0206]

[Table 8]

The width and depth of the 2-pipeline array is rtt.
The constants defined in the _option package can be independently configured in this embodiment. PIPE_IE_DLD_COLS and P
IPE_DLD_ROWS both limit the size of the high bandwidth array, which stores packets from the instruction execution and delayed load data categories. PI
The PE_CTL_LP_COLS and PIPE_CTL_LP_ROWS constants limit the size of the low bandwidth array, which stores packets from the control and loop trigger categories.

There is no restriction on the value for the number of rows (as long as the value is 1 or more). A packet is accepted into the pipeline only if every packet is suitable, and thus the number of rows is greater than or equal to the maximum packet width (partially), or this packet is never accepted. Since the number of rows does not improve the function, it does not exceed the total width (partially) for the two largest packet categories, and it is difficult to meet the timing requirements of the system.

Only the packet pipeline processes the data part. To make the packet more manageable,
In order to provide storage efficiency, achievable timing, and good negotiation between uncomplicated control logic, the packets of this embodiment of the RTT are all segmented. The portion consists of 8 nibbles of data and 1 nibble of control bits, as shown in the exemplary apparatus of FIG. Whatever the part of the packet is, the data is stored in that part and the control bits have the information in Table 9 below.

[0210]

[Table 9]

Being able to decode where packet boundaries occur because the packet port needs to be padded to zero before the SEGSTART packet and may need to distinguish any data in the middle of the packet from the SEGSTART packet header Is desirable.

When a packet arrives at the output of the production unit (as specified by the new signal), it is not necessarily accepted by the packet pipeline in the next cycle. A packet triggers a buffer overflow by pausing for a moment until space becomes available in the pipeline or space is overwritten by another packet of the same category.

To preserve the order in which a packet is generated and the order in which this packet leaves the packet pipeline, every new packet arrives the first time
An age tag is assigned. In the present embodiment, such an age tag is composed of 2 bits, and 2 bits cover all 4 packet categories that arrive in other periods. However, other bit numbers and schemes may be used. Two or more control age tags, the oldest_age point for the oldest packet that is not yet accepted in the pipeline, and the newest_age for the most recently arrived packet.
Points are maintained by the system.

The newest_age tag is incremented only in the cycle in which new packets arrive. oldest_age_tag is incremented each time every packet of that age is accepted by the pipeline. The 2 age counters in the described embodiment are all 4 modules (modulo N ar)
tithmetic) is used to cycle.

Further, each packet pipeline array has an input column pointer and an output column pointer. These pointers are registers with the width of the array,
The next part uses a form of "1-hot" encoding that is well known in the art to describe where the register falls in or is extracted from.
The 1-hot system simplifies control logic when calculating a new pointer value, regardless of whether the packet fits into the pipeline. For example, a binary pointer is a modular 5 operation on an array of 5 columns (modulo N
artithmetic) is required.

The output control logic needs a mechanism to determine what array packet should be removed next. A part counter, which represents how many parts must be removed from the high bandwidth array prior to that particular part, is associated with each part of the low bandwidth array. Each time a portion is removed from the higher bandwidth array, the output fraction counter is incremented and when this value matches the fraction count value of the next lower bandwidth portion to be extracted, that portion is removed and the counter Reset.

In contrast, Appendix IV provides a definition of an exemplary register used in the buffer / packet pipeline of this embodiment.

Software Driver As shown in FIG. 11a, the present invention additionally uses a software driver to interface between the capture hardware and the software debug program.
This allows the capture session to be configured before it is run. At run time, the exemplary embodiment of the driver shown in FIG. 11a configures the RTT and execution registers to the target location and initializes the capture hardware.

An exemplary embodiment of the RTT driver of the present invention is a minicomputer (eg, a solar powered S
It applies to run on un Microsystems workstations), but it will be appreciated that other hardware and software environments may be used. For example, Microsoft Windo running on a microcomputer (eg WinNT)
A driver approach based on ws® can be used. The various features described herein include:
It will be appreciated that one of ordinary skill in the programming arts given the present disclosure can readily implement it in a target environment / language. Therefore, the following discussion will focus on the details of any particular implementation and focus on the functionality of the software driver feature.

The driver software of this embodiment is
Designed to support various debugging environments.
Based on this fact, the driver is advantageously developed regardless of any particular debug. Existing GUI for each targeted debug environment
Integration of the interface and linking to the RTT driver is required, but such integration is easily done by those skilled in the software programming arts. Such an approach ensures that each debug environment provides tight integration with the RTT driver software.

The driver software can also be configured to interface with a single logic analyzer, and also to support hardware variations, other logic analyzer brands, or dedicated custom hardware. It is open and extensible so that it can be updated. Any number of other hardware environments may be supported.

Control of RTT capture is based on the concept of a trace session in the exemplary embodiment. The trace session contains the code of the execution target and the result of the capture trace by the trace set defined by the user. The trace session represents each capture run. Before starting a trace session, the user configures a set of traces. The configuration is, in this case,
It includes a description of the type of information to be captured, trace start and end conditions, any trigger conditions and associated actions, and filters to be applied. Session set details are selectively captured and maintained by the debug GUI. Thus, the user can modify and delete such sets as needed. Debugging also allows the user to save the current trace set or load a previously saved set, which includes: (i) capture buffer size : user Allows you to specify the size of the trace buffer that should be used up to the maximum physically available size. (ii) Buffer operation : The user can specify whether the capture buffer is used as a circular memory or a single-use memory. (iii) Target start condition : The user can specify the execution start value of the selective program counter (PC). Start the captured trace like this
An option is provided to sync with your PC.

(Iv) Capture start condition : The user
It is possible to specify whether the trace capture should start immediately after the trace is activated or immediately after one or more specified conditions are met. (v) Capture end condition : The user can specify when to end the trace capture.
This is, for example, when the capture buffer is full or when one or more specified conditions are met. (vi) Filter : The user can specify whether a particular address range should be ignored for tracing. Conversely, the user can specify an important address range so that the trace is captured only when the PC is within that range.

Conditions for starting and ending capture include, but are not limited to, discrete program counter (PC) values, PC ranges, data values, data addresses, or combinations of data values and addresses. User RTT
It is possible to have any number of starts and conditions or filters limited only by the number of monitors combined in the unit.

[0225] Once the trace set is defined, the user can trace capture (trace session).
To start. The results for each trace session can be provided to the debug GUI as needed. Users can store and load trace results as well as compare different trace results on the screen simultaneously.

The software driver of this embodiment is
Provides comprehensive handling of error and exception situations. Defect (f
The appropriate text description for ault) is further communicated to the user interface, console output, or log file.

FIG. 11b is a dialog GUI for configuring the trace set used in the RTT driver of the present invention.
2 illustrates an exemplary embodiment of the. The GUI has a scalable number of trace filters and triggers. Filters and triggers can be ordered by activity priority. The filter / trigger is the first “N” filter /
The main attributes of the trigger are shown in a simplified list view so that you can see them at the same time. The main attributes of the filter / trigger can be edited directly by double clicking on the list display. Clicking twice in the appropriate row toggles the start, stop, store and activate attributes. The user clicks twice in the other column to enter the full editor. In general, sets for trace sessions, such as buffer size and morphology, are accessed from a separate tabbed section. A summary view of selectivity may appear on the right sidebar. The Selectivity Summary View summarizes all trace sets selected from the various control and view panes in one place.

FIG. 11c shows the dialog of the filter editor.
3 illustrates an exemplary embodiment of a GUI. Dialog GUI provides various ways to enter the target address value. The address can be accessed by typing it in directly (eg as a hexadecimal value) or by pulling down a list of recently used code labels.
Alternatively, select “mor” at the bottom of the pull-down list.
e. ． ． The “” option can be selected to display a full code browser.
The GUI allows users to write descriptive comments. This is especially useful when more filters / triggers are added to the trace set.

The debugger GUI of the exemplary embodiment provides a display showing all currently loaded trace sessions, and will be displayed for any of the other summary views at the user's request. The summary information is optionally (i) the date and time of the trace capture, (ii) the duration of the capture time, (iii) the size of the session data (this can be done by the total memory size of the trace data or the number of records). , (Iv) the trace set used for the trace session, (v) a summary including the filename (s) for the results of all sessions stored on disk or loaded from that disk, and (vi ) Contains additional user description for the trace session.

The Debugger GUI provides a trace display view showing all captured trace events in chronological order. This view is now dynamically generated to let the RTT library manage complete trace data for your capture session,
This ensures that only the active subset is always queried and displayed in the debugger. In the exemplary embodiment, the trace display includes a list view in which the view area is sorted into named columns to show other fields of information extracted from the trace data. The trace field contains (i) time stamp information, (ii) program counter address, (iii) the current source statement (eg "C" or assembler language),
(iv) data access address, (v) data access value, (vi) execution “C” time (eg, number of cycles an opcode instruction is executed under conditions where evaluation is used), (vii) eg, Includes, but is not limited to, exceptional events such as trace FIFO overflow.

In the trace display, it is possible to search on any field among the displayed fields. The user can also use the software to measure the elapsed time between the two captured trace events. Also, the trace view now provides a link from the instruction trace line to other debugger views or hidden views that use menus with variable navigation, with options for jumping to the debugger source code as an example. Configure selectively.

Also, the debugger GUI is (1) a statistical view that allows comparison of the time spent from various code functions captured in the trace results, and (2) for the user to browse the symbol table of the object code. Configure to provide a convenient mechanism for. 11d and 11e show examples for codes and variable browsing, respectively. In the code browser, the user can select either a part or a function name from the hierarchical tree, or select individual source lines within the currently selected hierarchical node. Also, this embodiment for the GUI allows the user to open various session results and see side-by-side equivalent views opened for other sessions. FIG. 11f shows an exemplary trace data analysis GUI.

Other RTT user interface features include disclosure of relevant views and dialogs, including options for filtering highlighted code blocks in the source editor, and tracing to show overall statistics with corresponding categories highlighted. Includes a variable menu that allows a "quick jump" from one line of view to the statistical view.

Since the size of trace data that can be captured is potentially very large, it is important to provide some mechanism for hiding excess or heterogeneous data. The definition of "heterogeneous" data is user-defined and is therefore completely under user control. In one embodiment, such "data hiding" is done by way of a function of permanently changing the trace data, which by way of example provides a post-capture filter. Selectively,
A view-specific data hiding is provided, but by way of example here various inexpensive loop iterations are folded into a single trace display line for illustration. Such a single line is commented on a graphical expression (eg, "+" symbol or the like) to express its meaning. Such folded parts are expanded and collapsed as desired by the user through the traditional user interface mechanism.

Useful methods for displaying trace capture results include memory browser, register view and traditional hidden online debugger view, active
Includes a source code viewer to trace your PC. GUI
The control interface allows the user to move backwards and forwards through the trace buffer and the state of the target system is now immediately displayed at the selected point in the trace buffer.

Hereinafter, one exemplary embodiment of the software driver structure of the present invention will be described with reference to FIG. In this embodiment, two I / O interfaces are provided to the host computer, a debugger interface and a capture device interface. As mentioned above, the debugger interface provides a bidirectional link between the computer and the debugger interface of the remote core host. The capture device interface provides a bidirectional link between an external computer and other processing devices and a dedicated RTT capture device. For example, although FIG. 12 illustrates upstream and downstream communication channels coupled to the interface as separate channels, such channels can of course be configured on the same physical link if desired. is there.

The structure 1200 of FIG. 12 is from the capture device 1272 to the host computer (eg, PC) 12
The trace packet is transmitted at 74. The RTT driver then decompresses the packet before storing it in local memory and / or disk. The RTT driver is provided access to the original ELF code file for decompression. The RTT driver acts as a database server that actually provides the queried trace results back to the debugger software. It should be noted here that the RTT driver can simultaneously have results from several open trace sessions, which allows the user to make a visual comparison between different trace sessions. is there. In addition, the RTT driver manages the serialization of trace results. The RTT driver facilitated by the debugger software allows session results to be stored in a storage location named, for example, a disk file, and the session results can be loaded from this storage location.

In addition, the RTT driver of the present invention covers the following functions so that the comprehensive application programming interface (API), that is, (i) performance inquiry, (i
i) target debugger interface registration, (iii)
Provides session configuration, (iv) session execution, (v) session management, and (vi) query session data. Such an aspect will be described later in detail.

(I) Performance Query -This API returns information about the capture performance of the RTT system as a whole.
This information is determined by the hardware being used as well as the specifications of the synthesized RTT unit in this exemplary embodiment. The specification of the synthesized RTT unit is read from the target configuration register by using the target debugger interface, although other approaches can be used if desired. The following code illustrates such a feature:

(Ii) Target debugger interface
Registration -This API registers the process for the target debug interface with the debugger RTT driver. In the described embodiment, such a function can be implemented in two ways. One method uses DLL / SO processing, and the other method selectively uses a column path to the DLL / SO library file. As an example:

(Iii) Session Configuration -This API feature set provides the ability for set options to accomplish the next trace capture session. The configurable option uses a compression scheme that specifies what unit of packet encoding is used by the RTT unit. The choice in the exemplary embodiment is either a full address or a delta address, although it will be appreciated that other forms of encoding may be used as appropriate for the present invention. The following code illustrates such a feature:

A description of the active trace category is also provided as part of session configuration. The description specifies what categories of traces are captured and allows for individual selection from trace categories including instruction, time stamping, data and wait traces. This illustrates the following code:

Also, session configuration can be selectively configured to specify how the capture buffer is used. The choices included in one exemplary embodiment are the use of buffers in either fixed-use mode or circular-use mode, as shown in the following code:

Trace filters and triggers can also be specified as part of session configuration. Especially this
The API allows filter and trigger sets to be specified as in the following example:

(Iv) Session Execution -This API allows execution of trace sessions. An example is:

(V) Session Management -This set of API functions allows the results of a session to be stored and loaded, allowing the query of summary information. An example is:

(Vi) Query session data- such as
Session results with the API feature set can be queried and browsed in the debugger as shown in the following example:

Monitor Unit Below, FIGS. 13 to 1
The monitor unit 742 of the present invention will be described in detail with reference to FIG. As mentioned above, one purpose of the monitor block is to reduce the amount of data provided to the capture device 772 off-chip by filtering out unwanted trace information.

As is well known, the additional I / O pins on the IC add significant cost to the fabrication. However, the width of the packet port in the present invention can be made as small as possible for low cost applications. In such a system, a bottleneck occurs because the packet port transmits RTT data outside the chip. There are two major solutions to this bottleneck phenomenon, which guarantee that no overflow will occur (and no information will be lost). The first solution involves increasing the buffer to allow most of the data to be on-chip before transmission to the capture unit occurs. This prevents overflows from short size data bursts to medium size data bursts, but long periods of high bandwidth
Increasing the size of the buffer does not reduce the amount of data transmitted through the packet port, resulting in overflow. The second method involves discarding the data that the user has determined to be inappropriate using the monitor. Thus, it should be understood that while a monitor unit is used in the described exemplary embodiments, such a monitor unit is not essential for carrying out a more comprehensive invention.

The monitor unit 742 in this embodiment uses the output from the flattener unit 770 described above to determine what information is valid (and thereby what packet the generating unit 744 should generate). decide). The number of individual monitors that exist,
The complexity of filtering by it is the build time
(build time) can be selectively configured by the user. The operation of each individual monitor is described in detail later in this specification.

The monitor of this embodiment has the following functions.
That is, (i) monitoring of programmable conditions and buses, (ii) use of programmable actions when conditions are met, (iii) individual filters such as motion screening to provide range-specified filters. Ability to combine different monitor behaviors, (iv) various trace configurations
Configure to provide transformations to the HDL / synthesis program (eg, Verilog) for selection using (v) conversion tools, and individual filtering (eg, instructions, timing and data):

In one exemplary embodiment, multiple configurable monitors are provided at design time, and the user can select, for example, 0, 2, 4, 6 or 8 monitors. If no monitor is selected, the monitor block still exists, but the dynamic enable signal granted to the generation unit 744 is always active. The output signal from monitor unit (s) 742 is driven directly from the flip-flop. This provides a favorable partitioning of the design and generally provides better synthetic results. However, the use of such flip-flops is not important in a wide range of inventions.

Conversely, all inputs to the monitor block must come in from registered outputs. This is just a signal from a flat block, with the exception that action points must be merged into the design. This is something that should be studied further.

Each monitor compares on two input buses. In one exemplary embodiment, one bus is the register value that the user programs through the host interface and the other bus is the selection for the bus output from the flat block. (Again through registers programmed from the host interface)
The three selectable buses are, for example, (i) instruction address bus, (ii) data address bus, and (iii) data values for LR, SR and ST instructions. FIG. 13 graphically shows the first embodiment. Delayed load data (data from the LD instruction) is not monitored in this embodiment due to inconsistent return counts.

Depending on the selection of the multiplexer, each monitor can perform four kinds of operations, that is, ≧, <, =, ≠ on any of the above-mentioned three buses.
Also, the output should be tied to a valid flag, as the comparison by the monitor filters only when done on a valid instruction. This is because the signal also comes out of the flat block to produce such an effective flag,
This is because it relates to each of the input buses as much as possible.

There are three dynamic enable signals that are output to the generate block, each signal for a respective trace type: instruction trace, instruction timing trace, and data trace. Each dynamic enable comprises a separate control register that selects what monitor output is used to control the enable bits. Monitors can all be combined to perform address range comparisons (useful for grouping functions) and can be activated by any of the following forms: (i) start-condition When true, the enable is set to "1" until the stop condition is met. (ii) Stop-When the condition is true, the enable is set to "0" until the start condition is met. (iii) Accept-Enable is set to "1" when the condition is true, otherwise it takes the default value (depending on start / stop conditions). (iv) Prevent-When the condition is true, the enable is set to "0", otherwise (depending on the start / stop condition) it takes the default value.

One flip-flop is used to register the enable state for start and stop conditions. The same type of trigger signal is used when the logic analyzer captures the data on the trigger.
Triggers can be generated from any of the monitors (including the combination of the monitors) or an external source (including the action point block). In the exemplary case of the ARC core described earlier in this specification, selective debug facilities are provided that are used to monitor the instruction and data address buses as well as rewriting the data values and register files. Action points can brake the core when desired conditions are met and can be combined when monitoring is possible. However, such action points are slightly different from the monitor. Action points are used to trace many signals and trace requirements to the monitor, not the flattened pipeline. Therefore, an action point configured to brake the core in comparison to a PC will not trigger at the same moment it is configured to brake the rewriting of the register file.

As mentioned above, the monitor unit requires that various configuration registers be configured by the user through the host trace before the trace execution is performed.

All RTT registers, including those present in the monitor block, are doubly accessed and mapped into the auxiliary register space. This means that the host and core have other channels to the registers and host access is non-mandatory. In addition, the location of such registers should be fixed. Each monitor requires at least two registers.
One is for construction and the other is for comparison values. Also, each dynamic enable should require a configuration register.

In the exemplary embodiment, each monitor is individually configurable and has two registers associated with it. The first monitor register is used to select what bus is monitored and what form of comparison is made. The second monitor register contains a comparison value. An unsigned 32-bit value must be recorded in this register when performing identical or non-identical operations. When performing greater than or equal and smaller operations, the negative of the required value must be written into the two fill configurations. This is necessary to ensure that the monitor unit achieves the target clock speed.

Each dynamic cable further comprises a configuration register to select a monitor or monitor coupling for each of the four properties such as start, stop, allow and prevent. One is the source of the trigger (R)
The other one is for identifying the occurrence of the trigger after the trace capture.

The flattening unit 770 also takes the necessary signals from the processor pipeline that it needs to reconstruct the execution history and "flattens" them so that all signals associated with a particular instruction are It is valid during the same clock period. Prior to passing these signals to the generation block, these signals are passed to the monitor unit 742, where most of these signals are dispatched with the clock period number taken by the monitor itself for execution. Even though it costs a lot of money about the number of gates,
All these signals need to be routed so that the monitor's dynamic filtering affects the proper command. A very small portion of these signals is also used by the monitor to provide the filtering required by the user.

Table 10 below lists the exemplary port interface signals used between the flat unit and the monitor unit in this embodiment. All signals are registered inputs unless otherwise explained.

[0264]

[Table 10]

The signal from the flat unit 770 is dispatched by the monitor unit 742, but otherwise it remains unchanged before being passed on to the generation unit 744. There are three additional signals generated from inside the monitor unit, namely the dynamic enables for each of the trace configurations. These control the filtering and determine what packet form is generated.

Table 11 below lists the signals for an exemplary port interface used between the monitor and generator units in this embodiment.

[0267]

[Table 11]

All registers used to configure the monitor's operation are mapped into the auxiliary register space of the core (eg, the ARCtangent A4 processor described above). All registers are dual access structures that allow non-forced access by the host during processor execution.

Table 12 is a list listing exemplary port interface signals used between the monitor unit and the appropriate module in the core in this embodiment. All signals are registered inputs unless otherwise explained.

[0270]

[Table 12]

The configuration registers that run one or more RTT systems are maintained in another module called RTT_regs. Some of these registers (or the signals derived from them) consist of the appropriate period for activating the monitor in the order in which the generating unit receives them in time through the flat unit signals and dynamic enables. Must be shipped through a number. See Table 13.

[0272]

[Table 13]

The number of monitors present in the RTT system is NUM_M which can take the values 2, 4, 6 or 8 in this embodiment.
It can be configured by ONITORS constant (determined by rtt_options). It is also possible to design without a monitor by setting the MONITORS_EXIST constant to "false". In this embodiment, the NUM_MONITORS constant should not drop below 2 and edit notifications may occur due to incorrect loop ranges in the code. However, the inferred logic is still accurate.

The DATA_TRACE constant determines whether the RTT system can generate packets for data traces.
This affects the filtering function of the monitor unit. The turn-on of the data trace allows the monitor to compare the instruction address bus, the data address bus, and the lr, sr, st data value buses. When the data trace is turned off, the monitor can only compare with the instruction address bus.

If the instruction timing trace is TIMING_TR
If it is not enabled by the ACE constant, the dynamic enable of the timing trace is fixed to the inactive state,
It should not be affected by any of the monitors. If the data trace is not enabled for the DATA_TRACE constant, the dynamic enable of the data trace should be fixed in the inactive state and should not be affected by any of the monitors.

The constant MONITORS_PIPELINED determines how many stages the monitor is running. When set, the monitor requires two stages, and all flat unit signals are routed thereby, otherwise the monitor performs in a single stage.

FIG. 14 illustrates another exemplary embodiment for the structure 1400 of the single monitor unit 742. The structure for the monitor unit of this embodiment can be divided into two different parts as follows: 1) the comparison operation part by each of the monitors themselves, and 2) the way the monitors are combined and the monitor on the dynamic enable register. The operating unit that has.

Multiplexer-1 to make a comparison for valid erasures when the data trace is turned off.
402 selects an arbitrary bus. The only valid bus for making comparisons is the instruction address bus 1404.

The instruction decoder 1406 is needed to ensure that the monitor is activated only by the instructions configured to make the comparison. The monitor valid signal 1408 is always active when making a comparison to the instruction address bus. When performing a comparison against a data address or data value, the monitor enable signal is activated only if the current instruction form matches any of the instruction form flags in the monitor condition register.

The reference compare value 1412 is taken from the monitor's reference register (see Register Definitions), one 32-bit register for each monitor in the system.

The monitors of the RTT unit can be combined in one set or four sets as shown in FIG. The signal selected by multiplexer-1502 is determined by the monitor control register, for which the appendix
It is explained by the register definition provided in III.

The Monitor Condition Register determines how the monitor can force a dynamic enable. There are four options: 1) Start, 2) Stop, 3) Allow, and 4) Block. Each dynamic enable has two flip-flops associated with it, the dynamic enable itself, and a start / stop flip-flop that is used to hold a default value. The dynamic enable should be "0" when the "blocking" monitor is activated and "1" when the "allow" monitor is activated. If none of the Allow or Shutdown Monitors are activated, the Dynamic Enable takes default values from the Start / Stop Flip-Flops.
The "start" filter should set the start / stop flip-flop activity and the "stop" should set the start / stop flip-flop to inactive.

FIG. 16 illustrates the operation of a monitor coupled on dynamic enable. If one or more monitors behave as “tolerant” and one or more monitors are acting as “block”, a collision occurs (or a collision for “start” and “stop”), which is the lowest Monitors with indexes dominate.

In the embodiment described above, and because the start monitor has the additional property of performing dynamic enable activation (with start / stop flip-flops), trace capture can be achieved with satisfaction of the "start" condition. Occur. The stop monitor only affects the start / stop flip-flops, essentially stopping the trace capture one cycle after the start condition is met. This means that the instruction that causes the stop condition will still be captured in the trace (eg, the j-link exit point for a function).

Further, the processor itself can influence the start / stop flip-flop by recording in the monitor control auxiliary register. This allows the default state of other trace configurations to be set up by the host computer or RTT-aware operating system before trace capture occurs.

Appendix III provides detailed information and definitions for the exemplary monitor registers used in this embodiment.

Packet Port As mentioned above, the main purpose of packet port 772 is to transmit off-chip trace information to one or more external capture units. The packet port is responsible for receiving trace information from the buffer so that the trace information follows a predetermined protocol and allows the external capture unit to reconstruct the trace history. All trace information output from the generation unit will be viewed by the capture unit.

An exemplary embodiment of a packet port according to the present invention is (i) configurable port width, (ii) providing a capture clock, (iii) allowing the data stream to conform to a predetermined protocol, and (iv) ) Utilize translation tools to provide selected HDL / synthesis programs (eg, Verilog-like translation-like functionality. Also, typical packet ports are also designed to allow multi-core traces to be streamed through a single packet port. To be done.

As will be described in more detail below, the exemplary embodiment also advantageously provides the ability to easily reduce the width of a packet port to one pin utilizing fewer protocol changes.

As shown in FIG. 17, the packet port structure 1700 of the exemplary embodiment receives the output from the FIFO 902 and filters out invalid data. The structure 1700 comprises a plurality of no-multiplexers 1704 arranged in a parallel structure, with one no-multiplexer assigned to each nipple of a packet port pin. Each packet port nibble can take a 0xF (“1111”) value if it requires an input from each nibble of data at the FIFO output, so-called “nibble stuffing”. Although other configurations can be used, the number of port pins is a multiple of 4 (ie,
4, 8, 16)).

To decompress the RTT data stream, the segment start packet is made as seen by the external catcher device. All sequential packets in a segment have the data encoded for the absolute data value in the segment start packet. Thus, the exemplary structure 1700 described above.
Thus, four zero value nibbles will be placed before the segment start packet. This helps the external capture device to recognize the segment start event even though the latter is buried in the middle of the data stream. Thus, in the exemplary RTT protocol, four zero value nibbles should not appear in the absolute trace packet, which is accomplished by nibble stuffing. Specifically, if the packet port encounters three consecutive zero-valued nibbles in the trace packet, it inserts an extra nibble value 0xF (“1111”) in the data stream. This ensures that if the next (4th) nibble is zero, the above protocol is not a violation. Nibble stuffing occurs whether the fourth nibble value is zero or not. FIG. 18 illustrates this process graphically.

Also, in the exemplary embodiment, packet port 772 synchronizes to the clock signal provided by the capture unit even though it is recognized that other synchronization schemes may be used. This signal can be used by the capture unit to synchronize the data capture if the system clock can be monitored for existing pins. The gated clock can be selectively provided by a packet port which eliminates the role of filtering null data from less "intelligent" capture devices. As shown in FIG. 19, the capture clock changes only when there is valid data on the packet port pin. The external capture unit samples the data on the falling edge of the packet port clock. This guarantees proper set and hold times as the data changes only on the rising edge of the clock.

Test Structure and Methodology The RTT of the present invention supports the observation of non-interfering cores during program execution. As mentioned above, the RTT of the exemplary embodiment is an instruction trace,
Capture four types of trace information such as data trace, event trace and timing trace information. Flat unit 770 observes the state of the processor to select external signals to detect changes associated with possible trace morphology. Trace information is generated by the generating unit 74
4 to the monitor unit 742 which dynamically filters the trace information for the user set. The monitor unit also generates a trigger. The generation unit 744 records the trace information by updating the internal state (eg, counter) and generating a packet. The buffer 712 stores the packet and transmits it to the storage device. When the buffer has too much storage capacity, interrupts are selectively transmitted to the core. The control unit 746 includes auxiliary registers and state machine used to control the operation of the RTT.

As mentioned above, the flat unit 770 eliminates the effects of all pipelines in the core (eg, ARC) pipeline. The output of the flat unit 770 looks like the output of an essentially pipelineless processor. A flat unit is when an instruction or interrupt is in a special state of the pipeline (ie 4 steps or rewrite steps in the exemplary ARC pipeline),
Contains all information related to the instruction or interrupt.
The core pipeline, in steps 1, 2 and 3, generates information related to an instruction or interrupt, which the flat unit stores when generating this information and the core when the related instruction or interrupt is issued to the pipeline. It goes out to the pipeline.

An exemplary test code scenario used to test the RTT flat unit 770 is presented in Appendix V.

The RTT monitor unit 742 takes the output from the flat unit 770 to see if the information is valid.
It also determines what packet generation unit 744 should generate. The number of each monitor present and thus the filtering complexity is user configurable at build time. Appendix VI shows an exemplary set of defined tests performed on the RTT monitor unit 742 during operation. Each column in the table in Appendix VI represents one test that shows how monitors are configured to provide the range of possible combinations that various monitors can respond to. While more filter combinations are possible, as shown in Appendix VI, the exemplary combinations shown provide a superior range for functionality and strength.

For generation unit 744, the test is configured as shown in Appendix VII.

Buffer 712 and packet port 772
On the other hand, the test is structured as shown in Appendix VIII.

The control unit 746 consists of all auxiliary registers used by the RTT unit. The registers write up to three sources in the control unit, which are possible in the exemplary embodiment, which are the core, host and RTT units. Within the control unit 746, all read / write operations and the functionality of each register are selectively tested. HMSL (Hyperscri
pt markup language) or similar script to read / control all control registers through the host port.
Used in the exemplary embodiment for writing. H
MSL can also be used in a "single step" to manually reactivate the RTT. However, other scripts or languages can be used to provide the same effect.

The test code developed for the RTT unit can be used in simulation and with hardware for performance observation. The results produced by the simulation are used to compare with the results produced by the hardware for the same test code. In the exemplary embodiment, two core "builds" are used to test the RTT unit. The first configuration contains only minimal build options for the core. The second configuration includes maximum possible build options. However, other combinations can be used for a variety of build options, including for example "partial" configurations with different desired features and options set. Table 14 details build options in an exemplary embodiment of a processor core (eg, ARC). In this example, four different RTT unit configurations were used with the minimum and maximum options described above.

[0301]

[Table 14]

Table 15 provides details associated with exemplary RTT unit build options. Overall, eight
(8) Configurations (core + RTT) can be used in combination with VHDL / Verilog, other simulators and AA3 / 0.18 technology. The entire 8 different builds are synthesized and verified for gate count and clock speed. Also, other core build options can be combined with these configurations.

[0303]

[Table 15]

Test systems (such as the ARCTest system manufactured by the assignee of the present invention) support at least a subset of RTT tests. The memory module is used to obtain pre-initialized results for comparison with simulation results. This test can be used for a variety of applications including, for example, customer credit verification or QC. This test, which is included as part of the following test system, is ideally configured to test all subsets of: This subset is (i) generated and recorded RTT interrupt, ZeroOverheadLp, conditional abort / branch, data load and dldd, control register (host) read / write, control register (core)
Includes read / write, single stepping through HMSL, dynamic activation of monitor, monitor and trigger, and pool trace mode.

Random Command Generation Function (US Patent Provisional Patent Application filed on November 5, 2001 by the same assignee under the name "Random Command Generation Device and Method", the entire text of which is incorporated herein by reference. Application No. 60/33
The exemplary system and method disclosed in US Pat. No. 8,507) can be used to produce random instructions for the RTT test of the present invention.

The four RTT configurations described in Table 15 can be used with the default RTT configurations selectable from the configuration software (eg, the structural software described above).

FIG. 20 shows an exemplary configuration of a test bench used in combination with the RTT unit. The test bench is used to test the RTT under simulation. The "mon" function 2002 of FIG. 20 removes the core pipeline effect and stores the decompressed data in a file (eg * .atb). The compressed data obtained from the RTT is stored in another file (eg * .rtt). First
Software application 2004 (eg, FIG.
A typical example of 0 is "rttDisplay") used to decompress a compressed RTT data file and generate trace data in the formation of a text file. The second software application 2006 (for example, "atbDisp
lay ”converts a decompressed data file into a text file, and the known difference between the decompressed data file and the decompressed version of the compressed file.
Remove (etc.). The difference between the two files can occur in multiple situations, which is (i) a zero overhead loop across multiple segments when the loop is set up in a previous segment, (ii) timing trace Includes delayed load data (DLDD) recovery (RTT trace does not store DLDD packets) after no delayed load and (iii) RTT deactivation.

The test code executed under the ISS 2010 is executed by another software application (for example, "scareTo
Generate one or more resulting files (eg * .iss) converted to a decompressed data file (eg * .atb) using the “Atb” software application. This generated *. The atb file is used by atbDisplay to generate the final trace text file ScarcToAtb removes the effects of delayed load data from the ISS data.

This embodiment uses three different references for RTT verification. (i) If there is no buffer overflow, the outputs of rttDisplay and atbDisplay are comparable. (ii) In case of buffer overflow, the rttSim application (software equivalent to RTT) is
Used to generate * .rtt files, the two generated rtt files are comparable. (iii) The file generated from ISS2010 will be an independent reference path for comparison with the RTT output.

The software modules described above are optionally configured with other instruction line options to produce the required trace data.

Under simulation, for independent block level testing, the minimal RTT module is the flat unit 770 and the generate unit 744. The monitor unit 742 and the buffer unit 712 of the RTT 702 can be added one by one with the flat unit and the generation unit for the same test. Trace information should be generated using this captured data. If there is no timing trace, the RTT module can be verified by running the same code under ISS. For timing traces, all timing information can be obtained using the monitor function (“mon”) 2002 described above, which can be combined with the ISS acquired. Exemplary Monitor Function 2 Described Here
002 can use other configurations, but ModelS
Support im and VHDL. Therefore, VHDL and ModelSim
Monitor function 200 when operating under simulation
All * .atb files generated from 2 should be saved. This file is the basis for additional comparisons on other simulators, including Verilog simulations.

The test code described above is applied with a logic analyzer selectively used to capture trace data to work on a development board (such as the Arcangl 13TM development board manufactured by the assignee hereof). be able to. Alternatively, a custom capture port can be used with an advanced trace display.

FIG. 21 shows an exemplary directory structure in which all test code and software applications / scripts described above are stored. The tests are categorized into RTT units (eg, smooth, monitor, generate, etc.) and the functionality and “corner case” (“c
orner cases ”) (ie, a combination of two or more parameters, such as those associated with a semiconductor process that can affect performance or other parameters). The file under each RTT unit should Structured to include, these are Test_name.hex, Test_name.out, Test_name.s
And Test_name_ISS.atb. Test_name_ISS.atb
Generated from ISS simulation of test code
Note that this is a * .atb file.
The common folder contains files common to all tests like Vector_table and Makefile. Makefile is all
Includes all instruction line options to compile various other test code for the RTT unit.

The "Universal" folder of FIG. 21 contains a subset of test files that are integrated with the test system and RTT.

In one exemplary embodiment, the configuration of each core comprises a single unified RTT configuration, maintaining a 1: 1 relationship between the core configuration and the RTT configuration. The test code is not integrated into the core configuration directory, it is integrated elsewhere. The test code is in another core + RTT configuration (i.e.
Can be used for "one-to-many" relationships).
Links are optionally used to attach all these test codes to other core configurations.

In the directory structure embodiment (FIG. 21), all tests run under simulation produce their results in the test code directory itself (eg, "mon.atb"). After completion, do the same thing in another directory
A script is used to copy to (eg BUILD / RTT directory), after which the test name is added. Also, the result generated from the comparison of other generated RTT / mon / ISS files is stored in the same BUILD / RTT directory.

A code scope tool is also provided in this embodiment. Exemplary coverage standards are provided below. (i) Scope of statement-Provides details of the statement of the program executed during the test bench execution. Each executable statement (excluding notification statements and comments) is tested to see how well it was executed. The statements that have not yet been executed are identified. (ii) Branch coverage- provides details of all program branches executed by the testbench. The branch is mainly
Occurs in IF and CASE blocks to correspond to possible outcomes of conditional statements within these blocks. Branches that have not yet been taken are identified. (iii ) Scope of condition-A check is made for a particular sub-condition in a conditional imperative statement to see which combination of sub-conditions makes the imperative statement true. Any such conditions that have not been captured are identified. (iv) Scope of route-specific route is HD depending on the test bench
Confirm that it was executed through L. Routes that have not been passed are identified. (v) Triggering range- Applies only to models written in VHDL, with signals in the recognition list of PROCESS and WAIT statements. Testing is done to see if the statement is triggered by a single changing signal or a combination of signals. Untriggered signals are identified. (vi) Signal Trace Coverage- includes signal set values specified by the user. Every time one of the signals changes at run time, the values of all monitored signals are recorded. This allows analysis of the combination of signal values generated during execution. (vii) Toggle range of application-when one signal changes from logic 0 to logic 1 and then to logic 0 again, or logic 1
It is a standard of coverage, which is obtained when changing from 1 to 0 and back to 1 and allows a quick and easy identification of circuit areas that are not performed. (viii) Scope of activity- provides a count of the number of times the signal changes a logic value during the simulation. Such equipment provides information on the relative activity of other signals within one circuit. (ix) Exclusion Scope- Selected areas of the HDL source code under test are excluded from any of the test lists.

The test code used to test the RTT module 702 is applied to provide coverage for the following conditions / events, which are (i) interrupts (memory error, instruction error, user interrupt). , (Ii) read / write to core / auxiliary / status register, (iii) arithmetic / logical operation, (iv) single operand instruction, (v) jump instruction, (vi) jump and nullify (nullify )
Delay slot instruction, (vii) jump and execution delay slot instruction, (viii) jump with adjacent address, (ix)
Jump with flag set, (x) conditional jump, (xi) branch, (xii) conditional branch, (xiii) s / w brake point, (xiv) direct / indirect jump, (xv) branch / jump and link , (Xvi) single instruction loop with zero overhead, (xvii) zero overhead loop with branches and jumps, (xviii) zero overhead loop with brake point instructions, (xix) long / short proximity data, and loop Zero overhead loop that composes limm data at the bottom of the, (xx) pause instruction, (xxi) extension instruction, (xxi
i) load / store operation, (xxiii) auxiliary register operation, (xxiv)
Use of short / long proximity data and destination proximity data, (xx
v) single step instruction, (xxvi) flag and flag set instruction, (xxvii) operation instruction interrupt, (xx
viii) Interrupt on jump / branch instruction, (xxix)
Interrupts for load / store instructions, (xxx) interrupts for auxiliary register accesses, (xxxi) self-modifying codes, and (xxxii) RTT buffer overflow ISRs.

Multiple Processor Configuration In the following, referring to FIG. 22, one exemplary embodiment of an integrated circuit 2200 with associated multiple RTTs 2202 will be described. It is to be understood that the embodiment of FIG. 22 was planned for an ASIC or FPGA, but that other forms of integrated circuits are suitable for use with the present invention, whether they include a single die or multiple dies. You should be aware that you can.

As shown in FIG. 22, integrated circuit 2200
Includes a plurality of RTT units 2202 previously described herein, where the RTT units are associated processor core elements 220.
Including 5. MTI (multi-core trace interface)
Unit 2204 is connected to the output of RTT unit 2202 to communicate data there between, where arbitration unit 2206 receives data from each RTT 2202 and is on one chip (or distributed over two or more dies). plural
RTT has one or more buffers and / or packet ports
Allow (r) to be shared. The multiprocessor chip has one RT per processor core 2205 on the chip.
It is possible to have T, but it has to be understood that other combinations of RTT units 2202 and cores can be used, eg multi-core multiplexed into a single RTT.

As shown in FIG. 22, the MTI 2204 (including the arbitration unit 2206) arbitrates between the packet port 2209 and each RTT 2202. Arbitration unit 22
06 selects the corresponding RTT, MT from the RTT buffer 2210
"Emit" the packet to I2204. The released packet is stored here if the shared buffer 2212 exists. Otherwise, the emitted packet is directly MTI
2204 to the packet port 2214.

RTTs 2202 when MTI 2204 is used
Is configured to generate a packet-start output signal for each nibble of the packet port and support a port stall input signal. Start of packet output signal (etc.) (rtt_pk
t_start) allows the MTI 2204 to easily determine boundaries between packets. Port stall or sustain input signal
By (rtt_pkt_hold), MTI stalls the packet port of the individual RTT when a collision occurs.

The MTI 2204 also adds these final RTT identification fields when each packet is in the shared buffer 2212. The size of the identifier field is 1 nibble (for 2 to 16 RTTs) and 2 nibbles (for 17 to 256 RTTs) in one exemplary embodiment.
However, it should be recognized that other forms and configurations of the identifier field (or other mechanisms for identifying the occurrence of a packet) can be used. For example, the identifier may include another bit or nibble, but such extra cost may be incurred by another RTT.
It is used to associate -or core-specified information with each packet. Optionally, the identifier field can be added at the beginning of the packet boundary (the opposite of the end). Many other variations and permutations are suitable for the present invention.

Designs for the exemplary integrated circuit devices described herein (in fact, any other integrated circuit embodiment of the invention not explicitly described) are any known in the art. It should be recognized that numbers can be combined using logic synthesis techniques. User can order
One exemplary method of synthesizing the logic of an integrated circuit having a (ie, "soft") instruction set is the title of the invention is "Method and apparatus for managing configuration and functionality of semiconductor design" 1998. US provisional patent application No. 60 / 104,271 filed on October 14, 1999, is claimed as priority, and the applicant of the present application filed on October 14, 1999 under the same title is in a joint mooring. US Patent Application No. 90/41
No. 8,663, the disclosures of two applications are incorporated herein by reference in their entireties. However, it may be replaced by other synthetic approaches. Devices are built using custom VHDL designs obtained using such methods, then synthesized into logic level representations, then compiled, placed, and well known in the art.
And converted to a physical device using fabrication techniques. For example, the present invention is compatible with 0.35, 0.18, and 0.1 micron processes and can be applied to processes of ultimately finer or other solutions. One exemplary process for device fabrication can be used with others, but the 0.1 micron "Blue Logi" provided by IBM Corp.
This is the c "Cu-11 process.

FIG. 23 shows an exemplary integrated circuit device manufactured using a 1 micron process. As shown in FIG. 23, the device 2300 is particularly suitable for the trace unit 23.
02, pipeline processor core 2305 (eg, AR
C), "local" buffer memory 231 on chip
2, external debug interface 2307, memory interface 2313, and packet port 230
Including 9. This device is manufactured using a custom VHDL design obtained using the method described above, then synthesized into a logic-level representation, and then compiled, placed, and manufactured as is well known in the art. Converted into a physical device using technology.

The integrated circuit device shown in FIG. 23 (also the device to be described later in this specification) is a serial communication device, a parallel port, a timer, a counter, a high current driver, an A /
Those skilled in the art will recognize that commonly available peripherals such as D-converters, D / A-converters, interrupt processors, LCD drivers, ROMs and other similar devices can be included. Should do. The processor may also include other custom or application specific circuitry. The invention is not limited to the form, number and complexity of peripherals and other circuits that can be combined using the methods and devices. Instead, the physical capacity of existing semiconductor processes that have improved over time should add limitations. Therefore, the possible complexity and degree of integration employing the present invention should be increased more than the semiconductor process is improved.

It should be noted that many IC designs currently use microprocessor and DSP cores. However, the DSP should only need for a limited number of DSP functions or the fast DMA structure of the IC. The invention disclosed herein is also compatible with such structures. Furthermore, using the observation method disclosed here, the CP of the IC
Great advantages are realized for all U and DSP functions.

Method In the following, referring to FIG. 24a, a method for obtaining trace data from one or more processors during the execution of a program will be described in the above-mentioned concept of the invention. Although the following description is with respect to the exemplary uniprocessor RTT embodiment of FIG. 1, it should be understood that other embodiments (such as FIG. 7 or FIG. 22) can be used to implement the general method. Is.

As shown in FIG. 24a, the method generally includes first providing a trace unit 102 adapted to receive data from the processor being evaluated (step 2402). The host is also indirectly interfaced with the trace unit 102, for example via a debug port, and the host interface of the processor core is traced as described above.
(Step 2404). Thereafter, a plurality of packets associated with the operation of the processor are generated by the trace unit based on the data received from the processor (step 2406). These packets are shared buffer 112
(Step 2408) and subsequently read and analyzed to obtain information associated with the operation of the processor (step 2410). In the exemplary embodiment of the method described above, the trace unit 102 is adopted for the generation of four distinct traces (ie, instruction, data, timing and miscellaneous). An internal monitor controls the capture of processor data for provision to the trace unit 102. The trace unit is OFF, RUN and TRIGGERED based on the inputs received from the monitored processor (eg writing to the trace unit register space) and any external and user inputs.
It varies between operating states. The packets generated by the trace unit are formatted with the information generated, the form of the trace, and other inputs received from the user / designer to facilitate subsequent analysis of the packet stream derived from the shared buffer. .

When the internal storage device is used (see FIG.
4b), the trace unit is placed in the RUN state (step 2412) and a trace is captured in the shared buffer 112 based on a triggering event such as writing to the RTT control register (step 2414). In step 2416, the host reads the trace data via the debug interface or other interface between the host and the trace unit (non-real time).

If an external storage mode is selected,
(FIG. 24c), the trace unit is placed in the RUN state (step 2420) and a packet is generated by the trace unit 102 and transmitted to the capture device connected to the packet port 109 (step 2422). Thereafter, the trace is captured and stored in the shared buffer (steps 2424, 2426) and the shared buffer emits to the capture device via the packet port 109 (step 2428).

Although particular aspects of the present invention have been described with respect to particular sequences of method steps, these descriptions are merely illustrative of the broader methods of the present invention and may be modified by particular applications as necessary. Certain steps may not be necessary or may be optional under certain circumstances. Additionally, particular steps or functions may be added to the disclosed embodiments or the order of performance of two or more steps may be transposed. All such modifications are considered to be included herein within the scope of the invention disclosed and claimed herein.

While the detailed description has illustrated, described and pointed out novel features of the invention which have been added to various embodiments, it will be understood that devices or steps shown by those skilled in the art may be carried out without departing from the scope of the invention. It should be appreciated that various omissions, substitutions and changes in form and detail may be made. The above description is the optimal mode currently considered in practicing the present invention.
This description is not intended to limit the invention but rather should be used to illustrate the general principles of the invention. The scope of the invention should be determined with reference to the appended claims.

Appendix I Detailed Packet Description IA (Instruction Address) The IA packet contains the target PC of the indirect jump. The full target PC value is 24 bits, but only the unique part is recorded.

STF (Store, Fixed Data Size) The STF packet contains all the information for the store instruction. It is generated when the store instruction is executed. Depending on the current trace options, the packet may include a data address, a data value, a segment instruction counter size, and a segment instruction counter. The full data address is 32 bits, but only the unique portion is written in the exemplary embodiment. The data value size is 8 bits for STB instructions and 16 bits for STW instructions.
And 32 bits for ST and SR instructions. STV (Store, Variable Data Size) STV packets are similar to STF packets except that the data value field is of variable size. The size of the data value is specified in the packet. In that case the STF packet should be used, so the data value is never 8
Not a nibble.

LDA (Load Address) LD (load address) packets are generated when a load instruction is executed. Depending on the current trace options, the packet may be a data address, the size of the segment instruction count,
And a segment instruction count. The full data address is 32 bits, but only the unique portion is written.

LDD (Load Data) LDD packets are generated when load data is written to a register if the user can use the data values to be written. The load instruction may require a destination register field for the load instruction because it may return out of the instruction. If the "Used Fixed Data Value Size" field is 1, the size of the load is implied by the opcode and the "Data Value Size" field is omitted. The size of the implied data value is 8 bits for LDB instructions, 16 bits for LDW instructions, and 32 bits for LD and LR instructions. If the "size of used default data value" is 1, the "size of data value" field is omitted. If the "size of fixed data value" field is 1, the "size of used default data value" field value is 0. The "stall instruction counter" field contains the value of the stall instruction counter. The stall instruction counter is set to zero after the LDD packet is generated. This field is present when timing trace is enabled. This allows the trace decoder to determine the cycle of load data written to the register file. For more details on the stall instruction counter, refer to the detailed timing description.

PF (Pass / Fail state) A PF packet is used when a conditional instruction passes or fails.
Here is a test of its condition code. The pass / fail bit is 1 for pass and 0 for fail. USER (SR for USER register in RTT) USER packet is S for USER auxiliary register in RTT
It is generated when the R instruction is executed. The written value is stored in the packet.

STALL STALL packet is the core (co
re) is not able to issue a command and is generated every period. The presence of the "instruction counter and" stall reason "fields is independently enabled by a programmable register. The" stall instruction counter "field contains the value of the stall instruction counter, which is zero when a packet is generated. PC to trace decoder set (eg IA, STV / STV / LDA with enabled data filtering, PF, BCBIC, BCBICO
V, USER, SEGSTART, LPEND, or INT) and is incremented for each instruction issued. This field allows the stall experience to be determined for the exact command. If the stall instruction counter overflows, a SICOV packet is generated. When generating a stall packet, this stall instruction counter is set to zero. The incoding of the "stall reason" field includes multiple other approaches. This can be instruction cache misses, load uses (ie data cache misses),
Specify stall source (s), including store buffer full, and multi-cycle instructions. The cycle counter value is incremented for successive stall cycles. If a stall reason exists, it must be the same for the period counter for increments. When the cycle counter stops incrementing or overflowing, STAL
L packets are generated. If the field of "cycle counter = 1" is 1, "cycle counter value = 1 or less"
Field is omitted. If "instruction counter = 1"
If the field of 1 is 1, the field of “cycle counter value” is omitted. The "counter value = 1 or less" field encodes a stall value of 1 to 16 cycles.

SICOV (Overflow Stall Instruction Counter) The SICOV packet indicates the overflow stall instruction counter. The value of this counter is not in the packet because the maximum value of the counter is constant. TSOV (Overflowed Timestamp) The TSOV packet indicates a 16-bit time stamp that overflowed. It is generated when time stamping is enabled. Prior to the TSOV packet being transmitted to the packet port, the RTT ensures that it has at least 4 nibbles of all zeros before it. With the implementation of this scheme, the external capture device can easily find the start of the TSOV packet.

BCBIC (Backward Conditional Branch Instruction Counter) The BCBIC packet indicates that the backward conditional branch instruction has failed in the test for that condition code. This packet contains a count of a number of times for backward conditional branch instructions that were passed but not recorded in the trace. The counter is only incremented if the instruction trace is active. If the "counter is 0" field is 1, the "counter value" field is omitted. BCBICOV (Overflowed backward conditional branch instruction counter) The BICICOV packet indicates the overflowed backward conditional branch instruction counter. The value of this counter is not in the packet because the maximum value of the counter is constant.

APE (Action Point Event) The APE packet indicates that an action point event has occurred. If time stamping is enabled, the time stamp field is included in the packet. EXTSIG (Modified External Signal) The EXTSIG packet indicates that one or more external signals selected for RTTDP have been modified. The designer defines the signal to be monitored. All signal values are stored in the packet. If time stamping is enabled, the time stamp field is included in the packet.

SEGSTART (Start of Segment) The SEGSTART packet is the first packet in the segment. It contains the current PC value as a full address. SEGS
Before the TART packet is transmitted to the packet port, RTT
Guarantees that there are at least 4 nibbles of all zeros before it. By doing this, the trace decoder and external capture device can easily find the start of the SEGSTART packet anywhere in the packet stream. If time stamping is enabled, the time stamp field is included in the packet. The new segment reason field specifies why SEGSTART is included in the packet. If more than one reason occurs at the same time, the reasons are written numerically to a small value. Possible cases are written in Table 3 below.

SEGEND (End of segment) A SEGEND packet is generated when the BCBIC counter value is not 0 and the segment end is for any of the following reasons: (i) instruction limit within the reached segment Is specified to the user, (ii) requested by any external input signal, (iii) requested by writing a control register in RTT, or (iv) any state is RUN or TRIGGERED and the instruction trace is Switched from enabled to disabled. The counter is set to zero after it is flushed. TRIG (Enter Trigger State) TRIG packet is generated in external storage mode and RTT change poem between RUN and TRIGGERED states. Prior to the transmission of a TRIG packet to the packet port, the RTT guarantees that it has at least 4 nibbles of all zeros before it. By doing this, the external capture device will
You can easily find the start of an IG packet.

LPSTART (Loop Start) LPSTART packet contains LP_S stored in full 24-bit value.
Contains the TART register value. It is generated when the zero overhead loop is triggered and when the LP_START value sets up prior to the current segment. LPEND (loop end) LPEND packet is a full 24-bit value LP_END
Contains the register value. It is generated when the zero overhead loop is triggered and when the LP_END value sets up prior to the current segment.

INT (Interrupt Take) An INT packet is generated when an interrupt is taken.
This includes the PC at the time of the interrupt and the new PC of the first instruction in the interrupt vector table. full
The PC value is incoded. If time stamping is enabled, the timestamp field is included in the packet.

Appendix II Detailed packet description (second embodiment) STALL STALL packets are generated every cycle that the core is enabled to use, but cannot pull back instructions when instruction timing trace is enabled. The "Counter Value" field incodes the stall value from 1 to 16 cycles (the value of zero in the packet is actually 16 cycles).
The cycle counter value is incremented for successive stall cycles. A STALL packet is generated when the period counter stops incrementing or overflowing. The presence of the "instruction counter" and "stall reason" fields indicates that RTT_P
Independently enabled by KT_CTL register. If there is no instruction counter, the "instruction counter = 1" field is 0. If the “cycle counter = 1” field is 1, the “cycle counter value” field is omitted. If the “instruction counter = 1” field is 1,
The "instruction counter value" field is omitted. The 4-bit "Stall Reason" field is defined as follows.

DATA (Data conversion) DATA packet contains all information for auxiliary register load (LR instruction), all forms of storage (SR, ST, STW, STB instructions),
And the correct data address for memory loads (LD, LDW, LDB instructions). It is generated when the data conversion instruction is executed. Depending on the current trace options, the packet may include a data address, a data value, and a segment instruction offset size. The full data address is 32 bits, but only the unique portion is written. Data values are of variable size. The size of the data value is specified in the packet. Data value present field is 1
If so, the Data Value Size, Use Default Data Address Size, and Data Value fields are present. For store and auxiliary load instructions, data value present is 1 if data value capture is statically enabled.
Since the DLDD packet holds the data value for the memory load instruction, the existence of the data value is 0. If the data address capture is statically enabled, the data address field is present, the data address size field is present, and if the size of the used default data address is 0, there is no data value.

DLDD (Deferred-Load Data) A DLDD packet is generated if the user has available load data values to write when delayed load data is written back to the register file. It is generated for memory load instructions (LD, LDW, LDB). The deferred load instruction may deviate from the instruction and return, so it requires the destination register field for the deferred load instruction. Loads from the auxiliary register (LR) do not use this packet because their load data is not delayed.
The "stall cycle counter value" and "stall instruction counter value" fields allow the trace recorder to determine the cycle of the load data written to the register file. These fields are present when the instruction timing trace is static. STAL after DLDD packet generation
The counter is set to zero if the L packet does not contain a stall reason field.

PF (Pass / Fail State) The PF packet indicates the pass or fail of the conditional instruction in its condition code test. This pass / fail bit is 1 for pass and 0 for fail. IA (Instruction Address) The IA packet includes a target PC for an indirect jump or a target PC for a conditional direct jump if the first instruction is executed after the interrupt occurs. The full target PC value is 24 bits, but only the unique part is written.

BCBPC (Branch Conditional Branch Path Counter) A BCBPC packet indicates a failure of a backward conditional branch instruction in its condition code test. This packet becomes a pass, but contains a number of time counts for backward conditional branch instructions that are not recorded in the trace. This counter is incremented only when the instruction trace is active. If the "pass count = 0" field is 1, then
The "pass count value" field is omitted. LPPC (Zero Overhead Loop Pass Counter) The LPPC packet indicates a zero overhead loop trigger fail (end of loop). This packet contains a number of time counts for triggers that are passed but not recorded in the trace. This counter is incremented only when the instruction trace is active. If the "pass count = 0" field is 1, the "pass count value" field is omitted.

SICOV (Stall Instruction Counter Overflowed) The SICOV packet indicates a stall instruction counter overflow. The maximum value of the counter is constant, so the value of this counter is not in the packet. BCBPCOV (Overflowed backward conditional branch path counter) A BCBPCOV packet indicates a backward conditional branch path counter overflow. The maximum value of the counter is constant, so the value of this counter is not in the packet.

LPPCOV (Overflowed Zero Overhead Loop Path Counter) The LPPCOV packet indicates a zero overhead loop path counter overflow. The maximum value of the counter is constant, so the value of this counter is not in the packet. APE (Action Point Event) The APE packet indicates that an action point event has occurred. If time stamping is enabled when the action point event occurs, the time stamp En is set to '1' and the time stamp field is included in the packet.

EXTSIG (changed external signal) EXTSIG packet has the value of one or more selected external signals as RT.
Indicates that T has been updated. The designer defines the signal to be monitored. All signal values are stored in packets. If time stamping is enabled when the value of the external signal is updated, the time stamp En is set to '1' and the time stamp is included in the packet. INT (take interrupt) INT packet is generated when taking an interrupt. It contains the segment instruction offset of the interrupted instruction (not executed) and the full address of the first instruction in the interrupt vector table. If interrupts are statically enabled and instruction tracing is disabled, the segment instruction offset value cannot be used by the decoder to determine the interrupt instruction IN
T-packets are still generated. If time stamping is enabled, the time stamp field is included in the packet. The BCBPC and LPPC counter values are set to zero after being recorded in the INT packet.

LPTRIG (loop trigger) LPTRIG packet is stored in full 24-bit value LP_ST
Includes ART and LP_END registers. This packet is taken with a zero overhead loop ligated and LP_START and L by the previously executed instruction of the current segment.
Generated when the P_END register is written. TSOV (Overflowed Timestamp) A TSOV packet indicates a 15-bit time stamp overflow. It is generated when time stamping is enabled. If other packets include the "timestamp overflow" bit generated prior to the generation of the TSOV packet, then the TSOV packet will not be generated for such overflow.

SEGSTART (Start of Segment) The SEGSTART packet is the first packet in the segment. It contains the current PC value as a full address. Prior to the transmission of the SEGSTART packet to the packet port, RT
T guarantees that there are at least 4 nibbles of all zeros before it. By doing this, the trace decoder and external capture device can easily find the start of the SEGSTART packet. If the BCBPC and LPPC counter values are all 0, they are omitted. If time stamping is enabled, the time stamp field is included in the packet. The content of the packet control register value in the SEGSTART packet determines whether time stamping is enabled.

The new segment reason field is SEGSTA
Specify why the RT packet is being generated. If more than one reason occurs at the same time, the reasons are written numerically to a small value. The possible cases are:

SRSPEC (SR for a specific register) SRSPEC packet is a program for a specific register.
It is generated when the SR instruction is executed. Specific register is RT
When T_USER and RTT_PKT_CTL, LPSTART and LPEND. The specific register identifier and the written value are stored in the packet. The Timestamp and Timestamp Overflow fields allow the use of this time stamp and are only present when SR is for the RTT_PKT_CTL register.

The specific register identifier codes and the size of the register value field for each register is as follows:

Appendix III-Exemplary Register Instructions

The column "ADDr" is the auxiliary address of the register. The "Resister Name" column is the name of the register used in this document. "Core WR", "Host WR", and "R"
"TT WR" column is a source that can write each register
A list that may be (source). "EN WR"
The column specifies whether the register can be written while RTT is enabled. The "RD" column specifies whether the register can be read. 3 readable registers
Can be read by all possible sources. The “Dual” column clearly indicates whether dual access to the register is possible. The “Bits” column specifies the size of each register. Unused and saved register bits are read as 0 and always written as 0. A read to a write-only register returns the core identification register.
Writes to read-only registers are ignored.
Registers write up to three possible sources: core, host and RTT. The core writes the register by executing the SR instruction. The host writes the register by using the host interface. The RTT writes the register when the initial state of this RTT commands a register update. If the NAW bit in the RTT_HOST_CTL register is 1, then any core written to the RTT register will be ignored. Only the host controls the value of the NAW bit, which is used to ensure that the core cannot write the RTT register. See the RTT_HOST_CTL register description below for further details on the NAW bit. If the NAW bit is 0, RTT is ignored by any core that writes the RTT_LOCK register to the specified value, and any core that writes to the RTT register except previously unlocked. This does not apply to the RTT_LOCK register itself. To further elaborate on the locking mechanism, refer to the RTT_LOCK register description below. The dual access register can be accessed by the host while the core is enabled.
The core and the host simultaneously use the same RTT for the dual access register that can be accessed by the host and the core
You can try to write a register. In this situation, the host writes are win and the core writes are roast. In order to guarantee the success of the writing of the core to the dual access register writable by the host and the core, the core must read the register value by the LR instruction and repeat SR / LR until the success. It should be noted that the RTT_CMD register cannot be read, but the RTT_STAT and RTT_FIFO_STAT registers can be read to determine the success or failure of the command. If the host is
If you need to "automatically" make multiple accesses to an RTT register that can be written by the core (for example, read the register, calculate the new value, and write the register), the NAW bit is automatically Must be set to one that prevents writing to the RTT register during operation.

RTT_Build Register The RTT_Build Register specifies the RTT assembly configuration. This is used to determine the host and / or
Or used by programs executed by ARC. The VERSION field specifies that there is an RTT run. The value 0x1 is the current run of RTT. 0x0 VERSI
ON specifies that there is no RTT. Other values are saved. The NUM_MON field specifies the number of monitors that are present. The incoding of this is given by the following table (NUM_MON = number of monitors / 2):

The DT field is either 1 if a data trace is present in the design or 0. The TT field is 1 if a timing trace is present in the design or 0. Action point event is A in the APE field
1 if it can be written in a PE packet, or 0. USER_NB_M1 field is 1 or less RTT_
The number of nibbles in the USER register. Currently fixed at 5 (6 nibbles), but later RTT version changes are possible. The FIFO_ENTRIES field specifies the current number of FIFO entries. Each entry is 64
It is a bit width. FIFO_ENTRIES is 0 (FIFO does not exist)
It has a range from 1 to 2048. The EXTSIG_NB_M1 field specifies the number of nibbles of external signals of 1 or less recorded in the EXTSIG packet. This value defaults to 0 (1 nibble) when there is no recording of any external signal. PORT_WIDT
The H field specifies the width of the packet port. The incoding for this is given by the following table:

RTT_STAT Register The RTT_STAT register contains the status of RTT. The EN bit is one of the enabled RTTs. It can take several cycles which are set to zero on reset. The TR bit is one of the triggered RTTs. It is set to zero on reset. The IRQ bit is one of the RTTs whose interrupt signal is asserted on ARC. It is set to zero on reset.
The 0V bit is one of the RTT buffers in overflow. It is set to zero on reset. This field is provided for testing purposes. TSO
The (Time Stamp Overrun), APO (Action Point Overrun), and ESO (External Signal Overrun) bits are set to one of their corresponding mechanisms for overrun. Overrun is detected when an event reoccurs prior to the previous event being written to the packet. The PMT bit is empty or one of 0 in the packet pipeline in the RTT buffer. TMT
The bit is either free on the packet port or is one of zero. It is set to 1 on reset. This field is provided for testing purposes. UL bit is one of the unlocked RTTs. This RTT is RT
It is unlocked when the T_LOCK register is written to a specific value and locked again after the next ST instruction. BCBP
C contains the value of the backward conditional branch path counter.
It is set to zero on reset. This field is provided for testing purposes. LPPC contains the value of the zero overhead loop pass counter. It is set to zero on reset. This field is provided for testing purposes.

RTT_CMD Register The RTT_CMD register is used to send one of the next commands to the RTT. The format of the RTT_CMD register is as follows: If the RTT_CMD register is written by the SR instruction executed on the core, the command affects the first instruction after the SR instruction and the interrupt. The CMD_DIS command disables RTT. The CMD_EN_ command enables RTT. The CMD_TRIG command triggers RTT. CMD_E
The N_TRIG command enables and triggers RTT.
The CMD_NS command is the start of a new segment after the next non-delayed slot instruction or interrupt. CMD_C
The B command erases the contents of the buffer. It is provided for testing purposes. CMD_SET_IR
The Q command sets the interrupt request signal sent to the ARC. It is provided for testing purposes.
The CMD_CLR_IRQ command clears the interrupt request signal sent to the core. This is used in normal operation.

RTT_CK_CTL Register RTT_CK_CTL controls the RTT clock. The CK_EN bit is set to 1 to enable RTT and set to zero to disable it. It is set to zero on reset. RTT_CK_CTL, RTT_LOCK and RTT_HOST if the RTT clock is unavailable
All operations stop except for the _CTL register. The RTT clock can also be disabled to save power when RTT is not required.

RTT_LOCK Register Prior to allowing the core to write to some other RTT register, it must always unlock the RTT first by writing the following values to the RTT_LOCK register. This is done to greatly reduce the likelihood of error code that would cause the RTT register to be written incorrectly. After writing the RTT_Lock register, the core is allowed to write one other RTT register. RTT_
After writing to the LOCK register, the RTT remains unlocked until the next instruction is executed in the register where it resides. If an interrupt occurs between the SR for the RTT_LOCK to be written and the SR for the RTT, causing the interrupt handler to execute the SR instruction, the interrupt handler must read the RTT_STAT.UL bit before executing an instruction, and the final SR After executing the above, SR must be executed for the RTT_LOCK register. When RTT_HOST_CTL, if the NAW bit of the register is set to 1, the core will not allow any RTT register writes.

RTT_HOST_CTL Register The RTT_HOST_CTL register contains options that are enabled only for the host. The NAW bit controls core write access to the RTT register. If this bit is 1, all SR instructions to the RTT register will be ignored. If this bit is 0, the SR instruction writes the RTT register. The blocking core writes to the RTT register to ensure that programs running in the core cannot change the RTT behavior. If NAW is 0, the core is used to minimize the chance that a program running in the core will accidentally change RTT behavior. The NAW bit is set to zero on reset.

RTT_PKT_CTL Register The RTT_PKT_CTL (packet control) register controls the run time RTT option that must be recorded in the packet stream for the decoder. Each bit is set to 1 to enable, and to zero to disable. The meaning of the bits is given by the following table. All dynamically enabled bits are set to zero on reset. If the instruction timing trace is dynamic enable, then the instruction trace must also be dynamic enable. UPC (Use Pass C
ounts) bit is the backward conditional branch path counter,
Zero overhead loop path counter and associated packets (BCBPC, LPPC, BCBPCOV, LPPCOV) enabled / disabled. This bit can only be modified when RTT is disabled. The UPC bit is set to zero on reset. The LCM bit is set to zero to use the high compression mode for recording motive instruction traces and set to 1 to use the bottom compression mode. This bit can only be modified when RTT is disabled. It is set to zero on reset. The STR bit controls whether the STALL packet contains a stall reason field. STR is set to zero at reset. If LD bit is 1, AD
One or two of the V and DA bits must all be 1. If any of the ST, LR, or SR bits is 1, then one or both of the SDV and DA bits must be 1. If any of the ADV, SDV, or DA bits are 1, then data trace is enabled. If data trace or instruction timing trace is enabled, instruction trace must also be enabled to enable trace decoding. RTT_USE
SR to R, RTT_PKT_CTL, LPSTART, and LPNED registers
SDV, DA, and SR bits are ignored for instructions. RTT
Storing in _USER and RTT_PKT_CTL registers is RTT_HOST
Always written if the _CTL.NAW bit is not 1. L
Stores to PSTART and LPEND are written only when instruction trace is statically enabled. The storage in all these registers is written using the SRSPEC packet. The RTT_PKT_CTL register value is also written in each SEGSTART packet. The DTO bit controls whether the DATA packet contains a Segment Instruction Offset field. This field must be present when the data filtering is active so that the trace decoder can determine the record of load / store instructions. It is set to zero on reset. The RTT_PKT_CTL register can only be written when RTT is disabled. This is due to the SR command
Even though the RTT_PKT_CTL register can be written to, it need not be written by the host interface once RTT is enabled. This latter case enables tracing to the executing program on the core so that packet generation and format can be controlled.

RTT_EN_DIS_CTL Register The RTT_EN_DIS_CTL register must not be recorded in the packet stream when RTT is enabled or disabled and also controls the run time RTT options that can be modified. If the FT (Full Trace) bit is 1, the full trace mode is active. When activated in full-trace mode, this RTT will start stalling the core when the instruction reaches stage 4 and when all packets are potentially generated by the (some) instruction received by the packet pipeline. , Erase this stall. If full trace is active, instruction timing trace and event timing trace are disabled (ITT of RTT_PKT_CTL
And the ETT bit will be 0). The FT bit is set to zero on reset.

RTT_SEG_CTL Register The RTT_SEG_CTL register controls the generation of new segments based on the maximum instruction count. The SEGMAX field contains the maximum value for the segment instruction offset. This maximum may exceed two instructions due to pipelining in the RTT, and may exceed each instruction in the delay slot (a segment cannot start in the delay slot). Since the normal core code does not issue instructions in the delay slot, the delay slot has the effect of increasing the maximum instruction by 1 in the segment. Therefore, the maximum regirl value S for SEGMAX that can avoid the counter overflow is 0 ×
7 ffc. SEGMAX is set to this value at reset. If the SEGMAX field is greater than the current segment instruction offset, the SEGMAX limit will have no effect until the beginning of the next segment.

RTT_DIS_CTL Register The RTT_DIS_CTL register must not be recorded in the packet strip and controls the run time RTT option which can only be set when RTT is disabled. This register must not be recorded when RTT is enabled. The MM (Minimum Mode) bit is used when the capture device is set up for a "after" trigger. If MM
Is 1 and RTT is not triggered, FT (RTT_EN_DIS_
Static enable values in the EXT, APT and RTT_PKT_CTL registers (in the RTT register) are ignored and are treated as 0 except for ITT and ETT. If ITT and / or ETT is 1
If, then the timestamp is enabled and no timestamp overflow is recorded. If ITT is 1
If so, no stall packet is generated. EXT and A
No PT overruns are recorded. No buffers other than TSOV packets are generated during minimal mode, so the buffer overflow is substantially eliminated. When RTT is triggered, FT, EXT, APT and RTT_PK
The static enable value in the T_CTL register is no longer ignored. The MM bit is set to zero on reset. The INT (Interrupt) bit is statically enabled for INT packet generation. If the instruction trace is static and dynamic enabled (IT bit in RTT_PKT_CTL is 1 and dynamic enable from monitor is 1), INT bit is ignored. It is set to zero on reset. If the MD (Manual Disable) bit is 0, the RTT is disabled for one cycle after the core is disabled (that is, the halt bit in the status register is converted from 0 to 1). It is set to zero on reset. The EXT (external signal) bit is statically enabled for the generation of EXTSIG packets. It is set to zero on reset. APT (Actionpoint Event) bit is A
Statically enabled for PE packet generation. It is set to zero on reset.

RTT_BUF_CTL Register The RTT_BUF_CTL (buffer control) register controls the buffer. This register must not be recorded when RTT is enabled. If the DFR (Destable FIFO RAM) bit is 1, FIFO RAM
Access to read / write instructions RTT_FI
Started by recording in the FO_CMD register.
This mode is provided just to allow the FIFORAM to be tested, instead of requiring other structures like BIST. During normal operation, the DFR bit
Must be zero. At reset, it is set to 0. If the IO (interrupt overflow) bit is 1 and a buffer overflow occurs, the core is interrupted. If 0 is recorded in the IO bit and the interrupt is active, the interrupt remains active. Interrupt RT instruction
It is erased by recording in the T_CMD register. IO
The bit is set to 0 on reset. The MFFE (Maximum Full FIFO Entries) field specifies the maximum number of FIFO entries allowed to be completely full before the RTT clears the buffer overflow. A value equal to the total number of FIFO entries means that the FIFO has been completely analyzed,
Allow buffer overflows to be cleared.
A value of 0 means FI before the buffer overflow is cleared.
FO is forced to be free. The MFFE value is set to 0 at reset.

RTT_MON_CTL Register The RTT_MON_CTL register controls operations affecting one or more monitors. This register should not be recorded when RTT is enabled. RTT_MON_CT
The contents of the L register are as follows. The DYEN (Dynamic Enable) field contains the current value of each dynamic enable. These are set to 0 at reset. The meaning of each bit in the DYEN field is as follows. Bit 1 will be 0 if the timing trace is not in the design. If the data trace is not in the design, bit 2 will be 0. The STARTEN field contains the value of each dynamic enable used when the allow or prevent filter is inactive. These are set to 0 at reset. The PAIRS field is a 4-bit array. Bit n
If is 1, the results of the conditions for the monitors (2n and 2n + 1) are ANDed together, resulting in the conditions for the two monitors. The PAIRS field is set to 0 at reset. The QUADS field is a 2-bit array. If bit n is 1, monitor (4n, 4n +
The results of the conditions for 1, 4n + 2 and 4n + 3) are ANDed together to become the conditions for all four of these monitors. The QUADS field is set to 0 at reset.

RTT_TRIG_SRC Register The RTT_TRIG_SRC register specifies which of the possible sources caused the trigger. This register is
Set only if RTT was not previously triggered. The contents of the RTT_TRIG_SRC register are as follows. The MON field contains a bit for each monitor present in the design. If the monitor triggers RTT, the corresponding MON bit is set. The MON field is set to 0 at reset. CMD bit is RTT
1 if recording to the _CMD register triggers RTT
Is set to. The CMD field is set to 0 at reset. The SIG bit is assumed to be the input signal (rtt_tri
Set to 1 if g_on) triggers RTT. SIG
The field is set to 0 upon reset.

RTT_USER Register When recorded in the RTT_USER register, an SRSPEC packet is generated to record the value in the trace. This allows the traced program to insert "cookies" in the trace. RTT_FIFO_STAT Register The RTT_FIFO_STAT register represents the state of the FIFO. The FMT bit is 1 when the FIFO is empty and 0 otherwise. This bit is set to 0 at reset. FHD and FTL fields are
Each contains a FIFO tail pointer. Pointer is FI
This is the address for the FO memory. The FIFO is full if the pointers are the same and the FMT bit is 0. This pointer is set to 0 at reset.

RTT_FIFO_CMD Register The RTT_FIFO_CMD register is used for FIFO RAM and RTT_FIFO_D register.
Trigger data transfer between ATA0, RTT_FIFO_DATA1 and RTT_FIFO_DATAS registers. This register is RT
Only recorded when the T_BUF_CTL.DFR bit is 1. The RTT_FIFO_CMD register is provided for testing only and during normal operation the RTT_FIFO_CMD register should not be recorded. This register must not be recorded when RTT is enabled. The WR bit controls whether the FIFO RAM is recorded (WR = 1) or read (WR = 1). When the FIFO RAM is recorded, the RAM contents of the address specified by the RTT_FIFO_ADDR register are stored in RTT_FIFO_DATA0 and RTT_FIFO_DAT.
Recorded with the contents of A1 and the RTT_FIFO_DATAS register. When the FIFO RAM is read, RTT_FIFO_DATA0, R
TT_FIFO_DATA1 and RTT_FIFO_DATAS registers are RT
RAM at the address specified by the T_FIFO_ADDR register
Loaded with content. RTT_FIFO_ADDR Register The RTT_FIFO_ADDR register provides an address to be recorded or read when a read or write instruction is recorded in the RTT_FIFO_CMD register. This register must not be recorded when RTT is enabled.

RTT_FIFO_DATA0 Register The RTT_FIFO_DATA0 register maintains packet portion 0. The least significant nibble starts at bit offset 0.
If a read instruction is recorded in the RTT_FIFO_CMD register, this register will be loaded from RAM in the next week. If a write command is recorded in the RTT_FIFO_CMD register, this register will be recorded in RAM in the next week. If this register is loaded from RAM at the same time the core or host tries to record to this register, the core or host is ignored. This register should not be recorded when RTT is enabled. RTT_FIFO_DATA1 Register The RTT_FIFO_DATA1 register is the RTT_FIFO_DATA1 register, except that the RTT_FIFO_DATA1 register contains a packet portion 1.
Works the same as the _DATA0 register. This register is
It should not be recorded when RTT is enabled.

RTT_FIFO_DATAS Register The RTT_FIFO_DATAS register is the RTT_FIFO_DATAS register, except that the RTT_FIFO_DATAS register contains status bits.
Works the same as the 0 register. This register should not be recorded when RTT is enabled. The SIZE0 and SIZE1 fields are for packet parts 0 and 1.
Corresponds to each size. These are each encoded as follows.

RTT_MON_COND0 to RTT_MON_COND7
Registers Each RTT_MON_COND register is used to set up the conditions for a single monitor. If the related monitor
If not in the RTT, the read returns 0 and the record is ignored. These registers must not be recorded when RTT is enabled. Each RTT_MON
The contents of the _COND register are as follows. The DYEN (Dynamic Enable) field specifies which dynamic enable is affected by the monitor when configured as a filter. If the bit is 1, the corresponding dynamic enable (RTT_
The DYEN field in the NON_CTL register) is affected by the filter. Impact is determined by the action associated with the monitor (ACT field). The DYEN field is set to 0 when reset. SR
The C (condition source) field specifies the source value from the pipeline used for monitor condition evaluation. This field is set to 0 when reset.
The SRC field is 0 when the data trace is not present by design. The meanings of the fields are as follows.

The LD, ST, LR and SR bits specify which direction and which memory space is observed for the condition to pass. If the source is the instruction address,
These bits are ignored. If the source is a data address or data value, at least one of these 4 bits must be set.
The meanings of the bits are as follows. The REL (Condition Relation) field specifies the relation used for the monitor condition evaluation. This field is set to 0 when reset. The meaning of this field is as follows.

ACT (action) specifies the monitor operation when the monitor condition becomes true. This field is set to 0 when reset. The meaning of this field is as follows. If the TRIG field is 1 when the monitor condition occurs, the RTT will be a trigger (ignored if already triggered). RTT_MON_REF0 to RTT_MON_REF7 registers RTT_MON_REF register has 3 registers for one monitor.
Contains a 2-bit reference value. If the associated monitor is not in the RTT, the read will return 0 and the record will be ignored. These registers must not be recorded when RTT is enabled. The contents of each RTT_MON_REF register are as follows. The VALUE field is exactly 32 for the monitor.
Contains the bit reference value. This field is long-
It may include a word aligned instruction address, a 1 byte aligned data address or a data value.
This field is set to 0 when reset. If no data trace was present in the design, the most significant 8 bits of the value field would be 0, because the only reference value is the 24-bit instruction address.

Appendix IV Register Definition (Buffer / Packet Pipeline) The RTT_STAT register only the 1-bit status register corresponds to the packet pipeline. This is the overflow bit OV. RTT_S
The TAT register represents the status of RTT. If the RTT_STAT register is recorded by the core or host, then IR
The Q bit is set to 0 and all other bits are unchanged. The EN bit is 1 when RTT is enabled. This bit is set to 0 when reset. TR
Bit is 1 when RTT is triggered. This bit is set to 0 when reset. The IRQ bit is 1 if the RTT asserts the interrupt signal to ARC. This bit is 0 when reset
Is set to. The OV bit is 1 when the RTT buffer is in an overflow condition. This bit is set to 0 when reset. This field is provided for testing purposes. TSO (Time Stamp Overrun), APO (Action Point Overrun) and ES
The O (External Signal Overrun) bit is set to 1 when these corresponding mechanisms are overrun. These are set to 0 when reset. One overrun is triggered when an event is lost because it occurs further before the previous event is recorded in the packet. PMT bit is RTT
When the packet pipeline in the buffer becomes empty,
1 and 0 otherwise. This bit is set to 0 when reset. This field is provided for testing purposes. The TMT bit is
1 if the packet port is unlocked, 0 otherwise. This bit is set to 0 when reset. This field is provided for testing purposes. The UL bit is 1 when the RTT is unlocked. RTT is unlocked when the RTT_LOCK register is written with a specific value, and after the next SR instruction,
Further locked. BCBPC contains the value of the backward conditional branch path counter. This field is set to 0 when reset. This field is provided for testing purposes. LPPC contains the value of the zero-overhead loop pass counter. This field is provided for testing purposes.

RTT_CMD Register The erase buffer instruction for the RTT_CMD register effectively performs a synchronous reset on the packet pipeline. RTT
The _CMD register is used to convey one of the following instructions to the RTT. The format of the RTT_CMD register is as follows. The CMD_NS instruction starts a new segment after the next non-delay slot instruction or interrupt. If written by the SR instruction, the new segment begins after the SR instruction. The CMD_CB instruction erases the contents of the buffer. This field is provided for testing purposes.

Appendix V Example Smooth Unit Test Code Scenario DF1 Uses instruction and data cache to generate and avoid stalls. DF2 Pipeline install is not generated and a single periodic instruction is executed continuously so that the instruction is executed every cycle. DF3 Pipeline inter-stage dependency, where one stage depends on the results from the next stage. For example, non-operator Betis relies on the rewriting stage of previous instructions. DF4 A pair of instructions in which two instructions are adjacent, the second instruction uses the result produced by the first instruction, and the second instruction waits until the first instruction produces a result. Inspection against. This must be done in a continuous loop. Use this for both memory and core register access. To guarantee the delay in returning the first result, the first instruction must be ld.di. A range of instructions including operations must be used, branches and special things (flag, swi, blk, sleep)
Can be used as the second instruction. Also try different combinations of ld and ld.di orders.

DF5 Load sequence in continuous loop. DF6 The third instruction depends on the rewrite result from the first instruction. DF7 Stalls occur in stages 1, 2 and 3 of the pipeline. DF8 Stage 1 limm value stall is generated. DF9 Continuous execution of 2-cycle instructions, similar to instruction execution with proximity data. DF10 A combination of single and multi-cycle instructions. DF11 A loop in which rewriting and ALU shortening are disabled by a conditional fail, and the non-operator vector stage of the next instruction depends on rewriting. DF12 Call a subroutine from within a branch / jump loop with or without invalid delay slots. DF13 Wait for one register to be updated from the previous load, said register being one of the operands of the instruction in stage 2, a load operation. In this situation, the pipeline will stop. DF14 To cover the complete instruction set for various worst case scenarios. See test code. DF15 Use of smooth block action points and external signals. DF16 A self-modifying code that jumps to a known position from an interrupt. DF17 All stall tests applied to the zero overhead loop. DF18 Such stall test code must provide an appropriate stall reason from the generation block when used for timing trace. Flush DF19 core pipeline, then RT
Disable T.

DF20 RTT is disabled when an instruction is present in stage 4 of the pipeline. Repeat for all other pipeline stages. DF21 RTT is disabled when there are no instructions in stage 4 of the pipeline but other stages have instructions. Repeat for all other pipeline stages. Run the test code that nests the loop from within the DF22ISR. Generate a processor stall from DF23RTT. The first instruction in the DF24 ISR writes a test code such as a direct jump / branch / conditional branch. DF25 Instruction 1 exists in stage 4 pipeline, and instruction 2 stops at stage 3 at the same time, and examines the oldest instruction address signal of the smoother. If the DF26 instruction exists in stage 4 and the next instruction 2 exists in stage 1 (i-veti), that is, if there is a two-cycle stall between them, then the oldest smoother Check if the instruction address signal has the correct value. DF27 Code that executes an interrupt sequence and generates a high priority interrupt. DF28 At the same predetermined time, the following situation exists: inst1 is in stage 4, inst2 is stopped in stage 3, in
st3 causes the situation present in stage 1 to see if the oldest instruction address signal of the smoother has the correct value.

DF29 All instructions stop at stage 3,
The situation where neither is completed. When DF30 inst1 stops at stage 4 and the second instruction is at the next stage. (2 cycles stall after 1st inst), In this case, check if the oldest instruction address signal of smoother has correct value. LD + LDB + L with DF31 data trace being executed
Use DW + LD.DI, ST + STW + STB + LR + SR for continuous sequences and other combinations. Check that the generated data address and value are correct. Also use it to write to the RTT specific register. Also check the generated status register value. It also causes interrupts and stalls. The final instruction in the DF32 loop has limm data, and the final instruction is limm, but the limm data is recorded outside the loop in a zero overhead loop. DF33 pc_plus_one is the same as LP_END when zero overhead loop; final loop end instruction is next cycle /
Stalls are generated so that they do not get stuck in cycles. It also causes all three types of pipeline stalls when the final instruction with or without limm data is executed in a zero overhead loop. Run a zero overhead loop with the loop count register set to DF341. DF35 Implements a zero overhead loop with the following: That is, use the LP instruction to set up the DF35-1 loop and have only one instruction in the loop. DF35-2 Only two instructions between the setting of lp_count register and the last instruction of the loop. The DF36 final instruction is an unconditional jump instruction that triggers the loop and does not return to the loop, a zero overhead loop. Also, the final and second in the loop
Code for all forms of jump as the final instruction of. DF37 Stalls occur in a very tight zero overhead loop with timing and data traces performed. It also spawns all other packet types within the zero overhead loop. DF38 In a zero overhead loop, it tries to generate loop trigger, segstart, timestamp overflow and all possible packets in the same cycle. DF39 Conditional and unconditional zero-overhead loops that end with other forms of jump and link instructions, with sequences of same forms of jumps and other forms of jumps.

DF40 Very strict zero overhead loop with final instruction with limm data, loop is
Use such a loop when generated using the SR instruction rather than LP. When the last command is limm data, it will generate all other possible packets in the same cycle. DF41 In the zero overhead loop, just LP_END
Use the SR instruction to set the register only and not the LP_START register. Run a zero overhead loop. Use the DF42 load / store instruction, the stall caused by the delayed load, and the next instruction waiting for the result from the previous load instruction. Use a load store instruction in a zero overhead loop. Use load / store instructions in delay slots. A zero overhead loop constructs a second final instruction, a load instruction and a final instruction, the final instruction depending on the result of the previous load. DF43 Use brake and sleep instructions in zero overhead loop.

Appendix VI Definitions: Monitor Configuration: Determines what monitors are configured and used in this test; pairs and 4 pairs are represented by "&". Source: The source comparison bus can be an address (IA), data address (DA) or data value (DV). Relationship: Select the comparison operation to be performed on each monitor. Data command: If the source is DA or DV, select the command for monitor comparison. Trigger: Set the trigger bit in the monitor condition register, the RTT should trigger when the monitor condition is true. Action: Determine how the monitor will affect the dynamic enable etc.

Appendix VII Example Generation Unit Test Code Scenario DG1 Packet generation for instruction trace, data trace, timing trace, action trace, action point and external signal. These forms of trace must be generated individually and in other combinations. The DG2 RTT generation block can generate control data, instruction execution, loop trigger, and delayed load data packet at a predetermined time. The test code tries to generate such things at the same time. Also check that the generated data packet has no holes. DG3 Test code that has to generate new category packets of any category in each clock cycle and one or more packets in each cycle. DG4 Access other channels of the memory controller using a combination of ld and ld.di instructions for all trace configurations. Check for DG5 Data Trace Segment Offset Address Both 3-bit and 15-bit addresses are recorded in the data packet. Since the packets output from the DG6 generation block must maintain a sequence of control, instruction execution, loop triggers and delayed loads, so that the code will generate them etc. in a defined time in a continuous loop. Run and inspect the sequence. It also tries to generate an overflow condition with it.

DG7 Check for both low / high compression packets generated and if traces can be regenerated from them. Switch between low / high compression modes at run time. DG8 Delta encoding allows partial instruction and data addresses to be stored. When running test code with instructions / data mapped to different parts continuously, jumps to these parts cause a total of 6/8 nibbles change in the instructions / data. All packets generated must have the full 24/32 bit address. It is also used in combination with interrupt generation. DG9 Generates a SEGSTART in the same cycle with an IA packet for full 24 and 32 bit indirect jumps and loads. When SEGSTART and interrupt are generated in the same cycle, the first instruction in the ISR is an indirect jump / load / store with a complete 24/32 bit address change. DG10 Attempt to execute code with the instruction limit value specified for each segment. On each instruction limit, a new segment of trace must start. In the meantime, it also disables RTT, which also starts a new segment. Each instruction execution can reduce the instruction limit value to 1 to start a new segment. DG11 The test code that causes a buffer overflow is continuously executed for the specified buffer size. Erasure of a new segment must start for each overflow. Decreasing the buffer size to a minimum value will create a new trace segment when each overflow is cleared. When the DG12 code is running, it uses an external signal to generate a new segment of the trace.

When the DG13 code is executing, it uses the instruction register to generate a new trace segment. A segment is generated by enabling and disabling RTT. Trigger the DG14 RTT and enable instruction trace to create a new segment and also use a filter to accomplish this. When using such a method, the buffer size is reduced and the instruction limit value is reduced to the minimum value. Attempts to use an external signal to start a new segment. This can be accomplished by disabling and then enabling and then triggering, or simultaneously enabling and triggering. When an instruction is executed in the DG15 delay slot, it creates a new segment using all the methods described above. It also disables RTT when a delay slot instruction is executed. DG16 Dynamically enable other trace configurations
/ Write to disable. For the DG17 data trace, generate all the above new segment generation methods. It has a branch at the end of DG18 loop and writes the code that causes BCBPC overflow and LPPC counter overflow. DG19 Interrupts a new segment that is also generated in another cycle, or continuously executes a code that generates an instruction address in the same cycle. If new segments are not generated in the same cycle, the instruction address is
The instruction address recorded in SEGSTART must be used. Repeat for the data trace. [D
G9]

DG20 Instruction trace using conditional / unconditional, sequential minutes, jumps, loops, short / far jumps, direct / indirect jumps and other worst-case combination of these instructions. To generate. DG21 Generate both PF and counter value packets for backward conditional branch instruction (BCBPC) using code. Use the counter method for DG22 BCBPC and the loop in between to generate IA, PF, DATASRSPEC, LPTRIG, and all other packet forms and return further to the BCBPC loop. DG23 BCBPC instruction checks the condition that the counter is never updated. That is, the condition fails at the first moment. Implemented with DG22. DG24 Such as combined with other control packet generation
Causes maximum overflow for BCBPC counters and other counter overflows such as timers. DG25 Generate multiple levels of nested loops and use branches and zero overhead loops within them. DG26 For each instruction execution, create a new segment by decreasing the buffer size or instruction limit / segment, use BCBI to generate a counter overflow and fail on the first execution, and Between these, IA, PF, DATA SRSPEC and LPTRIG packets are generated. DG27 BCBI Loop and counter / PF method to generate interrupt. In the DG28 BCBI loop, one segment and one of BCBPC and LPPC packets are generated in the same cycle. DG29 All BCBI for zero overhead loop
Repeat coverage case. With DG30 SEGSTARTS, all overflows, SICs
Generate OV, BCBPCOV, LPPCOV, TSOV.

Generate a DG31 BCBPC / LPPC count value,
And while generating a DLDD between them, the counter must be reset when a DLDD packet is input. It creates a BCBPCOV packet with LPPC and vice versa. It also attempts to erase both the BCBPC and LPCC counter values. It also relies on the DG32 address space (memory and auxiliary registers) to generate traces for data addresses and data values. (LD / ST from memory / auxiliary and special registers or here). (DATA / DLDD / SRSPEC packet). Static
/ USE with or without dynamic enable
Generate SRSPEC by writing to the R / PKT_CTL register. LPSTAR with or without instruction enable
Write to T / LPEND. Use a data filter with the DG33 data trace to check if a segment instruction in a data packet can generate a trace for every packet generated (DATA / DLDD / SRSPEC packets). When segment command offset for DG34 data packet is enabled, SEGSTART and
Try to generate DATA or SRSPEC or INT. Use external signals and action points to generate event traces with or without DG35 time stamps. Combine event traces with instruction and data traces. DG36 Timestamps for instructions and lazy load data, events (ap, ext signals, interrupts and SEGSTA
RTS) to generate instruction and event timing traces. Reduce the buffer size (or use the SR instruction) so that more frequent SEGSTARTS are generated with such traces. This is done continuously to generate a timestamp overflow. Attempts to generate overflows and events in the same cycle. DG37 Run test code with no stall packets generated with timing trace enabled. DG38 Stage R1 records a timestamp overflow, and at the same time creates a situation where a buffer overflow occurs and no timestamp overflow is recorded. DG39 Generate stall packets by enabling instruction-timing traces with event timing traces. Attempts to generate a stall overflow and at the same time dynamically generates a disable / enable instruction trace. INT and multiple SEGSTARTS with stall overflow / stall packets
To generate. Also, when a stall packet is generated,
Try to trigger an external event. BCBPCOV, LPPCO when stall / overflow packets are generated
Generate V, TSOV. In addition to the stall generation, all other types of packets are generated.

With the DG40 SICOV packet, generate all other packets that provide the PC value in the same cycle and the previous cycle. It also creates a packet that does not create a PC value. DG41 Stalls and overflows are generated for the following reasons. Solid delay (eg I-cache loss), load-use, load-return (only with 3 port register file / 4 port register file), load / store queue full, multi-cycle instruction, dependency (eg,
Non-shortened registers, flag settings with conditional jumps / branches, etc.), interrupts, long-proximity data, aborted delays-slot instructions, extension instructions, brake instructions or action point triggers, single-stage or instruction-stage Processor in mode. It also creates a stall overflow with all other control packets. DG42 Only after a single / multiple timestamp overflow is generated, a timestamp overflow is generated or a buffer overflow is erased through a buffer overflow in the same cycle. This should generate a timestamp overrun. Also, all control packets are generated with time stamp overflow. DG43 SEGSTART, instruction trace dynamic enable, external signal event, action point and timestamp overflow are generated in the same cycle. The order of the packets is maintained by the production block. Run in a continuous loop. DG44 Enable RTT, disable RTT without executing any instruction. No start of segment should be generated. Set the trigger to 1 while the DG45 RTT enable is 1. SEGSTART must have a reason such as REASON_TRIGGERED. The same applies when the trigger is 1 and the enable is 1. DG46 Trigger is "0" and RTT enable is "0".
When changing from '1' to '1', REASON_ENABLED must be generated. DG47 REASON_BUF_OV_CLR_AND_TRIGGERED, REAS
Generate ON_BUF_OV_CLR as the reason for SEGSTART. DG48 Generate all or part of the eight possible SEGSTART reasons in the same cycle and observe that priority is maintained.

DG49 Use test code to continuously generate other packets, disabling RTT when packets are still moored in the generate block.
All packets moored to the production block must be flushed and then a SEGSTART packet must be produced. In any case, SEGSTA
RT must not be lost. The same is repeated for the DATA trace and the timing trace. DG50 SEGSTART packet disabling RTT runs test code in a continuous loop to be generated for all other possible reasons. Such a test code shall have the following cases: DG50-1 There is no delay slot instruction after every SEGSTART reason. DG50-2 Delay slot instruction after all SEGSTART reasons. DG50-3 Many delay slot instructions after SEGSTART. DG50-4 Interrupt after SEGSTART reason. DG50-5 Interrupt possible in delay slot after SEGSTART reason. DG50-6 A large number of instructions that are not in the delay slot or are in a delay slot with interrupts. DG50-7 Limm in delay slot after SEG START. DG51 A large number of external signal triggers are continuously generated so that all external signal packets are not generated. DG52 Generates a large number of action point packets with or without other control packet generation in the same cycle. Also, the action point event is generated earlier than the APE packets are continuously generated. DG53 Generates multiple timestamp overflows with or without other control packets in the same cycle.

DG54 LPSTART and L in the 1st segment
The zero overhead loop code is executed serially so that the PEND signal is recorded and then executed several times to form a loop within the same segment. Continue the loop with another new segment, but this is
Must generate LPTRIG packet. It also implements another zero overhead loop mechanism in which the loop trigger and SEGSTART occur in the same cycle. LP
The same repeats when END is recorded in the first segment and LPSTART is recorded in the next segment and vice versa. DG55 Status register functional test. DG56 RTT_PKT_CTL register functional test. Test RTT in DG57 FT mode. DG58 Write test code to generate and cover other packet sizes for all packet types. DG59 When there are packets in stages r3, r2 and r1, it causes a buffer overflow and writes code with some packets detected in the generated block. All such things must be discarded. Also, after the buffer overflow is generated,
Packet generation must continue and these packets must also be dropped. DG60 Eliminate buffer overflow and generate all other packets in the same cycle. Then, a large number of packets are generated again in the same cycle. Also, depending on the packet category, another packet is generated at the instant of overflow. DG61 In addition, the buffer critical value is changed so that the overflow is erased when the packet pipeline is empty, and the whole and many packets are generated in the same cycle.

Appendix VIII Example Buffer / Packet Port Test Code Scenario DB1 Resize buffer from maximum / minimum to recommended value and generate with other user configurable buffer overflow scenarios (captures are immediately erased or de-enabled to overflow buffer in overflow conditions) Get the throughput for the maximum output from the block. Uses both low / high compression to generate packets. Run test code that should handle buffer overflow interrupts, and test frequent interrupt generations and treat them the same. To change the width / depth of the DB2 register array,
Configure the packet pipeline and execute the developed test code. DB3 Reduce the buffer size so that frequent overflows occur. DB4 packets with a nibble width of 7 or less,
One is generated every cycle and four pieces are continuously generated every cycle. The DB5 packet has a width of 8 nibbles, one for each cycle and four for each cycle. DB6 packets with a width of 9 nibbles or more are continuously generated, one per cycle and four per cycle. DB7 One maximum size packet for all categories is generated in each cycle, and four of these are continuously generated in the same cycle. When entering the DB8 pipeline, create a packet so that it does not occupy all packet parts. The pipeline must pass the part as it is, but the port must remove unnecessary bits from the part. DB9 Then, no data is applied. That is, all zeros are applied.

DB10 SE for every 7 cycles
Generate GSTARTS. DB11 2,3 until all packets are covered
SEGSTART with other category packets of the same also combines other control category packets in the same manner. DB12 Generates a packet with 3 consecutive zero nibbles and 3 or more consecutive zero nibbles, and also tries to generate most possible nibbles that pack the packet. DB13 The output packet sequence must be maintained, changing other packet categories in the same cycle. After the DB14 FIFO is full, test whether to release the data without loss or accept the data with the correct critical value. Write the case where the counter of the packet pipeline overflows with 32 or more IE and DLDD packets continuously generated without any other control category packet between DB15.

[Brief description of drawings]

FIG. 1 is a functional block diagram illustrating one exemplary structure of an integrated circuit device including a processor core and an RTT unit according to the present invention.

FIG. 2 is a functional block diagram illustrating an exemplary embodiment of an apparatus provided with an internal host storage device for storing data trace information according to the present invention.

FIG. 3 is a functional block diagram illustrating a second exemplary embodiment of an apparatus for storing data trace information according to the present invention, in which an external storage device is provided in an intermediary device.

FIG. 4 is a logical flow chart illustrating a general methodology for trace compression using delta encoding in accordance with the present invention.

FIG. 5a is a packet form encoding according to the present invention.
FIG. 3 is a graphic representation of an embodiment of a (first nibble), and b is a graphic representation of an embodiment of a packet form encoding (second nibble) according to the present invention.

FIG. 6a is a diagram showing the operation of the maximum compression synchronous instruction trace of the present invention with respect to conditional / unconditional branch, jump and other operations, and b is conditional / unconditional branch, jump and FIG. 8 is a diagram showing the operation of the external monitor synchronization instruction trace of the present invention regarding other operations.

FIG. 7 is a functional block diagram showing a second exemplary structure of an integrated circuit device including a processor core and an RTT unit according to the present invention.

FIG. 8A is a functional block diagram showing a first embodiment of a packet pipeline having an RTT structure according to the present invention;
FIG. 6 is a functional block diagram showing a second embodiment of the RTT structure packet pipeline of the present invention.

FIG. 9 is a functional block diagram illustrating one exemplary packet pipeline FIFO device according to the present invention.

FIG. 10 is a graphic representation of an exemplary arrangement of packet parts according to the present invention.

FIG. 11a is a functional block diagram illustrating an exemplary software driver interface and configuration according to the present invention.

FIG. 11b is a diagram illustrating an exemplary embodiment of a dialog GUI for configuring a trace set used in the RTT driver of the present invention.

FIG. 11c illustrates an exemplary embodiment of a filter editor dialog GUI.

FIG. 11d is a diagram showing an example of code and variable browsing used in the software driver of the present invention.

FIG. 11e is a diagram showing an example of code and variable browsing used in the software driver of the present invention.

FIG. 11f is a diagram showing one exemplary GUI for analyzing trace results.

FIG. 12 is a functional block diagram illustrating one exemplary software driver structure according to the present invention.

FIG. 13 is a functional block diagram illustrating one exemplary monitor bus structure according to the present invention.

FIG. 14 is a functional block diagram illustrating one exemplary RTT monitor unit structure according to the present invention.

FIG. 15 is a functional block diagram illustrating an exemplary monitor combination (eg, 1 pair, 4 pairs) according to the present invention.

FIG. 16 is a functional block diagram illustrating the interaction of a combined monitor and dynamic enable.

FIG. 17 is a functional block diagram illustrating one exemplary packet port structure according to the present invention.

FIG. 18 is a graphical representation of an exemplary “nibble stuffing” method in accordance with the present invention.

FIG. 19 is a timing diagram illustrating operation of an exemplary embodiment of a packet port clock.

FIG. 20 is a functional block diagram of one exemplary test bench apparatus according to the present invention.

FIG. 21 is a graphical representation of one exemplary directory structure used in connection with testing RTT units of the present invention.

FIG. 22 is a functional block diagram illustrating a second exemplary structure of an integrated circuit device including a multiprocessor core and an RTT unit.

FIG. 23 is a plan view of the integrated circuit device of FIG. 1 showing the general layout of the die.

FIG. 24a is a logical flow chart illustrating a general methodology for obtaining trace data from a processor according to the present invention.

24b is a logical flow chart illustrating the method of FIG. 24a using internal storage mode.

24c is a logical flow chart illustrating the method of FIG. 24a using external storage mode.

[Explanation of symbols]

100 devices 101 integrated circuit device 102 RTT unit 105 processor core unit 107 Debug Port / Interface 109 packet port 112 shared buffer 131 processor core unit core 140 Trace capture unit 142 monitor unit 144 generation unit 146 control unit 148 Action Point Trigger Generator 152 Trace signal 160 external input interface 702 RTT unit 709 packet port 712 packet buffer 742 monitor unit 744 generation unit

─────────────────────────────────────────────────── ─── Continuation of front page (51) Int.Cl. ⁷ Identification code FI theme code (reference) G06F 15/177 678 G06F 15/177 678H 15/78 510 15/78 510K F term (reference) 5B042 GA11 GA33 GC08 HH30 MA15 MA19 MC40 5B045 JJ02 JJ08 JJ49 5B048 AA12 BB02 DD08 FF03 5B062 CC01 JJ08 5B083 CC10

Claims (60)

[Claims] 1. At least one digital processor core adapted to execute a plurality of instructions, and receiving a plurality of data from the at least one processor in connection with execution of at least some of the instructions. And at least one trace unit adapted to generate a plurality of data packets associated therewith, perform data communication with the at least one trace unit, and store at least a portion of the plurality of packets. And at least one storage device adapted to perform data communication with the at least one storage device and transmit at least a portion of the data packet to one processing device. A device that includes a port and. 2. The processor core includes a pipelined reduced instruction set computer (RISC) having at least one extension instruction, and at least some of the instructions include the at least one extension instruction. 1. The device according to 1. 3. The apparatus of claim 1, wherein the core processor core, trace unit, and storage device include a single integrated circuit die. 4. The data packets are at least partially compressed using a data compression technique.
The device according to. 5. The compression technique comprises:
The apparatus according to claim 4, including an encoding (delta-encoding). 6. The apparatus of claim 4, wherein the compression technique comprises variable size encoding of the data. 7. A random access memory (RAM), and a memory controller operatively connected to the RAM and the at least one processor core, the RAM being at least a portion of the plurality of instructions. The apparatus of claim 1, wherein the apparatus stores: 8. The at least one trace unit is adapted to perform data communication with the at least one processor core, and to observe and capture trace data of the processor core. At least one monitor unit adapted to receive the trace data from the at least one capture unit and filter the trace data; and receive the data from the at least one monitor unit, the at least one trace unit At least one generating unit adapted to generate the data packet for transmission from
The device according to. 9. The plurality of digital processor cores,
At least two of these cores include a plurality of digital processors having trace units associated between them, a first port, and an arbitration unit for performing data communication with the at least two trace units and the first port. As the first interface unit, the data processing device including the first interface unit, wherein the arbitration unit is adapted to arbitrate access to the first port between the trace units. 10. The first interface unit further includes a shared buffer, the shared buffer is in data communication between the first port and the arbitration unit, and the shared buffer is a plurality of data generated by the trace unit. Applied to store packets,
The data processing device according to claim 9. 11. The system further includes a second interface unit for performing data communication with the processor core, and a second port for performing data communication with the second interface unit, wherein the second port and the interface unit are the processor. The data processing device of claim 9, which is operative to transfer data between the core and an external host computer. 12. The system further comprises a second interface unit for performing data communication with the processor core, and a second port for performing data communication with the second interface unit, wherein the second port and the interface unit are the processor cores. 11. The data processing device according to claim 10, which operates to transfer data between the computer and an external host computer. 13. The data processing apparatus according to claim 10, wherein the shared buffer emits packets in real time to an external capture device via the first port. 14. The at least one capture unit adapted to perform data communication with an associated processor core to observe and capture trace data of the processor core, and the at least one capture unit. At least one monitor unit adapted to receive the trace data from the capture unit and filter the trace data; and a plurality of data for receiving the trace data from the at least one monitor unit for transmission from the trace unit. 10. The data processing apparatus of claim 9, further comprising at least one generating unit adapted to generate the packets of. 15. Each of the trace units is adapted to perform data communication with an associated processor core and to observe and capture trace data of the processor core, and the at least one capture unit. At least one monitor unit adapted to receive the trace data from a capture unit and filter the trace data; receive data from the at least one monitor unit and transmit the trace data to the shared buffer. The data processing apparatus of claim 10, further comprising at least one generating unit adapted to generate the data packet under at least partial control of an arbitration unit. 16. The control unit further comprising a control unit that communicates with the second interface unit and operates to selectively connect the processor core to the second port via the second interface unit.
1. The data processing device according to 1. 17. The data processing device according to claim 16, wherein the control unit reads and writes at least one register of the processor core. 18. The control unit further includes a control unit that communicates with the second interface unit and operates to selectively connect the processor core to the second port via the second interface unit. 12. The data processing device according to item 12. 19. A method of compressing a plurality of data bytes to form a data packet representing at least a portion of a digital processor trace, the method representing a first frequency of values occurring within the plurality of data bytes. Providing a first coding, providing a second coding that represents a second frequency of values occurring in the plurality of data bytes, and generating the data packet using the first and second codings And compressing the data packet, wherein the first and second codes include a plurality of data nibbles. 20. The compression method according to claim 19, wherein the step of providing first and second coding comprises determining an expected probability distribution of the values. 21. A method of processing trace data having a plurality of data bytes, the method comprising compressing the plurality of data bytes having a plurality of data nibbles, (i) storing at least a portion of a first value. And (ii) referencing the at least a portion of the first value with respect to a previously encoded second value, the at least first portion including the second value and another data nibble. A data processing method comprising: a compressing step including only the above, forming a plurality of data packets using the compressed data bytes, and storing the plurality of data packets in a storage device. 22. The data processing method according to claim 21, wherein the first and second values include identifiable instruction addresses. 23. The data processing method according to claim 21, wherein the first and second values include identifiable data addresses. 24. A method of processing a data packet within a digital processor trace unit, comprising: providing at least one first address having a predetermined first size; and at least one having a variable second size. Providing two second addresses, encoding the at least one first address in at least one first packet, encoding a first address including a field value of a first size, and at least one Encoding the at least one second address in a second packet, the encoding of a second address including a field value of a second size that is not equal to the field value of the first size. One first Packet, the first based on the size field is processed as a pool packet, said at least one second packet, the processing method of the data packet to be processed as a partial size packet based on the second size field. 25. The step of providing at least one first address comprises the step of providing at least one 24-bit instruction address, the second size field value being less than the first size field value. 24. A data packet processing method as described in 24. 26. The step of storing the at least one first address in a corresponding register; the step of storing the at least one first and second packet in a storage device; and the first address stored in the register. 25. determining a pool address associated with the at least one second packet in the storage device based on at least a portion of the method of claim 24. 27. The step of determining the pool address determines the pool address associated only with the address of at least one second packet that is older than the oldest packet of the same form having the pool address. 27. The method of processing a data packet of claim 26, including: 28. A method of compressing data associated with a digital processor trace, the first aspect as a step of analyzing the data to identify multiple occurrences of the at least first and second aspects of the data. Data is derivable from a source code representation and the second form of data is not derivable from the representation, including a data analysis step and storing only the occurrences of the second form data in a storage device, A method of compressing data, wherein said generation of said first form of data during decompression is derived from a representation of said source code and said generation of said second form of data is retrieved from said storage device. 29. A method of obtaining trace data from at least one operating digital processor, the method comprising: providing a trace unit adapted to receive data from the at least one processor; Generating a plurality of packets related to the operation of the processor based on data, storing at least a part of the plurality of packets in a storage device, and performing data communication with the storage device from the storage device Removing the packet through one port. 30. The method of claim 29, further comprising compressing the data in the step of generating the packet. 31. The data comprises a plurality of data bytes having a plurality of nibbles, the data compressing step comprising: (i) storing at least a portion of the first value; and (ii) storing the first value. 31. The method of data acquisition according to claim 30, comprising the step of referencing at least a portion to a previously encoded second value, the at least first portion containing only the second value and other data nibbles. 32. The compressing step comprises: analyzing the data to identify multiple occurrences of at least first and second forms of data, the first form of data being derivable from a source code representation. The data of the second form cannot be derived from the representation, the data analysis step and the step of storing only the occurrence of the data of the second form in a storage device, the data of the first form being decompressed. The method of claim 30, wherein the occurrence is derived from the source code representation and the occurrence of the second form of data is retrieved from the storage device. 33. The method of claim 30, further comprising filtering the data received from the at least one processor in the packet before generating a corresponding packet. 34. The at least one processor is
Including a plurality of processors having respective trace units, the method comprising: generating a plurality of packets within the respective trace units; and arbitrating access to the storage device between the respective trace units of the processors. 31. The data acquisition method according to claim 30, further comprising: 35. The step of generating includes the step of generating a plurality of identifiable traces associated with the operation of the at least one processor, the traces from a group including instruction traces, data traces, and timing traces. 30. The data acquisition method according to claim 29, which is selected. 36. A structure of a packet port useful for transmitting data between a trace unit and a capture device, the structure adapted to store a plurality of packet data at least temporarily. A plurality of no-multiplexers having a device, a plurality of inputs and at least one output, each input being adapted to receive at least a portion of the packet data from the storage device; A packet including a plurality of terminals for data communication between a capture device and at least one output of each of the plurality of multiplexers, and at least one control circuit configured to generate a signal for controlling the operation of the multiplexer. Port structure. 37. A monitor unit adapted for use with a trace unit associated with a digital processor, the logic unit adapted to output a signal logically related to a plurality of inputs; An instruction decoder having an input and an output including one of the inputs to the logic unit; a plurality of inputs; and an output including one of the inputs to the logic unit A first multiplexer, a plurality of inputs each, and an output including at least two of the plurality of inputs of the first multiplexer,
A first and a second arithmetic unit having a plurality of data, and an output adapted to store a plurality of data and having a data communication with at least one of the inputs of the first and the second arithmetic unit. A monitor unit including a register, a second multiplexer having a plurality of inputs, and one output in communication with at least one of the plurality of inputs of each of the first and second arithmetic units. 38. The monitor unit of claim 37, wherein the inputs of the instruction decoder and the second multiplex are at least partially related to a signal generated by a smoothing unit. 39. The smoothing unit receives (i) a plurality of signals from a processor pipeline, (ii) processes all signals associated with a particular instruction in the pipeline, and outputs the same clock. 39. A monitor unit according to claim 38, adapted to be effective on a cycle. 40. A structure of a multiple monitor unit for use in a trace unit for a digital processor, the first logic unit being adapted to produce an output logically associated with a plurality of first inputs; An input and the plurality of first of the first logic units
A first monitor unit having one output including one of the inputs, a plurality of inputs, and an output including one of the first inputs of the first logic unit;
A second monitor unit having at least (i) the output of the logic unit, and (ii)
A multiplex monitor unit structure including a multiplexer adapted to multiplex a plurality of inputs including the output of the first monitor unit to at least one no-multiplexer output. 41. As a second logic unit adapted to produce an output logically related to a plurality of second inputs, at least one of said second inputs is said output of said first logic unit. As a third monitor unit having a second logic unit including a plurality of inputs and an output, the output of the third monitor includes one of the plurality of second inputs of the second logic unit. Third
The multiple monitor structure of claim 40, including a monitor unit. 42. The multiple monitor structure according to claim 41, wherein the third monitor unit includes a single monitor unit. 43. The first or second monitor unit is adapted to output a signal logically related to a plurality of inputs, a monitor logic unit, one input, and the inputs of the logic unit. An instruction decoder having one output including one of the plurality of inputs, a first monitor multiplexer having a plurality of inputs and one output including one of the inputs of the logic unit, and a plurality of inputs; A first and a second arithmetic unit having one output including at least two of the plurality of inputs of the first monitor multiplexer, the first and second arithmetic units being adapted to store a plurality of data; A register having two arithmetic units and an output for performing data communication with at least one of the inputs; a plurality of inputs; and the respective first and second arithmetic units 41. The multiple monitor structure of claim 40, comprising a second monitor multiplexer having at least one output in communication with at least one of said plurality of inputs. 44. A circuit having a plurality of inputs and at least one output for use in a trace unit associated with a digital processor, the priority logic circuit having a plurality of said inputs and a plurality of outputs. A first flip-flop adapted to produce a first output signal, a second flip-flop adapted to produce a second output signal, a plurality of inputs and one output As a first signal selector, the output of the first signal selector includes one input of the first flip-flop, and at least one of the outputs of the priority logic circuit is one of the first selectors. As a second signal selector having a first signal selector including an input and a plurality of inputs and one output, the output of the second signal selector is the second free selector. Wherein one input of flop-flop, at least one of said output of said priority logic comprises at least one input of said second selector circuit and a second signal selector. 45. The circuit of claim 44, wherein the outputs of the first and second flip-flops include the inputs of the first and second signal selectors, respectively. 46. The circuit of claim 45, wherein the output of the first flip-flop also includes the input of the second signal selector. 47. The circuit of claim 46, wherein the selector comprises a multiplexer. 48. The circuit of claim 44, wherein the plurality of inputs of the priority logic circuit include an output of each monitor unit. 49. For use with a processor trace unit, buffering a plurality of data packets between at least one pipeline having a first data width and a first clock domain and a packet port having a first clock domain. A dual port RAM having a second data width smaller than the first data width, the storage device being adapted to: (i) the RA of the data packet;
A storage device in which writing to M is substantially tuned to the first clock domain, and (ii) reading of the data packet from the RAM is substantially tuned to the second clock domain. 50. The storage device of claim 49, wherein the first clock domain comprises a clock of the trace unit. 51. The storage device of claim 50, wherein the RAM further comprises a depth and the second data width is fixed, but the depth is user configurable when building the processor and trace unit. . 52. A processor core, a trace unit for performing data communication with the core, a host unit, a host interface for providing data communication between the core and the host unit, and a trace unit generated by the trace unit. A processor observation system including a capture device adapted to capture a plurality of data packets and deliver at least some of the packets to the host unit. 53. The processor observation system of claim 52, wherein the trace unit, processor core, and host interface are located on a single integrated circuit die. 54. The trace unit is adapted to smooth pipeline data received from the core; a smoothing unit; operatively connected to the smoothing unit to selectively collect data from the smoothing unit. Applied to pass,
A monitor, a generation unit adapted to generate a plurality of data packets based on the path data from the monitor, and performing data communication with the generation unit,
53. The processor observation system of claim 52, including a buffer adapted to buffer at least a portion of the plurality of data packets for subsequent transmission to the capture device. 55. The processor observation system according to claim 54, further comprising a packet port for performing data communication between the buffer and the capture device. 56. The host unit includes a user interface, a debugger program operatively communicating with the user interface, a host driver operatively communicating with the debugger program, the host driver, the capture device, and an operative device. And a first communication driver module for communicating with the core, at least the user interface, the debugger program, the host driver, and the first communication driver module allow a user to observe data generated by the trace unit in association with the core. 53. The processor observation system of claim 52, which operates as follows. 57. The processor observation system of claim 56, further comprising a second communication driver in operative communication with the debugger program and the host interface. 58. A host unit adapted for observing data at least partially generated by an associated processor observing unit in relation to operation of a digital processor, the user interface comprising: a user interface; A debugger program that communicates dynamically, a host driver that operatively communicates with the debugger program, and a first communication driver module that operatively communicates with the host driver and the processor observation unit. The host unit, the program, the host driver, and the first communication driver operate to enable a user to observe data associated with the processor generated by the observation unit. 59. The host unit of claim 58, further comprising a second communication driver operative to perform data communication between the host driver and the digital processor. 60. A pipeline processor core, a smoothing unit adapted to smooth pipeline data received from the core, and operatively connected to the smoothing unit to select data from the smoothing unit. And a generation unit adapted to generate a plurality of data packets based on the path data from the monitor, and a data communication between the generation unit and an external device. A buffer adapted to buffer at least a portion of the plurality of data packets for subsequent transmission to the integrated circuit.