Processor condition sensing circuits, systems and methods

Description Submit all comments and votes

NOTICE

(C) Copyright 1989 Texas Instruments Incorporated. A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

This invention relates to electronic data processing and emulation, simulation, and testability devices and systems, and methods of their manufacture and operation.

BACKGROUND OF THE INVENTION

Advanced wafer lithography and surface-mount packaging technology are integrating increasingly complex functions at both the silicon and printed circuit board level of electronic design. Diminished physical access is an unfortunate consequence of denser designs and shrinking interconnect pitch. Designed-in testability is needed, so that the finished product is still both controllable and observable during test and debug. Any manufacturing defect is preferably detectable during final test before a product is shipped. This basic necessity is difficult to achieve for complex designs without taking testability into account in the logic design phase, so that automatic test equipment can test the product.

In addition to testing for functionality and for manufacturing defects, application software development requires a similar level of simulation, observability and controllability in the system or sub-system design phase. The emulation phase of design should ensure that an IC (integrated circuit), or set of ICs, functions correctly in the end equipment or application when linked with the software programs.

With the increasing use of ICs in the automotive industry, telecommunications, defense systems, and life support systems, thorough testing and extensive real-time debug becomes a critical need.

Functional testing, wherein a designer is responsible for generating test vectors that are intended to ensure conformance to specification, still remains a widely used test methodology. For very large systems this method proves inadequate in providing a high level of detectable fault coverage. Automatically generated test patterns would be desirable for full testability, and controllability and observability are key goals that span the full hierarchy of test (from the system level to the transistor level).

Another problem in large designs is the long time and substantial expense involved. It would be desirable to have testability circuitry, system and methods that are consistent with a concept of design-for-reusability. In this way, subsequent devices and systems can have a low marginal design cost for testability, simulation and emulation by reusing the testability, simulation and emulation circuitry, systems and methods that are implemented in an initial device. Without a proactive testability, simulation and emulation approach, a large of subsequent design time is expended on test pattern creation and grading.

Even if a significant investment were made to design a module to be reusable and to fully create and grade its test patterns, subsequent use of module may bury it in application specific logic, and make its access difficult or impossible. Consequently, it is desirable to avoid this pitfall.

The advances in IC design, for example, are accompanied by decreased internal visibility and control, reduced fault coverage and reduced ability to toggle states, more test development and verification problems, increased complexity of design simulation and continually increasing cost of CAD (computer aided design) tools. In the board design the side effects include decreased register visibility and control, complicated debug and simulation in design verification, loss of conventional emulation due to loss of physical access by packaging many circuits in one package, increased routing complexity on the board, increased costs of design tools, mixed-mode packaging, and design for produceability. In application development, some side effects are decreased visibility of states, high speed emulation difficulties, scaled time simulation, increased debugging complexity, and increased costs of emulators. Production side effects involve decreased visibility and control, complications in test vectors and models, increased test complexity, mixed-mode packaging, continually increasing costs of automatic test equipment even into the 7-figure range, and tighter tolerances.

SUMMARY OF THE INVENTION

Among the objects of the present invention are to provide improved emulation, simulation and testability architectures and methods which provide visibility and control without physical probing or special test fixtures; to provide improved emulation, simulation and testability architectures and methods which are applicable to critical components of system designs to support test and integration of both hardware and software; to provide improved emulation, simulation and testability architectures and methods that are a viable alternative to high capital-cost test equipment and systems; to provide improved emulation, simulation and testability architectures and methods which integrate access to sophisticated operations in hardware emulation, fault emulation, simulation and built-in test; to provide improved emulation, simulation and testability architectures and methods which apply hardware and software visibility and control to reduce application development time and thus reduce the user manufacturer's time-to-market on new products; and to provide improved emulation, simulation and testability architectures and methods to leverage hierarchical partitioning and automatically generate reusable tests for related chips and systems.

Generally, one form of the invention is a data processing device including a semiconductor chip, an electronic processor on-chip and an on-chip condition sensor connected to the electronic processor for analysis of the operations.

Other device, system and method forms of the invention are also disclosed and claimed herein. Other objects of the invention are disclosed and still other objects will be apparent from the disclosure herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are set forth in the appended claims. The preferred embodiments of the invention as well as other features and advantages thereof will be be best understood by reference to the detailed description which follows, read in conjunction with the accompanying drawings, wherein FIGS. 1-43 are incorporated from any of applications Ser. Nos. 347,605, 347,596, 347,615, 347,966, 347,968, 347,967 and 347,969 and wherein:

