Patent Application
20130067284
This invention relates generally to processing trace information to identify hardware and/or software problems. More particularly, this invention relates to compact trace formats for utilization in a multi-processor environment.
The PDTrace™ architecture refers to a set of digital system debugging methodology and its implementations available through MIPS Technologies™, Inc., Mountain View, Calif. The PDTrace™ technology is described in U.S. Pat. Nos. 7,231,551; 7,178,133; 7,055,070; and 7,043,668, the contents of which are incorporated herein by reference.
Current PDTrace™ technology supports single processor systems. It would be desirable to extend PDTrace™ technology to support multi-processor systems.
Time stamps or other high overhead techniques may be used to organize trace information from multiple processors. However, this results in voluminous information and large computational demands. Similarly, tracing information in a multi-processor system may result in information overload and long processing times.
Therefore, it is desirable to condense the amount of information to be processed, while still providing adequate information to support meaningful debugging operations. Ideally, different trace formats would be provided depending upon debugging requirements. In addition, an efficient technique to correlate information from different trace streams is desirable to reduce information bandwidth and processing times.
The invention includes a method of coordinating trace information in a multiprocessor system. Processor trace information is received from a set of processors. The processor trace information from each processor includes a processor identity and a coherence indicator that demarks selective shared memory transactions. Coherence manager trace information is generated for each of the processors. The coherence manager trace information for each processor includes trace metrics and a coherence indicator.
The invention also includes a system with a set of processors generating multi-processor trace information. Each processor of the set of processors generates trace information and a coherence indicator for a set of transactions. A coherence manager generates multi-processor trace messages that include coherence indicators. A computer organizes, in accordance with the coherence indicators, the multi-processor trace messages into different trace streams. The different trace streams are the debugged.
An embodiment of the invention includes a computer readable storage medium with executable instructions to characterize a trace information controller. The executable instructions define a serializer circuit to form serialized trace information derived from trace information from a set of processors. A serialized request handler provides global transaction ordering of the serialized trace information and provides serialized request handler trace frames. An intervention unit sends coherent requests to the processors, receives coherent responses from the processors, and generates intervention unit trace frames. A coherence manager trace control block processes the serialized request handler trace frames and intervention unit trace frames to produce trace words.
The invention is more fully appreciated in connection with the following detailed description taken in conjunction with the accompanying drawings, in which:
Like reference numerals refer to corresponding parts throughout the several views of the drawings.
The computer 120 includes standard components, such as input/output devices 122 connected to a central processing unit 124 via a bus 126. A memory 128 is also connected to the bus 126. The memory 128 includes a debug module 130, which includes executable instructions to debug trace information from multiple processors. The debug module 130 includes executable instructions to process condensed coherence indicators of the invention to isolate individual trace streams associated with individual processors. The debug module 130 also includes executable instructions to process trace metrics, processor identifiers and various information in PDTrace™ technology trace formats, as discussed below. The debug module 130 also includes executable instructions to evaluate interactions between processors, as indicated in the traced information.
The next operation of
Individual processor trace streams can be identified 204. For example, the debug module 130 may process core trace messages and trace messages from the coherence manager to recreate an accurate execution trace. The coherence indicators of the core trace messages are correlated with the coherence indicators of the coherence manager trace information to identify individual trace streams.
Once individual trace streams have been identified, individual trace streams may be debugged 206. In particular, the individual trace streams may be debugged for hardware and/or software problems. Information in individual trace streams allows one to debug interactions between the individual processors of the multi-processor system.
The multi-processor system 102 may also include an input/output coherence unit 304 to process requests from input/output units (not shown). Traffic from the processors 302 and input/output coherence unit 304 is applied to a coherence manager 310. The coherence manager 310 queues, orders and processes all memory requests in the multi-processor system. The processors of the multi-processor system communicate with one another through shared memory regions. The coherence manager 310 serializes memory operations and provides global ordering of memory operations.
The coherence manager 310 includes a circuit 312 to serialize requests. Serialized requests are then processed by the serialized request handler 314. The serialized request handler 314 provides global transaction ordering. More particularly, the serialized request handler 314 interprets and routes each request to a memory interface, a memory mapped input/output interface or the intervention unit 316.
The serialized request handler 314 routes coherent requests to the intervention unit 316, as shown with arrow 318. Non-coherent requests to memory or memory mapped input/output are also controlled by the serialized request handler 314, as shown with arrow 319. The serialized request handler 314 also sends a coherence indicator to the intervention unit 316, as shown with arrow 320. The coherence indicator is periodically referred to herein as “COSID or “CSyncID”. A trace enable signal is also applied to the intervention unit 316 from the serialized request handler 314, as shown with arrow 322. This signal helps the intervention unit identify transactions that are traced by the serialized request handler. This in turn enables the intervention unit to only trace transactions traced by the serialized request handler. The serialized request handler can selectively trace transactions based on control register settings. The serialized request handler 314 produces serialized request handler trace frames, as shown with arrow 324.
As previously indicated, the coherence manager 310 also includes an intervention unit 316. The intervention unit 316 sends coherent requests to processors, collects responses to requests and takes specified actions. The intervention unit 316 also provides intervention cache state for each transaction. The intervention ports 326 of the intervention unit 316 service coherence requests from processors that can affect the state of local cache lines. The intervention unit 316 generates intervention unit trace frames, as shown with arrow 328.
The serialized request handler trace frames and the intervention unit trace frames are processed by a coherence manager trace control block 330. The coherence manager trace control block 330 processes the serialized request handler trace frames and the intervention unit trace frames to produce trace words, which are sent to a trace funnel 332, as shown with arrow 334. The trace funnel 332 receives trace words from the processors 302, as shown with arrows 336. The funnel 332 interleaves trace words from the processors and the coherence manager 310. The resultant trace stream is applied to trace pins of a probe or is stored in on-chip memory, as indicated with arrow 338.
If the serialized request handler 314 or the intervention unit 316 produces a trace message, but it cannot be accepted by the trace control block 330 and the Inhibit Overflow bit in the trace control block control register is 0, then an overflow occurs and the message is dropped. At this point, the serialized request handler 314 and intervention unit 316 stop tracing. All transactions that are pending in the intervention unit 316 that have not been traced will not be traced (i.e., the trace enable bit associated with that transaction is cleared). The trace control block 330 then waits until all trace words in its FIFO have been accepted by the trace funnel 332. At that point, the resynchronization signal is asserted to all processors and the serialized request handler 314 and the intervention unit 314 are allowed to start tracing messages again (assuming that trace is still enabled via the trace control registers).
The coherence manager 310 produces a coherence manager trace message 406, which includes the same coherence indicator 404. The coherence manager trace message 406 provides information on common memory port transactions. As discussed below, the coherence manager trace information includes trace metrics. Embodiments of the invention provide different formats for the trace metrics depending upon debugging requirements.
Using the coherence indicator 404, which is common to both the processor trace message 402 and the coherence manager trace message 406, the different types of trace messages may be correlated downstream, e.g., at the debug module 130. This is more fully appreciated in connection with
The third line of
The invention is more fully appreciated in connection with the following specific examples of an embodiment of the invention. The core specific trace signals associated with the PDTrace™ technology are compatible with the present invention. The only alteration required to these signals is to include a coherence indicator. In one embodiment, a two bit coherence indicator is used to synchronize core trace messages with trace messages received from the coherence manager.
The coherence manager 310 may be implemented to process a set of serialized request handler signals and a set of intervention unit signals. In one embodiment, the serialized request handler signals may include various trace metrics, including a source processor, a serialized command, stall information, the address of a request being processed, and a target address. The intervention unit signals may include various trace metrics, including a source processor, a bit vector of intervention port responses, a global intervention state for a cache line, a transaction cancelled indicator, an intervention that will cause a cancelled store condition to fail, an intervention that will cause a future store condition to fail, transaction delay information, and stall cause information. These signals are characterized in the tables below.
The following signals represent updates to the PDTrace™ architecture interface that allow interaction with the disclosed coherence manager. The Trace Control Block (TCB) registers are used to enable or disable coherence manager (CMP) trace, as well as to enable/disable various available features. A new register TCBControlD is added to control various aspects of the trace output. The various bits used in TCBControlD are defined in Table 6. Bits 7 to 22 are reserved for implementation specific use.
Observe that the PX_Ctl fields allow the coherence manager to trace a different amount of information for each port. For example, for the port connected to the IOCU 304, it is beneficial to trace the address because there is no other tracing in the ICOU 304. However, for ports connected to a processor, the address may not be as useful since it is already traced by the processor.
Table 8 illustrates values to support flexibility in the amount of information being traced. The architecture enables implementations to enable and disable trace features per input port of the coherence manager.
Since each core in the system has its own set of TCBControl registers, one core is made the ‘master’ core that controls trace functionality for the coherence manager (CM). This can be done using a CMP GCR to designate a core as the master trace control for the CM. This control register is located in the global debug block within the GCR address space of the CM, at offset 0x0000. The format of the register is given below in Table 9.
Software control is enabled through the CMTraceControl register in the GCR register space (Debug Control Block, offset 0x0010). This register is very similar to TCBControlD, and is described below.
The PDtrace™ architecture requires some information to be traced out from each core to allow correlation between requests from the core with transactions at the coherence manager. The information required includes the coherent synchronization ID. The exact implementation of how this information is made available is highly dependent on the particular core on which it is implemented.
One embodiment of the invention expands PDTrace™ architecture trace formats TF2, TF3, and TF4. Each of these formats is expanded by one to four bits. Each instruction that is capable of generating a bus request (“LSU” instruction) adds at least two bits. All non-LSU instructions add a single bit (0) to the end of the trace formats. An LSU instruction that hits in the cache adds two bits “10”. If the instruction misses in the cache, it adds four bits—11XY where XY represent the COSId. The hit/miss/COSId information for an LSU instruction is sent after the instruction completion message for that instruction has been sent. Specifically, it is attached to the second LSU instruction after the original instruction. For some architectures, this guarantees that the hit/miss information is available at the time it needs to be sent out.
A second mechanism introduces three variants of a new CPU trace format (TF8). A TF8 message is output on any memory operation that misses in the cache. The format is shown in Table 12A.
As previously discussed, trace data can have two sources within the coherence manager—the serialization response handler (SRH) or the Intervention Unit (IVU). The SRH uses two trace formats (CM_TF1, CM_TF2), and the IVU uses one format (CM_TF3). One trace format (CM_TF4) is used to indicate that overflow has occurred. Since overflow implies that trace messages have been lost, the system must be resynchronized. The first one to four bits of a trace word can be used to determine the packet type.
Different SRH trace formats are selected based upon the type of debugging one wants to perform. For example, more information is traced for hardware debugging compared to software debugging. The SRH produces trace metrics including a source processor, a serialized command, stall information, the address of the request being traced, and a target address. One or more of these metrics may be arranged in various formats. When request addresses are not being traced, the CM_TF1 trace format, shown in Tables 12 and 13 is used. If the TLev field in TCBControlD (or CMTraceControl) is set to 1, each packet also includes the SRH_WaitTime field, as shown in Table 13. The packet width varies from 14 bits (trace level 0; Table 12) to 22 bits (trace level 1; Table 13). Trace reconstruction software determines the total packet length by examining the appropriate control bits in TCBControlD or the CMTraceControl register.
When request addresses are being traced, the CM_TF2 trace format, shown in Tables 14 and 15 are used. Since each core sets the lowest three address bits to zero, only address bits [31:3] are traced. If the TLev field in TCBControlD (or CMTraceControl) is set to 1, each packet also includes the SRH_WaitTime field. The packet width varies from 45 bits (trace level 0; Table 14) to 53 bits (trace level 1; Table 15). Trace reconstruction software determines the total packet length by examining the appropriate control bits in TCBControlD or the CMTraceControl register.
The IVU produces trace metrics including a source processor, a bit vector of intervention port responses, global intervention state for a cache line, a transaction cancelled indicator, an indication that an intervention will cause a cancelled store condition to fail, an indication that an intervention will cause a future store condition to fail, transaction delay information, and stall cause information. One or more of these metrics may be arranged in various formats. Trace data from the IVU uses the CM_TF3 trace format, shown in Tables 16 and 17. If the trace level (TLev in TCBControlD or CMTraceControl) is set to 1, each packet also includes two additional fields (WaitTime and StallCause). Each packet is 18 bits (trace level 0; Table 16) or 29 bits (trace level 1; Table 17). The SCF field indicates if a Store Conditional Failed, and the SCC field indicates if a Store Conditional was cancelled. Trace reconstruction software determines the trace level being used by examining the TCBControlD register or the CMTraceControl register.
Various formats can be selected based upon the circumstances. For example, if bandwidth is plentiful and/or one wants maximum information, the trace level may be set to 1 and address tracing may be enabled. This provides information about why certain stalls occur and how long they are (trace level 1). This also provides an additional level of correlation between addresses seen at the CPU and addresses seen at the coherence manager. The trace formats of Tables 15 and 17 may be used in these circumstances.
If the system is bandwidth limited and/or the user is only interested in software debugging, trace level 0 may be selected with address tracing disabled. This provides a minimal level of information about CPU requests that reaches the coherence manager (e.g., information about sharing, global cache line state, etc.), but excludes information about stalls and does not include the address. The trace formats in this case may be those of Tables 12 and 16.
If the system is bandwidth limited, but the user is interested in performance debugging, the trace level may be set to 1 with disabled address tracing. This provides some additional information about stalls. The trace formats in these instance may be those of Tables 13 and 17.
If the coherence manager inhibit overflow bit (CM_IO) is not set, it is possible for trace packets to be lost if internal trace buffers are filled. The coherence manager indicates trace buffer overflow by outputting a CM_TF4 packet. Regular packets resume after the CM_TF4 packet. The coherence manager resynchronizes with all cores by requesting a new COSId. Table 18 illustrates the overflow format.
The PDtrace architecture defines mechanisms that allow hardware breakpoints to start (or stop) tracing. An embodiment of the invention extends these mechanisms to allow the triggering of trace from the Coherence Manager. Each breakpoint trigger within the TraceIBPC and TraceDBPC registers can also be set to start tracing from the core and coherence manager. If a trigger that is set to enable coherence manager tracing is fired, the corresponding Core_CM_EN bit in TCBControlD is set to one. Similarly, if a trigger that is set to disable tracing fires on a core, the Core_CM_EN bit is set to zero. The TraceIBPC and TraceDBPC registers are shown below. Tables 19 through 23 show the new encodings that allow triggering of the coherence manager trace. The PDtrace architecture currently uses TF6 to indicate the staff/end of a trace due to a hardware breakpoint trigger. We define a new bit (bit 14 of TF6) within the TCinfo field in TF6 to indicate if the coherence manager will be affected by the current trigger.
Trace Format 6 (TF6) shown in Table 24 is provided to the coherence manager trace control block (TCB) to transmit information that does not directly originate from the cycle by cycle trace data on the PDtrace™ architecture interface. That is, TF6 can be used by the TCB to store any information it wants in the trace memory, within the constraints of the specified format. This information can then he used by software for any purpose. For example, TF6 can be used to indicate a special condition, trigger, semaphore, breakpoint, or break in tracing that is encountered by the TCB.
The definition of TCBcode and TCBinfo is shown in Table 25.
Revision 4.0 (and higher) of the PDtdrace specification uses two of the TCBcode fields to indicate that Instruction or Data Hardware Breakpoints were caused by the instruction in the trace format immediately preceding this TF6 format. Whether the trigger caused by the breakpoint turned trace off or on is indicated by the appropriate TCBinfo field value. Note that if the processor is tracing and trace is turned off this would be passed on to the external trace memory appropriately. If the processor is not tracing, and trace is turned on by a hardware breakpoint, then this record would show up in trace memory as the first instruction to be traced (it is also the one that triggered trace on). If tracing is on-going and other triggers continue to keep turning on trace, then this would show up as a TF6 in trace memory.
While various embodiments of the invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant computer arts that various changes in form and detail can be made therein without departing from the scope of the invention. For example, in addition to using hardware (e.g., within or coupled to a Central Processing Unit (“CPU”), microprocessor, microcontroller, digital signal processor, processor core, System on chip (“SOC”), or any other device), implementations may also be embodied in software (e.g., computer readable code, program code, and/or instructions disposed in any form, such as source, object or machine language) disposed, for example, in a computer usable (e.g., readable) medium configured to store the software. Such software can enable, for example, the function, fabrication, modeling, simulation, description and/or testing of the apparatus and methods described herein. For example, this can be accomplished through the use of general programming languages (e.g., C, C++), hardware description languages (HDL) including Verilog HDL, VHDL, and so on, or other available programs. Such software can be disposed in any known computer usable medium such as semiconductor, magnetic disk, or optical disc (e.g., CD-ROM, DVD-ROM, etc.). Embodiments of the present invention may include methods of providing the apparatus described herein by providing software describing the apparatus. For example, software may describe multiple processors, the coherence manager, etc.
It is understood that the apparatus and method described herein may be included in a semiconductor intellectual property core, such as a microprocessor core (e.g., embodied in HDL) and transformed to hardware in the production of integrated circuits. Additionally, the apparatus and methods described herein may be embodied as a combination of hardware and software. Thus, the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
This application is a continuation of U.S. patent application Ser. No. 12/060,214 filed Mar. 31, 2008 entitled, “Apparatus and Method for Low Overhead Correlation of Multi-Processor Trace Information”, which is related to the commonly owned U.S. patent application Ser. No. 12/060,204 filed Mar. 31, 2008, entitled, “Apparatus and Method for Condensing Trace Information in a Multi-Processor System”, the contents of which are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 12060214 | Mar 2008 | US |
| Child | 13609047 | US |
