Debug support in a processor chip

A central processing unit (CPU) with facilities for debug support. The debug support facilities include debug support unit (DSU), a debug support interface bus, and a diagnostic instrument. During an execution trace, the DSU transmits trace data such as an instruction address and a trace status via the bus to the diagnostic instrument. Instruction addresses are sent in 4-bit segments in one clock cycle during a trace. Trace status includes an indication of non-sequential instruction execution by the Instruction Unit (IU). A control bit is used to toggle a hold on IU operation where a non-sequential instruction is encountered in trace mode. The diagnostic instrument uses trace data provided by the DSU to generate a complete execution trace in real-time. During breakpoint operations, input such as a debug instruction is provided by the diagnostic instrument via the debug support interface bus to the CPU for execution thereby.

FIELD OF THE INVENTION 
The present invention relates in general to debug support in a single chip 
central processing unit (CPU) and specifically to an interface in a single 
chip CPU for coupling to a diagnostic instrument to facilitate debugging 
and tracing of transactions performed by the CPU. 
BACKGROUND OF THE INVENTION 
In a typical procedure of bringing up a computer, a set of diagnostic 
programs is first run. The diagnostic programs are typically written to 
test specific components of the computer and, in the event of a failure, 
provide error message(s) identifying or isolating the cause(s) thereof. 
Upon completion of the diagnostic programs, benchmark application programs 
may also be executed. The benchmark application programs typically 
comprise routines that exercise the functions expected from the computer 
and are run to determine whether these functions are performed correctly 
thereby. 
In running the test programs and/or the benchmark application programs, one 
often encounters failures that do not manifest themselves until after 
processing has proceeded for a substantial period of time past the 
failures, or failures (such as timing errors caused by unexpected 
capacitance in signal paths) that manifest only when the computer runs at 
full speed (as oppose to those that manifest in "single-cycle" which are 
relatively more easy to debug). When such types of failures occur, one 
vital debugging tool is to obtain a trace of the transactions performed by 
the computer. Tracing the transactions performed by the computer often 
means tracing the instructions it executes. From the trace, the activities 
of the computer during the time of a failure can be examined and from such 
activities the possible area of the failure can be isolated. 
Tracing instructions is also useful for developing and debugging a computer 
software, where the trace can assist in understanding how and when 
problematic portions of the software are entered or exited. 
Another often-used tool for debugging a computer system and/or computer 
software is to set breakpoints at selected addresses of the software. The 
breakpoints trap the flow of the software, such as whether, when and how 
certain portions of a software are entered and exited. From the flow, the 
behavior of the software can be examined. 
Setting breakpoints also facilitates debugging and development of a 
computer or a computer software by allowing trial values to be injected at 
various processing stages of the software. 
Tracing and trapping instructions are typically accomplished in prior art 
computers by a debug support circuit which is connected to the system 
bus--the bus that connects the CPU to the external memory and other 
peripheral devices. Connecting the debug support circuit to the system bus 
is convenient in prior art computers because it is where addresses, 
instructions and data of the computer flow. Moreover, by connecting the 
debug support circuit to the system bus, there is no need to add new 
input/output pins to a semiconductor chip; otherwise, the new I/O pins 
needed may be significant because instruction tracing requires outputting 
addresses whose length is normally equal to the width of the computer. 
Unfortunately, providing the debug support circuit from the system bus also 
increases the electrical load of the system bus and interferes with the 
design and operation thereof. Moreover, debug support operations may be 
handicapped by shared use of the system bus, as they may be interfered by 
operations of the external memory and other peripheral devices. 
Connecting the debug support circuit to the system bus is also undesirable 
for CPUs that use internal cache(s). In these CPUs, memory access is not 
performed if there is a cache hit; that is, instructions, data and 
addresses will not pass through the system bus when they are already 
present in the internal cache. If the instructions, data or addresses are 
accessed without passing through the system bus, they may become 
undetectable to the debug support device. 
What is needed in view of the foregoing is a new debug support interface in 
a CPU whereby tracing and trapping of instructions can be achieved without 
using the system bus. Preferably, the new debug support interface allows 
tracing and trapping of instructions even when the CPU has an internal 
cache. Moreover, because increasing input/output pins of a semiconductor 
chip has an adverse effect on the cost and design thereof, it is also 
important that the new debug support interface does not significantly 
increase the number of input/output pins of the chip. 
SUMMARY OF THE INVENTION 
The present invention discloses a single chip central processing unit (CPU) 
for coupling with a external memory via a system bus to form a data 
processing system. The central processing unit comprises a processor 
having means for decoding instructions and means for executing 
instructions. The central processing unit also comprises a first bus for 
connecting the processor with the system bus to communicate instructions 
and data between the processor and the external memory. The central 
processing unit according to the present invention also comprises a second 
bus for connecting the processor with an external diagnostic instrument to 
communicate instructions and data between the processor and the diagnostic 
instrument. 
The present invention also discloses a method in a computer of providing a 
trace of instructions processed by a processor. The method comprises the 
step of outputting data of the trace through a bus which is smaller in 
width than the trace data and the step of maintaining the rate of the 
processor substantially at its normal rate when the trace data are output. 
The present invention also discloses a computer system, having a first 
memory, a second memory, a processor fetching instructions from a memory 
space, and means for mapping said memory space into said first memory 
during normal operations and mapping said memory space into said second 
memory during debug support operation.

