JP2006514349A - Method and apparatus for determining processor state without interfering with processor operation - Google Patents

Abstract

A method and apparatus for determining the internal state of a host processor. Test data is loaded into the output port 152 of the service processor 140. The service processor 140 polls the valid bit recorded in the host processor 10. After determining that the valid bit is clear, the service processor 140 sends test data to the host processor and sets the valid bit. State data is generated in response to the test data. The state data is written to the output port 104 of the host processor 10. The service processor 140 receives data from the output port 104 of the host processor 10. The operation for determining the state of the host processor 10 is executed without hindering the execution of instructions of the host processor 10.

Description

  The present invention relates to processors, and more particularly to a method and apparatus for determining the state of a processor.

  Various techniques are used when designing new computer systems and system software to measure how various hardware mechanisms work while instructions are executed by the system processor. One form of measurement of system hardware operation is to determine the state of the processor at various stages of program execution. Determining the state of a processor includes querying the processor by sending data to the processor. Data received from the processor is processed, and additional data indicating the state of the processor is generated. Such data includes content such as registers and reservation stations. This additional data is then transmitted from the processor for observation. Alternatively, the processor may be configured to periodically send data to the department source, where the data is used to determine the status of the processor or other information.

  Various tools have been developed to query the processor and determine the state of the processor. These tools allow test data to be input to the processor, state data can be generated in response to the processor receiving the test data, and state data can be transmitted from the processor for observation. One difficulty with such tools is the execution of instructions while querying the processor. Typically, such tools require processor operations to generate interrupts or interrupts during processor queries. An instruction stream executed by the processor requires interrupts to input test data, generate state data, and output state data. Inputting test data and outputting state data requires the use of existing input and output ports, which results in interruptions in the input and output of other data to or from the processor. Furthermore, the input of test data results in the processor switching to another service routine, which results in deferring the currently executing instruction stream. These factors make it difficult to determine the speed at which a particular routine executes on the processor. Furthermore, transmission to another service routine results in the inability to determine the true processor state from the processor query.

  A method and apparatus for determining the status of a host processor is disclosed. In one embodiment, the service processor polls for valid bits recorded in the register of the host processor's receiver. If it is determined that the valid bit is clear, the service processor loads the test data into the output register, transmits the test data to the host processor, and sets the valid bit when the transmission is complete. In response to the host processor determining that the valid bit has been set, test data is read from the register of the receiver. State data representing the state of the host processor is generated in response to the test data. The host processor can poll the valid bit of the transmitter's register for its output port and saves data in the transmitter's register in response to detecting that the valid bit is clear. The data is then transmitted to the service processor receiver, and the valid bit is set in response to the previously described transmission. The operations of data transmission to the host processor and data reading from the host processor are performed without interrupting execution of instructions. Furthermore, transmission and reception of data by the host processor occur independently of each other.

  In one embodiment, the host processor has an input port and an output port. The host processor input port is configured to be coupled to the service processor output port. On the other hand, the output port is configured to be coupled with the input port of the service processor. Both the host and service processor input and output ports each include a register configured to record a number of bits. Each register is configured to record a valid bit indicating that the data recorded when set is valid. The input port register is configured to receive data only when the valid bit is clear. When data is transmitted from the output port to the input port, the valid bit is set in the input port register. Both host processors and service processors are configured to be read from the registers of their respective input ports in response to detecting that the valid bit is set.

  In one embodiment of the service processor, data is loaded into an output port register or read from an input port through a boundary scan test access port (Boundary Scan Test Access Port) (TAP) consistent with the IEEE 1149.1 standard. Data is loaded sequentially through the test data input (TDI) pin into the service processor output port registers. Similarly, data is sequentially shifted from the service processor output port registers through the test data output (TDO) pin.

  In many embodiments, operations that combine input ports and output ports operate separately from each other. That is, the service processor output port transmits data to the host processor input port independently of any data transmission from the host processor output port to the service processor input port. In yet another embodiment, data is sent periodically to or from the processor, or data is sent from the processor in response to individual queries.

  While the invention is amenable to various modifications and alternative forms, specific embodiments described herein have been shown by way of example and are described in detail below. . It should be understood, however, that the particular embodiments shown are not intended to limit the invention to the particular form disclosed, but rather to fall within the scope of the invention as defined by the appended claims. Covers all improvements, equivalents, and variations to which it belongs.

  A block diagram of one embodiment of the processor 10 is shown in FIG. Other embodiments are possible and are contemplated. As shown in FIG. 1, the processor 10 includes a prefetch / predecode unit 12, a branch prediction unit 14, an instruction cache 16, an instruction matching unit 18, a plurality of decode units 20A-20C, a plurality of reservation stations 22A-22C, It includes a plurality of functional units 24A-24C, a load / store unit 26, a data cache 28, a register file 30, a reorder buffer 32, an MROM unit 34, and a bus interface unit 37. Elements referred to herein with a particular reference number following the letter are collectively referred to by a single reference number. For example, the decode units 20A-20C are collectively referred to as the decode unit 20.

  Prefetch / predecode unit 12 is coupled to receive instructions from bus interface unit 37. Still further, the prefetch / predecode unit 12 is coupled to the instruction cache 16 and the branch prediction unit 14. Similarly, branch prediction unit 14 is coupled to instruction cache 16. Furthermore, the branch prediction unit 14 is coupled to the decode unit 20 and the functional unit 24. The instruction cache 16 is further coupled to the MROM unit 34 and the instruction matching unit 18. The instruction matching unit 18 is in turn coupled with the decode unit 20. Each decode unit 20A-20C is coupled to a load / store unit 26 and a respective reservation station 22A-22C. The reservation stations 22A-22C are further coupled to respective functional units 24A-24C. In addition, the decode unit 20 and the reservation station 22 are coupled with a register file 30 and a reorder buffer 32. The functional unit 24 is also coupled to the load / store unit 26, the register file 30, and the reorder buffer 32. Data cache 28 is coupled to load / store unit 26 and to bus interface unit 37. The bus interface unit 37 is further coupled to the L2 interface to the L2 cache and the bus. Finally, the MROM unit 34 is coupled to the decode unit 20.

  The instruction cache 16 is a high-speed cache memory and is provided for recording instructions. Instructions are fetched or fetched from instruction cache 16 and sent to decode unit 20. In one embodiment, instruction cache 16 is configured to record instructions up to 64 kilobytes in a two-way set associative structure having 64 byte lines (one byte is composed of 8 binary bytes). Alternatively, any other desired structure and size may be used. For example, note that the instruction cache 16 may be implemented as a fully associative, set associative, or direct map structure.

  Instructions are recorded in the instruction cache 16 by the prefetch / predecode unit 12. Instructions are prefetched from the instruction cache 16 prior to the request by a prefetch scheme. Various prefetch schemes are used by the prefetch / predecode unit 12. Since the prefetch / predecode unit 12 transmits an instruction to the instruction cache 16, the prefetch / predecode unit 12 generates predecode data corresponding to the instruction. For example, in one embodiment, prefetch / predecode unit 12 generates three predecode bits for each byte of the instruction. They are a start bit, an end bit, and a functional bit. The predecode bits form a tag indicating the boundary of each instruction. The prerecord tag also provides additional information, such as whether a given instruction can be decoded directly by the decode unit 20, or whether the instruction is executed by calling a microcode procedure controlled by the MROM unit 34. Send. Furthermore, the prefetch / predecode unit 12 is configured to detect a branch instruction and is configured to record branch prediction information corresponding to the branch instruction in the branch prediction unit 14. Other embodiments may use any suitable predecode scheme as desired, and may not use predecode.

  One encoding of the predecode tag for an embodiment of the processor 10 using a variable byte length instruction set is described below. A variable byte length instruction set is an instruction set in which different instructions occupy different numbers of bytes. A typical variable byte length instruction set used by one embodiment of processor 10 is the x86 instruction set.

