WO2006008721A2

WO2006008721A2 - Emulation and debug interfaces for testing an integrated circuit with an asynchronous microcontroller

Info

Publication number: WO2006008721A2
Application number: PCT/IB2005/052372
Authority: WO
Inventors: Fabrizio Campanale; Jens Muttersbach; Andrea Foni
Original assignee: Koninklijke Philips Electronics, N.V.; U.S. Philips Corporation
Priority date: 2004-07-16
Filing date: 2005-07-16
Publication date: 2006-01-26
Also published as: JP2008507025A; EP1782204A2; WO2006008721A3

Abstract

A target devi ce integrated circuit with an embedded asynchronous microcontroller is fitted with a standard JTAG-TAP interface. On board the IC a TAP port controller and emulation interface are able to intercept and substitute every instruction being fetched from a code memory. An external emulation PC has the ability to inspect on-board data and code memories by instruc Icing the embedded asynchronous microcontroller to read and write them to the JTAG-TAP interface. Single-stepping and breakpoint registers are provided for debugging and testing by the external emulation PC.

Description

EMULATION AND DEBUG INTERFACES FOR INTEGRATED CIRCUIT TESTING

The present invention relates to computer program emulation and debugging, and more particularly to circuits and methods for digitally interfacing with embedded asynchronous microcontrollers with standard Joint Test Action Group (JTAG) test access ports (TAP).

Computer circuit designs which embed the processor in some device pose difficult test, emulation, and debug problems. Such embedded systems typically have no facility for interfacing with a programmer, assembler, or writeable program memory. So the test and development engineers ordinarily have no direct access into the target system as designed. In-circuit emulation (ICE) was introduced to solve this dilemma. A host program development system is fitted with a special processor at the end of an umbilical cable. A personal computer (PC) can be fitted with an adapter pod for this purpose. Such cable then plugs into the processor socket of the target embedded system. The input/output (I/O), memory, assembler, compiler, and graphical user interfaces of the ICE development system are all then available to the engineer so that the programs can be tested in the actual target hardware. All the I/O, program memory, data memory, CPU registers, and peripherals in the target system are accessible to and modifiable by the host development system.

An important resource of the ICE is therefore the target access, specifically the ability to examine and change the contents of registers and memory. Breakpoints allow program execution to be stopped when certain events occur, and are another important debugging resource. Being able to stop program executions at defined locations and conditions allows a full analysis of how the program got where it did and how it affected the target system. Emulators can also use breakpoints to implement single stepping that allows the engineer to execute the target program one instruction at a time. ICE development systems and their supporting equipment and software are expensive. They are also highly specialized to the particular processors being used in each target embedded system, and adapters and special software must be purchased for each type. In addition, dedicated on-chip logic is needed for interfacing to the external emulator. Usually it is an IP either provided by the emulator company or by the supplier of the embedded microprocessor. Such extra costs add to the IC development expense budget.

Emulators can be used to take control and test computer circuit boards their processor, memory, or bus interfaces. Once in control, the emulator loads and runs diagnostic tests to debug the target hardware and software. Test access on densely packed boards is no problem for a processor emulator, although the real processor must be socketed to allow its replacement. Emulators were used extensively in board development, but increasing processor speeds now have made them impractical.

Jfϊ||t||2|;i_: :,;;i;.-_' O

ROM-memory emulators plug into the sockets to replace the boot ROM, and insert diagnostic program code for the processor's normal boot code. Such socket interfaces are bi-directional so that the unit-under-test (UUT) can communicate with the tester. But ROM emulators are not able to diagnose the processor to boot ROM area. Product design circuit modifications need to be made if the ROM's are soldered- in.

Bus emulators can be connected to a bus slot or edge connector, giving test access to the various circuits and functions of the UUT via read/write bus cycles. They are useful for testing plug-in bus cards such as VME and PCI.

The Joint Test Action Group (JTAG) interface was originally designed to overcome test-access problems on miniaturized components. A serial interface defined is known as the test access port (TAP). It uses five data and timing pins to access daisy-chained shift registers built into each component's I/O pins. Such allows a chain of JTAG-compliant components to be "boundary scanned" for errors. The JTAG protocol has been expanded by microprocessor and digital signal processor (DSP) manufacturers to provide on-board debug facilities for hardware and software developers. Such helps overcome the typical 30-MHz speed barrier encountered by external emulators. Vendor-specific extensions to JTAG typically have 2-3 additional signal lines and an enhanced instruction set for controlling the processor core. Commercially available debug interface-enabled CPU's include Intel® Pentium® processors, Intel XScale™ Microarchitecture Processors, Motorola™, IBM® PowerPC™, AMD®, MIPS®, and ARM® processor families. The IEEE also has published IEEE ISTO- 5001 for debug interfaces. The debug interfaces have been given various trademark names, e.g., Motorola's background debug mode (BDM), AMD's hardware debug tool(HDT), and Motorola/IBM's common on-chip processor (COP). The BDM interface is similar to JTAG, but the signal lines and protocol differ.

