BACKGROUND ART During the design of new computer systems and system software, various techniques may be employed to determine how the various hardware mechanisms will behave during the execution of instructions by a system processor. One aspect of determining the behavior of system hardware involves the determination of processor states at various stages of program execution. Determining the processor state may involve querying the processor by sending it data. The data received by the processor may then be acted on and produce additional data indicative of the processor state. Such data may include the contents of registers, reservation stations, and so on. The additional data may then be transmitted from the processor for observation. Alternatively, a processor may be configured to periodically transmit data to an external source where the data may be used to determine a processor state or other information.

Various tools have been developed for querying a processor to determine the processor state. These tools may allow test data to be input to the processor, state data to be generated responsive to the processor receiving the test data, and the state data to be transmitted from the processor for observation. One such drawback to such tools involves the execution of instructions during the querying of the processor. Typically, such tools require that the operation of the processor be interrupted during the processor query. An instruction stream that is being executed by the processor may need to be interrupted in order to input the test data, generate the state data, and output the state data. Inputting test data and outputting state data may require the use of existing processor input and output ports, thereby interrupting the inputting and outputting of other data to or from the processor. Furthermore, the inputting of test data may result in the processor switching to an alternate service routine, which may result in the suspension of the currently executing instruction stream. These factors may make it difficult to ascertain the speed at which certain routines execute in the processor. Furthermore, the transition to an alternate service routine may result in the inability to determine the true processor state from the processor query.

DISCLOSURE OF INVENTION A method and apparatus for determining the state of a host processor is disclosed. In one embodiment, a service processor may poll a valid bit stored in a register of a receiver in the host processor. Upon determining that the valid bit is clear, the service processor may load test data into an output register and transmit test data to the host processor, setting the valid bit upon completing the transmission. The test data may be retrieved from the register of the receiver responsive to the host processor determining that the valid bit is set. State data, indicative of a state of the host processor, may be generated responsive to the test data. The host processor may poll a valid bit in a register of a transmitter in its output port, and may deposit data into the register of the transmitter responsive to detecting that the valid bit is clear. The data may then be transmitted to the receiver of the service processor, and the valid bit may be set in response to said transmitting. The operations of transmitting data to the host processor and retrieving data from the host processor may be performed without interrupting the execution of instructions. Furthermore, transmission and reception of data by the host processor may occur independently of each other.

In one embodiment, the host processor includes an input port and an output port. The input port of the host processor may be configured to be coupled to an output port of the service processor, while the output port may be configured to be coupled to an input port of the service processor. The input ports and output ports of both the host and service processors may each include a register configured to store a number of bits. Each register may be configured to store a valid bit that, when set, may indicate that the data stored is valid. The registers in the input ports may be configured such that they may only receive data when the valid bit is cleared. When data is transferred from an output port to an input port, the valid bit may be set in the register of the input port. Both the host processor and the service processor may be configured such that data may be retrieved from the register of their respective input ports responsive to detecting that the valid bit is set.

In one embodiment of the service processor, data may be loaded into the register of the output port or retrieved from the input port through a boundary scan test access port (TAP) which may conform to the IEEE 1149.1 standard. Data may be serially loaded into the register of the service processor output port through a test data in (TDI) pin. Similarly, data may be serially shifted out of the register in the service processor input port through a test data out (TDO) pin.

In various embodiments, the operation of the combinations of input ports and output ports may operate independently of one another. In other words, the output port of the service processor may transfer data to the input port of the host processor independently of any data transfers from the output port of the host processor to the input port of the service processor. Furthermore, in various embodiments, data may be transferred in regular intervals to or from the processor, or data may be transferred from the processor responsive to an individual query.