FIG. 44 is a pictorial diagram of development tools for developing integrated circuit chips and software;

FIG. 45 is a partially pictorial, partially block diagram of a system configuration for emulation, simulation, testability and attached processor data processing, communications I/O and peripheral access;

FIG. 46 is a diagram of a software configuration for a host computer of FIG. 45;

FIG. 47 is a block diagram of a modular port scan (MPSD) arrangement;

FIG. 48 is a block diagram of a scan test/MPSD configuration;

FIG. 49 is a block diagram of an integrated approach to test and emulation circuitry;

FIG. 50 is a partially block, partially schematic diagram of a scan testability interface;

FIG. 50A is a state transition diagram of a test access port (TAP) controller in FIG. 50;

FIG. 51 is a block diagram of processor chip domains, boundary scan and scan test/emulation circuitry on chip;

FIG. 52 is a block diagram of the processor chip of FIG. 51 showing functional blocks of the chip allocated to the various domains, and showing a message passing circuit;

FIG. 53 is partially pictorial, partially block diagram of the processor chip of FIGS. 51 and 52;

FIG. 54 is a block diagram of scan paths in greater detail than that of FIG. 50;

FIG. 55 is a block of scan paths in greater detail than that of FIG. 54;

FIG. 56 is a block diagram of connections of a control adapter to the domains, showing nomenclature;

FIG. 57 is a block diagram of modules in the domains, also illustrating a mode-driven stops process;

FIG. 58 is a process diagram of operation of the system of FIGS. 45, 50, 57 and 59 for emulation, simulation and testability;

FIG. 59 is a detailed block diagram of the adapter of FIGS. 49, 51, 52, 53, 56 and 57;

FIG. 59A is a compact diagram of shift register latches SRLs in a scan chain in FIG. 59;

FIG. 60 is a schematic diagram of a code state machine and an event manager circuit therefor in the adapter of FIG. 59;

FIG. 61 is a state transition diagram of the code state machine of FIG. 60;

FIG. 62 is a schematic diagram of selection and flip-flop circuitry of the adapter of FIG. 59;

FIG. 63 is a schematic diagram of a lock control circuit of the adapter of FIG. 59;

FIG. 64 is a schematic diagram of one of three identical logic circuits of the adapter of FIG. 59 supplying codes to a domain;

FIG. 65 is a schematic diagram of one of three identical clock control circuits of the adapter of FIG. 59 for switching functional clock FCLK or test clock JCLK to a domain;

FIG. 66 is a pictorial diagram of a testing system for testing numerous integrated circuits on a wafer in wafer fabrication;

FIG. 67 is a process flow diagram of operation of the testing system of FIG. 66;

FIGS. 68A and 68B are two halves of a block diagram of a central processing unit CPU core improved for emulation, simulation and testability;

FIG. 69 is a block diagram of an analysis circuit for monitoring the operations of an integrated circuit device;

FIG. 70 is a process flow diagram of operations of the analysis circuit of FIG. 69;

FIG. 71 is a block diagram of a hardware breakpoint circuit in FIG. 68A;

FIG. 72 is a block diagram of a trace stack in FIG. 68A;

FIG. 73 is a process flow diagram of operations of the trace stack and a program counter stack of FIG. 68A;

FIG. 74 is an address map of a processor device;

FIG. 75 is a time-series diagram of the contents of the program counter stack and not the trace stack;

FIG. 76 is a partially pictorial, partially block diagram of a system for simulated peripheral accesses;

FIG. 77 is a process flow diagram of operations of the system of FIG. 76;

FIG. 78 is a block diagram of the message passing circuitry of FIG. 52;

FIG. 79 is a process flow diagram of an attached processor method of operating the system of FIG. 45;

FIG. 80 is a block diagram of a graphic system processor GSP chip;

FIG. 81 is a more detailed block diagram of a CPU portion of the GSP chip of FIG. 80 showing testability, emulation and simulation circuitry;

FIG. 82 is a waveform diagram of clock waveforms for operating the GSP chip of FIG. 80;

FIG. 83 is a schematic of a parallel register latch for use in the GSP chip of FIG. 80;

FIG. 84 is a schematic of a serial register latch for use in the GSP chip of FIG. 80;