Such interfaces were originally developed for design engineers, but functional test solutions can also be implemented. Test and diagnostic equipment designed to use a processor's debug interface requires only about six to 10 test points on the UUT. Such access can be achieved in most board designs, either by placing an interposer between CPU 116 and the socket, using a very simple bed of nails when CPUs are soldered, or making use of the JTAG break-out header provided by some board manufacturers. Any bus-architecture UUT can be divided into functional blocks such as bridges,

RAM, video controllers and I/O controllers. Each functional block contains arrays of memory or I/O registers. Test programs use the extended JTAG debug functions provided by processor manufacturers to sequentially access these registers, building up a complete test. Low-level functions include stop/start the processor, read/write memory, read/write general-purpose registers, read/write I/O, breakpoints, single-step code, and code trace. Combinations of these functions accommodate downloading test code to a UUT, controlling and monitoring test code execution, and collecting test results from UUT memory. For example, the read/write functions can test RAM, which also verifies intermediate buses. I/O controllers are tested either by looping the output back into the input, as in the case of network interface controllers, or generating/measuring signals with external devices attached to the board's connectors. Some test systems include I/O emulation units, which avoid the need to attach real peripheral devices. More expense and complexity is encountered if the target device CPU is not a synchronous type. Specialized interfaces are needed to deal with asynchronously clocked embedded processors.

All such costs can conspire to make the target system production costs too expensive. The manufacturing costs can climb so high that there is little possibility that the product would succeed at the price points needed to make a reasonable profit.

What is needed are dedicated embedded architectures for debugging of asynchronous embedded processors that can reduce the costs of emulation and testing without resorting to external vendor IP's or hardware. Briefly, a target device integrated circuit embodiment of the present invention comprises an embedded asynchronous microcontroller and is fitted with a standard JTAG- TAP interface. On board the IC, a JTAG-TAP port controller and emulation interface are able to intercept and substitute every instruction being fetched from a code memory. An external emulation PC has the ability to inspect on-board data and code memories by instructing the embedded asynchronous microcontroller to read and write them to the

JTAG-TAP interface. Single-stepping and breakpoint registers are provided for debugging and testing by the external emulation PC.

An advantage of the present invention is a circuit is provided with built-in emulation and debug capability. A further advantage of the present invention is a method is provided for a target device to be tested in free running mode while watching for breakpoints the device performance is not hampered, or emulation code can be executed at less than full speed that interacts with a PC.

A still further advantage of the present invention is that a system is provided which has an inexpensive and industry standard JTAG serial interface.

The above and still further objects, features, and advantages of the present invention will be come apparent upon consideration of the following detailed description of specific embodiments thereof, especially when taken in conjunction with the accompanying drawings. Fig. 1 is a functional block diagram of an emulation system embodiment of the present invention; and

Fig. 2 is a flowchart diagram of an emulation interface mode method embodiment of the present invention, and is useful in the system of Fig. 1. Fig. 1 illustrates an emulation system embodiment of the present invention, and is referred to herein by the general reference numeral 100. The emulation system 100 comprises an ordinary personal computer (PC) 102 connected to a target device 104 through a standardized 5-pin JTAG interface 106. (I) A TCK/clock pin synchronizes the internal state machine operations. (2) A TMS/mode select pin is sampled at the rising edge of TCK to determine the next state. (3) A TDI/data-in pin is sampled at the rising edge of TCK and shifted into the target device 104's test or programming logic when the internal state machine is in the correct state. (4) A TDO/data-out pin represents the data shifted out of the target device 104's test or programming logic and is valid on the falling edge of TCK when the internal state machine is in the correct state. And, (5) A TRST/reset pin resets an internal state machine when driven low.

A software tool included and operating on the PC 102 is able to control the emulation behavior of the target device through the emulation hardware interface. The debugging software defines various functions to interface the emulator software environment so it can interact with the target device. For example: read/write RAM

(DATA, IDATA, XDATA); read/write special function register (SFR); read/write program code; initialize, re-initialize, reset/stop target hardware; read/write program counter; get/set registers; STOP, single STEP and RUN target execution; and, set/clear breakpoints.