In typical encoding, if a given byte is the first byte of an instruction, the start bit for that byte is set. If the byte is the last byte of the instruction, the end bit for that byte is set. Instructions that are directly decoded by the decode unit 20 are referred to as “fast path” instructions. The remaining x86 instructions are referred to as MROM instructions according to one embodiment. For fast path instructions, the functional bit is set for each prefix byte included in the instruction and cleared for the other bytes. Instead, for MROM instructions, the functional bit is cleared for each prefix byte and set for the other bytes. The type of instruction is determined by examining the functional bit corresponding to the end byte. If the functional bit is clear, the instruction is a high speed instruction. Conversely, if the functional bit is set, the instruction is an MROM instruction. The instruction's operation code is thereby placed in the instruction that is directly decoded by the decode unit 20 as a byte associated with the first clear functional bit of the instruction. For example, a fast path instruction including two prefix bytes, ModR / M byte, immediate byte has the following start, end, and functional bits.
Start bit 10,000
End bit 00001
Functional bit 11000

  The MROM instruction is an instruction that is determined to be too complicated to be decoded by the decoding unit 20. The MROM instruction is executed by calling the MROM unit 34. More specifically, upon receiving an MROM instruction, the MROM unit 34 parses and issues the instruction to a predetermined subset of fast path instructions to achieve the desired operation. MROM unit 34 sends a subset of fast path instructions to decode unit 20.

  The processor 10 speculatively fetches instructions following conditional branch instructions using branch prediction. A branch prediction unit 14 is included to perform branch prediction operations. In one embodiment, branch prediction unit 14 uses a branch target buffer. The branch target buffer caches in the instruction cache 16 for every 16 byte part of the cache line, up to two branch target addresses and corresponding adopted / not adopted predictions. The branch target buffer has, for example, 2048 entries or other suitable number of entries. The prefetch / precode unit 12 determines the initial branch target when a particular row is predecoded. Subsequently, an update to the branch target corresponding to the cache line occurs by executing the instruction of the cache line. Instruction cache 16 provides an indication of the instruction address being fetched so that branch prediction unit 14 can determine which branch target address to select to form the branch prediction. The decode unit 20 and the functional unit 24 send update information to the branch prediction unit 14. The decode unit 20 detects a branch instruction that has not been predicted by the branch prediction unit 14. The functional unit 24 executes the branch instruction and determines whether the predicted branch direction is incorrect. If the branch direction is “adopted”, the following instruction is fetched from the target address of the branch instruction. Conversely, if the branch direction is “not employed”, the next instruction is fetched from the memory location following the branch instruction. When a mispredicted branch instruction is detected, the instruction following the mispredicted branch is discarded from various units of the processor 10. As another configuration, the branch prediction unit 14 is coupled to the reorder buffer 32 instead of the decode unit 20 and the functional unit 24 and receives branch misprediction information from the reorder buffer 32. Various suitable branch prediction algorithms are used by the branch prediction unit 14.

  Instructions fetched from the instruction cache 16 are communicated to the instruction matching unit 18. As instructions are fetched from the instruction cache 16, the corresponding predecode data is scanned and information is sent to the instruction matching unit 18 (and MROM unit 34) regarding the fetched instructions. The instruction matching unit 18 uses the scan data to match instructions to each decode unit 20. In one embodiment, instruction matching unit 18 aligns instructions from three sets of 8 instruction bytes to decode unit 20. Decode unit 20A receives instructions prior to instructions received simultaneously by decode units 20B and 20C (in program order). Similarly, decode unit 20B receives an instruction prior to an instruction received simultaneously by decode unit 20C in program order. In some embodiments (eg, an embodiment using a fixed length instruction set), the instruction matching unit 18 is eliminated.

  The decode unit 20 is configured to decode instructions received from the instruction matching unit 18. Register operand information is detected and sent to the register file 30 and the reorder buffer 32. In addition, if the instruction requires one or more memory operations to be performed, the decode unit 20 sends the memory operations to the load / store unit 26. Each instruction is decoded into a series of control values for the functional unit 24, and these control values are sent to the reservation station 22 along with replacement or immediate data and operand address information contained in the instruction. In one specific embodiment, each instruction is decoded into two upper bound operations performed separately by the functional units 24A-24C.

  The processor 10 supports out-of-order execution. Therefore, the reorder buffer 32 is used to keep track of the original program sequence for register read and write operations, register renaming, speculative instruction execution and branch misprediction recovery, and "exact" exceptions. (Precise exceptions) The temporary recording location in the reorder buffer 32 is reserved after decoding an instruction including a register update, thereby recording the speculative register state. If the branch prediction is incorrect, the result of the speculatively executed instruction along the mispredicted path can be invalidated in the buffer before it is written to the register file 30. Similarly, if a particular instruction causes an exception, the instruction following the particular instruction is discarded. In this way the exception is “exact” (ie, the instruction following the specific instruction that causes the exception is not completed before the exception). It should be noted here that a specific instruction is speculatively executed if executed before the instruction preceding the specific instruction in program order. The preceding instruction is a branch instruction or an instruction that causes an exception. In either case, the speculative result is discarded by the reorder buffer 32.

  The decoded instruction sent at the output of the decode unit 20 is sent directly to the respective reservation station 22. In one embodiment, each reservation station 22 provides instruction information (eg, decoded instructions as well as operand values, operand tags, and / or immediate data) for up to six pending instructions waiting to be issued to the corresponding functional unit. Can be held. Note that, for the embodiment of FIG. 1, each reservation station 22 is associated with a dedicated functional unit. Thus, three dedicated “issue portions” are formed by the reservation station 22 and the functional unit 24. That is, the issuing unit 0 is formed by the reservation station 22A and the functional unit 24A. The commands that are aligned and sent to the reservation station 22A are executed by the functional unit 24A. Similarly, the issuing unit 1 is formed by a reservation station 22B and a functional unit 24B. The issuing unit 2 is formed by a reservation station 22C and a functional unit 24C.

  After decoding a particular instruction, if the desired operand is in a register location, register address information is sent to reorder buffer 32 and register file 30 simultaneously. Register file 30 has a record location for each designed register included in the instruction set implemented by processor 10. Additional recording locations are included in the register file 30 for use by the MROM unit 34. The reorder buffer 32 has a temporary recording location for the result of changing the contents of these registers, thereby allowing out-of-order execution. The temporary recording location of the reorder buffer 32 is reserved for each instruction, and each instruction is determined to modify one content of the real register after decoding. Thus, during execution of a particular program, at various points, the reorder buffer 32 has one or more locations that contain speculatively implemented content of a given register. Following the decoding of a given instruction, if it is determined that the reorder buffer 32 has a previous location or a location allocated to a register used as an operand in a given instruction, the reorder buffer 32 1) allocates immediately before Either the value of the assigned location, or 2) the tag for the location allocated immediately before, if no value has been generated by the functional unit that ultimately executes the previous instruction, to the corresponding reservation station Forward. If the reorder buffer 32 has a place to be reserved for a given register, the operand value (or reorder buffer tag) is sent from the reorder buffer 32 instead of from the register file 30. The value is taken directly from the register file 30 if there is no reserved location for the requested register in the reorder buffer 32. If the operand corresponds to a memory location, the operand value is sent through the load / store unit 26 to the reservation station.

  In one specific embodiment, reorder buffer 32 is configured to record and process instructions that are simultaneously decoded as a unit. This configuration is referred to herein as “row type”. By processing several instructions together, the hardware used for the reorder buffer 32 can be simplified. For example, the row-type reorder buffer included in this embodiment provides sufficient recording for instruction information regarding three instructions (one from each decode unit 20) whenever one or more instructions are sent by the decode unit 20. Allocate. On the other hand, variable length records are allocated to the conventional reorder buffer according to the number of instructions actually sent. A relatively large number of logic gates are required to allocate variable length records. If each of the instructions decoded at the same time is executed, the result of the instruction is recorded in the register file 30 simultaneously. The record can then be freely allocated to another series of simultaneously decoded instructions. In addition, the total number of control logic used per instruction is reduced because the control logic is amortized on the various simultaneously decoded instructions. The decoder buffer tag that identifies a particular instruction is divided into two fields. Line tag and offset tag. The line tag identifies a series of simultaneously decoded instructions that include a particular instruction, and the offset tag identifies which instruction in the set corresponds to a particular instruction. It should be noted that recording an instruction results in register file 30, and freeing the corresponding recording is referred to as "retire" the instruction. It should further be noted that any reorder buffer configuration may be used in various embodiments of the processor 10.

  As stated above, the reservation station 22 records instructions until the instructions are executed by the corresponding functional unit 24. The instruction is selected to execute if (i) the operand of the instruction is provided; and (ii) if the operand is in the same reservation station 22A-22C and the instruction preceding the instruction in program order is not provided Is done. When an instruction is executed by one of the functional units 24, the result of the instruction is passed directly to any reservation station 22 waiting for the result, while the result is passed to update the reorder buffer 32 ( This technique is commonly referred to as result forwarding). Instructions are selected for execution and passed to functional units 24A-24C where the associated results are forwarded during the clock cycle. The reservation station 22 in this case sends the forwarded result to the functional unit 24. In embodiments where the instructions are decoded into various operations to be performed by the functional unit 24, each operation is scheduled separately.

  In one embodiment, each functional unit 24 is configured to perform integer arithmetic operations of addition and subtraction, as well as shift, transmission, logical operations, and branch operations. The operation is performed in response to a control value decoded by the decode unit 20 for a specific instruction. A floating point unit (not shown) is also used and adapted for floating point operations. The floating point unit operates as a coprocessor that receives instructions from the MROM unit 34 or reorder buffer 32 and then communicates with the reorder buffer 32 to complete the instructions. In addition, the functional unit 24 is configured to perform address generation for load and store memory operations performed by the load / store unit 26. In one particular embodiment, each functional unit 24 has an address generation unit for generating addresses and an execution unit for performing the remaining functions. The two units are operated independently of different instructions or operations during the clock cycle.

  Each functional unit 24 also sends information regarding the execution of conditional branch instructions to the branch prediction unit 14. If the branch prediction is incorrect, the branch prediction unit 14 causes the instruction to flow after the mispredicted branch that has entered the instruction processing pipeline and fetches the requested instruction from the instruction cache 16 or main memory. It should be noted that in such circumstances, the original program that occurred after the discarding of the mispredicted branch instruction, including those that were speculatively implemented and temporarily recorded in the load / store unit 26 and the reorder buffer 32 This means that the result of the sequence instruction is discarded. It should be further noted that the result of the branch execution is sent by the functional unit 24 to the reorder buffer 32, which represents a mispredicted branch to the functional unit 24.

  The result generated by the functional unit 24 is sent to the reorder buffer 32 when the register value is updated, and to the load / store unit 26 when the content of the memory location is changed. If the result is to be recorded in a register, reorder buffer 32 records the result in a location that is reserved for the value of the register when the instruction is decoded. A plurality of result buses 38 are included to forward results from the functional unit 24 and the load / store unit 26. The result bus 38 carries the results generated as well as a reorder buffer tag that recognizes the instruction to be executed.

  The load / store unit 26 provides an interface between the functional unit 24 and the data cache 28. In one embodiment, the load / store unit 26 has a first load / store buffer and a second load store / buffer. The first load / store buffer is configured to have a recording location for data and address information for pending loads or stores not accessing the data cache 28. The second load / store buffer has a recording location for data and address information for loads and stores that have accessed the data cache 28. For example, the first buffer has 12 locations and the second buffer has 32 locations. The decode unit 20 arbitrates for access to the load / store unit 26. When the first buffer is full, the decode unit must wait until the load / store unit 26 is free for pending load or store request information. The load / store unit 26 also performs a dependency check for the load memory operation on the pending store memory operation to confirm that the data consistency is maintained. Memory operations are data transmissions between the processor 10 and the main memory subsystem (although transmission is accomplished in the data cache 28). A memory operation is the result of an instruction that uses an operand recorded in memory. Or the result of a load / store instruction that causes the transmission of data but not other operations.

  The data cache is a high-speed cache memory provided for temporarily recording data transmitted between the load / store unit 26 and the main memory subsystem. In one embodiment, the data cache 28 has a two-way set associative structure and a recording capacity up to 64 kilobytes. Data cache 28 may be implemented with a variety of specific memory structures including set associative structures, full associative structures, direct map structures, and other suitable structures in appropriate sizes.

  The bus interface unit 37 is configured to communicate between the processor 10 and other components of the computer system via the bus. For example, the bus is compatible with the EV-6 bus developed by Digital Equipment Corporation. In addition, any suitable interconnection structure can be used including packet-based, unidirectional or bidirectional links. Any L2 cache interface is also used to interface to the level 2 cache as well.

  Note that although the embodiment of FIG. 1 is superscalar execution, other embodiments may use scalar execution. Furthermore, the number of functional units varies depending on the embodiment. Other embodiments may use a central reservation station rather than the individual reservation stations shown in FIG. Yet another embodiment uses a central scheduler rather than the reservation station and reorder buffer of FIG.

  The processor 10 includes a port as shown here as a mailbox 100. The port allows to be queried while executing the instruction stream. Mailbox port 100 is configured to be coupled with a service processor or debug processor outside processor 10. Test data used to query the state of the processor 10 is received via the mail port 100. Similarly, state data indicating the state of the processor 10 resulting from the inquiry is transmitted from the mailbox port 100 to the service processor or the debug processor. Mailbox port 100 is coupled to one or more units of processor 10, such as decode units 20A-20C, register file 30, instruction cache 16, functional units 24A-24C. Information is transmitted or received from the mailbox port 100.

  FIG. 2 shows a block diagram of one embodiment of a system for determining the state of a processor. In this embodiment, processor 10, and thereafter host processor 10, is coupled with service processor 140. In some embodiments, service processor 140 is located on another computer system that is coupled to the computer system on which host processor 10 is implemented. In other embodiments, service processor 140 is located on a board that is inserted into a peripheral slot of the computer system in which the host processor is located, or attached to the same board as the host processor.

  As previously mentioned, the host processor 10 includes a mailbox port 100. Mailbox port 100 includes a mailbox input port 102 and a mailbox output port 104. Mailbox input port 102 is configured to couple with complementary output port 152 of service processor 140. Similarly, mailbox output port 104 is configured to couple with complementary input port 154 of service processor 140.

  The mailbox input port 102 of the host processor 10 receives test data transmitted from the service processor 140. The test data is transmitted from the output port 152 of the service processor 140 to the mailbox input port 102 of the host processor 10. Similarly, the service processor 140 is configured to receive state data from the host processor 10. The state data is transmitted from the mailbox output port 104 of the host processor 10 to the input port 154 of the service processor 140. Each complementary repair of input / output ports functions independently of each other. That is, the output port 152 transmits test data to the mailbox input port 102 independently of any transmission of state data from the mailbox output port 104 to the input port 154.

  Test data is continuously loaded into the output port 152 of the service processor 140 via a test data input (TDI) pin that is part of the test access port (TAP). The test access port is a boundary scan port compatible with the IEEE standard 1149.1. Similarly, state data is continuously shifted from the input port 154 via the test data output pin. Additional details about loading test data and unloading state data from service processor 140 are described below.

  FIG. 3 is a block diagram illustrating one embodiment of a host processor input port coupled to a service processor output port. In the exemplary embodiment, mailbox input port 102 of host processor 10 is coupled to mailbox output port 152 of service processor 140. Mailbox input port 102 includes an input register 112. The input register 112 is configured to receive and record test data. Test data is received from an output register 162 located at output port 152. Both output registers 162 and input registers 112 are of various sizes. In one embodiment, output register 162 and input register 112 are configured to record 32 bits of data and one valid bit. Other embodiments with different register sizes as well as various registers (for both mailbox input ports and both mailbox output ports) are possible and are contemplated.