BRIEF DESCRIPTION OF DRAWINGS Other aspects of the invention will become apparent upon reading the following detailed description and upon reference to the accompanying drawings in which: Figure 1 is a block diagram of one embodiment of a processor; Figure 2 is a block diagram of one embodiment of a system for determining the state of a processor; Figure 3 is a block diagram of illustrating one embodiment of a host processor input port coupled to a service processor output port; Figure 4 is a block diagram of one embodiment of a host processor output port coupled to a service processor input port; Figure SA is a flow diagram of one embodiment of a method of querying a host processor; and Figure 5B is a flow diagram of one embodiment of a method for outputting state data from a host processor.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and description thereto are not intended to limit the invention to the particular form disclosed, but, on the contrary, the invention is to cover all modifications, equivalents, and alternatives falling with the spirit and scope of the present invention as defined by the appended claims.

MODE (S) FOR CARRYING OUT THE INVENTION Turning now to Figure 1, a block diagram of one embodiment of a processor 10 is shown. Other embodiments are possible and contemplated. As shown in Figure 1, processor 10 includes a prefetch/predecode unit 12, a branch prediction unit 14, an instruction cache 16, an instruction alignment unit 18, a plurality of decode units 20A-20C, a plurality of reservation stations 22A-22C, 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 followed by a letter will be collectively referred to by the reference number alone. For example, decode units 20A-20C will be collectively referred to as decode units 20.

Prefetch/predecode unit 12 is coupled to receive instructions from bus interface unit 37, and is further coupled to instruction cache 16 and branch prediction unit 14. Similarly, branch prediction unit 14 is coupled to instruction cache 16. Still further, branch prediction unit 14 is coupled to decode units 20 and functional units 24.

Instruction cache 16 is further coupled to MROM unit 34 and instruction alignment unit 18. Instruction alignment unit 18 is in turn coupled to decode units 20. Each decode unit 20A-20C is coupled to load/store unit 26 and to respective reservation stations 22A-22C. Reservation stations 22A-22C are further coupled to respective functional units 24A-24C. Additionally, decode units 20 and reservation stations 22 are coupled to register file 30 and reorder buffer 32. Functional units 24 are coupled to load/store unit 26, register file 30, and reorder buffer 32 as well. Data cache 28 is coupled to load/store unit 26 and to bus interface unit 37. Bus interface unit 37 is further coupled to an L2 interface to an L2 cache and a bus. Finally, MROM unit 34 is coupled to decode units 20.

Instruction cache 16 is a high speed cache memory provided to store instructions. Instructions are fetched from instruction cache 16 and dispatched to decode units 20. In one embodiment, instruction cache 16 is configured to store up to 64 kilobytes of instructions in a 2 way set associative structure having 64 byte lines (a byte comprises 8 binary bits). Alternatively, any other desired configuration and size may be employed. For example, it is noted that instruction cache 16 may be implemented as a fully associative, set associative, or direct mapped configuration.

Instructions are stored into instruction cache 16 by prefetch/predecode unit 12. Instructions may be prefetched prior to the request thereof from instruction cache 16 in accordance with a prefetch scheme. A variety of prefetch schemes may be employed by prefetch/predecode unit 12. As prefetch/predecode unit 12 transfers instructions to instruction cache 16, prefetch/predecode unit 12 may generate predecode data corresponding to the instructions. For example, in one embodiment, prefetch/predecode unit 12 generates three predecode bits for each byte of the instructions: a start bit, an end bit, and a functional bit. The predecode bits form tags indicative of the boundaries of each instruction. The predecode tags may also convey additional information such as whether a given instruction can be decoded directly by decode units 20 or whether the instruction is executed by invoking a microcode procedure controlled by MROM unit 34. Still further, prefetch/predecode unit 12 may be configured to detect branch instructions and to store branch prediction information corresponding to the branch instructions into branch prediction unit 14. Other embodiments may employ any suitable predecode scheme or no predecode, as desired.

One encoding of the predecode tags for an embodiment of processor 10 employing a variable byte length instruction set will next be described. A variable byte length instruction set is an instruction set in which different instructions may occupy differing numbers of bytes. An exemplary variable byte length instruction set employed by one embodiment of processor 10 is the x86 instruction set.