The target device 104 is a single-chip integrated circuit (IC) and includes a JTAG test access port (TAP) controller 108 connected to an emulation interface 110. Program code from a code memory 112 can be substituted with debug code and register information from the emulation interface. Such debug code and other control information is downloaded from the PC 102 through he JTAG TAP 106 and TAP controller 108. A data memory 114 is connected through a private bus to an asynchronous microcontroller (CPU) 116. For example, CPU 116 can be an Intel type 80C51 microcomputer.

The emulation interface 110 includes a JTAG interface 118, a configuration (EMU_CFG) register 120, an emulation data register (EMU_DR) 122, a breakpoints (EMU_BP) register 124, an instruction register (EMU_IR) 126, a program counter (EMU_PC) register 128, and emulation (EMU) controller 130, and a bus multiplexer 132 to switch between emulation code or regular program code from the code memory 112. The EMU_IR 126 contains the 8-bit instruction to be executed by CPU 116 when in EMU External Mode. The EMU_PC register 128 stores a current 18-bit value of the code address when a STOP or a breakpoint occurs. It is used by the emulator to restore the system by forcing a jump to the program counter address. The EMU breakpoints register 124 stores two 18-bit instruction addresses the operator wants the microcontroller 116 to break execution and halt.

The EMU DR 122 provides for external inspection by PC 102 of 8-bit data in memories 112 and 114. In EMU External Mode, the asynchronous microcontroller 116 is commanded to move data from the memories and internal registers into the EMU_DR register 122. The EMU_DR 122 can be then read out though the JTAG interface 118.

Table I defines the nine bits used in the EMU_CFG register 120.

TABLE-I

An efficient hardware algorithm is included to control CPU 116 with external debugging software running on PC 102 through the JTAG-TAP standard interface 106. Such architecture realizes all the advantages of an emulation enhanced system, without degrading the performance of CPU 116. It represents a balance between the lowest costs in terms of area and design time. Such approach is well suited for asynchronous microprocessor applications that have separate instruction and data address spaces, e.g., Harvard architectures. It can also be applied to systems where the data and instruction share one address space, as in von Neumann architectures, when the target microprocessor is the memory system bus master. Fig. 2 represents an emulation- interface mode process, and is referred to herein by the general reference numeral 200. The emulation can be controlled by PC 102, the various bits in EMU_CFG register 120 are writeable and readable by PC 102 and are inspected and partially modified by process 200. Table I provides the program bit symbols used hereafter in describing process 200. The process 200 begins at a new program instruction request, e.g., by CPU 116 through instruction start signal and code address bus. A step 202 checks to see if the EMU ON flag (EMU CFG.l) is set, meaning the emulation mode is on. If it is, then a step 204 checks the DIR & Start_instr flag (EMU_CFG.5). If true, a step 206 copies the code address (code add) into the EMU_PC register 128, in effect an unconditional program jump for CPU 116. A step 208 saves the CPU's interrupt enable bit. A step 210 disables CPU interrupts and watch dog timer (WDT). A step 212 sets IR_V = "0". A step 214 loops until IR_V becomes true. A step 216 sends the instruction register EMU_IR to CPU 116 for execution and then loops back to step 202.

If step 202 resulted in EMU_ON being false, a step 218 allows a regular program instruction from code memory 112 top be routed through multiplexer 132 to CPU 116 for regular execution. In other words, a test for emulation mode is made every instruction cycle of CPU 116. The overhead connected with this can be very minimal in terms of propagation time, as the decision to do an emulation instruction can be implemented with hardware. If step 204 found that DIR & Start_instr flag was not true, a step 220 restores IEN.7 and disables the WDT. A step 222 looks to see if single-stepping (STEP) is required (EMU_CFG.3). If yes, a step 224 sends a next instruction to CPU 116. The direction is set false and step is set false, e.g., DIR=O (EMU_CFG.8) and STEP=O (EMU_CFG.3). Control returns to step 202. If step 222 was false, e.g., STEP=O, then a step 228 inspects the breakpoints for a match, e.g., first breakpoint BPl (EMU_CFG.6) and second breakpoint BP2 (EMU_CFG.7). If a breakpoint is matched, a step 230 sets the direction true (EMU_CFG.8), and breakpoint value is set true, e.g., DIR=I and BPV=I. Control returns to step 202.

If step 228 was false, e.g., no breakpoint, then a step 232 inspects for stop and start instructions (EMU_CFG.9). If yes, a step 236 sets the direction true, and the stop value is set true, e.g., DIR=I and STOPV=I. If no, one byte is send to CPU 116 in a step 234. Control returns to step 202.

