Background OF THE invention
Micro process have found way into a huge variety of products. Often the processor and it programming is completely ''embedded" into the design of the device, hence the term "embedded processors" to describe such processors. Several examples of devices having embedded processors are cellular telephones, computer printers, high performance disk drives for computer data, and automobile control systems.
'Development tools that: are useful for general purpose (non-embedded) proces£3ors are not satisfactory for embedded processor development. In other words, the test procedures for production of the processor itself may not be satisfactory for testing the processor in its embedded environment. It is more difficult to have visibility into processor operation. To solve this problem, one technique that is being increasingly used is referred to as "emulation".
In general, an emulator, whether software or hardware, permits direct control by a designer over a target processor. Because it is the application in which the processor will be used, and not the processor itself, that is being designed, the articulator must emulate those conditions.
Ir.-circuit emulation, commonly referred to as ICE, uses emulators that are typically a combination of hardware and software. The emulator is typically
connected between this embedded processor- and a host CPU
that is running debugging software. The emulation is

"in-circuit" in the sense :hat the processor may be connected to the emulator while it is embedded into the system in which it is to be embedded.
Real-time in-circuit emulation permits a software designer to monitor, analyze, and modify code without impacting operation of the device in which the processor is embedded. The behavior of the emulator is identical to that of the target. For example, in the case of an embedded processor for a disk drive, the emulator might permit the designer to modify the code while the disk drive continues to run normally.

SUMMARY OF THE INVENTION
One aspect of the invention is a method of initializing a processor to run emulation code provided • by a debugger. The CPU is provided with emulation logic for controlling an initialization sequence, said emulation logic being in communication with both the CPU and the debugger. The emulation logic is placed in a reset mode, such that no requests from said CPU or from said debugger are serviced. Next, the emulation logic is requested to enter a, start-up mode, in which only requests from the debugger are serviced. The emulation logic is then released from the reset mode, such that it immediately enters the start-up mode. During this start-up mode, the CPU is placed in a described initialization state. Finally, the emulation logic is released from the start-up mode, such that the emulation code may now be executed.
An advantage of the invention is that it accomplishes emulation initialization without the need for scanning in a start-up state. The result is a faster and less complicated initialization than a scan type initialization. The method may be used when no system clocks are available.

BRIEF DESiCRIPTTION OF THE DRAWINGS
FIGURE 1 is a block diagram of an emulation system having emulation logic in accordance with the invention, and a CPU under development using the emulation system.
FIGURE 2 illustrates the finite state machine of FIGURE 1.
FIGURE 3 illustrates the initialization method of the invention.

DETAILED DESCRTPTTOM OF THE THE INVENTIQN
Overview of Emulation system
FIGURE 1 is a block diagram of an emulation system ID for ar. embedded CPU 14. Emulation system 10 is comprised of debug software executable on a host computer (debugger 11) , a scan controller 12, and emulation logic (emulator 13).
Emulation system 10 in an in-circuit emulation system, that is, it is used for developing a particular application in which CPU 14 ia to be used. For example, an applications developer might be designing an application such as a new cellular phone whcse functions will be controlled by the processor 14. The programming under development is referred to herein as the "target" application code. Although not shown in FIGURE 1, CPU 14 may have various connections to other parts of the application system in which it is to be embedded.
Execution of the programming being tessted is under the control of debugger 11. More specifically, debugger 11 receives the output frotr. an emulation pirocess and transfers this output to err.ulator 13 . It is through the user interface of debugger 11 that the developer interacts with emulator 13 to control and monitor the operation of CPU 14 as it executes the target application code.
Many variety of debugger software exist, but in general the debugger 11 provides at least an interface for the designer to input commands. Typically, the

debugger 11 also provides displays of program execution, including values of variables, arrays, structures, pointers, and registers. Memory contents Can typically be displayed and edited. Using a debugger 11, the contents of a register or other memory can be changed and the program restarted with new data. The debugger 11 may permit instructions to be executed one at a time or to be stopped at a specified instruction.
The commands issued by the debugger ll are transTated into serial bit patterns by scan controller 12.r Scan controlleir 12 then provides these bit patterns to emulator 13 through a interface I3a associated with emulator 13. Results of commands and other messages from CPU 14 are sent back to debugger 11 chrough the same JTAG interface 13a and through scan controller 12. Scan controller 12 may be any one of a number of commercially available devices that convert computer-format ted data to a serial bit stream and vice versa.
JTAG interface 13a may also be referred to an IEEE 1L49.1 interface, which identifies the IEEE standard with which it substantially complies. As is standard, JTAG interface 13a has at least five pins: test data input (TDI), test data output (TDO), test mode select (IMS), test clock (TCK), and test reset (TRST).
Emulator 13 provides various emulation functions. In the example of this description, it provides two modes of operation. In its real-time mode, if a break event occurs, the main body of the program code halts execution