To determine the state of the host processor 10, the valid bit in the input register 112 must be queried following the loading of test data into the output register 162.
As previously mentioned, the data is loaded into the mailbox output port 152 via a boundary scan TAP compatible with the IEEE 1149.1 standard. In the illustrated embodiment, output register 162 is coupled to the TDI pin. Test data is continuously shifted to the output register 162 via the TDI pin. In addition to the test data, a valid bit is also set in the output register via the TDI pin.

  In order to transmit test data to the input register 112, it is first necessary to poll the valid bit to confirm that it is in a clear state. Since this bit is in the host processor clock domain, it must first be synchronized to the service processor clock domain. The synchronized version of the valid data is captured in output register 162 and sequentially shifted out for testing. Test data is sequentially loaded into output register 162 while valid data is sequentially shifted out for testing.

  If it is determined that the valid bit is set while polling the valid bit of the input register 112, this indicates that test data has been loaded into the mailbox input port 102 but has not been read by the host processor 10. Yes. Therefore, loading test data into the output register 162 and subsequent transmission to the input register 112 is prohibited while this valid bit is set. After reading the test data, the valid bit is cleared from the input register 112 by the host processor. In response to detecting that the valid bit recorded in the input register 112 is in a clear state, the output port 152 starts transmitting test data to the input register 112. In this embodiment, a separate TAP instruction is used and the valid bit is set. By using this instruction, data is synchronously loaded from the output register 162 to the input register 112 (see “A” in FIG. 3).

  The processor core of the host processor 10 also polls the valid bit of the input register 112. After detecting a set of valid bits indicating normal loading of test data into the input register 112, the processor core reads the test data. The test data is then used to generate state data and return to the service processor. Further details are described below.