Embodiments of the present invention recognize that when real time debugging is not required it is possible to reduce the number of IC pads dedicated to emulation, and those pads can use an inexpensive serial interface. The standard JTAG Test Access Port is already present in many modern IC devices for test purposes, and typically will not add any further costs to present designs in terms of silicon area, package, design. Software running on PC 102 can control registers in the emulation interface through the JTAG interface, the register bits are used by the hardware to control various interactions with CPU 116.

Initialization (INIT), re-initialization (RE-INIT), and target reset functions are called by the software tool on PC 102 when it is necessary to initialize or finalize the hardware target. Such routines include any initialization of the PC-to-JTAG interface, as well as the initialization of the configuration registers of the emulation interface 110. The EMU_reset command writes a "0" the EMU_CFG.NRST bit. Such forces a reset of the whole chip except the JTAG controller 108 and the emulation interface 110. Before re- writing the EMU_CFG.NRST bit to " 1 ", various other bits must be set in order to control CPU 116 after EMU reset. For example, EMU_CFG.EMU_ON=1 to enable the EMU_HW control of the code bus, and EMU_CFG.DIR=1 to set the code provenience from JTAG

RUN, STOP and STEP emulation controls are included. An EMU freeze mode is entered as soon the reset flag (NRST) is written again to "1" and the internal chip-reset sequence is completed, CPU 116 will try to start up again. But the emulation interface 110, finding the EMU ON and DIR bits equal to "1", will freeze CPU 116 at the instruction address 0x0000, just during the fetching phase, entering into the EMU freeze mode. In this phase, it is possible to reconfigure the registers of emulation interface 110, defining the breakpoints addresses, or the external instructions. It's also possible to modify the direction of the instructions after a current instruction has been executed. The DIR bit is read for each current operation by emulation interface 110, and is processed again only at the beginning of the next new instruction. An EMU external mode is entered when emulation software on PC 102 lets CPU 116 run and writes the EMU_CFG.IR_V bit to "1 ". Such will validate the content of instruction register 126 that is passed to CPU 116 to be executed (EMU Internal Mode).

At the beginning of each new instruction requested by CPU 116, emulation interface 110 will check the EMU-ON and DIR bits in EMU_CFG register 120. If the DIR bit is still at one, emulation interface 110 will automatically reset the DR_V bit to invalidate the instruction register and will enter in the EMU freeze mode.

With this handshake mechanism, the external emulator can synchronize its operations with the events within the target device 104. Polling the IR_V bit until it becomes "0", as in step 212, emulation PC 102 will know when CPU 116 is frozen. Setting the IR_V to "1 " will let CPU 116 have the current instruction via EMUJR register 126.

To prevent entering the interrupt state during the EMU External Mode, emulation interface 110 temporarily disables all the interrupts, and resets the global interrupt enable bit in an associated interrupt controller. Similarly any watch dog timer is inactivated while CPU 116 is in emulation mode.

The original value of the global interrupt enable bit is saved into the EMU CFG.IE bit and is restored into the interrupt controller every time EMU internal modes are entered.

For EMU internal modes, if at the beginning of a new instruction the DIR bit is "0", the target device 104 will enter into either an EMU internal step mode or an EMU internal standard mode, depending on the value of the EMU CFG.STEP bit.

In EMU internal step mode, only one complete instruction is provided to CPU 116 from the internal memory. The emulation interface 110 will then copy the code address bus value into the EMU-PC register, set the DI R bit to "1" for the next cycle, copy the global interrupt enable bit into EMU CFG.IE, and reset the STEP bit to 0 In the second case, EMU internal standard mode, the execution will run full speed from the internal memory until a STOP command is received. This is done by either writing "1" EMU CFG. STOP, or until a breakpoint is encountered. The emulation interface 110 then copies the code address bus value into the EMU-PC register, sets the DIR bit to "1" for the next cycle, copies the global interrupt enable bit into EMU_CFG, and sets the EMU V.STOP V (stop valid bit) to "1", or setthe EMU V.BP1 V / BP2 V (breakpoints valid bit) to "1".

The emulation software tool on PC 102 preferably has only indirect read/write access into all of the data/code memory space via CPU 116. A direct access of the emulation interface 110 to the code and data memories 112 and 114 is not desirable since CPU 116 is asynchronous, and multiplexed access of the memories would slow down process execution. It is possible while CPU 116 is in the emulation state to execute arbitrary code through the emulation interface. Access to any kind of embedded memories (RAM, flash and registers) uses CPU 116 to do the data shuttling, by running a routine to move the memory contents into the emulation hardware registers accessible from JTAG.