FIG. 85 is a block diagram of a control read only memory (CROM) for the GSP chip of FIG. 80;

FIG. 86 is a detailed block diagram of signature analysis test circuitry for the CROM of FIG. 85; and

FIG. 87 is a schematic diagram of a cell in the signature analysis test circuitry of FIG. 86.

Corresponding numerals and other corresponding symbols refer to corresponding parts in the various Figures of drawing except where the context indicates otherwise.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Various inventive electronic architectures, devices, systems and methods were described extensively in the detailed description and drawings 1-43 common to all of the coassigned applications with Ser. Nos. 347,605; 347,596 issued Oct. 10, 1991 (U.S. Pat. No. 5,072,418); 347,615; 347,966; 347,968; 347,967; and 347,969. All of these foregoing coassigned applications are incorporated herein by reference. Numbering of Figures in the present application begins with FIG. 44 to continue the sequence of detailed description. Corresponding numerals in this application and said coassigned applications refer to corresponding parts for clarity of exposition.

A device 11, described in the coassigned applications and further described herein, is adapted for sophisticated interfacing with development tools illustrated in FIG. 44. Hardware design tools include an extended development system 1101 interfaced by a serial line 1103 to a circuit board 1043 holding device 11. Also provided in the development tools are an evaluation module 1111 connected to an analog interface board AIB 1113.

A software development system SWDS provides for user entry of source code 1121 in the C computer language which source code then is compiled by a C compiler 1123 into code 1125.

C compiler 1123 is an optimizing compiler fully implementing the standard Kernighan and Ritchie C language, for instance. The compiler 1123 accepts programs written in C and produces assembly language source code, which is then converted into object code by the assembler 1127. This high-level language compiler 1123 allows time-critical routines written in assembly language to be called from within the C program. Conversely, assembly routines may call C functions. The output of the compiler is suitably edited before assembly and link to further optimize the performance of the code. The compiler 1123 supports the insertion of assembly language code into C source code, so that the relative proportions of high-level and assembly language code are tailored according to the needs of a given application.

The code 1125 is assembled by an assembler 1127 into relocatable object code. A linker 1129 produces non-relocatable machine code or linked object code which is then downloaded into the device 11 through the development system.

Assembler 1127 and linker 1129 comprise a software development tool that converts assembly language files into executable object code. Key features are macro capabilities and library functions, conditional assembly, relocatable modules, complete error diagnostics, and symbol table and cross reference. Four programs address specific software development needs, discussed next.

The assembler 1127 translates assembly language source files into machine language object files. Source files contain instructions, assembler directives and macro directives. Assembler directives are used to control various aspects of the assembly process, such as the source listing format, data alignment and section content.

The linker 1129 combines object files into a single executable object module. As the linker creates an executable module, it performs relocation and resolves external references. The linker accepts relocatable object files created by the assembler as input. It also accepts archive library members and output modules created by a previous linker run. Linker directives allow combining or binding of file sections or symbols to addresses and defining or redefining global symbols.

An archiver allows collection of a group of files into a single archive file. For example, several macros are suitably collected into a macro library. The assembler searches through the library and uses the members that are called as macros by the source code 1125. The archiver also suitably collects a group of object files into an object library such as files that resolve external references during linking.

An object format converter converts an object file into any one of several EPROM programmer formats, such as TI-TAG format. The converted file is then downloaded to an EPROM programmer so that the EPROM code so established is then executed on the device 11 target chip in system 1043.

Simulator 1131 executes a software program that simulates operation of the target chip for cost-effective software development and program verification in non-realtime. The simulator simulates the entire target chip instruction set and simulates the key peripheral features including DMA, timers and serial port when the target chip includes them. Command entry is accepted from either menu-driven keystrokes (menu mode) or from a batch file (line mode). Help menus are provided for all screen modes. Its standard interface can be user customized. Simulation parameters are quickly stored/retrieved from files to facilitate preparation for individual sessions. Reverse assembly allows editing and reassembly of source statements. Memory is displayed as hexadecimal 32 bit values and assembled source code, separately or at the same time.