but time-critical interrupts can still be serviced, in its "stop" mode, all interrupts are disabled.
Emulator 13 is a DMA (direct memory access) emulator. In other words, it uses DMA accecsses directly to the registers and other memory of CPU 14. This permits the debugger on host 11 to gain direct access to the contents of the memory. To this end, the emulator 13 takes control of the memory interface during unused cycles of the instruction pipeline. Thus, the CPU's memory may be monitored without requiring processor rejsources. It is an alternative to a "scan-based" envulator, which use an extension of the JTAG boundary scan standard to scan storaige elements in the CPU.
In the example of this description, the DMA logic associated with emulator 12 detects unused bus cycles to gain access to memory. The emulator 13 can thus read and write to memory of CPU 14 and monitor CPU :.4 without affecting the operation of the target application code.
The DMA function of emulator 13, as well as its other functions, may be implemented with logic circuitry. One or more state machines may be used to implement the various functions of emulator 13. As explained below in connection with FIGURE 2, emulator 13 has a finite state machine (FSM) 13b, which handles initialization of emulation code.
CPU 14 has conventional processing elements. It has a memory interface for transferring data and control signals between CPU 14 and associated memory. It has connections for other signals, such as for clock and

control signals, and reset and interrupt signals, as well as for signals to and from emulator 13.
As indicated in FIGURE l, emulator 13 eind CPU 14 may be integrated on the same integrated circuit device. An example of such a deivice is ones made from the T320C2700, a digital processor core available from Texas Instruments Incorporated. However, tho same concepts can be extended to CPU's whose emulation logic is not integrated on-chip, in which case, emulator 13 could be implemented with additional software or with off-chip hardware. Typically, however, for initialization in accordance with the invention, the required processing speeds call for a least an on-chip finite state machine 13b.
Finite State Machine
FIGURE 2 illustrates state machine 13b, which services the bi-directional flow of control messages and data between debugger 11 and CPU 14. State machine I3b may also handle addition functions, such as providing an interface between scan controller 12 and CPU 14 for e:-nulation code, also referred to as "monitor" code, defined as specially privileged code running on CPU 14 that performs debug functions.
As illustrated, state machine 13b has three modes: a reset mode, normal mode, and hermit (start-up) mode. In reset mode, no requests are serviced. In normal mode, debugger and CPU requests are serviced, with priority to debugger requests. In start-up mode, only debugger

requests are serviced; all access by CPU 14 to internal control paths is disabled..
FSM 13b may be implemented with known progrs.mmable logic circuitry. For example, an ASIC standard cell array or a PLD (programmable logic device) may be used. Like all state machines, FSM 13b directs a set of operations (described below?) so that they occur in desired sequences, synchronized by a clock signal.
CPU IirLtialization with Emulation Logic
FIGURE 3 illustrates a method of inicializing CPU 14 to run emulation code in accordance with the invention. As explained below, this method provides an initial emulation logic state regardless of the CPU state.
The various requests for service described below may be accomplished with JTAG sequences via debugger 11. Each sequence is; scanned in, usi.ng the JTAC, TDI and 'VMS signals, by means of scan controller 12.
. Step 31 is a power on step, which may result in CPU 14 coming up in a random state. This random state could prevent a "clean" initialization for the enulation logic. For example, clocks could be unknown and FSM 13b could be locked up.
In Step 32, clock select circuitry is switched to run emulator 13 and CPU 14 off the JTAG test clock (TCK). This ensures that all logic is clocked. Step 32 can be omitted if emulator and CPU clocks are running.