In the exemplary 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 an instruction, the end bit for that byte is set. Instructions which may be directly decoded by decode units 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 other bytes. Alternatively, for MROM instructions, the functional bit is cleared for each prefix byte and set for other bytes. The type of instruction may be determined by examining the functional bit corresponding to the end byte. If that functional bit is clear, the instruction is a fast path instruction. Conversely, if that functional bit is set, the instruction is an MROM instruction. The opcode of an instruction may thereby be located within an instruction which may be directly decoded by decode units 20 as the byte associated with the first clear functional bit in the instruction. For example, a fast path instruction including two prefix bytes, a Mod R/M byte, and an immediate byte would have start, end, and functional bits as follows: Start bits 10000 End bits 00001 Functional bits 11000 MROM instructions are instructions which are determined to be too complex for decode by decode units 20. MROM instructions are executed by invoking MROM unit 34. More specifically, when an MROM instruction is encountered, MROM unit 34 parses and issues the instruction into a subset of defined fast path instructions to effectuate the desired operation. MROM unit 34 dispatches the subset of fast path instructions to decode units 20.

Processor 10 employs branch prediction in order to speculatively fetch instructions subsequent to conditional branch instructions. Branch prediction unit 14 is included to perform branch prediction operations. In one embodiment, branch prediction unit 14 employs a branch target buffer which caches up to two branch target addresses and corresponding taken/not taken predictions per 16 byte portion of a cache line in instruction cache 16.

The branch target buffer may, for example, comprise 2048 entries or any other suitable number of entries.

Prefetch/predecode unit 12 determines initial branch targets when a particular line is predecoded. Subsequent updates to the branch targets corresponding to a cache line may occur due to the execution of instructions within the cache line. Instruction cache 16 provides an indication of the instruction address being fetched, so that branch prediction unit 14 may determine which branch target addresses to select for forming a branch prediction. Decode units 20 and functional units 24 provide update information to branch prediction unit 14. Decode units 20 detect branch instructions which were not predicted by branch prediction unit 14. Functional units 24 execute the branch instructions and determine if the predicted branch direction is incorrect. The branch direction may be"taken", in which subsequent instructions are fetched from the target address of the branch instruction. Conversely, the branch direction may be"not taken", in which subsequent instructions are fetched from memory locations consecutive to the branch instruction. When a mispredicted branch instruction is detected, instructions subsequent to the mispredicted branch are discarded from the various units of processor 10. In an alternative configuration, branch prediction unit 14 may be coupled to reorder buffer 32 instead of decode units 20 and functional units 24, and may receive branch misprediction information from reorder buffer 32. A variety of suitable branch prediction algorithms may be employed by branch prediction unit 14.

Instructions fetched from instruction cache 16 are conveyed to instruction alignment unit 18. As instructions are fetched from instruction cache 16, the corresponding predecode data is scanned to provide information to instruction alignment unit 18 (and to MROM unit 34) regarding the instructions being fetched.

Instruction alignment unit 18 utilizes the scanning data to align an instruction to each of decode units 20. In one embodiment, instruction alignment unit 18 aligns instructions from three sets of eight instruction bytes to decode units 20. Decode unit 20A receives an instruction which is prior to instructions concurrently received by decode units 20B and 20C (in program order). Similarly, decode unit 20B receives an instruction which is prior to the instruction concurrently received by decode unit 20C in program order. In some embodiments, (e. g. embodiments employing fixed-length instruction sets), the instruction alignment unit 18 may be eliminated.

Decode units 20 are configured to decode instructions received from instruction alignment unit 18.

Register operand information is detected and routed to register file 30 and reorder buffer 32. Additionally, if the instructions require one or more memory operations to be performed, decode units 20 dispatch the memory operations to load/store unit 26. Each instruction is decoded into a set of control values for functional units 24, and these control values are dispatched to reservation stations 22 along with operand address information and displacement or immediate data which may be included with the instruction. In one particular embodiment, each instruction is decoded into up to two operations which may be separately executed by functional units 24A-24C.