Simulator 1131 execution modes include 1) single/multiple instruction count, 2) single/multiple cycle count, 3) Until Condition Is Met, 4) While Condition Exists, 5) For Set Loop Count and 6) Unrestricted Run with Halt by Key Input. Trace expressions are readily defined. In trace execution, display choices include 1) designated expression values, 2) cache registers, and 3) instruction pipeline for easy optimization of code. Breakpoint conditions include Address Read, Address Write, Address Read or Write, Address Execute, and Expression Valid. Simulator 1131 simulates cache utilization and does cycle counting. For example, in cycle counting the number of clock cycles in single step mode or run mode are displayed. External memory is suitably configured with wait states for accurate cycle counting.

Simulator 1131 accepts object code produced by the assembler 1127 and linker 1129. Input and output files are suitable associated with the port addresses of the I/O instructions to simulate I/O devices connected to the processor. Before starting program execution, any breakpoints are set and the trace format defined.

During program execution on simulator 1131, the internal registers and memory of the simulated target chip are modified as each instruction is interpreted by the simulator 1131. Execution is suspended when a breakpoint or error is encountered or when execution is halted. When program execution is suspended, the internal registers and both program and data memories can be inspected and modified. A trace memory is also displayable. A record of the simulation session can be maintained in a journal file so that it can be re-executed to regain the same machine state during another simulation session.

The simulator 1131 allows verification and monitoring of the state of the target chip without the requirements of hardware. Simulation speed is on the order of hundreds or thousands of instructions per second depending on the operating system and hardware selected for simulator 1131. A state-accurate simulation might be as slow as 1-2 instructions per second. Emulation at the higher real-time functional clock rate is performed by development system 1101 instead of simulator 1131.

Simulator 1131 provides for complete computer simulation not only of the device 11, but also its peripherals on the board 1043 through file I/O for example.

Extended development system 1101 provides full-speed, in-circuit emulation for system design and for hardware and software debug on widely available personal computer systems. The development tools provide technological support from system concept to prototype. The development system elements provide ease of use and offer the designer the tools needed to significantly reduce application system development time and cost to put designs into production faster.

FIG. 45 illustrates in even more detail the emulation environment provided by the extended development system 1101. A controller card 1141 compatible with IEEE JTAG standards is included in the emulation host computer 1101. This controller card 1141 communicates by serial line 1103 to PC board 1043 and DSP device 11 of FIG. 45. System 1043 has Texas Instruments Scope (TM) testability meshed with Texas Instruments MPSD (Modular Port Scan Design) emulation for a complete solution from development, through manufacture, and including field test. The inventive approaches are applicable in digital signal processors (DSP), graphics signal processors (GSP), memories (MEM), programmable array logic (PAL), application specific integrated circuits (ASIC), and general purpose logic (GPL) general purpose Micro Computers and Micro processors, and any device requiring test or code development.

Host computer 1101 of FIG. 45 has peripherals including a printer 1143, hard disk 1145, and telecommunications modem 1143 connected to a telephone line for uploading to a remote mainframe in field test and other procedures. The peripheral capabilities of bus 1149 of host computer 1101 are not only available for emulation, but also provide access by application system 1043 to these peripherals along serial line 1103. Host computer 1101 thus is not only available to the system 1043 as an emulation host but also as an attached processor itself and as a port for communications I/O and to other peripheral capabilities temporarily needed by system 1043 but ordinarily unavailable to system 1043.

FIG. 46 illustrates an emulation and simulation software configuration for computer 1101 wherein device independent emulator software has a window driven user interface and a test executive program.

Device specific configuration files for each of the devices on board 1043 are provided. For example, there is a DSP configuration file, a GSP (graphic signal processor) configuration, a programmable array logic (PAL) file, an ASIC file and a GPL register file.

The emulation hardware and software of FIGS. 45 and 46 provide a user-friendly, personal-computer or work station-based development system which provides all the features necessary to perform full-speed in-circuit emulation with target chips on board 1043. For example, DSP 11 is suitably a Texas Instruments 320 series digital signal processor disclosed in coassigned U.S. Pat. No. 4,912,636 hereby incorporated herein by reference; or a 320C50 digital signal processor disclosed in U.S. Pat. No. 5,072,418 which is incorporated herein by reference. An exemplary graphics signal processor is the Texas Instruments 34020 GSP disclosed in the GSP coassigned applications incorporated hereinabove and having inventive emulation circuitry more fully described hereinbelow.

The emulator comprised of FIG. 45 host computer 1101 with controller card 1141 and software of FIG. 46 allows the user to perform software and hardware development, and to integrate the software and hardware with the target system. An important emulation interface provides control and access to every memory location and register of the target chip and extend the device architecture as an attached processor.