The transmission and reception protocols between the input port and output port are the same for both host processors 10 and service processor 140. Table 1 below illustrates the protocol for one embodiment that combines input / output ports.
Table 1
│Transmitter │Receiver │
│ │ │
│1. Until clear state | Host process until set
│ Polling the valid bit of the host processor │ Polling the valid bit of the memory │
│Poll │ ru. │
│ │ │
│2. Save data in register | 2. Read data. │
| │ │
│ │ │
│3. Effectiveness of host processor | 3. Host processor valid bits
│Set the bit. Clear │. │

  In general, the transmitter (ie, output port) of the system needs to poll the host processor's valid bit before sending data to the receiver. After detecting that the valid data of the host processor is clear, the data is stored in the output register and transmitted to the input register of the receiver. The successful transmission of data from the transmitter to the receiver is indicated by setting the valid bit in the input register. The system's receiver (ie, input port) polls the host processor's valid bit until the host processor is set. Setting the host processor's valid bit indicates that valid data is present in the input register, thus allowing the receiver to read the data. Following the data read, the host processor valid bit is cleared.

  In various embodiments, the service processor receiver periodically shifts data from the input register and examines the valid bits following the preceding shift (since the valid bits are part of the data being shifted out). Determine if the data is valid.

  FIG. 4 shows a block diagram of one embodiment of an output port of a host processor that is coupled to an input port of a service processor. In the illustrated embodiment, the mailbox output port 104 of the host processor 10 is coupled to the input port 154 of the service processor 140. Mailbox output port 104 includes an output register 114 that is configured to record state data received from the processor core of host processor 10. The state data received by the output register 114 is generated in response to the test data input first. Mailbox output port includes output register 114, while input port 154 includes input register 164.

  Before any data transmission is performed to the output register 114, it is necessary to poll the valid bit recorded in the output register 114 to determine whether it is clear or not. After determining that the valid bit is in a clear state, the mailbox output port 104 stores the state data in the output register 114 and then sets the valid bit in the output register 114. Data transmission to the input register 164 is initiated by the service processor 140. This is performed in the capture-DR (Capture-DR) state of the TAP controller. When state data and valid bits are sent to the input register 164, the valid bits are examined and the data is read out by shifting out through the Test Data Out (TDO) pin. If the valid bit is set, the service processor 140 determines that the data shifted out with the valid bit is executable (ie, valid data).

  Data transmission to and from the mailbox input port is controlled by a series of instructions to both service processors and the host processor. In one embodiment, the TAP instructions for the service processor are MBOXIN, MBOXINSETV, MBOXOUT, and MBOXOUTCLRV. The MBOXIN instruction is used by the service processor 140 to accomplish the transmission of test data from the output port 152 to the mailbox input port 102. The service processor 140 executes the MBOXINSETV instruction in response to the transmission of test data. Therefore, a valid bit is set in the input register 112 to indicate to the host processor 10 that valid data exists. The MBOXOUT instruction is executed to start transmission of state data from the host processor 10 to the service processor 140. The MBOXOUTCLRV instruction is executed to clear the valid bit recorded in the output register 114.

  Instructions executed by the host processor 10 include model specific register (MRS) read and write instructions for mnemonics UC_SPREG_MBOX_IN and UC_SPREG_MBOX_OUT. The MSR read of UC_SPREG_MBOX_IN starts accessing the mailbox input register 112 and reads test data from the register. The MSR write for UC_SPREG_MBOX_IN is used to clear the valid bit. The MSR write for UC_SPREG_MBOX_OUT initiates access to the mailbox output register 114 to save state data or set the valid bit. The MSR read of UC_SPREG_MBOX_OUT is used to detect that the valid bit is clear.

  It should be noted that the mnemonics associated with the various instructions are examples for one particular embodiment. Embodiments with other mnemonics describing specific instructions used with input and output ports are possible and will be discussed.

  It should be noted that the output register 162 and the input register 164 of the service processor 140 may be any TAP shift register between the TDI and TDO pins, and any shift register may contain test / state data and at least one at least one register. It has a sufficient number of bit positions to record valid bits. It should further be noted that other embodiments of the processor 140 are also possible and will be considered, in which test data is loaded and state data is read out via mechanisms in addition to the TAP described above. In addition, for the purposes of this discussion, the terms service processor and debug processor are interchangeable, and the debug processor can be substituted for the service processor and is configured in accordance with the discussion herein.

  FIG. 5A shows a flow diagram of one embodiment of a method for querying a host processor. Method 500 begins by polling the input register of the host processor (item 502) for valid bits. During polling, a determination is made as to whether the valid bit is clear or set (item 504). If the valid bit is set, polling continues. A valid bit that is set indicates that the host processor input register contains valid data that has not yet been read. The serial loading of test data is done via the TDI pin as described above. Other embodiments in which test data is loaded in parallel are possible and are contemplated. Following loading of test data into the output register, the service processor output port can send data to the host processor input register (item 508) and set the valid bit (item 510). Setting a valid bit in the input register of the host processor indicates to the processor that valid data exists and is ready for reading. In response to detecting the set of valid bits, the host processor reads the test data and generates state data based on the test data (item 512). The valid bit recorded in the input register of the mailbox input port can be cleared by the host processor following reading of the test data by the host processor.

  FIG. 5B is a flow diagram illustrating one embodiment of a method for outputting state data from a host processor. The state data is generated by the method described in FIG. 5A and the mechanism described in FIGS. 1-4. Method 550 begins by polling the valid bit of the host processor's output register (item 552). Similar to the method described with reference to FIG. 5A, polling of valid bits continues until it is determined that the valid bits are clear (item 554). If it is determined that the valid bit is clear, the host processor stores the state data in the output register of the mailbox output port (556). Following loading of the state data into the output register, the host processor sets a valid bit in the output register (item 560). The service processor sends the valid bit and data in the Capture-DR state and then shifts it from the input register (item 562). If the valid bit to be transmitted is set, then the data is identified as valid. In response to reading the state data from the input register, the host processor valid bit can be cleared so that additional state data can be sent from the host processor. In particular, it is important that the operations described with reference to FIG. 5B can occur independently of the operations described with reference to FIG. 5A.

  It should be noted that the term “test data” as used herein refers to any type of data that is input to the host processor 10 to receive the desired response. Similarly, the term “state data” refers to any type of data used to provide information regarding the operation of the host processor 10. In addition, it should be noted that the loading of test data and / or reading of state data is either in response to individual queries of the processor or operations performed periodically. Alternative embodiments are possible, discussed, and the specific order of polling valid bits and transmitting data may differ from that described herein.

  Although the invention has been described with reference to particular embodiments, it will be understood that the embodiments are illustrative and that the scope of the invention is not limited. Any variations, modifications, additions and improvements of the embodiments are possible. These variations, modifications, additions and improvements fall within the scope of the invention as set forth in the following claims.

  The present invention can be applied to a processor.