Processor 10 supports out of order execution, and thus employs reorder buffer 32 to keep track of the original program sequence for register read and write operations, to implement register renaming, to allow for speculative instruction execution and branch misprediction recovery, and to facilitate precise exceptions. A temporary storage location within reorder buffer 32 is reserved upon decode of an instruction that involves the update of a register to thereby store speculative register states. If a branch prediction is incorrect, the results of speculatively-executed instructions along the mispredicted path can be invalidated in the buffer before they are written to register file 30. Similarly, if a particular instruction causes an exception, instructions subsequent to the particular instruction may be discarded. In this manner, exceptions are"precise" (i. e. instructions subsequent to the particular instruction causing the exception are not completed prior to the exception). It is noted that a particular instruction is speculatively executed if it is executed prior to instructions which precede the particular instruction in program order. Preceding instructions may be a branch instruction or an exception-causing instruction, in which case the speculative results may be discarded by reorder buffer 32.

The decoded instructions provided at the outputs of decode units 20 are routed directly to respective reservation stations 22. In one embodiment, each reservation station 22 is capable of holding instruction information (e. g. decoded instructions as well as operand values, operand tags and/or immediate data) for up to six pending instructions awaiting issue to the corresponding functional unit. It is noted that for the embodiment of Figure 1, each reservation station 22 is associated with a dedicated functional unit 24. Accordingly, three dedicated "issue positions"are formed by reservation stations 22 and functional units 24. In other words, issue position 0 is formed by reservation station 22A and functional unit 24A. Instructions aligned and dispatched to reservation station 22A are executed by functional unit 24A. Similarly, issue position 1 is formed by reservation station 22B and functional unit 24B; and issue position 2 is formed by reservation station 22C and functional unit 24C.

Upon decode of a particular instruction, if a required operand is a register location, register address information is routed to reorder buffer 32 and register file 30 simultaneously. The register file 30 comprises storage locations for each of the architected registers included in the instruction set implemented by the processor 10.

Additional storage locations may be included within register file 30 for use by MROM unit 34. Reorder buffer 32 contains temporary storage locations for results which change the contents of these registers to thereby allow out of order execution. A temporary storage location of reorder buffer 32 is reserved for each instruction which, upon decode, is determined to modify the contents of one of the real registers. Therefore, at various points during execution of a particular program, reorder buffer 32 may have one or more locations which contain the speculatively executed contents of a given register. If following decode of a given instruction it is determined that reorder buffer 32 has a previous location or locations assigned to a register used as an operand in the given instruction, the reorder buffer 32 forwards to the corresponding reservation station either: 1) the value in the most recently assigned location, or 2) a tag for the most recently assigned location if the value has not yet been produced by the functional unit that will eventually execute the previous instruction. If reorder buffer 32 has a location reserved for a given register, the operand value (or reorder buffer tag) is provided from reorder buffer 32 rather than from register file 30. If there is no location reserved for a required register in reorder buffer 32, the value is taken directly from register file 30. If the operand corresponds to a memory location, the operand value is provided to the reservation station through load/store unit 26.

In one particular embodiment, reorder buffer 32 is configured to store and manipulate concurrently decoded instructions as a unit. This configuration will be referred to herein as"line-oriented". By manipulating several instructions together, the hardware employed within reorder buffer 32 may be simplified. For example, a line-oriented reorder buffer included in the present embodiment allocates storage sufficient for instruction information pertaining to three instructions (one from each decode unit 20) whenever one or more instructions are dispatched by decode units 20. By contrast, a variable amount of storage is allocated in conventional reorder buffers, dependent upon the number of instructions actually dispatched. A comparatively larger number of logic gates may be required to allocate the variable amount of storage. When each of the concurrently decoded instructions has executed, the instruction results are stored into register file 30 simultaneously. The storage is then free for allocation to another set of concurrently decoded instructions. Additionally, the amount of control logic circuitry employed per instruction is reduced because the control logic is amortized over several concurrently decoded instructions. A reorder buffer tag identifying a particular instruction may be divided into two fields: a line tag and an offset tag. The line tag identifies the set of concurrently decoded instructions including the particular instruction, and the offset tag identifies which instruction within the set corresponds to the particular instruction. It is noted that storing instruction results into register file 30 and freeing the corresponding storage is referred to as "retiring"the instructions. It is further noted that any reorder buffer configuration may be employed in various embodiments of processor 10.