Emulator controller card 1141 provides full-speed execution and monitoring of each target chip such as device 11 in the user's target system 1043 via a multi-pin target connector. In one embodiment, thirty software and hardware breakpoints, software and hardware trace and timing, and single-step execution are provided. The emulator has capability to load, inspect, and modify all device 11 registers. Program data and program memory can be uploaded or downloaded. The user interface of host computer 1101 for emulation purposes is a windowed user interface designed to be identical to the windowed user interface of simulator 1131 for the corresponding target chip. The emulator 1101 is portable and reconnectable for multiprocessing. Emulator 1101 provides a benchmark of execution time clock cycles in realtime.

Full-speed execution and monitoring of the target system is suitably controlled via a multi-wire interface or scan path in the multi-pin target connector. The scan path controls the target chip in the system 1043, providing access to all the registers as well as associated internal and external memory.

Program execution takes place on the target chip (e.g. 11) in the target system 1043. Accordingly, there are no timing differences during emulation, as might occur without the in-circuit emulation provided by this preferred embodiment. Heretofore, emulation may have involved sending signals over a cable to emulate the target chip 11 in its absence. Advantageously, the present embodiment is a non-intrusive system that utilizes chip 11 itself, and avoids cable length and transmission problems. Loading problems on signals are avoided, and artificial memory limitations are obviated. Emulation performance coincides with specifications for the emulated target chip itself.

Software breakpoints allow program execution to be halted at a specified instruction address. Hardware breakpoints are also advantageously operative on-chip. When a given breakpoint is reached, the program either halts execution to permit user observation of memory and status registers, or the breakpoint is included in a more complex condition, which when satisfied results in an appropriate stop mode being executed. At this point, the status of the target chip or system is available for display by the user with as little as a single command.

Software trace and hardware program counter trace permit the user to view the state of target chip 11 when a breakpoint is reached. This information is suitably saved on command in a file for future analysis. Software timing allows the user to track clock cycles between breakpoints for benchmarking time critical code.

Single-step execution gives the user the ability to step through the program one instruction at a time. After each instruction, the status of the registers and CPU are displayed. This provides greater flexibility during software debug and helps reduce development time.

Object code is downloaded on command to any valid program memory location or data memory location via the interface. Downloading a 1K-byte object program illustratively takes on the order of 100 milliseconds. By inspecting and modifying the registers while single-stepping through a program, the user can examine and modify program code or parameters.

A windowed user interface for emulator 1101 is suitably made identical to that of simulator 1131, affording a straightforward migration from simulator-based development to emulator-based development. The user-friendly screen displays the program code in mnemonics and equivalent hexadecimal code. Windowed displays are suitably provided for extended precision registers, the CPU status and memory locations.

A first screen option is a primary screen that includes a command line displayed at top of screen, functions of special-function keys, and four status windows which are individually accessed using the F1 key of commercially available keyboards. The windows include a source code window, an auxiliary display window, a CPU status window, and an extended precision registers window. The contents of the windows are made accessible for user inspection and modification.

Commands are entered in a MENU mode or a LINE mode. In the MENU mode, a menu at the top of the screen permits the user to view every option available while entering a single command. Further menus are then displayed until the entire command has been entered. The LINE mode allows user to enter an entire command expression. A summary of commands is provided in Appendix I.

Emulator card 1141 of FIG. 45 suitably occupies slots in an IBM PC-XT/AT computer when the latter is used as host computer 1101. The card 1141 is detached and transferred to another PC (personal computer of equivalent functionality) as needed, affording emulator portability. For simulation, a memory map for the controller card 1141, which may include EPROM (erasable programmable read only memory), SRAM (static random access memory), DRAM (dynamic random access memory), and on-chip memory and peripherals, can be configured by the designer to reflect the actual environment of the target system 1043, including wait states and access privileges. In this way, card 1141 and host computer 1101 simulate peripherals which are as yet absent from board 1043 in a particular development context.

In one embodiment, multiprocessing applications are emulated by extending line 1103 between each of several application boards from one to the next, maintaining real-time emulation and preserving the information on each target chip.