1 is a block diagram of one embodiment of a processor. FIG. 1 is a block diagram of one embodiment of a system for determining the state of a processor. FIG. FIG. 3 is a block diagram illustrating one embodiment of a host processor input port coupled to a service processor output port. FIG. 4 is a block diagram of one embodiment of a host processor output port coupled to a service processor input port. FIG. 4 is a flow diagram of an embodiment of a method for querying a host processor. FIG. 3 is a flow diagram of one embodiment of a method for outputting state data from a host processor.

Claims (10)

A method for determining the state of a host processor, comprising:
Polling a first input register located in the host processor for a first valid bit until the first valid bit is clear (502);
Loading test data into a first output register located in the service processor (506);
Transmitting the test data from the first output register to the first input register (508);
Set the first valid bit (510) after the transmission is completed; and
Reading the test data from the first input register in response to detecting the first set of valid bits (512);
The load, the poll, the send, the set, and the read are those that do not interrupt an instruction stream executed by the host processor. Determining the state of the host processor based on the test data; and
The method of claim 1, wherein state data is output to the service processor, the state data indicating a state of a host processor, and the determination and the output are performed asynchronously with respect to a host processor clock. The output is
Polling the second output register for a second valid bit until the second valid bit is clear (552);
Loading state data into the second output register (556);
Sending the state data from the second output register to a second input register located in the service processor (558); and
The method of claim 2, wherein the state data is output (562) from the second input register.   4. The method of claim 3, wherein the first valid bit is cleared in response to reading the test data.   4. The method of claim 3, wherein the second valid bit is set following loading of the second input register. A host processor (10) and a service processor (140), the host processor comprising a first input register (102), the service processor comprising a first output register (152), and the host processor comprising a second input register (152); The output register (104), the service processor comprises a second input register (154),
The service processor is configured to determine the state of the host processor;
In the judgment,
Polling the first valid bit of the first input register until the first valid bit is cleared;
Loading test data into the first output register;
Transmitting the test data from the first output register to the first input register;
The first valid bit is set after the transmission is completed,
The host processor is configured to read the test data from the first input register in response to the first valid bit; and
The load, the poll, the transmission, the set, and the read do not interrupt an instruction stream executed by the host processor. The host processor further includes:
Determining the state of the host processor based on the test data; and
The system is configured to output state data to the service processor, wherein the state data indicates a state of a host processor, and the determination and output are executed asynchronously with respect to the host processor clock. 6. The system according to 6. The host processor further includes:
Polling the second valid bit of the second output register until the second valid bit is clear;
Storing state data in the second output register;
The state processor is configured to transmit state data from the second output register to the second input register, and the service processor is configured to output the state data received by the second input register. Item 8. The system according to Item 7.   The system of claim 8, wherein the host processor is configured to clear the first valid bit in response to reading the test data.   The system of claim 8, wherein the host processor is configured to set the second valid bit in response to storing state data in the second output register.

Images