Although particular embodiments of the present invention have been described and illustrated, such is not intended to limit the invention. Modifications and changes will no doubt become apparent to those skilled in the art, and it is intended that the invention only be limited by the scope of the appended claims.

Claims

CLAIMS What is claimed is:

1. An emulation and debug system for integrated circuit testing, comprising: an external computer with a software emulation tool, a user interface, and a JTAG connector; a JTAG test access port (TAP) for connection with said JTAG connector and a JTAG TAP controller able to support communication with said software emulation tool and disposed in an integrated circuit target device; an asynchronous microcontroller having a private code memory and data memory and disposed in said integrated circuit target device; an emulation interface disposed in said integrated circuit target device and connected between said JTAG TAP controller and the asynchronous microcontroller; and a set of emulation registers disposed in the emulation interface and providing read/write access to said software emulation tool for data, program instructions, program counter, breakpoints, and emulation configuration which are accessible to and can control said asynchronous microcontroller.

2. The system of claim 1, further comprising: a multiplexer disposed in the emulation interface that can be controlled by software emulation tool to select program instructions from either an instruction register included in the set of emulation registers or said code memory.

3. The system of claim 1, further comprising: an emulation controller disposed in the emulation interface that is interconnected with said asynchronous microcontroller such that at the beginning of each new program instruction fetch an instruction can be substituted which was supplied by said software emulation tool.

4. The system of claim 3, further comprising: a breakpoints register associated with the emulation controller and disposed in the emulation interface that is inspected during each emulation cycle of said asynchronous microcontroller to halt execution of a program supplied by said software emulation tool.

5. The system of claim 1, wherein the JTAG TAP includes: a TCK/clock pin for synchronizing operations of an internal state machine in said JTAG-TAP controller; a TMS/mode select pin which is sampled at a rising edge of TCK to determine the next state for said state machine; a TDI/data-in pin which is sampled at a rising edge of TCK and shifted into programming logic when said internal state machine is in a correct state; a TDO/data-out pin which represents data shifted out and is valid on a falling edge of TCK; and a TRST/reset pin for resetting said internal state machine.

6. An integrated circuit target device, comprising in a single integrated circuit: a JTAG test access port (TAP) for connection with an external computer hosting an software emulation tool; a JTAG TAP controller connected to the JTAG-TAP and able to support communication with said software emulation tool; an asynchronous microcontroller having a private code memory and data memory; an emulation interface connected between said JTAG TAP controller and the asynchronous microcontroller; and a set of emulation registers disposed in the emulation interface and providing read/write access to said software emulation tool for data, program instructions, program counter, breakpoints, and emulation configuration which are accessible to and can control said asynchronous microcontroller.

7. The device of claim 6, further comprising: a multiplexer disposed in the emulation interface that can be controlled by software emulation tool to select program instructions from either an instruction register included in the set of emulation registers or said code memory.

8. The device of claim 6, further comprising: an emulation controller disposed in the emulation interface that is interconnected with said asynchronous microcontroller such that at the beginning of each new program instruction fetch an instruction can be substituted which was supplied by said software emulation tool.

9. The device of claim 8, further comprising: a breakpoints register associated with the emulation controller and disposed in the emulation interface that is inspected during each emulation cycle of said asynchronous microcontroller to halt execution of a program supplied by said software emulation tool.

10. The device of claim 6, wherein the JTAG TAP includes: a TCK/clock pin for synchronizing operations of an internal state machine in said JTAG-TAP controller; a TMS/mode select pin which is sampled at a rising edge of TCK to determine the next state for said state machine; a TDI/data-in pin which is sampled at a rising edge of TCK and shifted into programming logic when said internal state machine is in a correct state; a TDO/data-out pin which represents data shifted out and is valid on a falling edge of TCK; and a TRST/reset pin for resetting said internal state machine.

11. A method of target device emulation from an external user computer, the method comprising: downloading data, program instructions, program counter, breakpoints, and emulation configuration supplied by a software emulation tool running on an external user computer through a JTAG test access port to an emulation interface; fetching a new instruction with an asynchronous microcontroller that is also connected to said emulation interface; executing said instruction with said asynchronous microcontroller if an emulation mode is off and looping back to the step of fetching afterwards; and otherwise, executing an instruction supplied by said software emulation tool and stored in an emulation register in said emulation interface and looping back to the step of fetching afterwards.

12. The method of claim 11, further comprising: testing a program counter against a breakpoint stored in said emulation interface if said emulation mode is on and stopping execution is a match is found.