As noted earlier, reservation stations 22 store instructions until the instructions are executed by the corresponding functional unit 24. An instruction is selected for execution if : (i) the operands of the instruction have been provided; and (ii) the operands have not yet been provided for instructions which are within the same reservation station 22A-22C and which are prior to the instruction in program order. It is noted that when an instruction is executed by one of the functional units 24, the result of that instruction is passed directly to any reservation stations 22 that are waiting for that result at the same time the result is passed to update reorder buffer 32 (this technique is commonly referred to as"result forwarding"). An instruction may be selected for execution and passed to a functional unit 24A-24C during the clock cycle that the associated result is forwarded. Reservation stations 22 route the forwarded result to the functional unit 24 in this case. In embodiments in which instructions may be decoded into multiple operations to be executed by functional units 24, the operations may be scheduled separately from each other In one embodiment, each of the functional units 24 is configured to perform integer arithmetic operations of addition and subtraction, as well as shifts, rotates, logical operations, and branch operations. The operations are performed in response to the control values decoded for a particular instruction by decode units 20. It is noted that a floating point unit (not shown) may also be employed to accommodate floating point operations. The floating point unit may be operated as a coprocessor, receiving instructions from MROM unit 34 or reorder buffer 32 and subsequently communicating with reorder buffer 32 to complete the instructions. Additionally, functional units 24 may be configured to perform address generation for load and store memory operations performed by load/store unit 26. In one particular embodiment, each functional unit 24 may comprise an address generation unit for generating addresses and an execute unit for performing the remaining functions. The two units may operate independently upon different instructions or operations during a clock cycle.

Each of the functional units 24 also provides information regarding the execution of conditional branch instructions to the branch prediction unit 14. If a branch prediction was incorrect, branch prediction unit 14 flushes instructions subsequent to the mispredicted branch that have entered the instruction processing pipeline, and causes fetch of the required instructions from instruction cache 16 or main memory. It is noted that in such situations, results of instructions in the original program sequence which occur after the mispredicted branch instruction are discarded, including those which were speculatively executed and temporarily stored in load/store unit 26 and reorder buffer 32. It is further noted that branch execution results may be provided by functional units 24 to reorder buffer 32, which may indicate branch mispredictions to functional units 24.

Results produced by functional units 24 are sent to reorder buffer 32 if a register value is being updated, and to load/store unit 26 if the contents of a memory location are changed. If the result is to be stored in a register, reorder buffer 32 stores the result in the location reserved for the value of the register when the instruction was decoded. A plurality of result buses 38 are included for forwarding of results from functional units 24 and load/store unit 26. Result buses 38 convey the result generated, as well as the reorder buffer tag identifying the instruction being executed.

Load/store unit 26 provides an interface between functional units 24 and data cache 28. In one embodiment, load/store unit 26 is configured with a first load/store buffer having storage locations for data and address information for pending loads or stores which have not accessed data cache 28 and a second load/store buffer having storage locations for data and address information for loads and stores which have accessed data cache 28. For example, the first buffer may comprise 12 locations and the second buffer may comprise 32 locations.

Decode units 20 arbitrate for access to the load/store unit 26. When the first buffer is full, a decode unit must wait until load/store unit 26 has room for the pending load or store request information. Load/store unit 26 also performs dependency checking for load memory operations against pending store memory operations to ensure that data coherency is maintained. A memory operation is a transfer of data between processor 10 and the main memory subsystem (although the transfer may be accomplished in the data cache 28). Memory operations may be the result of an instruction which utilizes an operand stored in memory, or may be the result of a load/store instruction which causes the data transfer but no other operation.

Data cache 28 is a high speed cache memory provided to temporarily store data being transferred between load/store unit 26 and the main memory subsystem. In one embodiment, data cache 28 has a capacity of storing up to 64 kilobytes of data in an two way set associative structure. It is understood that data cache 28 may be implemented in a variety of specific memory configurations, including a set associative configuration, a fully associative configuration, a direct-mapped configuration, and any suitable size of any other configuration.