The development system 1141 operates in two modes: emulation mode and algorithm development and verification mode. In the algorithm verification mode, the target chip 11 debugs its software at full speed before the target system is complete. To accomplish this, code is downloaded into the memory on the board 1043 and executed at full speed via the interface on an application board used in place of the incomplete target system. A suitable application board includes a DSP 11, 16K=32 bits of full-speed (zero wait states) SRAM on a primary bus, two selectable banks of 8K=32 bits full speed (zero wait state) SRAM on an expansion bus, and 512K=32 bits DRAM. With ample SRAM, the user has realtime emulation capabilities and memory storage flexibility for a variety of algorithms. Zero wait state capability in SRAM allows memory read/write in realtime.

For algorithim development and code verification the system can single step and run until breakpoint is reached. Algorithim verifiction runs data through the algorithim and verifies its function. Burst execution, I/O and other functions are available.

Page mode DRAM improves bulk storage performance. Three types of DRAM cycles are used on one example of an application board. These are single-word read, single-word write and page-mode read which respectively have wait states of four, two, and one wait state per access. Page mode read cycles are automatically evoked when device 11 performs two or more back-to-back read cycles on the same memory page (256 words). Utilizing page-mode results in a decrease in wait states when accessing on application board 1043 DRAM on application board 1043.

In FIG. 45 both test and development support system access to the application system resource is via a serial scan bus master or scan interface on controller card 1141, and described later hereinbelow. Sophisticated emulation and simulation functions are built out of primitives. Primitives are sets of bits that define control operations (like commands or instructions) available through controller card 1141.

The functionality of the device 11 can be accessed by each of two illustrative inventive serial implementations. A first implementation is Texas Instruments Modular Port Scan Design (MPSD) as shown in FIG. 47 and disclosed in coassigned application Ser. No. 057,078 issued Aug. 22, 1989 (U.S. Pat. No. 4,860,290) and incorporated herein by reference. Shift register latches (SRLs) designated "S" are distributed through the device 11 like a string of beads on a serial scan path respective to each module to provide access to all important registers.

In FIG. 48, a second approach uses a SCOPE transmission medium combined with MPSD technology in a SCOPE interface 1150.

In FIG. 49 device 11 has an on-chip JTAG interface 1149 as described herein. The scan interface is connected to line 1103 of FIG. 45 and has inputs for test clock TCK, mode select TMS, and test data input TDI (scan in), as well as a test data output TDO (scan out). A special emulation adapter 1203 is connected between the scan interface 1149 and MPSD modules of the functional circuitry 1213 of device 11. Emulation adapter 1203 in different forms involves hardwired state machine circuitry, assembly language, or microcoded state machine embodiments.

The characteristics of some implementations when used in support of emulation are shown in Table I:

TABLE I ______________________________________ SCOPE/ MPSD SCOPE MPSD ______________________________________ Industry Standard No Yes Yes Communication Max Clock Period Depends Unlimited Unlimited Functional Clock No Yes Yes Independence Boundary Scan Support No Yes Yes Silicon Efficiency Yes No Yes Most Emulation Capability No Yes Yes Number of Extra Pins Four Six Six ______________________________________

The implementation SCOPE/MPSD capitalizes on the strengths of MPSD and SCOPE individually to create a hybrid emulation technology.

FIG. 50 shows a block diagram of improved SCOPE hardware which is provided on each of the chips such as device 11 on PC board 1043. Four pins TDI, TMS, TCK and TDO communicate with the system. TMS and TCK communicate with a tap controller 1151 which is connected to an instruction register 1153 and an instruction decoding circuit 1155.

Test access port (TAP) controller 1151 is in turn coupled to instruction register (IR) 1153 and a first multiplexer 1173. The instruction register can receive serial scan signals from the TDI line and output serially to MUX 1173. MUX 1173 is under control of the TAP and can select the output signal from the instruction register or from another MUX 1171.

The instruction register also controls a bypass register (BR) 1167 and one or more boundary scan registers (BSR) 1161. The bypass register receives the TDI signal and outputs it to MUX 1171. MUX 1171 is under control of the instruction register 1153. Based on the instruction loaded into the instruction register, MUX 1171 outputs its input from the bypass register or its input from one or more BSRs, or internal device register scan. Each boundary scan register is controlled via the test access port and the instruction register.

The boundary scan arrangement operates in a normal mode or a test mode. During the normal mode, input data entering terminals of IC logic passes through the boundary scan register, into the IC logic and out to the normal output terminals without any change due to the BSR. During the test mode, normal input data is interrupted, and test input data is captured, shifted, and updated within the boundary scan register. The boundary scan register includes two memories, a first memory for receiving and shifting data from the TDI line and a second memory for holding output data. The second memory is selectively operable to transfer data from the first memory to the second memory.