DESCRIPTION OF THE PREFERRED EMBODIMENT 
FIG. 1 is a schematic block diagram illustrating a single chip central 
processing unit (CPU) 100 wherein the present invention is embodied. The 
CPU 100 has an architecture generally described in "The SC.TM. 
Architecture Manual, Version 8", Sun Microsystems, Inc Jan. 30, 1991, 
which is incorporated herein by reference. The CPU 100 is a 32-bit wide 
processing unit. Accordingly, the basic format of its instructions, its 
data and addresses and its components such as busses, arithmetic and logic 
unit and registers are 32 bits wide. It is noted, however, that the width 
is specifically mentioned herein to facilitate discussion and 
understanding of the preferred embodiment and is not intended to limit the 
applicability of the present invention. 
Like to a conventional computer, CPU 100 fetches instructions and data from 
an external memory 125. The fetched instructions are processed by an 
Integer Unit (IU) 110 located within the CPU 100. The term "Integer Unit" 
is used herein to conform with the terminology set forth by the SC 
Architecture and is not intended as limitation of the applicability of the 
present invention. The IU 110 generally possesses facilities normally 
found in conventional computers, such as instruction sequence logic, a 
program counter, etc. 
The CPU 100 is connected to the external memory 125 via a 32-bit wide 
conventional bus 126, commonly referred to as a system bus. Besides the 
external memory 125, the system bus 126 also connects the CPU 100 to other 
peripheral devices, such as disks, monitors, keyboard, mouses, etc. (not 
shown). The CPU 100 is connected to the system bus 126 through a bus 
interface unit (BIU) 120. BIU 120 operates to control and buffer signals 
passing between the CPU 100 and the external memory 125, and between the 
CPU 100 and other peripheral devices. 
According to the preferred embodiment, CPU 100 can directly address up to 
one terabyte (10.sup.12) of memory, organized into 256 address spaces of 4 
gigabytes (10.sup.9) each. These address spaces may or may not overlap in 
physical memory, depending on the particular system design. 
In accordance with the SC architecture, a memory access involves an 
8-bit Address Space Identifier (ASI) as well as a 32-bit address. The ASI 
selects one of the address spaces, and the address selects a 32-bit word 
within that space. The assignment of the address spaces is listed in Table 
1. 
It is noted from Table 1 that ASI 0.times.9 (hereinafter, "0.times." is 
used to designate that the number that follows is an hexadecimal number; 
for example, 0.times.9 means a hexadecimal value of "9") is reserved for 
storing instructions to be executed by the CPU 100 in supervisor mode and 
ASI 0.times.B is reserved for storing data to be executed by the CPU 100 
in supervisor mode. 
FIG. 1 also shows a clock control logic 160 which supplies clock and other 
control signals needed for the operation of various components within the 
computer 100. Description of the clock control logic 160 is deemed 
unnecessary as it is not needed for the understanding and use of the 
present invention and because the design of the clock control logic 160 is 
so dependent on the particular design of a CPU. 
Similar to a conventional computer, CPU 100 has logic for supporting 
interrupts, including those initiated externally such as by the peripheral 
devices, and those caused by executions of instructions. The later 
interrupts are also called "traps". 
Interrupts and traps can be enabled and disabled in CPU 100 as in 
conventional computers. When enabled, interrupts and traps cause control 
of the CPU 100 to be transferred (i.e. a process switch) to a service 
routine. In accordance with the SC architecture, control of the CPU 100 
is transferred to an address generated by a trap base register (TBR). One 
field of the TBR contains the base address of a trap dispatch table. 
Normally, an 8-bit trap type number serves as an offset into this table. 
Unlike other traps, however, pointers to breakpoint trap routines are not 
generated from the TBR; rather, they are set to start at 0.times.00000ff0. 
Similar to a conventional computer, CPU 100 is provided with means for 
saving the state of the CPU 100 when an interrupt or trap occurs before 
entering a service routine. Similar to a conventional computer, it also 
has means for restoring the CPU 100 to the interrupted state upon return 
from the service routine. 
To reduce access time of instructions/data, CPU 100 employs an hierarchical 
memory architecture. Under such memory architecture, instructions and data 
from the external memory 125 are first staged respectively into an 32-bit 
wide instruction cache 150 and a 32-bit wide data cache 151, both of which 
are internal to the chip. When the IU 110 needs to fetch memory items such 
as instructions and data, a check is made to see if they have already been 
staged to the caches 150, 151. If a copy of the required memory item is 
already present in the caches (that is, if there is a "cache hit"), the 
copy in the caches 150, 151 is accessed by the IU 110 and access to the 
external memory 125 is not made. In other words, if there exists a copy of 
the data or instructions in the caches 150, 151, no address and access 
signals are output by the CPU 100 to the system bus 126. 
The BIU 120, the IU 110 and the caches 150, 151 are coupled by an internal 
bus 155 which comprises a signal path for carrying instruction (also 
called instruction.sub.-- data under the SC convention) 155a, a signal 
path for carrying addresses of instructions (also called 
instruction.sub.-- addresses under the SC convention) 155b, a signal 
path for carrying addresses of data (also called data.sub.-- addresses 
under the SC convention) 155c, a signal path for carrying data (also 
called data.sub.-- data under the SC convention) 155d and a signal path 
for carrying control signals 155e. 
In accordance with the present invention, CPU 100 also comprises a debug 
support bus (EMU.sub.-- BUS) 140 for connecting to a diagnostic instrument 
145. The availability of EMU.sub.-- BUS 140 allows the diagnostic 
instrument 145 to set breakpoints in the CPU 100 as well as to obtain a 
complete trace of instructions processed by the CPU 100. 
The EMU.sub.-- BUS 140 occupies ten input/output pins in the CPU chip. The 
signals assigned to these ten pins are shown schematically in FIG. 2 and 
their functions are listed in Table 2. The EMU.sub.-- BUS 140 is connected 
to the CPU 100 via a debug support unit (DSU) 130. The DSU 130 has a 
plurality of registers, including six on-chip breakpoint descriptor 
registers. Two of these descriptor registers are provided for setting 
breakpoints on instruction addresses, two are provided for setting 
breakpoints on data addresses and two are provided for setting breakpoints 
on data values. DSU 130 is also provided with a debug control register for 
controlling a debug operation and a DSU status register for reporting 
status of a debug operation. Definitions of the various bits in the DSU 
control register are listed in Table 3. Definitions of the various bits in 
the DSU status register are listed in Table 4. 
The DSU breakpoint descriptor registers, DSU control register and DSU 
status register are memory mapped to ASI 0.times.1 and their respective 
addresses are listed in Table 5. 
With reference to FIG. 2, a plurality of signals are provided between the 
DSU 130 and the IU 110, including those signals listed in Table 6. 
One important debugging tool provided under the preferred embodiment of the 
present invention is the ability to trace a sequence of instructions 
executed by the CPU 100. The instructions are traced by their respective 
addresses, which can be obtained either from the internal bus of the 
addresses sent by the IU 110 to the internal cache 150 during an 
instruction fetch, or from the program counter (PC) of the CPU 100. 
To be effective for debugging, it is preferable for a trace to contain all 
or almost all of the instruction addresses. It is also preferably that 
trace be performed with minimal intrusion to the operation of the CPU 100 
(for example, slowing it down). 
It is recalled that CPU 100 uses a 32-bit wide address to access 
instructions. However, it is also recalled that in order to minimize the 
number of I/O pins on the chip, only ten input/output pins are provided 
for the EMU.sub.-- BUS 140. Of these 10 pins, eight pins are assigned for 
communicating data/addresses/instructions between the CPU 100 and the 
diagnostic instrument 145. Therefore, even if all these eight pins are 
used, at least four cycles are required to output one address. However, 
the highest throughput of the CPU 100 is one instruction per cycle. If the 
throughput of the CPU 100 is to be maintained during a trace operation, 
the trace would omit at least three addresses for every address output 
(i.e. the trace is incomplete). However, a trace with such a gap may not 
be effective for debugging purposes because important information may have 
left out. 
On the other hand, if a complete trace is to be output, the CPU 100 must be 
slowed down. However, when the CPU 100 is slowed down, the trace obtained 
thereby may fail to capture crucial timing characteristics of the CPU 100 
and/or fail to reflect its performance under true working conditions. 
According to the present invention, a trace is performed by outputting the 
instruction addresses on bits EMU.sub.-- D&lt;3:0&gt;. An instruction address is 
output in segments of 4 bits each during a trace operation, so it can be 
output via EMU.sub.-- D&lt;3:0&gt;. Each of these 4-bit segments is hereinafter 
referred to as a nibble. Since an instruction address is 32 bits long, a 
total of 8 nibbles are formed and thus a total of 8 cycles are required to 
completely output an address. An instruction address is output by 
outputting the most significant nibble (bits&lt;32:29&gt;) first, followed by 
the next most significant nibble (bit&lt;28:25&gt;), etc. 
Because memory items are addressed by 32-bit words, the last two bits of an 
instruction address are always zero. Therefore, these two bits are not 
output in the trace. Instead, bit &lt;1&gt; of the last nibble is advantageously 
used to send an indication to the diagnostic instrument 145 to indicate 
whether CPU 100 is in supervisor state. Bit &lt;0&gt; of the last nibble is 
advantageously used to send an acknowledgment to the diagnostic instrument 
145 that a trap is taken. 
When each nibble is sent in a cycle, a three-bit trace status is 
concurrently sent through EMU.sub.-- SD&lt;2:0&gt;. These three bits can be 
decoded into the eight different messages shown in Table 7. The status 
information EMU.sub.-- SD&lt;2:0&gt; includes an indication, "sequential fetch", 
which indicates whether the CPU 100 is executing a next sequential 
instruction in the corresponding cycle. From the above-identified 
indication, the diagnostic instrument 145 is informed that sequential 
instructions are performed and therefore a complete trace can be 
reconstructed even when instruction addresses are not sent. The status 
information EMU.sub.-- SD&lt;2:0&gt; also include an indication, MSN 
(IA&lt;31:28&gt;), which indicates whether EMU.sub.-- D&lt;3:0&gt; currently 
outputting a most significant nibble. 
When a jump or a branch is taken, that is, when the instruction processed 
becomes out of sequence, the jumped-to address must be output to the 
diagnostic instrument 145 because it can no longer rely on the sequential 
nature of the instructions to reconstruct the trace. Therefore, if the DSU 
130 is busy in outputting the nibbles of an instruction address when an 
out-of-sequence instruction is executed, it sends a HOLD signal to the IU 
110. In response to the HOLD signal, IU 110 becomes temporarily dormant. 
After the nibbles of the outputting instruction address are completely 
output, the HOLD signal is dropped because DSU will then have time to 
output the out-of-sequence instruction address. When the HOLD signal is 
dropped, the IU 110 can continue processing. 
For additional flexibility, a TRACE.sub.-- NOT.sub.-- HOLD.sub.-- IU (bit 
11) bit is provided in the DSU control register. When this bit is set, 
processing by the IU 110 is not held even if the IU 110 executes an 
out-of-sequence instruction. As a result, operation of the IU is 
completely free from interruption by the trace operation. However, because 
an out-of-sequence instruction is taken, the first address of the new 
sequence may be missing in the trace result. 
A trace operation is illustrated generally in the flow chart of FIG. 3. In 
the first of every eight cycles, the DSU 130 obtains the address of the 
instruction executed by the IU 110 (block 301). The address is then 
partitioned into eight nibbles. In block 303, the most significant nibble 
is output from EMU.sub.-- D&lt;3:0&gt;, along with a status from EMU.sub.-- 
SD&lt;2:0&gt;. The status EMU.sub.-- SD&lt;2:0&gt; is set to "111" to indicate to the 
diagnostic instrument 145 that the nibble output in the cycle is the most 
significant nibble of an instruction address. 
The rest of the nibbles are output in successive cycles (block 305). 
Concurrently with the outputting of each nibble, a new instruction is 
processed by the IU 110 (unless the HOLD signal is set). A determination 
is made to see whether the instruction processed by IU 110 is a jump or 
branch instruction (block 307). Such determination can be made by checking 
the I.sub.-- PLUS.sub.-- 4 line from the IU 110 (see Table 6). Signals 
such as I.sub.-- PLUS.sub.-- 4 can typically be found in conventional 
computers, when they are generated to inform the instruction sequence 
logic in a computer of whether the next instruction to be processed is an 
instruction sequential to the instruction currently being executed, or 
whether it is a target instruction of a branch/jump operation. 
Referring back to the flow chart of FIG. 3, if a jump/branch is taken, the 
DSU 130 checks whether the "TRACE.sub.-- NOT.sub.-- HOLD.sub.-- IU" flag 
(bit 11) in the DSU control register is set (block 308). If this flag is 
off and if the next instruction is an out-of-sequence instruction, DSU 130 
sends a HOLD signal to the IU 110 (block 309). In response, IU 110 delays 
processing of the new instruction until the HOLD signal is dropped. 
The HOLD signal is dropped when the DSU 130 sends the last nibble of the 
outputting instruction address. In block 311, a determination is made to 
see whether the last nibble is sent. If the last nibble is sent, the DSU 
130 obtains another instruction from the IU 110 (block 301). Otherwise, if 
the last nibble is not sent, DSU 130 returns to block 305 to send the next 
nibble. The trace operation continues in similar manner. 
FIGS. 4a-4c show a specific example of a trace operation. For ease of 
discussion, it is herein assumed that instruction addresses of the 
computer has only 16 bits. 
FIG. 4a shows a hypothetical sequence of instructions to be performed by 
the CPU 100. This sequence includes a first instruction located at 
location 0001 and its next sequential instruction located at location 
0002. The 0002 instruction causes the CPU 100 to take a branch to location 
0007. Instruction 0007 is followed by a next sequential instruction at 
0008 which causes the CPU 100 to jump to location 0010. After instruction 
0010 is executed, a next sequential instruction 0011 is executed, which 
causes the CPU 100 to jump to location 1000. 
FIG. 4b shows how a complete trace of the instructions is accomplished. In 
cycle 1, IU 110 sends the address 0001 to the DSU 130. Upon receiving the 
address, DSU 130 sends the first nibble "0" of the address through 
EMU.sub.-- D&lt;3:0&gt; to the diagnostic instrument 145. The nibble is stored 
by the diagnostic instrument 145. DSU 130 also sets EMU.sub.-- SD&lt;2:0&gt; to 
"111" to indicate that this is the most significant nibble of an 
instruction and that this is not a sequential instruction. For purposes to 
be described below, the diagnostic instrument 145 initializes a counter in 
this cycle. 
In cycle 2, IU 110 sends the address 0002, along with the I-PLUS-4 bit to 
the DSU 130. At the same time, DSU 130 sends the second nibble "0" through 
EMU.sub.-- D&lt;3:0&gt;, which is stored by the diagnostic instrument 145. DSU 
110 also sets EMU.sub.-- SD to "010" to inform the diagnostic instrument 
145 that a next sequential instruction has been performed by the IU 110. 
The diagnostic instrument 145 can either store this status or it can, in 
response to the status, increments the content of the counter. From the 
stored status or from the value of the counter, the diagnostic instrument 
145 can later reconstruct the instruction sequence. 
In cycle 3, IU 110 sends address 0007 to the DSU 130. However, because a 
jump is performed, it deactivates the I-PLUS-4 bit. Because DSU 130 has 
not finished sending the nibbles of instruction 0001, when it senses that 
the I-PLUS-4 bit is deactivated, it sends the HOLD signal to the IU 110 
(assuming that the "Trace.sub.-- Not.sub.-- Hold.sub.-- IU" bit is not 
set). In response to the HOLD signal, IU 110 suspends further processing. 
The DSU 130 continues to send the third nibble "0" of instruction 0001, 
which is received and stored by the diagnostic instrument 145. Along with 
the third nibble, EMU.sub.-- SD is set by DSU 130 to "001". 
In cycle 4, processing by the IU 110 is still held by the HOLD signal. The 
DSU 130 sends the last nibble "1", which is received and stored by the 
diagnostic instrument 145. EMU.sub.-- SD is set by DSU 130 to "001". 
Therefore, at the end of cycle 4, the last nibble of the first address is 
completely sent to the diagnostic instrument 145. From the nibbles, the 
diagnostic instrument 145 can reconstruct address 0001. Moreover, based 
upon the stored statuses or the value of the counter, DSU 130 can 
reconstruct the address of 0002 (simply for adding the length of an 
instruction). When the last nibble is sent, DSU 130 drops the HOLD signal. 
In cycle 5, DSU 130 sends the first nibble "0" of address 0007 to the 
diagnostic instrument 145. EMU.sub.-- SD&lt;2:0&gt; is also set to "111" as in 
cycle 1. Because the HOLD signal is dropped, IU 110 can continue 
processing the next instruction. 
In cycle 6, IU 110 sends address 0008 to the DSU 130. Similar to Step 2, 
DSU 110 sets EMU.sub.-- SD to "010" to inform the diagnostic instrument 
145 that the next sequential instruction is performed. 
The rest of the cycles are performed in a manner similar to those described 
in the previous cycles, specifically cycles 1, 2, 3 and 4. 
FIG. 4c illustrates how the above-described trace data are reconstructed in 
the diagnostic instrument 145. It can seen that a complete trace can be 
obtained even though only eight bits are available for output the trace 
data. 
FIG. 5 is a schematic block diagram illustrating the general logic within 
the DSU 130 for outputting the trace data. As stated, DSU 130 is connected 
to the instruction address bus 155b. When an address is received by the 
DSU 130, it is segmented into eight nibbles. Each of these nibbles is 
connected to an input of a multiplexor 501. It is recalled that since a 
memory is addressed in words only, the least significant two bits of the 
address are always zero. Therefore, these two bits are not connected to 
the multiplexor 501. Instead, these last two bits are connected to an 
ISUPER signal and a TRAP-ACK signal. The ISUPER is a signal which 
indicates whether the IU 110 is operating in supervisor mode. The TRAP-ACK 
signal is used to acknowledge that a trap operation is performed. 
To output the nibbles in sequence, one implementation is to provide a 
three-bit counter 502 the output of which controls the multiplexor 501. 
The multiplexor 501, in response to the output of the counter 502, outputs 
the nibbles through EMU.sub.-- D&lt;3:0&gt; in eight successive cycles. 
Also connected to the DSU 130 is a signal MSN from the IU 110. The MSN 
signal indicates whether the nibble being output from the IU 110 is the 
most significant nibble. It can be found in the instruction sequence logic 
of many conventional computers. 
Also connected to the DSU 130 are a HELD signal which indicates whether the 
IU 110 is held; a TRAP ACK which indicates whether a trap is taken; the 
I-PLUS-4 as previously described, and an IFETCH signal which indicates 
whether the IU 110 is performing an instruction fetch. 
The above signals are input into a logic shown in FIG. 5. Through the 
logic, the status signals EMU.sub.-- SD&lt;2:0&gt; as shown in Table 7 are 
encoded. 
Also output from the DSU 130 is an EMU.sub.-- SD&lt;3&gt; signal. This signal is 
used to indicate whether one or more of the breakpoint conditions defined 
by the DSU descriptor registers and the DSU control register is matched. 
This signal can advantageously be used to perform complex breakpoint 
operations, as will be described hereinafter. 
Another important debugging tool provided in the CPU 100 is the ability to 
set breakpoints to monitor various addresses of a program and/or to 
monitor various data values. When a breakpoint is encountered, the 
diagnostic instrument 145 is notified. 
CPU 100 provides a diagnostic engineer with two options with regard to 
breakpoint operations. Under the first option, operation of the CPU 100 is 
interrupted. The diagnostic instrument 145 can then inject 
instructions/data into the CPU 100 for execution thereby. Under the second 
option, operation of the CPU 100 is not interrupted. However, notification 
of the breakpoint is sent to the diagnostic instrument 145 through 
EMU.sub.-- SD&lt;3&gt; as described above. The diagnostic instrument 145 may be 
programmed to perform specific actions, such as by monitoring for certain 
pattern of breakpoints, for example, to monitor for a breakpoint that is 
encountered for the sixth time or to monitor for a condition in which a 
first breakpoint and a second breakpoint are encountered successively. The 
notification from EMU.sub.-- SD&lt;3&gt; can be used to drive such program. 
The breakpoints are defined by the DSU descriptor registers and by the DSU 
control registers. There are two breakpoint descriptor registers defining 
instruction address breakpoints. Two descriptor registers are provided for 
defining data address breakpoints and two are provided for defining data 
value breakpoints. When these descriptor registers is used for creating a 
breakpoint, corresponding bit(s) in the DSU Control Register, as shown in 
Table 3, must be set. 
The data value description registers work in either one of two ways. If the 
value of data.sub.-- value.sub.-- mask bit in the DSU Control Register is 
"1", the data value descriptor register 2 is used as a mask for data value 
descriptor register 1. In this mode, only those bits of data value 
descriptor 1 are compared, for which the mask bit is "1". All other bits 
are ignored in the breakpoint comparison. If the data.sub.-- value.sub.-- 
mask bit is "0", the data value descriptor registers 1 and 2 act as the 
lower and upper bound respectively, for a range comparison. The break 
condition is determined by the values of the data value condition bit in 
the debug control register. If the data value condition is a "0", then the 
break condition is given by the expression: 
______________________________________ 
data value description 1 .ltoreq. 
accessed value .ltoreq. 
data value descriptor 2 
______________________________________ 
If the data.sub.-- value.sub.-- condition bit is a "1", this break 
condition is inverted, turning the comparison into an "out-of-range" test. 
The data value comparison may be conditioned by the type of transaction 
("load" or "store") that is being performed. The condition is defined by 
encoding of the data.sub.-- value.sub.-- transaction.sub.-- type bits in 
the DSU control register shown in Table 3. 
A break occurs when one or more condition, instruction address, data 
address or data value set forth in the descriptor registers is matched. A 
break may also be caused externally and asynchronously by activating the 
EMU.sub.-- BRK pin. 
A break causes the CPU 100 to take a trap in the same way as a reset or an 
exception causes the CPU 100 to take a trap. Breakpoint traps have a 
priority less than the other synchronous traps, but greater than trap 
instructions or external interrupts. When a breakpoint trap is recognized 
by the IU 110, it branches to address 0.times.00000ff0. 
It was stated above that breakpoints are normally set by appropriately 
setting the DSU control and descriptor register. The general steps for 
setting these DSU registers are shown in the flow chart of FIG. 6. 
In block 610, the diagnostic instrument 145 activates the EMU.sub.-- BRK 
204 input to the DSU 130. At the same time, the CPU 100 is reset. When 
EMU.sub.-- BRK 204 signal is activated, the CPU 100 is set to a 
"DSU-IN-USE" mode (block 611) and supervisor mode. Both these modes are 
represented by respective flags in the CPU 100. Similar to a conventional 
computer, when the CPU 100 is reset, IU 110 fetches an instruction from 
address "0" (block 612). 
As shown in FIG. 1, the IU 110, DSU 130 and the BIU 120 are all coupled by 
an internal bus 155. When the IU 110 operates under the supervisor mode, 
instructions are accessed with ASI=0.times.9 or ASI=0.times.B. Moreover, 
when the CPU 100 operates under the DSU.sub.-- IN.sub.-- USE mode, 
addresses with ASI=0.times.9 or ASI=0.times.B are ignored by the BIU 120, 
but instead processed by the DSU 130. In other words, when the IU 110 
accesses the memory under the DSU.sub.-- IN.sub.-- USE mode, the memory 
spaces of ASI=0.times.9 and ASI=0.times.B are mapped from the external 
memory 125 to the memory provided with the diagnostic instrument 145. The 
mapping is transparent to the IU 110. When IU fetches an instruction from 
location "0", the fetch operation is performed through the EMU.sub.-- BUS 
140 in a similar manner as it would have been performed to the external 
memory 145 or to a peripheral device through the system bus 126. 
FIG. 10 is a block diagram illustrating how the memory spaces ASI=0.times.9 
and ASI=0.times.B are mapped to the diagnostic instrument 145 during a 
breakpoint operation. When the DSU.sub.-- IN.sub.-- USE flag is set by a 
breakpoint trap, it enables the output of either ASI=0.times.9 or 
ASI=0.times.B to output from block 101. The positive output of block 101 
is applied to DSU 130 to enable it to pass addresses and memory items 
between the IU 110 and the diagnostic instrument 145. The negative output 
of the block 101 is applied to BIU 120 to disable it from passing 
addresses and memory items between the IU 110 and the system bus 126. 
In address "0" of the memory provided with the diagnostic instrument 145, 
an instruction such as "load DSU register n" is stored. The instruction is 
sent to the CPU 100 as though it comes from the external memory 126 (block 
614). IU 110 processes this instruction and as a result loads the DSU 
register n (block 615). 
When the IU 110 finishes processing this instruction, it fetches the next 
instruction (block 617). The address of the next instruction is again sent 
to the DSU 130 because of the above described condition. DSU 130 again 
forwards it to the diagnostic instrument 145. The process continues until 
the diagnostic instrument 145 sends an instruction such as a "return from 
trap (RETT)" instruction (block 618). Upon executing the RETT instruction, 
the CPU 100 exits the DSU.sub.-- IN.sub.-- USE mode and the memory spaces 
ASI=0.times.9 and ASI=0.times.B are again mapped to the external memory 
125. From there on, the CPU 100 can start processing of normal application 
programs. 
FIG. 7 is a flow chart illustrating in general how a typical breakpoint 
operation is performed. In block 711, breakpoints are set as described 
above. In block 712, the CPU 100 continues to fetch instructions and 
process the fetched instructions. When each instruction is processed, a 
determination is made (block 713) to see if a breakpoint, as defined in 
the description registers and the DSU control register, is encountered. 
If a breakpoint is encountered, a trap is taken and the CPU 100 takes a 
process switch and enters into supervisor mode and DSU.sub.-- IN.sub.-- 
USE mode. It then executes a trap routine stored in location 
0.times.00000ff0 (block 714) of the supervisor address space. 
In processing the trap routine, the IU 110 sends out addresses for 
instructions and data (block 715). However, because CPU 100 is in 
DSU-IN-USE mode and supervisor mode (ASI=0.times.9, 0.times.B), these 
addresses are acted upon by the DSU 130 instead of the BIU 120 (block 
716). The switch is transparent to the IU 110 which waits for the 
data/instructions in a similar manner as when it accesses the external 
memory 125 or the peripheral devices. 
DSU 130 outputs these addresses to the diagnostic instrument 145 in a 
similar manner as BIU 120 outputs addresses to the external memory 125 or 
to the peripheral devices. The diagnostic instrument 145, in response to 
the addresses from the IU 110, returns instructions/data in a similar 
manner as though it is a peripheral device (block 717). 
The CPU 100 receives the instructions/data as though it receives 
instructions/data from the external memory 125 or a peripheral device 
through BIU 120. When an instruction is received, it is processed by the 
IU 110 (block 619). 
At the end of the trap routine, a "return from trap instruction" (RETT) 
instruction is sent from the diagnostic instrument 145 to the IU 110. 
As an alternative to the above described breakpoint handling procedure, a 
bit "Disable.sub.-- Match.sub.-- BreaK" can be set in the DSU control 
register. When this flag is set, a break or process switch is not 
initiated even when the breakpoint encountered. However, a match signal is 
sent from the CPU 100 to the diagnostic instrument 145 through EMU.sub.-- 
SD&lt;3&gt;. The feature is provided to allow the diagnostic to set complex 
breakpoints. 
FIG. 8 is a schematic block diagram illustrating how an instruction address 
breakpoint is detected. The diagram shows a comparator with one input 
connected to a descriptor register (IA1/IA2/DA1/DA2/DV1/DV2) and another 
input connected to the program counter (PC) in the IU 110. The output of 
the comparator 801 is connected to a switch 802 which is controlled by the 
disable.sub.-- match.sub.-- break bit of the DSU control register. When 
the two inputs match, the output of the comparator 801 is activated. If 
the disable.sub.-- match.sub.-- break bit is off, a break is generated to 
the IU 110. If the disable.sub.-- match.sub.-- break bit is on, no break 
is generated; however, a signal is sent through EMU.sub.-- SD&lt;3&gt; to inform 
the diagnostic instrument 145 that a match is encountered. Other 
breakpoint conditions, such as data addresses, data values can similarly 
be checked. 
It is recalled that the EMU.sub.-- BUS 140 is used for communicating 
instructions, data and addresses between the CPU 100 and the diagnostic 
instrument 145. According the preferred embodiment of this invention, such 
communication is achieved by the special protocol as described 
hereinbelow. 
Information are communicated between the DSU 130 and the diagnostic 
instrument 145 in frames of eight bits each. These eight bits are 
communicated through EMU.sub.-- D&lt;3:0&gt; and EMU.sub.-- SD&lt;3:0&gt;. EMU.sub.-- 
D&lt;3:0&gt; of the first frame of each communication is a header which 
indicates the intent of the communication. Definitions of the various 
values of the header are listed in Table 8. For example, if DSU 130 wants 
to fetch an instruction from the diagnostic instrument 145, a header of 
"0100" is placed on the EMU.sub.-- SD in the first frame. 
EMU.sub.-- D of the first frame contains the type of data (e.g. byte, 
half-word) involved. The codes for the different types of data re listed 
in Table 10. 
The second to the fifth frames are used by the DSU 130 to send the 
addresses of the instruction being fetched. 
Responsive to the request, the diagnostic instrument 145 fetches the 
instruction from the addressed location. The instruction is then 
communicated to the DSU 130 between the sixth frame and the ninth frame. 
After the instruction is sent, the EMU.sub.-- BUS is set to a high 
impedance for one frame to signify completion of the communication. 
When DSU 130 needs to read data (or an instruction) from the diagnostic 
instrument 145, a header of "1110" (or 0110) is sent through EMU.sub.-- SD 
in the first frame along with a code in EMU.sub.-- D representing the type 
of data involved. The address of the requested data is placed between 
frames 2 to 5. 
Responsive to the request, the diagnostic instrument 145 fetches the data 
from the sent address and places it between frames 6 to 9. At the end of 
the communication, EMU.sub.-- BUS is also set to a high impedance state 
for one frame to signify completion of the operation. 
When DSU 130 needs to write data (or an instruction) to the diagnostic 
instrument 145, a header of 1010 (or 0010) is sent through EMU.sub.-- SD 
in the first frame, along with a code in EMU.sub.-- D representing the 
type of data being read. The address of the requested data is placed 
between frames 2 to 5. The data is sent to the diagnostic instrument 145 
in frames 6 to 9. At the end of a write operation, the EMU.sub.-- BUS is 
not set to a high impedance state as required in the other operation. 
If the above operations involve more than one operand, a NEXT operation is 
performed. Such operation is performed in the similar manner except that 
no address is sent. 
A summary of the different communication protocols is given in Table 11. 
By way of example, assuming that the DSU 130 is to write a byte of 
0.times.fe to address 0.times.65432102 of the diagnostic instrument 145. 
The values of the nine frames in the write operation is shown in Table 9. 
FIG. 9 is a schematic diagram illustrating the interface within the DSU 130 
for communicating with diagnostic instrument 145. The interface comprises 
an multiplexor 901 which is connected to the internal busses 155. An 
address/data select signal is generated by a DSU control logic to control 
the multiplexor 901 in selecting whether address or data is output. 
The output of the multiplexor 901 is divided into 4 8-bit segments each of 
which is input into another multiplexor 902. The header, which is 
generated by the DSU control logic is also connected to an input of 
multiplexor 902. Multiplexor 902 is controlled by a signal generated by 
the DSU control logic. As previously described, the DSU control logic 
first outputs the header from the multiplexor 902 to a transceiver 904. At 
the same time, the DSU control logic also sends a signal to the 
transceiver 904 to cause it to transmit the header to EMU.sub.-- BUS. 
Subsequently, the four segments of address/data are output sequentially. 
When the header and address/data fields are output, if the communication is 
for fetching instructions or data, the DSU control logic reverses the 
direction of the transceiver 904 to receive data/instruction from the 
diagnostic instrument 145. As segments of instruction/data are received 
from the diagnostic instrument 145, they are received and assembled in the 
de-multiplexor 903 under the control of the DSU control logic. After they 
are assembled, the data/instruction is output to the IU 110 through the 
internal bus 155. 
At the end of the communication, a control signal is sent from the DSU 
control to the transceiver to cause it change to high impedance state. 
FIG. 11 is a schematic block diagram illustrating the general structure of 
the DSU 130. Each of the above functions, breakpoint, trace and 
communication is performed by a logic block 1103, 1102 and 1101. Each 
logic block has a controller implemented by a state machine. The DSU 
control register is connected to the three logic block as 1103, 1102 and 
1101 to provide the appropriate control signal. The logic blocks generates 
output as described and output to the ZMU.sub.-- B/IU. 
The above describes a debug support interface in a single chip CPU that 
utilizes a second bus for communicating to a diagnostic instrument. With 
the availability of a second bus, debug support in the CPU is improve. 
However, while a second bus is provided, the pins created thereby are kept 
to a minimum. 
A description of the particular embodiment is given above for the 
understanding of the present invention. It will be understood by those 
skilled in the art that various modifications and additions can be made 
without substantially departing from the scope of this invention, which is 
defined by the following claims. 
TABLE 1 
______________________________________ 
ASI Address Space Assignment 
______________________________________ 
ASI&lt;7:0&gt; Address Space 
0x1 Control Register 
0x2 Instruction Cache Lock 
0x3 Data Cache Lock 
0x4-0x7 Application Definable 
0x8 User Instruction Space 
0X9 Supervisor Instruction Space 
0xA User Data Space 
0xB Supervisor Data Space 
0xC Instruction Cache Tag RAM 
0xD Instruction Cache Data RAM 
0xE Data Cache Tag RAM 
0xF Data Cache Data RAM 
0x10-0xFE Application Definable 
0xFF Reserved for Debug Hardware 
______________________________________ 
TABLE 2 
______________________________________ 
Pin Assignments of Debug Support Bus EMU.sub.-- BUS 
______________________________________ 
EMU.sub.-- D&lt;3:0&gt; 
Four bits for communicating 
201 data/instructions between the CPU 100 
and a diagnostic instrument 145 
during a debug or a trace operation. 
EMU.sub.-- SD&lt;3:0&gt; 
Four bits for communicating either 
202 data or status between the CPU 100 
and the diagnostic instrument 145. 
EMU.sub.-- ENB 203 
A bit for informing the diagnostic 
instrument 145 how EMU.sub.-- D and EMU.sub.-- SD 
are being used. An active EMU.sub.-- ENB 
203 signal indicates that the EMU.sub.-- D 
and EMU.sub.-- SD are being used as a port 
for inputting/outputting diagnostic 
instructions, data and addresses. An 
inactive EMU.sub.-- ENB 203 signal means 
that EMU.sub.-- D and EMU.sub.-- SD are being used 
for a performing a trace operation. 
EMU.sub.-- BRK 204 
A bit for use by the diagnostic 
instrument 145 for controlling the 
DSU 130. When EMU.sub.-- ENB 203 is active, 
EMU.sub.-- BRK 204 causes a break operation 
in the CPU 100. When EMU.sub.-- ENB 203 is 
inactive, EMU.sub.-- BRK 204 represents a 
request for requesting the CPU 100 to 
wait. 
______________________________________ 
TABLE 3 
______________________________________ 
DSU Control Register 
______________________________________ 
Bits&lt;31-24&gt;: 
ASI value for Data Address 2: Specifies 
the ASI match value for Data Address 2. 
Bits&lt;23-16&gt;: 
ASI value for Data Address 1: Specifies 
the ASI match value for Data Address 1. 
Bit&lt;15&gt;: Data Address 2 User/Supervisor Bit: 
Specifies either a User or Supervisor Mode 
Match for data address 2. 
Bit&lt;14&gt;: Data address User/Supervisor Bit: 
Specifies either a User or Supervisor Mode 
match for data address 1. 
Bit&lt;13&gt;: Reserved 
Bit&lt;12&gt;: Disable.sub.-- Match.sub.-- Break 
Bit&lt;11&gt;: Trace.sub.-- Not.sub.-- Hold.sub.-- IU 
Bit&lt;10&gt;: Trap.sub.-- Disable.sub.-- Break.sub.-- Point 
Bit&lt;9&gt;: Reserved. 
Bit&lt;8&gt;: Enable Data Address 2 Break: Enables "(1)" 
or disables "(0)" the breakpoint 
comparison for Data Address Descriptor 2. 
Bit&lt;7&gt;: Enable Data Address 1 Break: Enables "(1)" 
or disables "(0)" the breakpoint 
comparison for Data Address Descriptor 1. 
Bit&lt;6&gt;: Enable Instruction Address 2 Break: 
Enables "(1)" or disables "(0)" the 
breakpoint comparison for Instruction 
Address Descriptor 2. 
Bit&lt;5&gt;: Enable Instruction Address 1 Break: 
Enables "(1)" or disables "(0)" the 
breakpoint comparison for Instruction 
Address Descriptor 1. 
Bit&lt;4&gt;: Single Step: Enables single-step operation 
when set. During single-step operation, a 
breakpoint trap is issued on every 
instruction. 
Bits&lt;3-2&gt;: 
Data Value Transaction Type: Determines 
the class of instructions (loads, stores, 
or both) that can cause a Data Value 
breakpoint trap. 
00 - Break only on loads; 
01 - Break only on stores; 
10 - Break on load or store; 
11 - Break always. 
Bit&lt;1&gt;: Data.sub.-- Value.sub.-- Condition: Determines whether a 
data value inside the range specified by 
the data value descriptor registers, or 
outside this range (assuming that the 
data value mask bit is "0". 
Bit&lt;0&gt;: Data.sub.-- value.sub.-- Mask: Controls the 
interpretation of the data value 
descriptor registers. When the 
data.sub.-- value.sub.-- mask bit is "1", data value 
descriptor 2 is used as a mask for data 
value descriptor 1. When the 
data.sub.-- value.sub.-- mask bit is "0", the data value 
descriptor registers specify the upper and 
lower bounds of an address range. 
______________________________________ 
TABLE 4 
______________________________________ 
DSU Status Register 
______________________________________ 
Bits&lt;31-8&gt;: 
Reserved 
Bit&lt;7&gt;: DSU.sub.-- Reg.sub.-- Exception. 
Bit&lt;5&gt;: Data Address 2 Match: set to "1" if 
address matched. Software should clear 
this bit after reading it. 
Bit&lt;4&gt;: Data Address 1 Match: set to "1" if 
address matched. Software should clear 
this bit after reading it. 
Bit&lt;3&gt;: Instruction Address 2 Match: set to "1" if 
address matched. Software should clear 
this bit after reading it. 
Bit&lt;2&gt;: Instruction Address 1 Match: set to "1" if 
address matched. Software should clear 
this bit after reading it. 
Bit&lt;1&gt;: 
EMU.sub.-- ENB asserted on reset: set on reset 
if the -EMU.sub.-- ENB 203 input is asserted; 
cleared on reset otherwise. This bit 
maintains its value until the next reset. 
EMU.sub.-- ENB and EMU.sub.-- BRK are used to con- 
figure the DSU on reset. This bit is read only. 
Bit&lt;0&gt;: EMU.sub.-- BRK asserted on reset: set on reset 
when the EMU.sub.-- BRK 204 input is asserted; 
cleared on reset otherwise. This bit 
maintains its value until the next reset. 
EMU.sub.-- ENB and EMU.sub.-- BRK are used to con- 
figure the DSU on reset. This bit is read only. 
______________________________________ 
TABLE 5 
______________________________________ 
Memory Locations of DSU Registers 
______________________________________ 
0x0000FF00 
Instruption Address Descriptor Register 1 
0x0000FF04 
Instruction Address Descriptor Register 2 
0x0000FF08 
Data Address Descriptor Register 1 
0x0000FF0C 
Data Address Descriptor Register 2 
0x0000FF10 
Data Value Descriptor Register 1 
0x0000FF14 
Data Value Descriptor Register 2/Mask Register 
0x0000FF18 
Debug Control Register 
0x0000FF1C 
Debug Status Register 
______________________________________ 
TABLE 6 
______________________________________ 
Interface Signals Between IU 110 and DSU 130 
______________________________________ 
ISUPER A signal from IU 110 to DSU 130, to inform 
DSU 130 that IU 110 is in supervisor mode. 
IFETCH A signal from IU 110 to DSU 130, to inform 
DSU 130 that an instruction is fetched. 
I-PLUS-4 A signal from IU 110 to DSU 130, to inform 
the DSU 130 that IU 110 is processing a 
next sequential instruction (i.e. not 
branch has been taken). 
TRAP ACK A signal from IU 110 to DSU 130, to inform 
DSU 130 that IU 110 has taken a trap. 
HELD A signal from IU 110 to DSU 130, to inform 
DSU 130 that processing of instructions is 
held. 
IA TRACE HOLD 
A signal from DSU 130 to IU 110 during a 
trace operation, to request the IU 110 to 
hold processing until DSU 130 can catch 
up outputting the trace data. 
______________________________________ 
TABLE 7 
______________________________________ 
Trace Status 
EMU.sub.-- SD&lt;2:0&gt; 
______________________________________ 
000 no instruction fetch and no MSN (IA&lt;31:38&gt;) on 
EMU.sub.-- D&lt;3:0&gt;. 
001 IU was held and no MSN (IA&lt;31:28&gt;) on 
EMU.sub.-- D&lt;3:0&gt;. 
010 sequential fetch and no MSN (IA &lt;31:28&gt;) on 
EMU.sub.-- D&lt;3:0&gt;. 
011 sequential fetch and MSN (IA&lt;31:28&gt;) on 
EMU.sub.-- D&lt;3:0&gt;. 
100 trap non-sequential and no MSN (IA&lt;31:28&gt;) on 
EMU.sub.-- D&lt;3:0&gt;. 
101 trap non-sequential and MSN (IA&lt;31:28&gt;) on 
EMU.sub.-- D&lt;3:0&gt;. 
110 indicates branch/jump non-sequential and no MSN 
(IA&lt;31:28&gt;) on EMU.sub.-- D&lt;3:0&gt;. 
111 indicates branch/jump non-sequential and MSN 
(IA&lt;31:28&gt;) on EMU.sub.-- D&lt;3:0&gt;. 
______________________________________ 
TABLE 8 
______________________________________ 
Communication Protocol Between DSU and DIAGNOSTIC 
INSTRUMENT 
Header: 
______________________________________ 
NOP EMU.sub.-- SD&lt;3:0&gt; = 0000 
INST EMU.sub.-- SD&lt;3:0&gt; = 0100 
NEXT EMU.sub.-- SD&lt;3:0&gt; = 0101 
READ(SI) EMU.sub.-- SD&lt;3:0&gt; = 0110 
WRITE(SI) EMU.sub.-- SD&lt;3:0&gt; = 0010 
READ(SD) EMU.sub.-- SD&lt;3:0&gt; = 1100 
WRITE(SI) EMU.sub.-- SD&lt;3:0&gt; = 1010 
______________________________________ 
TABLE 9 
__________________________________________________________________________ 
An Example of A Communication Between DSU and 
Diagnostic Instrument 
Frame 1 2 3 4 5 6 7 8 9 
__________________________________________________________________________ 
EMU.sub.-- SD&lt;3:0&gt; 
b"1010" 
0x0 
0x2 0x4 
0x6 
x 0xf x x 
EMU)D&lt;3:0&gt; 
b"0100" 
0x2 
0x1 0x3 
0x5 
x 0xe x x 
__________________________________________________________________________ 
TABLE 10 
______________________________________ 
Data Type in the HEADER 
______________________________________ 
No-Data: 
EMU.sub.-- D [3:0] = 0000 //NOP 
Byte-0: EMU.sub.-- D [3:0] = 0001 //BYTE-READ/WRITE & 
DA [1:0] = 00 (EMU.sub.-- D[0] = 1) 
Byte-1: EMU.sub.-- D [3:0] = 0010 //BYTE-READ/WRITE & 
DA [1:0] = 01 (EMU.sub.-- D[1] = 1) 
Byte-2: EMU.sub.-- D [3:0] = 0100 //BYTE-READ/WRITE & 
DA [1:0] = 10 (EMU.sub.-- D[2] = 1) 
Byte-3: EMU.sub.-- D [3:0] = 1000 //BYTE-READ/WRITE & 
DA [1:0] = 11 (EMU.sub.-- D[3] = 1) 
Upper- EMU.sub.-- D [3:0] = 0011 //HALFWORD- 
Halfword: 
READ/WRITE & DA [1:0] = 00 
Lower- EMU.sub.-- D [3:0] = 1100 //HALFWORD- 
Halfword: 
READ/WRITE & DA [1:0] = 10 
Word: EMU.sub.-- D [3:0] = 1111 //INST, NEXT 
WORD-READ/WRITE 
______________________________________ 
TABLE 11 
__________________________________________________________________________ 
Summary of the Protocol 
__________________________________________________________________________ 
NOP [1 Byte frame] .vertline.HEADER.vertline. 
NEXT [5 Byte frame] .vertline.HEADER.vertline.D3/i.vertline.D2/i.vertline. 
D1/i.vertline.D0/i.vertline.Hi-Z.vertline. 
WRITE 
[8 Byte frame] 
.vertline.HEADER.vertline.A3/o.vertline.A2/o.vertline.A1/o.vertline.A 
0/o.vertline.D3/o.vertline.D2/o.vertline.D1/o.vertline.D0o.vertline. 
1 
READ [9 Byte frame] 
.vertline.HEADER.vertline.A3/o.vertline.A2/o.vertline.A1/o.vertline.A 
0/o.vertline.D3/i.vertline.D2/i.vertline.D1/i.vertline.D0i.vertline.H 
i-Z.vertline. 
INST [9 Byte frame] 
.vertline.HEADER.vertline.A3/o.vertline.A2/o.vertline.A1/o.vertline.A 
0/o.vertline.D3/i.vertline.D2/i.vertline.D1/i.vertline.D0i.vertline.H 
i-Z.vertline. 
__________________________________________________________________________