Bus interface unit 37 is configured to communicate between processor 10 and other components in a computer system via a bus. For example, the bus may be compatible with the EV-6 bus developed by Digital Equipment Corporation. Alternatively, any suitable interconnect structure may be used including packet-based, unidirectional or bi-directional links, etc. An optional L2 cache interface may be employed as well for interfacing to a level two cache.

It is noted that, while the embodiment of Figure 1 is a superscalar implementation, other embodiments may employ scalar implementations. Furthermore, the number of functional units may be varied from embodiment to embodiment. Other embodiments may use a centralized reservation station rather than the individual reservation stations shown in Figure 1. Furthermore, other embodiments may employ a central scheduler rather than the reservation stations and reorder buffer shown in Figure 1.

Processor 10 may include a port, shown here as mailbox port 100, which allows it to be queried during the execution of an instruction stream. Mailbox port 100 may be configured to be coupled to a service processor or a debug processor that is external to processor 10. Test data, used for querying a state of processor 10 may be received through mailbox port 100. Similarly, state data, indicative of the state of processor 10 resulting from the query may be transmitted from mailbox port 100 to the service processor or debug processor. Mailbox port 100 may be 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, and so on. Information may be sent or received from mailbox port 100.

Moving now to Figure 2, a block diagram of one embodiment of a system for determining the state of a processor is shown. In the embodiment shown, processor 10, hereafter host processor 10, may be coupled to service processor 140. In some embodiments, service processor 140 may be located in another computer system that may be coupled to a computer system in which host processor 10 is implemented. In other embodiments, service processor 140 may be located on a board inserted into a peripheral slot of the computer system in which host processor 10 is located, or may even be mounted to the same board as host processor 10.

As previously noted, host processor 10 includes a mailbox port 100. Mailbox port 100 may include mailbox input port 102 and mailbox output port 104. Mailbox input port 102 may be configured to be coupled to a complementary output port 152 of service processor 140. Similarly, mailbox output port 104 may be configured to be coupled to a complementary input port 154 of service processor 140.

Mailbox input port 102 of host processor 10 may receive test data transmitted from service processor 140.

The test data may be transmitted from output port 152 of service processor 140 to mailbox input port 102 of host processor 10. Similarly, service processor 140 may be configured to receive state data from host processor 10. The state data may be transmitted from mailbox output port 104 of host processor 10 to input port 154 of service processor 140. Each of the complementary pairs of input/output ports may function independently of one another.

In other words, output port 152 may transmit test data to mailbox input port 102 independently of any transmissions of state data from mailbox output port 104 to input port 154.

Test data may be serially loaded into a output port 152 of service processor 140 through a test data in (TDI) pin, which may be part of a test access port (TAP). The test access port may be a boundary scan port that is in compliance with IEEE standard 1149.1. Similarly, state data may be serially shifted from input port 154 through a test data out (TDO) pin. Additional details of loading test data and unloading state data from service processor 140 will be discussed below.

Turning now to Figure 3, a block diagram of illustrating one embodiment of a host processor input port coupled to a service processor output port. In the embodiment shown, mailbox input port 102 of host processor 10 is coupled to mailbox output port 152 of service processor 140. Mailbox input port 102 includes input register 112.

Input register 112 is configured to receive and store test data. The test data may be received from output register 162 located in output port 152. Both output register 162 and input register 112 may be of various sizes. In one embodiment, both output register 162 and input register 112 are configured to store 32 bits of data and one valid bit.

Other embodiments having different register sizes, as well as multiple registers (for both mailbox input ports and both mailbox output ports), are possible and contemplated.

In order to determine the state of host processor 10, the valid bit of input register 112 must be queried, followed by the loading of test data into output register 162. As previously noted, data may be loaded into mailbox output port 152 through a boundary scan TAP that complies with the IEEE 1149.1 standard. In the embodiment shown, output register 162 is coupled to a TDI pin. Test data may be serially shifted into output register 162 through the TDI pin. In addition to the test data, a valid bit may also be set in the output register through the TDI pin.