Generally, in FIG. 50, serial information is down loaded from emulation computer 1101 via the SCOPE controller card 1141 through pin TDI and enters any one of a number of shift registers, including a boundary scan register 1161, a device identification register 1163 and design specific test data registers 1165. A bypass register 1167 is also provided. These shift registers or serial scan registers are selected via a MUX 1171 under the control of instruction decode circuitry 1155. The selected output from MUX 1171 is fed to a MUX 1173 so that under control of tap controller 1151 the instruction register 1153 or MUX 1173 output are fed to flip flop 1175 which in turn is connected to a serial return circuit 1177 which is suitably enabled to return or send serial outputs from all parts of the on-chip JTAG circuitry back to computer JTAG card 1141 via output serial pin TDO.

In FIG. 50A a state transition diagram of TAP controller 1151 has one and zero signal values entered adjacent to each state transition arc. These are values of signal TMS at the time of a rising edge on signal TCK. The states of the JTAG TAP (Test Access Port) controller are described in "A Standard Test Bus and Boundary Scan Architecture" by L. Whetsel, Texas Instruments Technical Journal, Vol. 5, No. 4, 1988, pp. 48-59 and L. Whetsel coassigned patent applications Ser. Nos. 241,439, abandoned parent of continuing application Ser. No. 908,760 filed Jul. 1, 1992, abandoned 241,520, abandoned parent of continuing application Ser. No. 876,694 filed Apr. 28, 1992, abandoned 241,511 (issued as U.S. Pat. No. 5,084,874) cofiled on Sep. 7, 1988 and 282,827, issued as U.S. Pat. No. 4,872,169 filed Nov. 8, 1988, all of which are hereby incorporated herein by reference.

Turning to basic concepts recognized and utilized herein, emulation involves hardware support built around each circuit so that operations can be executed within the circuit while doing analysis in parallel as the circuit runs. Emulation permits the circuits to be run at full speed in real time as the emulator computer 1101 monitors the circuits and starts and stops them. The user defines and develops software in the environment of the target system. Put another way, emulation reads inputs from the board 1043 and produces outputs to the board as if device 11 were absent, for the purpose of determining appropriate software and operation signals. Ultimately, when the device 11 is supplied with the appropriate software resulting from emulation work, the device 11 operates in a manner which is compatible with the rest of the circuitry of board 1043. Advantageously, in the improved system disclosed herein, the device 11 is actually on the board and with the serial communication capabilities, all of the operations of device 11 are monitored directly from the device itself. In view of the extremely high speed of device 11, the device itself assists in its own emulation.

In a previous approach, a cable is terminated in a pin-plug that mates to a socket provided on the board in place of the emulated device. The socket introduces a noise issue. A socket may be impractical when a surface mount device is to be emulated, due to limited board space. Advantageously, device 11 is soldered onto board 1043 and emulation is mediated by the device itself.

The few pins utilized by the scan interface 1150 eliminate the need for conventional full pin-out target connectors and eliminate problems associated with cable reliability, transmission effects and timing differences. In this way, board 1043 can be probed with logic analyzers and oscilloscopes in the improved system without physical or electromagnetic interference from a heavy cable. Moreover, clock rates in excess of 20 megaHertz for device 11 are so fast that previous emulation schemes may be incapable of emulating it.

Simulation as the term is used herein creates a software representation of the target board 1043 so that the entire board can be developed in simulation on simulator 1131 of FIG. 44 (or by running the simulator program on computer 1101). In another aspect of simulation, when the device 11 is available but the rest of the circuitry for target board 1043 is incomplete, the simulator can mimic the planned complete board by serial scan upload or download from device 11 to computer 1101, and then serial scan download or upload from computer 1101 to device 11 in substitution for the missing circuitry of board 1043. In this aspect, simulation is accelerated by running the device 11 itself at full speed according to the improvements described herein. Even when computer 1101 runs at a slower speed than device 11, simulation is effective to simulate peripherals which are accessed infrequently by device 11.

Test as the term is used herein has four different areas. The first area--Device Test--is test of a device 11 itself before the device manufacturer ships it.

The second area of test is Device Verification--verification of full functionality of the device in every aspect.

The third ar