In step 33, FSM 13b is put: in reset mode. As explained above in connection v/ith FIGURE 2,-all requests for service are ignored.
In step 34, debugger 11 requests the start-up mode for FSM 13b. Thus, a debugger request is now active, although FSM 13b is still in reset mode. This request is not immediately serviced, but is held. For example, it may be held in a register associated with FSM 13b.
In Step 35, FSM 13b is released from the reset mode, again using a JTAG sequence. FSM 13b is now in normal mode, which requires FSM 13b to give priority to debugger requests. Thus, FSM 13b now services the request to enter che start-up mode. That is, in the first cycle after release from reset, FSM 13b reads the higher priority request to enter the start-up mode. Thus, regardless of the state of CPU 14, the start-up mode of FSM 13b is entered.
As a result of Step 35, the start-up mode is now on, such that FSM 13b ignores requests from CPU 14 and is free from CPU interference. Thus, CPU 14 may now be set to a known state.
Thus, in Step 37, the known CPU state is applied. In the example of this description, a reset state has previously been loaded to a register, but in general, the ri=;lease accomplished by Step 3 9 permits any known state (whether previously requested or now requested) to be applied. Also, in the example of this description, there are various debug units between emulator 13 and CPU 14,

which are initialized at this time by being held in reset.
In Step 38, the start-up mode is exiced, such that FSM 13b in again in normal mode. CPU 14 has undergone a clean initialization and the emulation code may begin to execute.
Although the above description is in terms of eaiulation initialization, the same method can be used for error-recovery during emulation, such as when CPU 14 makes unwanted accesses to emulator resources. The two-way emulation link can be broken and CPU 14 prevented from accessing CPU logic.
other Embodiment
Although the present invention has been described in d(2.t:ail, it should be understood that various changes, substitutions, and alterations can be made hereto without departing from the spirit and scope of the invention as defined by the appended claims.

1. A method of initializing a processor to run
emulation code provided by a debugger, comprising the
steps of:
providing emulation logic for controlling an initialization sequence, said emulation logic being in communication with said CPU and said debugger;
placing said emulation logic in a reset mode, such that no requests! from said CPU or from said debugger are serviced;
I requesting said emulation logic to enter a start-up mode, in which only requests from said debugger are serviced
releasing said emulation logic from said reset mode, such that said emulation logic enters said start-up mode;
placing said CPU in a desired initialization state; and
releasing said emulation logic from said start-up mode, such that said emulation code may be executed.
2. The method of Claim 1, wherein said emulation logic is implemented as a finite state machine.
3. The method of Claim 1, wherein said requesting and releasing steps are performed via a JTAG sequence input to said emulation logic.
4. The method of Claim 1, wherein said desired initialization state is a continuous reset state.

5. The method of Claim 1, wherein said placing step is the result of requesting and applying steps separated in time by said releasing step.
6. The method of Cla;i.m 1, wherein said requesting step is performed by a request to enter said start-up mode in a register accessed by said state ma.chine .
7. The method of Claim 1, wherein said releasing step is accomplished such that said emulation logic immediately enters a normal mode in which requests from Said debugger are given priority and such that said emulation logic enters said start-up mode.
8. The method of Claim 1, further comprising the step of setting said emulation logic and said CPU on a common clock.
9. The method of Claim 8, wherein said common clock ia a JTAG clock.
10. The method of Claim 1, wherein said stejp of
releasing said emulation logic from said start-up, mode,
results in said emulation logic entering a normal mode in
which requests from both said CPU and said debugger are
serviced.

1l. An on-chip emulation logic circuit for an embedded CPU and for initializing said CPU for emulation code provided by a debugger, comprising:
JTAG interface for bi-directional communications between said CPU and said debugger;
a finite state machine for initializing said CPU to run emulation code, said finite state machine operable to enter any one of the followingthree modes: a reset mode in which no requests from said debugger or said CPU are serviced, a normal mode in which requests from said debugger are given priority, and a start-up mode in which only requests from said debugger are serviced;
means for holding a request for said start-up mode while said finite state machine is in said reset mode; and
emulation logic for performing one or more emulation functions during execution of said emulation code.
12. The emulation logic circuit of Claim 11, wherein said means for holding is a register.
13. A processor device for use with a debugger, ccmprising:
a central processing unit; and
emulation logic integrated onto said device, said emulation logic comprising at least a finite state machine for initializing said central processing unit to run emulation code, said finite state machine operable to enter any one of the following three states: a reset

state in which no requests from said debugger or said CPU are serviced, a normal state in which requests from said debugger are given priority, and a start-up state in which only requests from said debugger are serviced; and
a data interface for providing data to said device from said debugger.
14. The device of Claim 13, wherein said data interface is a serial data interface.
15. The device of Claim 13, wherein said data interface is a JTAG interfeice.

16. An on-chip emulation logic circuit substantially as herein
described with reference to the accompanying drawings.
17. A processor device for use with a debugger substantially as
herein described with reference to the accompanying
drawings.