In order to transmit the test data to input register 112, it may be first necessary to poll the valid bit to make sure it is clear. Since this bit is in the host processor's clock domain, it must first be synchronized to the service processor clock domain. The synchronized version of the valid bit is captured into output register 162 and serially shifted out for examination. While the valid bit is being serially shifted out for examination, test data may be serially loaded into output register 162.

If during the polling of the valid bit of input register 112 it is determined that the valid bit is set, it may be an indication that test data has been loaded into mailbox input port 102 but has not been retrieved by host processor 10. Thus, the loading of test data into output register 162 and its subsequent transfer to input register 112 may be inhibited while this valid bit is set. Upon retrieval of the test data, the valid bit may be cleared from input register 112 by the host processor. Responsive to detecting that the valid bit stored in input register 112 is clear, output port 152 may initiate transfer of the test data to input register 112. In this embodiment, a separate TAP instruction is used to set the valid bit. Using this instruction causes a synchronized load of the data from output register 162 to input register 112 (See'A'in Figure 3).

A processor core of host processor 10 may also poll the valid bit in input register 112. Upon detecting the setting of the valid bit indicating the successful loading of test data into input register 112, the processor core may retrieve the test data. The test data may then be used to generate state data to be transmitted back to the service processor, as will be discussed in further detail below.

The protocol for transmission and reception between input ports and output ports may be the same for both host processor 10 and service processor 140. Table 1 below illustrates the protocol for one embodiment of an input port/output port combination. Transmitter Receiver 1. Poll host processor valid bit until clear 1. Poll host processor valid bit until set 2. Deposit data into register 2. Retrieve data 3. Set host processor valid bit. 3. Clear host processor valid bit Table 1 In general, a transmitter in the system (i. e. an output port) must poll the host processor valid bit prior to transmitting data to a receiver. Upon detecting the host processor valid bit to be clear, data may be deposited into the output register and transferred to the input register of the receiver. Successful transfer of the data from the transmitter to the receiver may be indicated by the setting of the valid bit in the input register. A receiver in the system (i. e. an input port) may poll the host processor valid bit until it is set. The setting of the host processor valid bit indicates that valid data is present in the input register, thus allowing the receiver to retrieve the data. Following the retrieval of data, the host processor's valid bit may be cleared.

In various embodiments, the receiver in the service processor may periodically shift data from its input register and examine the valid bit subsequent to said shifting (as the valid bit is part of the data shifted out) in order to determine whether the data is valid.

Figure 4 is a block diagram of one embodiment of a host processor output port coupled to a service processor input port. In the embodiment shown, mailbox output port 104 of host processor 10 is coupled to input port 154 of service processor 140. Mailbox output port 104 includes an output register 114, which is configured to store state data received from the processor core of host processor 10. The state data received into output register 114 may be generated responsive to previously input test data. Mailbox output port includes a output register 114, while input port 154 includes a input register 164.

Prior to any transfers of data to output register 114, it is necessary to poll the valid bit stored in output register 114 to determine if it is clear. Upon determining that the valid bit is clear, mailbox output port 104 may deposit state data into output register 114 and subsequently set the valid bit in output register 114. The transfer of data to input register 164 is initiated by service processor 140. This is done in the Capture-DR state of the TAP controller. Once the state data and valid bit have been transferred to input register 164, the valid bit may be examined and the data may be retrieved by shifting it out through the test data out (TDO) pin. If the valid bit is set, service processor 140 determines that the data that has been shifted out along with the valid bit is viable (i. e. valid data).

The transfers of data to and from the mailbox input and output ports, respectively, may be controlled by sets of instructions for both the service processor and the host processor. For one embodiment, the TAP instructions for the service processor are: MBOXIN, MBOXINSETV, MBOXOUT, and MBOXOUTCLRV. The MBOXIN instruction may be used by service processor 140 in order to effect a transfer of test data from output port 152 to mailbox input port 102. Service processor 140 may execute the MBOXINSETV instruction responsive to the transfer of test data, thereby setting the valid bit in input register 112 in order to indicate to host processor 10 that valid data is present. The MBOXOUT instruction may be executed in order to initiate a transfer of state data from host processor 10 to service processor 140. The MBOXOUTCLRV instruction may be executed in order to clear the valid bit stored in output register 114.

Instructions executed by host processor 10 may include model specific register (MSR) reads and writes to the mnemonics UCSPREGMBOXIN and UCSPREGMBOXOUT. An MSR read of UCSPREGMBOXIN may initiate an access to mailbox input register 112 in order to retrieve test data from the register. An MSR write to UCSPREGMBOXIN may be used to clear the valid bit. An MSR write to UCSPREGMBOXOUT may initiate an access to mailbox output register 114 in order to deposit state data, or to set the valid bit. An MSR read ofUCSPREGMBOXOUT may be used to detect that the valid bit is clear.

It should be noted that the mnemonics associated with the various instructions are exemplary for one particular embodiment. Embodiments having other mnemonics to describe the particular instructions used with the input and output ports are possible and contemplated.

It should be noted that output register 162 and input register 164 of service processor 140 may be any shift register in the TAP between the TDI pin and the TDO pin that includes a sufficient number of bit positions to store the test/state data and at least one valid bit. It should also be noted that other embodiments of service processor 140 are possible and contemplated wherein test data is loaded and state data retrieved through mechanisms other than the TAP described above. In addition, for the purposes of this description, the terms service processor and debug processor may be interchangeable, as a debug processor may be substituted for a service processor and configured in accordance with the description herein.

Moving now to Figure 5A a flow diagram of one embodiment of a method of querying a host processor is shown. Method 500 begins polling of the valid bit in the input register of a host processor (item 502). During polling, it is determined as to whether the valid bit is clear or set (item 504). If the valid bit is set, polling continues.

A set valid bit may indicate that the input register of the host processor contains valid data that has not yet been retrieved. The serial loading of test data may be through a TDI pin as discussed above. Other embodiments wherein the test data is loaded in parallel are possible and contemplated. Following the loading of test data into the output register, the output port of the service processor may transfer the data to the input register of the host processor (item 508) and set the valid bit (item 510). The setting of the valid bit in the input register of the host processor may indicate to the processor that valid data is present and ready for retrieval. Responsive to detecting the setting of the valid bit, the host processor may retrieve the test data and generate state data based on the test data (item 512). The valid bit stored in the input register of the mailbox input port may be cleared by the host processor following the retrieval of the test data by the host processor.

Figure 5B is a flow diagram of one embodiment of a method for outputting state data from a host processor. The state data may be generated in accordance with the method described in Figure 5A and the mechanisms described in Figures 1-4. Method 550 begins with the polling of the valid bit of the output register of the host processor (item 552). Similar to the method described in reference to Figure 5A, polling of the valid bit continues until the valid bit is determined to be clear (item 554). Once the valid bit is determined to be clear, the host processor may deposit state data into the output register of its mailbox output port (item 556). Following the loading of state data into the output register, the host processor sets the valid bit in the output register (Item 560).

The service processor may transfer the data and the valid bit in the Capture-DR state and then shift it from the input register (Item 562). If the transferred valid bit is set, the data is also then known to be valid. Responsive to the retrieval of the state data from the input register, the host processor valid bit may be cleared, thereby enabling additional state data to be sent from the host processor. It is important to note that the operations described in reference to Figure 5B may occur independently of those described in reference to Figure 5A.

It should be noted that the term'test data'used herein may refer to any type of data that may be input into host processor 10 in order to receive a desired response. Similarly, the term'state data'may refer to any type of data that may be used to provide information concerning the operation of host processor 10. In addition, it should also be noted that the loading of test data and/or the retrieval of state data may either be in response to individual queries of the processor, or may be an operation that is performed at regular intervals. Alternative embodiments are also possible and contemplated wherein the specific order of polling the valid bits and transferring data may be different from that described herein.

While the present invention has been described with reference to particular embodiments, it will be understood that the embodiments are illustrative and that the invention scope is not so limited. Any variations, modifications, additions, and improvements to the embodiments described are possible. These variations, modifications, additions, and improvements may fall within the scope of the inventions as detailed within the following claims.

INDUSTRIAL APPLICABILITY This invention may generally be applicable to processors.