REGISTER  |  SIGN IN
United States Patent5321828
Phillips , ; et al.June 14, 1994
Title
High speed microcomputer in-circuit emulator
Abstract
An in-circuit emulator (ICE) for hardware/software development and debugging microprocessors. Program execution reconstruction is extracted from an on-board cache memory. An external ICE enclosure interfaces to a target system microprocessor via a cable and a buffer/interface pod. A control program directs a non-intrusive emulation and a monitor program resides in a personal computer host and supports ICE commands. The monitor program allows a user to follow a target system's program flow, to capture related processor information, to make program modifications, and allows the user to restart programs. An on-line disassembler presents a display so as to allow the designer to examine memory, using instruction mnemonics rather than hexadecimal values, thus improving the designer's ability to read program memory. A bit trace buffer records the state of each the microprocessor's signals during each cycle of each instruction. Multiple breakpoints allow a system developer to control a program in ROM, as well as one resident in RAM. An external-range hardware breakpoint and up to sixteen software breakpoints are provided and these allow a designer to display, set and reset breakpoint addresses.
Inventors:Phillips; Michael D. (Santa Clara, CA), Wilburn; Darrell L.  (Saratoga, CA), Hua; Van T.  (San Jose, CA), Minami; Gordon A.  (Palo Alto, CA), Kresge; Robert J.  (Cupertino, CA), Verhaegh; Charles  (Arkata, CA)
Assignee:Step Engineering (Sunnyvale, CA)
Appl. No.:712917
Filed:June 7, 1991
Current U.S. Class:703/28 
Field of Search:395/375,500 371/16.2
U.S. Patent Documents
4674089June 1987Poret et al.
5047926September 1991Kuo et al.
5053949October 1991Allison et al.
5056013October 1991Yamamoto
5132971July 1992Oguma et al.
Primary Examiner: Harrell; Robert B.
Assistant Examiner: Mohamed; Ayni
Attorney, Agent or Firm:Schatzel; Thomas E.
Claims

What is claimed is:
1. An in-circuit emulator (ICE) for connection with a target system, comprising:
umbilical means for connecting the target system to a microprocessor;
a low level control interface with means for accessing and modifying a target system memory, means for displaying and modifying a set of target system processor registers, means for hardware and software breakpointing to said target system, means for single and multiple stepping said target system and means for disassembling machine code into assembly code resident in a set of memory locations in said target system, the low level control interface being connected in communication with the umbilical means;
clocking means for triggering a circuit analyzer according to comparisons between user-defined external bits and trace signals derived from the target system, the clocking means being connected in communication with the umbilical means; and
in-line assembler/disassembler means coupled to said target system memory for examining and changing memory locations in the target system through the use of mnemonics communicated to a user such that a program machine code can be patched and tested, wherein the readability of program memory by a user is improved.

2. The ICE of claim 1, wherein:
the umbilical means comprises a single continuous flexible circuit with a target system connector, an interface pod proximate to said target system connector and means for connection to ICE, wherein each of said target system connector, said interface pod and ICE connection means have a rigid printed circuit board section layered onto said single flexible circuit.

3. A method of in-circuit emulation with a bond-out chip temporarily connected to a vacant microprocessor socket in a target system to provide debug visibility of execution of instructions from an on-board target microprocessor cache memory, comprising the steps of:
collecting trace data from a bond-out interface of said bond-out chip which provides a deterministic, yet discontinuous address stream during execution of a target system machine code program in said bond-out chip with an umbilical cable that attaches to said vacant target system microprocessor socket and that communicates said target system trace data to a trace buffer;
disassembling said trace data in said trace buffer into an assembler code representation;
displaying said assembler code using assembler mnemonics on a computer terminal screen for reading by a user with a means to scroll through said assembler code display;
displaying on said screen at least one line of a source code program that compiles into said assembler source code; and
highlighting a particular line of said displayed source code program that generates in compiling a particular line of assembler code then displayed and selected on said screen.

4. The method of claim 3, wherein:
the displaying is such that said mnemonics comprise those that are substantially similar to mnemonics associated with a particular commercial brand of target system microprocessor.

5. A method of reconstructing the path of execution from information present on a special bond-out interface bus of a microprocessor bond-out chip substituted for a target microprocessor during target program execution, comprising the steps of:
reading from said bond-out interface bus a discontinuous address stream that comprises program branch data that corresponds to jumps and/or calls executed during a debugging of said target program in said target system;
interpolating from said program branch data a sequence of machine level execution cycles that must necessarily occur for a particular type of target microprocessor between at least two points in said target program identified by said program branch data; and
disassembling said sequence of machine level execution cycles into a corresponding sequence of assembler source code statements.

6. A method of buffering and latching digital data from a device-under-test (DUT) synchronous with a clock from the DUT to a memory device where device propagation delays caused by the buffering are substantial in relation to data hold times required for the latching, the method comprising the steps of:
buffering said DUT clock to reduce loading on said DUT and to provide a buffered DUT clock output;
buffering said DUT data to reduce loading on said DUT and to provide a buffered DUT data output;
generating from said buffered DUT clock output a local clock synchronous to said DUT clock with means able to track substantial variations in said frequency of said DUT clock, said local clock leading said buffered DUT clock output by a predetermined and fixed period of time; and
latching said buffered DUT data output using said local clock, said predetermined and fixed period of time being such that said latching satisfies a data setup and a data hold time associated with said memory device.

7. An in-circuit emulator (ICE) for connection to a target system the ICE comprising:
umbilical means for connecting said ICE in between said target system and a target microprocessor, the umbilical means being on a single continuous flexible circuit and having a target system connector, an interface pod proximate to said target system connector and means for connection to said ICE; and each of said target system connector, said interface pod and said ICE connection means including rigid printed circuit board laminations on said single flexible circuit, wherein the umbilical means provides a single continuous flexible circuit that maintains good transmission line characteristics throughout;
a low level control interface with means for accessing and modifying a target system memory, means for displaying and modifying a set of target system processor registers, means for hardware and software breakpointing to said target system, means for single and multiple stepping said target system and means for disassembling machine code into assembly code resident in a set of memory locations in said target system, the low level control interface being connected in communication with the umbilical means;
in-line assembler/disassembler means coupled to said target system memory for examining and changing memory locations in the target system through the use of mnemonics communicated to a user such that a program machine code can be patched and tested, wherein the readability of program memory by a user is improved;
trace data means for collecting trace data from said target system during execution of said target microprocessor program in communication with the umbilical means and for storing said trace data in a trace buffer, the trace data means having,
clock buffering means coupled through the umbilical means for buffering a target system clock to reduce loading on said target system,
data buffering means coupled through the umbilical means for buffering said target system data to reduce loading on said target system,
oscillator means coupled through the umbilical means for generating a local clock synchronous to said target system clock, said local clock able to track substantial variations in said frequency said target system clock, said local clock leading said buffered target system clock by a predetermined and fixed period of time, and
latch means coupled to said data buffering means for latching buffered target system data with said local clock;
program branch reading means coupled to said target system processor through the umbilical means for reading program branch data that corresponds to jumps and/or calls taken by said target microprocessor;
interpolating means coupled to the program branch reading means for interpolating from said program branch data a sequence of machine level execution cycles that necessarily occur between at least two points in said target microprocessor program that are identified by said program branch data;
program machine code disassembly means coupled to the trace data means for disassembling said trace data and interpolations and for presenting said result in assembler mnemonics;
screen monitor display means coupled to the program machine code disassembly means for displaying said assembler mnemonics on a computer terminal screen for reading by a user with a means to scroll through said assembler code display;
source code display means coupled to the program machine code disassembly means for displaying on said computer terminal screen at least one line of a source code program that compiles into said assembler source code; and
outlining means coupled to the source code display means for highlighting a particular line of said displayed source code program.

8. An apparatus for diagnosing program execution in a microprocessor having an on-chip cache memory and a bond-out interface that provides a deterministic address stream that communicates externally an instruction pointer, at a minimum, when said microprocessor advances to a new sequential address, the apparatus comprising:
execution path reconstruction means coupled to said bond-out interface for reconstructing a path of execution from a discontinuous address trace, the execution path reconstruction means having means to read machine code instructions into a target memory;
machine code disassembly means coupled to the execution path reconstruction means for disassembling said machine code instructions into assembler code;
monitor means coupled to the machine code disassembly means for displaying to a user a set of disassembled machine code instructions with corresponding program memory addresses; and
indexing means coupled to the machine code disassembly means for determining a number to add to an instruction pointer index such that a pointer displayed on the monitor means can indicate an address of a next instruction to be disassembled to said user; and
annunciation means coupled to the machine code disassembly means for issuing a special flag when said microprocessor executes any one of a call, a return, a branch and an interrupt.

9. The apparatus of claim 8, further comprising:
a synchronized output signal means coupled to said microprocessor and having an ICE internal time-tag counter for externally synchronizing an additional ICE, wherein multi-processor in-circuit emulation is provided.
Description
BACKGROUND THE INVENTION

1. Field the Invention

The invention relates generally to microcomputer systems and more particularly to instruments that enable the development and debugging of the hardware and software in target machines by the emulation and control of the target CPU within the target environment.

2. Description the Prior Art

In circuit emulation (ICE) of microcomputers for target system development is popular and well known in the microcomputer system industry. ICE development tools have been available for several years from Step Engineering (Sunnyvale, Calif.), Intel Corporation (Santa Clara, Calif.), Motorola Microsystems (Tempe, Ariz.), and others.

Microprocessor chips are complex devices requiring that both their hardware and software environments to be near perfect for proper operation. When a new microcomputer chip is first introduced, for example the i960 RISC processor by Intel or the
68040 CISC processor by Motorola, compatible hardware and software target environments do not exist and must be developed rapidly. This poses some difficulty because the timing is such that this coincides with a time when expertise in those particular environments is low. Since the chip is new, a very limited number of engineers have any direct experience with it. The job of designing a new system that uses the latest microprocessor is extremely difficult and often paces the ability of a manufacturer to compete effectively in its respective market. ICE system tools help get new designs off the ground by allowing incremental hardware and software development and a convenient cross-assembler and downloading mechanism for target object modules.

As the microprocessor art has advanced, clock speeds have become relatively faster and word widths wider. An early ICE from Intel, sold as the MDS ICE-85 in the late 1970s, had an eight-bit data width and a five-megahertz clock. In the 1990s, data widths of 32 bits are routine, and clock speeds around 50 MHz. Initially, target processors could be relocated in the ICE and attached to the target system via an umbilical of woven or twisted wires. When clock speeds got too high for this, the target processors were left in the target systems, and had adaptors that plugged between the target processor and the target system to intercept and/or sense key signals. These signals were then buffered by a buffer box located at the target end of a cable extending back to the main unit of the ICE. Most flat cables do not work well at high speeds and some attempts were made to use coaxial cables. But with over 100 signals to communicate, use of coax cables is not practical. A few systems use flexible printed circuits with buried ground planes to interconnect the main chassis of an ICE system umbilically to its target processor buffer box. These prior art systems suffer from poor mechanical and electrical transitions between the processor and the flex, the flex and the buffer box, and the flex between the main chassis and the buffer box.

Wider data and address widths have also caused a competition between data, address, and control signals and processor status for pinouts in the device package. System designers decoded these pins to track program execution in real-time. Internal cache memories have fundamentally obfuscated the visibility system designers once had into the internal operations of a microprocessor. For those reasons, microprocessor manufacturers have produced special "bond-out" chips that resemble the standard versions of their respective parts, but the bond-outs have special pins, and sometimes whole buses, that give a system developer some visibility into the internal workings of the processor (and inside the cache). The view, however, is not as clear as one would hope for, and special devices and programs are needed to decode and give meaning to the hints provided at the special bond-out interfaces.

SUMMARY THE PRESENT INVENTION

It is therefore an object of the present invention to provide an improved means to in-circuit emulate high speed microprocessors.

Briefly, a first embodiment of the present invention is an in-circuit emulator (ICE) that functions as a peripheral to an IBM PC/AT compatible personal computer (PC/AT). The ICE supports the Intel Corporation i960 CA RISC processor (i960 CA) operating to 25 MHz, alternatively the ICE supports operation to 33 MHz. The ICE has means to reconstruct program execution from the on-board cache memory of a i960 CA. An external ICE enclosure interfaces to a target processor via a thirty inch cable and buffer/interface pod. The interface connects to all the signal pins of the i960 CA processor and has high-speed buffers to minimize target loading. A control program directs a non-intrusive emulation and is able to operate at 25 MHz. A monitor program resides in the PC/AT host and supports more than 30 ICE commands. The monitor program is such that it allows a user to follow the target system's program flow, to capture related processor information, to make program modifications, and to be able to restart programs. An on-line i960 CA disassembler presents a display that allows the designer to examine memory, using instruction mnemonics rather than hexadecimal values, thus improving the designer's ability to read program memory. An
8K/32K.times.160-bit trace buffer records the state of each of the i960 CA's signals during each cycle of each instruction. This provides the designer with a detailed record of the target system's operation. Multiple breakpoints allow a system developer to control a program in ROM, as well as one resident in RAM. An external range hardware breakpoint and up to sixteen software breakpoints are provided and these allow a designer to display, set and reset breakpoint addresses. Alternative embodiments to the first embodiment have additional breakpoints beyond sixteen. Complex triggering and breakpoint capabilities are possible via a standard logic analyzer interface incorporated into the ICE. The ICE is compatible with "C" language tools developed by Intel, Microtec Research and other third-party vendors. An interface to both GNU and Microtec XRAY source-level debuggers can be included to enhance the usefulness.

An advantage of the present invention is that it provides accurate trace and disassembly of a target processor's program executions.

Another advantage of the present invention is that real-time trace data is reliably collected at target processor speeds that exceed 33 MHz.

Another advantage of the present invention is that the umbilical cable to the target system is a single continuous flexible circuit and is able to maintain good transmission line characteristics throughout.

These and other objects and advantages of the present invention will no doubt become obvious to those of ordinary skill in the art after having read the following detailed description of the embodiments which are illustrated in the various drawing figures.

IN THE DRAWINGS

FIG. 1 is a block diagram of an in-circuit emulator (ICE), according to a first embodiment of the present invention;

FIG. 2 is a perspective view of the ICE of FIG. 1;

FIGS. 3A-3C are front, side, and rear views, respectively, of the ICE of FIG. 1;

FIGS. 4A and 4B are socket side and pin side views, respectively, of the cable and pod the ICE of FIG. 1;

FIG. 5 is a side view of a typical PGA plug stack formed at the end the of cable of FIGS. 4A and 4B in preparation for connection to a user's target system;

FIG. 6 is a block diagram of the pod interface within the main system enclosure of the ICE of FIG. 1;

FIG. 7 is a flowchart of the interrelationships among various operational modes the ICE of FIG. 1;

FIG. 8A is a schematic of a digital phase locked loop (DPLL) used in the pod of the ICE of FIG. 1. FIG. 8B is a block diagram of the DPLL chip of FIG. 8A;

FIG. 9 is a block diagram of a second embodiment of the present invention which is an add-on system ICE that expands the emulation capabilities of the ICE of FIG. 1;

FIG. 10 is a typical screen presented on the PC/AT to a user by the ICE of FIGS. 1 and 9 during a trace and debug session of a target system; and

FIG. 11 is a block diagram of a two stage range reduction circuit that incorporates a first level of SRAMs that have their data outputs connected to the address inputs of the second level of SRAMs.

DETAILED DESCRIPTION THE PREFERRED EMBODIMENTS

I. First Embodiment of the Present Invention

In FIGS. 1 and 2, a first embodiment of the present invention is an in-circuit emulator (ICE) 10 comprised of two major components, a pod 12 connected by an interface microprocessor signal flex circuit cable 13 to a user target system 14 and to a main box 16 that houses the main electronics. The pod 12 is connected to the main box 16 and target 14 via a PCB flexible cable 18 and cable 13 which is the same continuous flex circuit cable shown in detail in FIGS. 4A and 4B.

FIGS. 3A-3C show the locations on main box 16 of a halt indicator 24, a power indicator 26, a trigger input (J12) 28, a trigger output (J13) 30, an external trace interface 32, an ICE cable interface (J2) 34, a PC/AT Expansion Interface (J7) 36, and an AC power connector 38.

There is no embedded CPU in the ICE 10 system itself. Instead, the ICE 10 is directly controlled by an IBM PC/AT 20 or compatible "clone" personal computer. Other computer platforms can also be used with equal results, for example the IBM RS-6000. Both a target CPU and PC/AT CPU are used for ICE 10 functions. The ICE 10 connects to the PC/AT 20 or compatible via a PC/AT interface 22.

In FIG. 4A, the pod 12 assembly is shown in a special construction needed to buffer signals at high speeds, while simultaneously minimizing target system loading. At the clock speeds involved, data setup and hold times are exceedingly short and time windows for capturing data are difficult to meet. Propagation times through devices and the variability of those times within a single device and across several devices is a serious problem at the operational speeds of ICE 10. In loading the signal lines, the target system 14 microprocessor is as light as possible because the target system 14 design may be hypersensitive to such connections. Buffers are therefore required and each buffer introduces a device propagation delay and skews between signal lines will appear. Though these skews are hard enough to control when a single buffer chip is used, since there are typically 160 signals, or more, to buffer, at least twenty octal buffer chips will be needed. A large rigid printed circuit board is needed within pod 12 to hold such a number of chips and some alternative method of clocking trace registers is needed.

The microprocessor trace data and clocks of target system 14 cannot be used directly at high clock rates and so must be buffered. But, the typical buffered clock arrives too late to clock fast changing trace data into high speed trace registers and still meet the data hold times of commercially available devices.

Additionally, the fan-out loading effect on the clock trying to drive twenty or more register devices causes the clock to arrive even later in a cycle.

A function of pod 12 is to interface the rest of ICE 10 to the target system 14. Pod 12 buffers and registers all target system 14 signals and drives these signals up the cable to the main electronics. Pod 12 also has a separate 8-bit bidirectional ICE BUS 24 that allows ICE 10 to interpret and control a target microprocessor 26 (e.g., an Intel 80960CA, abbreviated i960 CA, "i959 CA" for the bond-out version) for debugging purposes.

In FIG. 5, cable 18 is sandwiched between target microprocessor 26, several protective spare PGA sockets, and target system 14 to connect signals 13 and ICE BUS 24 to pod 12.

A SYSTEM RESET signal driven by target system 14 is logically OR'ed with an ICE RESET signal from ICE 10. Target microprocessor 26 can therefore be reset either by the target system 14, or the ICE 10 hardware. ICE 10 can manipulate target microprocessor 26 into an ICE operational mode using this scheme. ICE 10 gates off any HOLD request signal into the target microprocessor 26 such that ICE 10 can disable the HOLD request, if necessary.

As shown in FIG. 6, the main box 16 of ICE 10 comprises the following major elements:

a BUS 24 control state machine 58;

a shadow memory 60 and associated circuits;

a trace memory 62 and associated circuits;

a PC/AT interface circuit 64;

an external discrete inputs circuit 66;

an expansion interface 68; and

a pod interface 70.

Pod Interfacing

Pod interface 70 has the following functions:

1) Pod interface 70 registers all the incoming signals from pod 12 with proper termination to achieve maximum data rate on the flex cable. It distributes these signals to other blocks of circuitry such as a trace buffer and a breakpoint detection circuit;

2) Pod interface 70 also contains a separate BUS 24 interface. The BUS 24 interface allows ICE 10 main electronics to communicate with target microprocessor 26 during the emulation process; and

3) Pod interface 70 also includes the pod 12 control circuit, comprising:

a) Means to enable/disable any HOLD request into target microprocessor 26. This is necessary to support "multi-processor" type target architectures;

b) Means to supply pod 12 circuitry with a RESET signal and "Mode Selection" control information during an ICE 10 RESET period; and

c) Means to supply general control signals between the system box 16 and pod 12.

BUS 24 CONTROL STATE MACHINE

BUS 24 control state machine 58 and its associated circuitry allow ICE 10 to communicate with target microprocessor 26 via the BUS 24. The use of such a state machine alleviates any need to have an embedded CPU dedicated to supporting ICE 10
internal functions. State machine 58 has three different modes of operation: run mode 62, command mode 64, and mode 66.

During run mode 62, state machine 58 and associated circuitry perform the following functions:

1) Monitors the trace messages on the BUS 24. A break message from the BUS 24 indicates that target microprocessor 26 is entering the mode 66 due to internal hardware or software breakpoints or an asynchronous halt command.

2) Sends the asynchronous halt command to target microprocessor 26 in order to force it to the mode 66. The asynchronous halt command will be sent upon request from either the PC/AT 20 or from the external hardware breakpoint circuitry or the trigger input. ICE 10 includes external hardware breakpoints for discrete external inputs (interface 36).

During command mode 64, state machine 58 and associated circuitry are responsible for the following functions:

1) Assisting target microprocessor 26 in accessing the shadow memory 60 via LOAD and STORE commands; and

2) Monitoring the BUS 24 for a READY indication from target microprocessor 26. This condition indicates that the target microprocessor 26 has returned to mode 66.

During mode 66, state machine 58 and associated circuitry perform the following functions:

1) Assisting the PC/AT 20 processor in sending commands 71 to target microprocessor 26. Commands 71 are preassembled by PC/AT 20 into the shadow memory 60; and

2) Monitoring target microprocessor 26 responses to the commands 71. Some commands 71 require response from target microprocessor 26. The state machine 58 will perform loads and stores between shadow memory 60 and target microprocessor 26 as directed by PC/AT 20.

The state machine 58 (FIG. 6) and associated circuitry comprises the following sub-sections:

1) Address request counter 72;

2) BUS 24 byte transfer counter 74;

3) shadow memory address counter 76;

4) Control state machine 78;

5) Trigger control circuit 80; and

6) Position counter 82.

Address Request Counter

The address request counter 72, in state machine 58, generates an address request input into the state machine 58 during run mode 62.

BUS 24 Byte Transfer Counter

BUS 24 byte transfer counter 74, in state machine 58, keeps track of the number of bytes to be transferred on the BUS 24 during command/response transfers.

Shadow Memory Address Counter

Shadow memory address counter 76, in state machine 58, points to a shadow memory address location to be accessed. State machine 58 updates the counter to the next address after every transfer. This 16-bit counter is loaded either by PC/AT 20 or directly from BUS 24.

PC/AT 20 sets up the starting address of a command sequence by loading an initial value for this counter into a register. State machine 58 will, upon request by PC/AT 20, load this value into the address counter and then send the halt command by transferring the contents of the shadow memory 60 location pointed to by the address counter.

Control State Machine

A control state machine 58 is the heart of the BUS 24 interface. It has the task of monitoring several inputs and controlling several outputs to handle the BUS 24 interface task.

The inputs to state machine 58 are as follows:

1) reset input (1).sup.1 : hardware reset input from the PC/AT 20;

2) BUS 24 (8): monitoring BUS 24 activity.

3) READY (1): BUS 24 VALID indication from target microprocessor 26;

4) Byte Count TC (1): BUS 24 byte transfer counter 74 terminal count;

5) PC/AT 20 asynchronous halt request (1): The halt command will be sent to target microprocessor 26 forcing it to go to

6) PC/AT 20 asynchronous halt command (1): state machine 58 will send a halt command sequence upon receiving this command. The halt command should previously have been assembled by the PC/AT 20 into shadow memory 60;

7) PC/AT 20 asynchronous halt type (1): PC/AT 20 indicates the TYPE of halt command to be sent to target microprocessor 26; and

8) external hardware breakpoint request (1): state machine 58 forces target microprocessor 26 into mode 66 upon receiving this request from the external hardware breakpoint circuit.

The outputs from state machine 58 are as follows:

1) reset output (1) hardware reset output to target microprocessor 26;

2) MESSAGES (1): BUS 24 message to target microprocessor 26;

3) BUS 24 (8): driving the BUS 24 commands.

4) trace ON/OFF (1): enable or disable the trace buffer;

5) address counter reload (1): state machine 58 reloads the address request counter 72 upon receiving an address on the BUS 24 during run mode 62;

6) BUS 24 byte counter control (1): state machine 58 decrements the byte counter after every DATA byte is transferred between the BUS 24 and shadow memory 60;

8) shadow memory 60 control: state machine 58 must control the shadow memory 60 and related circuitry during all operations;

9) PC/AT 20 Status: PC/AT 20 needs various status signals from state machine 58; and

10) target microprocessor 26 ICE mode status (2) state machine 58 indicates to the external ICE 10 circuitry target microprocessor 26 ICE mode. These are: reset mode, run mode 62, and mode 66.

Trigger Control Circuit

Trigger control circuit 80 has the following functions:

1) Enable/Disable the trigger out from ICE 10;

2) Enable/Disable trace buffer data capture; and

3) Enable/Disable qualifier inputs for matchword detection.

Position Counter

This 16-bit counter allows the trigger point to be positioned within the trace buffer. This counter is reset and loaded by the PC/AT 20 software.

Shadow Memory

Shadow memory 60 allows the external ICE to interface to the BUS 24. There are many uses of the shadow memory 60. In mode 66, the shadow memory 60 is used as a temporary storage buffer between the external ICE and target microprocessor 26. In command mode, the shadow memory 60 is used to store user programs. In ICE 10 design, the shadow memory 60, along with the PC/AT 20, assists in sending mode 66 commands. The shadow memory 60 section comprises the following subsections:

1) 64K bytes of high speed SRAM (55 ns SRAM);

2) A data multiplexing circuit to allow either the PC/AT 20 or the BUS 24 data bus to be connected to the shadow memory 60 data bus;

3) An address multiplexing circuit to allow either the PC/AT 20 address bus or the BUS 24 address generator to be connected to the memory address bus. The BUS 24 address generator is essentially a 16-bit loadable counter. This counter can be loaded by either the PC/AT 20 data bus or directly from the BUS 24. It points to the current shadow memory 60 byte to be transferred between the shadow memory 60 and target microprocessor 26; and

4) A control multiplexing circuit that generates control signals to the memory. This multiplexing circuit must again select between the PC/AT 20 and the BUS 24, depending on whether PC/AT 20 or the BUS 24 is accessing the memory.

Trace Memory and Associated Circuitry

The trace memory 62 can be divided into the following subsections:

1) A 8K/32K.times.160-bit wide high-speed SRAM (20 ns);

2) A data multiplexing circuit to allow either the PC/AT 20 data bus or target microprocessor 26 address, data, and control bus to be connected to the trace memory data bus;

3) An address multiplexing circuit to allow either the on-board trace address generator or the PC/AT 20 address to be connected to the trace memory 62 address bus. The PC/AT 20 can read the on-board trace address generator to determine the current position the trace buffer;

4) A control multiplexing circuit that generates control signals to the memory. This multiplexing circuit must select between the PC/AT 20 control bus and the trace control circuitry depending on whether PC/AT 20 or target microprocessor 26 is accessing the trace buffer; and

5) A trace memory 62 timing generator circuit to ensure proper timing for the trace memory 62 when being accessed by the either the PC/AT 20 or during the target system 14 CPU trace capture.

PC/AT Interface Circuit

PC/AT interface circuit 64 allows ICE 10 to be controlled from the PC/AT processor. Since there is no intelligence (CPU) in ICE 10, all software controlled functions are initiated by the PC/AT 20.

The PC/AT 20 interface circuit 34 can be divided into the following sections:

1) The PC/AT 20 bus buffer: This block of circuitry provides signal buffering for the address and control bus from the PC/AT 20 bus extender card. It also provides bidirectional drivers for the data bus;

2) A decoder circuit to decode a range of addresses on the I/O channel to be used by ICE 10. These decoded addresses shall be used as command/status register addresses. In addition, a page register is required for the ICE 10 memory mapping;

3) A set of command/status registers: The PC/AT 20 controls and monitors ICE 10 via these command/status registers; and

4) All ICE 10 memory is memory mapped into the 64K bytes of the PC/AT 20, starting typically at address D0000H, for example. Multiple pages of 64K bytes memory are required for all memory residing in the ICE 10. Each page register value determines a unique 64K bytes of ICE 10 memory that mapped into the PC/AT 20 64K bytes space.

External Discrete Circuit

The external discrete circuit 32 (FIG. 3B) is a user driven, 32-bit wide input to ICE 10. This input is synchronized with the target system 14 clock to store data in trace memory 62. The external circuit 32 allows the user to observe external events with respect to the target system 14 clock and the processor activity.

Expansion Interface

An expansion interface 68 allows future expansions of the ICE 10 system. ICE 10 hardware features are expandable by adding a second board (below). ICE 10 design therefore must provide many signals to the alternative board. The expansion interface 68 can be divided into four different subsections.

1) PC/AT 20 interface expansion;

2) external input expansion;

3) ICE 10 internal control expansion; and

4) Target system 14 interface expansion.

AT INTERFACE EXPANSION

PC/AT interface expansion carries buffered PC/AT 20 bus signals. The buffered PC/AT 20 bus comprises the AT address bus (16), data bus (16), control bus (6) and the paging register output (8). The PC/AT 20 interfaces to future ICE 10 hardware via this connector set.

External Input Expansion

The external discrete inputs are available for the external hardware breakpoint circuit circuitry via this interface. The external discrete inputs are registered in ICE 10 before being routed to the expansion connector.

ICE 10 Internal Control Expansion

This expansion interface is designed into ICE 10 hardware with the following consideration for board to board interconnection:

1) external circuit and hardware breakpoints;

2) trigger control and trace buffer;

3) alternative interfaces into the BUS 24 control state machine 58;

4) cycle tag and trace buffer;

5) hardware breakpoint and trace buffer; and

6) hardware breakpoint and state machine 58.

Target System Interface Expansion

This interface provides the (registered) target microprocessor 26 user bus to the ICE 10 expansion hardware. Advanced features such as code coverage, performance analysis, and histograms require the user target system 14 bus interface.

ICE 10 SYSTEM OVERVIEW

ICE 10 system is a PC/AT-based development system composed of hardware and software resources to form a development tool (ICE), and, for example, can be used for Intel RISC microprocessors. The following is an overview the system resources (hardware and software) and the interaction between them.

External Interface Signals

The external interface signals (connector 32, interface 66) between ICE 10 and other hardware components in the system comprise:

1) Target system 14 processor interface: the interface between pod 12 and the user target system 14;

2) pod 12 and the system box 16 interface: the interface between pod 12 and the ICE 10: the flex cable signals;

3) ICE 10 external Interfaces: external interfaces to and from the ICE 10 excluding pod 12 and the system box 16 interface which is described in a separate section. These external interfaces are:

a) the PC/AT 20 bus interface: using the PC/AT 20 interface card, this interface comprises one 40-pin connector;

b) discrete external inputs: this interface comprises two 40-pin connectors;

c) trigger input and output: SMB right angle connectors are used for the trigger input and output signals;

d) expansion interfaces: the expansion interfaces comprises the following:

AT expansion interface 68: one 64-pin connector;

external input expansion: one 64-pin connector;

ICE 10 internal controls: one 64-pin connector;

target system 14 expansion interface 68: four 64-pin connectors; and

spare future expansion: one 64-pin connectors; and

4) Power connector: one 4-pin MOLEX right angle connector.

Target System Processor Interface

An ICE 10 interfaces to the user system via the target system 14 target microprocessor 26 socket. Target microprocessor 26 is packaged in a 168-pin PGA.

The following exemplary table lists signal assignments for target microprocessor 26 (e.g., Intel i960 CA) having a 168-pin PGA socket.

______________________________________ SIGNAL PIN DIR DESCRIPTION ______________________________________ Data(0) E3 I/O Data bit 0 Data(1) C2 I/O Data bit 1 Data(2) D2 I/O Data bit 2 Data(3) C1 I/O Data bit 3 Data(4) E2 I/O Data bit 4 Data(5) D1 I/O Data bit 5 Data(6) F2 I/O Data bit 6 Data(7) E1 I/O Data bit 7 Data(8) F1 I/O Data bit 8 Data(9) G1 I/O Data bit 9 Data(10) H2 I/O Data bit 10 Data(11) H1 I/O Data bit 11 Data(12) J1 I/O Data bit 12 Data(13) K1 I/O Data bit 13 Data(14) L2 I/O Data bit 14 Data(15) L1 I/O Data bit 15 Data(16) M1 I/O Data bit 16 Data(17) N1 I/O Data bit 17 Data(18) N2 I/O Data bit 18 Data(19) P1 I/O Data bit 19 Data(20) P2 I/O Data bit 20 Data(21) Q1 I/O Data bit 21 Data(22) P3 I/O Data bit 22 Data(23) Q2 I/O Data bit 23 Data(24) R1 I/O Data bit 24 Data(25) S1 I/O Data bit 25 Data(26) Q3 I/O Data bit 26 Data(27) R2 I/O Data bit 27 Data(28) Q4 I/O Data bit 28 Data(29) S2 I/O Data bit 29 Data(30) Q5 I/O Data bit 30 Data(31) R3
I/O Data bit 31 Address(2) D16 O Address bit 2 Address(3) D17 O Address bit 3 Address(4) E16 O Address bit 4 Address(5) E17 O Address bit 5 Address(6) F17 O Address bit 6 Address(7) G16 O Address bit 7 Address(8) G17 O Address bit 8 Address(9) H17 O Address bit 9 Address(10) J17 O Address bit 10 Address(11) K17 O Address bit 11 Address(12) L17 O Address bit 12 Address(13) L16 O Address bit 13 Address(14) M17 O Address bit 14 Address(15) N17 O Address bit 15 Address(16) N16 O Address bit 16 Address(17) P17 O Address bit 17 Address(18) Q17 O Address bit 18 Address(19) P16 O Address bit 19 Address(20) P15 O Address bit 20 Address(21) P16 O Address bit 21 Address(22) R17 O Address bit 22 Address(23) R16 O Address bit 23 Address(24) Q15 O Address bit 24 Address(25) S17 O Address bit 25 Address(26) R15 O Address bit 26 Address(27) S16 O Address bit 27 Address(28) Q14 O Address bit 28 Address(29) R14 O Address bit 29 Address(30) Q13 O Address bit 30 Address(31) S15 O Address bit 31 BE0* R9 I Byte Enable 0 BE1* S7 I Byte Enable 1 BE2* S6 I Byte Enable 2 BE3* S5 I Byte Enable 3 W/R* S10 I WRITE/READ Control ADS* R6 O Address Strobe READY* S3 I READY to terminate a transf BTERM* R4 I Burst Terminate WAIT* S12 O WAIT by internal wait state BLAST* S8 O BURST LAST data transfer DT/R* S11 O Data Transmit/Receive DEN* S9 O Data Enable LOCK* S14 O BUS LOCK HOLD R5 I HOLD Request HOLDA S4 O HOLD Acknowledge BREQ R13 O BUS Request D/C* S13 O DATA or CODE DMA* R12 O DMA ACCESS SUP* Q12 O SUPERVISOR ACCESS RESET* A16 I PROCESSOR RESET FAIL* A2 O FAIL or READY STEST B2 I SELF TEST ONCE* C3 I ON CIRCUIT EMULATOR or ICEM CLKIN C13 I CLOCK INPUT CLKMODE C14 I CLOCK MODE PCLK1
B14 O Processor Output Clock 1 PCLK2 B13 O Processor Output Clock 2 DREQ0* B5 I DMA REQUEST 0 DREQ1* A6 I DMA REQUEST 1 DREQ2* B6 I DMA REQUEST 2 DREQ3* A7 I DMA REQUEST 3 DACK0* B8 O DMA Acknowledge 0 DACK1* A8 O DMA Acknowledge 1 DACK2* A9 O DMA Acknowledge 2 DACK3* A10 O DMA Acknowledge 3 EOP/TC0* A14 I/O End Of Process/Term. Cnt. EOP/TC1* A13 I/O End Of Process/Term. Cnt. EOP/TC2* A12 I/O End Of Process/Term. Cnt. EOP/TC3* A11 I/O End Of Process/Term. Cnt. NMI* D15 I Non Maskable Interrupt XINT0* B15 I Interrupt bit 0 XINT1* A15 I Interrupt bit 1 XINT2* A17 I Interrupt bit 2 XINT3* B16 I Interrupt bit 3 XINT4* C15 I Interrupt bit 4 XINT5* B17 I Interrupt bit 5 XINT6* C16 I Interrupt bit 6 XINT7* C17 I Interrupt bit 7 GND C7, C8, C9, C10 GND Reference C11, C12, F15, G3 GND Reference G15, H3, H15, J3 GND Reference J15, K3, K15, L3 GND Reference L15, M3, M15, Q7 GND Reference Q5, Q9, Q10, Q11 GND Reference VCC B7, B9, B10, B11 +5 V Power Supply B12, C6, E15, F3 +5
V Power Supply F16, G2, H16, J2 +5 V Power Supply J16, K2, K16, M2 +5 V Power Supply M16, N3, N15, Q6 +5 V Power Supply R7, R8, R10, R11 +5 V Power Supply ______________________________________

Note: Input and output in this table are with respect to target microprocessor 26.

Target Microprocessor BUS 24 Interface

BUS 24 is available on target microprocessors comprising "bond-out" chips. A user uses this bus to build in-circuit emulator (ICE) products. Suitable bond-out chips are available from various microprocessor manufacturers.

POD 12 and ICE 10 Interface

pod 12 interfaces to the ICE 10 main unit via a 209-pin PGA socket connector. The 209-pin PGA socket has the same dimension as the 168-pin socket except that it has one more row of pins. ICE 10 uses the additional row of pins to carry signals between the main electronics and pod 12 that are not apparent to the user.

FIG. 8A shows a means of generating a trace clock that slaves from the target system 14 clock over a range of frequencies and allows the trace clock to lead the system clock, effectively getting a negative delay. A Motorola MC88915 is used for the PLL function. The trace clock then will allow the trace registers enough setup time to latch the trace data while buffering the target system clock from these loads.

The pin assignment for target microprocessor 26 (168 PGA) is mapped into the 209 PGA socket interface for consistency. The pin assignment for the signals between pod 12 and ICE 10 main electronics for an Intel i960 CA example is listed below for reference. Other types of microprocessors will have different pinouts, of course.

______________________________________ SIGNAL PIN DIR DESCRIPTION ______________________________________ Data(0) E3 I Data bit 0 Data(1) C2 I Data bit 1 Data(2) D2 I Data bit 2 Data(3) C1 I Data bit 3 Data(4) E2 I Data bit 4 Data(5) D1 I Data bit 5 Data(6) F2 I Data bit 6 Data(7) E1 I Data bit 7 Data(8) F1 I Data bit 8 Data(9) G1 I Data bit 9 Data(10) H2 I Data bit 10 Data(11) H1 I Data bit 11 Data(12) J1 I Data bit 12 Data(13) K1 I Data bit 13 Data(14) L2 I Data bit 14 Data(15) L1 I Data bit 15 Data(16) M1 I Data bit 16 Data(17) N1 I Data bit 17 Data(18) N2 I Data bit 18 Data(19) P1 I Data bit 19 Data(20) P2 I Data bit 20 Data(21) Q1 I Data bit 21 Data(22) P3 I Data bit 22 Data(23) Q2 I Data bit 23 Data(24) R1
I Data bit 24 Data(25) S1 I Data bit 25 Data(26) Q3 I Data bit 26 Data(27) R2 I Data bit 27 Data(28) Q4 I Data bit 28 Data(29) S2 I Data bit 29 Data(30) Q5 I Data bit 30 Data(31) R3 I Data bit 31 Address(2) D16 I Address bit 2 Address(3) D17 I Address bit 3 Address(4) E16 I Address bit 4 Address(5) E17 I Address bit 5 Address(6) F17 I Address bit 6 Address(7) G16 I Address bit 7 Address(8) G17 I Address bit 8 Address(9) H17 I Address bit 9 Address(10) J17 I Address bit 10 Address(11) K17 I Address bit 11 Address(12) L17 I Address bit 12 Address(13) L16 I Address bit 13 Address(14) M17 I Address bit 14 Address(15) N17 I Address bit 15 Address(16) N16 I Address bit 16 Address(17) P17 I Address bit 17 Address(18) Q17 I Address bit 18 Address(19) P16 I Address bit 19 Address(20) P15 I Address bit 20 Address(21) P16 I Address bit 21 Address(22) R17 I Address bit 22 Address(23) R16 I Address bit 23 Address(24) Q15 I Address bit 24 Address(25) S17 I Address bit 25 Address(26) R15 I Address bit 26 Address(27) S16 I Address bit 27 Address(28) Q14 I Address bit 28 Address(29) R14 I Address bit 29 Address(30) Q13 I Address bit 30 Address(31) S15 I Address bit 31 BE0* R9 I Byte Enable 0 BE1* S7 I Byte Enable 1 BE2* S6 I Byte Enable 2 BE3* S5 I Byte Enable 3 W/R* S10 I WRITE/READ Control ADS* R6 I Address Strobe READY* S3 I READY to terminate a transfer BTERM* R4 I Burst Terminate WAIT* S12 I WAIT by internal wait state BLAST* S8 I BURST LAST data transfer DT/R* S11 I Data Transmit/Receive DEN* S9 I Data Enable LOCK* S14 I BUS LOCK HOLD R5 I HOLD Request HOLDA S4 I HOLD Acknowledge BREQ R13 (K14) I BUS Request D/C* S13 I DATA or CODE DMA* R12 I DMA ACCESS SUP* Q12 I SUPERVISOR ACCESS RESET* A16 I PROCESSOR RESET FAIL* A2 I FAIL or READY (IVLD*) STEST P5 I SELF TEST. Should be B2 ONCE* C3 I ON CIRCUIT (IMSG*) EMULATOR or ICEM CLKIN C13 I CLOCK INPUT CLKMODE C14 I CLOCK MODE PCLK2 F14 (B13) I Processor Clock 2 from (B13) DREQ0* B5 I DMA REQUEST 0 DREQ1* A6 I DMA REQUEST 1 DREQ2* B6 I DMA REQUEST 2 DREQ3* A7 I DMA REQUEST 3 DACK0* B8 I DMA Acknowledge 0 DACK1* A8 I DMA Acknowledge 1 DACK2* A9 I DMA Acknowledge 2 DACK3* A10 I DMA Acknowledge 3 EOP/TC0* A14 I End Of Process/Term. Cnt. EOP/TC1* A13 I End Of Process/Term. Cnt. EOP/TC2* A12 I End Of Process/Term. Cnt. EOP/TC3* A11 I End Of Process/Term. Cnt. NMI* D15 I Non Maskable Interrupt XINT0* B15 I Interrupt bit 0 XINT1* A15 I Interrupt bit 1 XINT2* A17 I Interrupt bit 2 XINT3* B16 I Interrupt bit 3 XINT4* C15 I Interrupt bit 4 XINT5* B17 I Interrupt bit 5 XINT6* C16 I Interrupt bit 6 XINT7* C17 I Interrupt bit 7 GND C7, C8, C9, C10 GND Reference C11, C12, F15, G3 GND Reference G15, H3, H15, J3 GND Reference J15, K3, K15, L3 GND Reference L15, M3, M15, Q7 GND Reference Q5, Q9, Q10, Q11 GND Reference VCC B7, B9, B10, B11 +5V Power Supply B12, C6, E15, F3 +5V Power Supply F16, G2, H16, J2 +5V Power Supply J16, K2, K16, M2 +5V Power Supply M16, N3, N15, Q6 +5V Power Supply R7, R8, R10, R11 +5V Power Supply ICEBUS0 D4 I/O BUS 24 Bit 0 ICEBUS1 D5 I/O BUS 24 Bit 1 ICEBUS2 D6 I/O BUS 24 Bit 2 ICEBUS3 D7 I/O BUS 24 Bit 3 ICEBUS4 D8 I/O BUS 24 Bit 4 ICEBUS5 D9 I/O BUS 24 Bit 5 ICEBUS6 D10 I/O BUS 24 Bit 6 ICEBUS7 D11 I/O BUS 24 Bit 7 ICEDIR D12 O BUS 24 DIR Control ICEEN D13 O BUS 24 Enable Control ICEMSG* F4 O BUS 24 Message From ICE 10 HRESET* D14 O RESET to ICE 10 HNLRESET* P4 I NLRESET from ICE 10 TGFAIL* P12 I TGFAIL READY* E4 I BUS 24 Valid from target .mu.P P10HOLD P10 I Processor HOLD P10RST* P11 I Processor RESET* HOLDEN E14 O Processor HOLD Enable EXFAIL* G14 O CP drives FAIL* signal BACKOFF B1 .about. NOT Documented by Intel SCNMOD* D3 .about. NOT Documented by Intel SPAREIN L4 I SPARE IN, Future expansion SPAREIN L14 I SPARE IN, Future expansion SPAREIN M14 I SPARE IN, Future expansion SPAREOUT N4 O SPARE OUT, Future expansion SPAREOUT N14 O SPARE OUT, Future expansion SPAREOUT M4 O SPARE OUT, Future expansion ______________________________________

Note: Input and output in this table are with respect to ICE 10.

The Discrete External Interface

A 32-bit discrete external circuit interfaces to ICE 10 via two 40-pin, dual-row connectors.

The first exemplary connector pin assignments are as follows:

______________________________________ SIGNAL PIN DIR DESCRIPTION ______________________________________ BE00 1 I External Input 00 BE01 3 I External Input 01 BE02 5 I External Input 02 BE03 7 I External Input 03 BE04 9 I External Input 04 BE05 11 I External Input 05 BE06 13 I External Input 06 BE07 15 I External Input 07 BE08 19 I External Input 08 BE09 21 I External Input 09 BE10 23 I External Input 10 BE11 25 I External Input 11 BE12 27 I External Input 12 BE13 29 I External Input 13 BE14 31 I External Input 14 BE15 33 I External Input 15 NC 17, 35 NO CONNECT JUMPER 37 to either GND or Vcc Vcc 2, 39 +5 V Power Supply GND All Even pins except pin 2 ______________________________________

The second exemplary connector pin assignments are as follows:

______________________________________ SIGNAL PIN DIR DESCRIPTION ______________________________________ BE16 1 I External Input 16 BE17 3 I External Input 17 BE18 5 I External Input 18 BE19 7 I External Input 19 BE20 9 I External Input 20 BE21 11 I External Input 21 BE22 13 I External Input 22 BE23 15 I External Input 23 BE24 19 I External Input 24 BE25 21 I External Input 25 BE26 23 1 External Input 26 BE27 25 I External Input 27 BE28 27 I External Input 28 BE29 29 I External Input 29 BE30 31 I External Input 30 BE31 33 I External Input 31 NC 17, 35 NO CONNECT JUMPER 37 to either GND or Vcc Vcc 2, 39 +5V Power Supply GND All Even pins except pin 2 ______________________________________

The PC/AT 20 Bus Interface

A PC/AT 20 bus interface comprises one 40-pin connector. Its pin assignment, in this example, is as follows:

______________________________________ SIGNAL PIN DIR DESCRIPTION ______________________________________ AD00 31 I/O ADDRESS & DATA 00 AD01 30 I/O ADDRESS & DATA 01 AD02 29 I/O ADDRESS & DATA 02 AD03 28 I/O ADDRESS & DATA 03 AD04 27 I/O ADDRESS & DATA 04 AD05 26 I/O ADDRESS & DATA 05 AD06 25 I/O ADDRESS & DATA 06 AD07 24 I/O ADDRESS & DATA 07 A08 2 I Address bit 08 A09 3 I Address bit 09 A10 4 I Address bit 10 A11 5 I Address bit 11 A12 6 I Address bit 12 A13 7 I Address bit 13 A14 8 I Address bit 14 A15 9 I Address bit 15 A16 10 I Address bit 16 A17 11 I Address bit 17 A18 12 I Address bit 18 A19 13 I Address bit 19 INTR* 14 O Interrupt to PC/AT 20 MILIOW* 16 I I/O WRITE MILMEMR* 18 I MEMORY READ MILMEMW* 20 I MEMORY WRITE MILIOR* 22 I I/O READ MILAEN 33 I AEN ALE 35 I Address Latch Enable GND 1, 15, 17, 19, 21, 23, 32, 34, 40 Vcc 36, 37, 38, 39. ______________________________________

The PC/AT 20 interface card Vcc should not be connected to ICE 10 Vcc.

Expansion Interface

An Expansion interface 68 comprises the following interconnections:

1) PC/AT 20 interface expansion;

2) external input expansion;

3) ICE 10 internal control expansion; and

4) target system 14 interface expansion.

PC/AT 20 Interface Expansion Interconnection

An interconnection allows the PC/AT 20 bus to access the second board. One 64-pin connector is used for this interface. An exemplary pin assignments are as follows:

______________________________________ SIGNAL PIN DIR DESCRIPTION ______________________________________ GND 1, 2 PD00 3 I/O DATA BUS 00 PD01 4 I/O DATA BUS 01 PD02 5 I/O DATA BUS 02 PD03 6 I/O DATA BUS 03 GND 7, 8 PD04 9 I/O DATA BUS 04 PD05 10 I/O DATA BUS 05 PD06 11 I/O DATA BUS 06 PD07 12 I/O DATA BUS 07 GND 13, 14 PR0 15 O Page register bit 0 PR1 16 O Page register bit 1 PR2 17 O Page register bit 2 PR3 18 O Page register bit 3 GND 19, 20 PR4 21 O Page register bit 4 PR5
22 O Page register bit 5 PR6 23 O Page register bit 6 PR7 24 O Page register bit 7 GND 25, 26 MEMR* 27 O Memory READ GND 28 MEMW* 29 O Memory WRITE GND 28 EXPSEL* 31 O ICE 10 SELECT GND 28 EINTR 33 I ICE 10 II INTERRUPT GND 34 CPA1510* 35 O Decode A15-A10 = 0 GND 36 PA00 37 O Address BUS 00 PA01 38 O Address BUS 01 PA02 39 O Address BUS 02 PA03 40 O Address BUS 03 GND 41, 42 PA04 43 O Address BUS 04 PA05 44 O Address BUS 05 PA06 45 O Address BUS 06 PA07 46 O Address BUS 07 GND
47, 48 PA08 49 O Address BUS 08 PA09 50 O Address BUS 09 PA10 51 O Address BUS 10 PA11 52 O Address BUS 11 GND 53, 54 PA12 55 O Address BUS 12 PA13 56 O Address BUS 13 PA14 57 O Address BUS 14 PA15 58 O Address BUS 15 GND 59, 60 PA16 55 O Address BUS 16 PA17 56 O Address BUS 17 PA18 57 O Address BUS 18 PA19 58 O Address BUS 19 ______________________________________

Note: Pin assignment for this interconnection can be changed depending on the type of board to board interconnection chosen.

The External Expansion Interconnection

An interconnection allows the ICE 10 hardware to interface to the discrete external inputs. Exemplary assignments are as follows:

______________________________________ SIGNAL PIN DIR DESCRIPTION ______________________________________ BEX00 1 O External Input 00 BEX01 3 O External Input 01 BEX02 5 O External Input 02 BEX03 7 O External Input 03 BEX04 9 O External Input
04 BEX05 11 O External Input 05 BEX06 13 O External Input 06 BEX07 15 O External Input 07 BEX08 17 O External Input 08 BEX09 19 O External Input 09 BEX0A 21 O External Input 10 BEX0B 23 O External Input 11 BEX0C 25 O External Input 12 BEX0D 27 O External Input 13 BEX0E 29 O External Input 14 BEX0F 31 O External Input 15 BEX10 33 O External Input 16 BEX11 35 O External Input 17 BEX12 37 O External Input 18 BEX13 39 O External Input 19 BEX14 41 O External Input 20 BEX15 43 O External Input
21 BEX16 45 O External Input 22 BEX17 47 O External Input 23 BEX18 49 O External Input 24 BEX19 51 O External Input 25 BEX1A 53 O External Input 26 BEX1B 55 O External Input 27 BEX1C 57 O External Input 28 BEX1D 59 O External Input 29 BEX1E 61 O External Input 30 BEX1F 63 O External Input 31 GND All Even pins are GROUND. ______________________________________

ICE 10 Internal Control Expansion Interconnection

An interconnection allows ICE 10 hardware to communicate with future add-on hardware for internal control purpose. A 64-pin connector is assigned for this interconnection. Its exemplary pin assignments are as follows:

______________________________________ SIGNAL PIN DIR DESCRIPTION ______________________________________ RICEDIR 1 I Expansion IB Direction RICEN* 3 I Expansion IB Enable RICE7 5 I/O Expansion RAW IB 7 RICE6 7 I/O Expansion RAW IB 6 RICE5 9
I/O Expansion RAW IB 5 RICE4 11 I/O Expansion RAW IB 4 RICE3 13 I/O Expansion RAW IB 3 RICE2 15 I/O Expansion RAW IB 2 RICE1 17 I/O Expansion RAW IB l RICE0 19 I/O Expansion RAW IB 0 STCTL* 21 I Store Control Enable FHWBP* 23 I Future HW BP SPARE
25-63 All odd pins between 25-63. GND ALL EVEN PINS ______________________________________

The Target System 14 Interface Expansion Interconnection

An interconnection allows the second board to monitor the target system 14 signals to perform advanced ICE features. Four 60-pin connectors are assigned for this purpose.

First Connector for Target System 14 Expansion

A first exemplary connector pin assignment for the target system 14 interface expansion interconnection is as follows:

______________________________________ SIGNAL PIN DIR DESCRIPTION ______________________________________ Data(0) 1 O Data bit 0 Data(1) 3 O Data bit 1 Data(2) 5 O Data bit 2 Data(3) 7 O Data bit 3 Data(4) 9 O Data bit 4 Data(5) 11 O Data bit 5 Data(6) 13 O Data bit 6 Data(7) 15 O Data bit 7 Data(8) 17 O Data bit 8 Data(9) 19 O Data bit 9 Data(10) 21 O Data bit 10 Data(11) 23 O Data bit 11 Data(12) 25 O Data bit 12 Data(13) 27 O Data bit 13 Data(14) 29 O Data bit 14 Data(15) 31
O Data bit 15 Data(16) 33 O Data bit 16 Data(17) 35 O Data bit 17 Data(18) 37 O Data bit 18 Data(19) 39 O Data bit 19 Data(20) 41 O Data bit 20 Data(21) 43 O Data bit 21 Data(22) 45 O Data bit 22 Data(23) 47 O Data bit 23 Data(24) 49 O Data bit
24 Data(25) 51 O Data bit 25 Data(26) 53 O Data bit 26 Data(27) 55 O Data bit 27 Data(28) 57 O Data bit 28 Data(29) 59 O Data bit 29 Data(30) 61 O Data bit 30 Data(31) 63 O Data bit 31 GND ALL EVEN PINS ______________________________________

Second Connector for Target System 14 Expansion

A second exemplary connector pin assignment for the target system 14 interface expansion interconnection is as follows:

______________________________________ SIGNAL PIN DIR DESCRIPTION ______________________________________ Address(2) 5 O Address bit 2 Address(3) 7 O Address bit 3 Address(4) 9 O Address bit 4 Address(5) 11 O Address bit 5 Address(6) 13
O Address bit 6 Address(7) 15 O Address bit 7 Address(8) 17 O Address bit 8 Address(9) 19 O Address bit 9 Address(10) 21 O Address bit 10 Address(11) 23 O Address bit 11 Address(12) 25 O Address bit 12 Address(13) 27 O Address bit 13 Address(14) 29 O Address bit 14 Address(15) 31 O Address bit 15 Address(16) 33 O Address bit 16 Address(17) 35 O Address bit 17 Address(18) 37 O Address bit 18 Address(19) 39 O Address bit 19 Address(20) 41 O Address bit 20 Address(21) 43
O Address bit 21 Address(22) 45 O Address bit 22 Address(23) 47 O Address bit 23 Address(24) 49 O Address bit 24 Address(25) 51 O Address bit 25 Address(26) 53 O Address bit 26 Address(27) 55 O Address bit 27 Address(28) 57 O Address bit 28 Address(29) 59 O Address bit 29 Address(30) 61 O Address bit 30 Address(31) 63 O Address bit 31 GND ALL EVEN PINS ______________________________________

Third Connector for Target System Expansion

A third exemplary connector pin assignment for the target system 14 interface expansion interconnection is as follows:

______________________________________ SIGNAL PIN DIR DESCRIPTION ______________________________________ BTHOLD 1 O HOLD Request BTW/R* 3 O WRITE/READ Control BTDEN* 5 O Data Enable BTBLAST* 7 O BURST LAST data transfer BTADS* 9 O Address Strobe BTRDY* 11 O READY to terminate a transfer BTHOLDA 13 O HOLD Acknowledge BTBRDY* 15 O 960CA BREADY BTDACK0* 17 O DMA Acknowledge 0 BTDACK1* 19 O DMA Acknowledge 1 BTDACK2* 21 O DMA Acknowledge 2 BTDACK3* 23 O DMA Acknowledge 3 BTDREQ0* 25 O DMA REQUEST 0 BTDREQ1* 27 O DMA REQUEST 1 BTDREQ2* 29 O DMA REQUEST 2 BTDREQ3* 31 O DMA REQUEST 3 EOP/TC0* 33 O End Of Process/Term. Cnt. EOP/TC1* 35 O End Of Process/Term. Cnt. EOP/TC2* 37 O End Of Process/Term. Cnt. EOP/TC3* 39 O End Of Process/Term. Cnt. BTBE0* 41 O Byte Enable 0 BTBE1* 43 O Byte Enable 1 BTBE2* 45 O Byte Enable 2 BTBE3* 47 O Byte Enable 3 BTINT0* 49 O Interrupt bit 0 BTINT1* 51 O Interrupt bit 1 BTINT2* 53 O Interrupt bit 2 BTINT3* 55 O Interrupt bit 3 BTINT4* 57 O Interrupt bit 4 BTINT5* 59 O Interrupt bit 5 BTINT6* 61 O Interrupt bit 6 BTINT7* 63 O Interrupt bit 7 GND ALL EVEN PINS ______________________________________

Fourth Connector for Target System Expansion

A fourth exemplary connector pin assignment for the target system 14 interface expansion interconnection is as follows:

______________________________________ SIGNAL PIN DIR DESCRIPTION ______________________________________ ICEBUS0 1 O BUS 24 Bit 0 ICEBUS1 3 O BUS 24 Bit 1 ICEBUS2 5 O BUS 24 Bit 2 ICEBUS3 7 O BUS 24 Bit 3 ICEBUS4 9 O BUS 24 Bit 4 ICEBUS5 11
O BUS 24 Bit 5 ICEBUS6 13 O BUS 24 Bit 6 ICEBUS7 15 O BUS 24 Bit 7 BMSGVLD* 17 O ICE Message Valid BAMARK* 19 O Address Valid ICEMSG* 21 O ICE Message (or ONCE*) READY* 23 O ICE Valid (or FAIL*) ICEADS* 25 O ICE Address Strobe (Overlay ?) SPARE
27 SPARE 29 BTBREQ 31 O BUS Request BTP10RST* 33 O Processor Reset Pin BTRESET* 35 O Target system 14 Reset BTP10HOLD 37 O Processor HOLD Pin BTFAIL* 39 O FAIL BTBACKOFF 41 O Processor BACKOFF Pin BTCLKMODE 43 O CLOCK MODE BTSCNMOD* 45 O SCAN MODE BTNMI* 47 O Non Maskable Interrupt BTLOCK* 49 O BUS LOCK BTD/C* 51 O DATA or CODE BTSUP* 53 O SUPERVISOR ACCESS BTDMA* 55 O DMA ACCESS BTWAIT* 57 O WAIT by internal wait state BTDT/R* 59 O Data Transmit/Receive SPARE 61 TCLKxx 63 O Processor Target system 14 Clock GND ALL EVEN PINS ______________________________________

Note:

1) Input and output in this table are with respect to ICE 10.

Power Connections

The power supply connection is made via a 4-pin right angle MOLEX connector. Exemplary pin assignments are as follows:

______________________________________ SIGNAL PIN DESCRIPTION ______________________________________ Vcc 1, 4 +5V Power Supply GND 2, 3 GND Reference ______________________________________

Overall, ICE 10 is preferably non-intrusive to the processor/target system 14 interface, with the only exception being the RESET line. Microprocessor 26 can be reset via ICE 10.

ICE 10 Software

System administration of ICE 10 is provided by a monitor program (a low level control interface 21) that loads on the PC/AT 20. The low level control interface 21 initializes all hardware devices, manages internal memories, organizes commands to be sent to the target system 14, and provides an easy to use command language for a user interface.

Execution Control

An execution control process loaded on the PC/AT 20 lets the target system 14 designer start, stop, and single-step to verify program circuit execution via the parallel interface to main unit 12. The execution control sets both software and hardware breakpoints for halting target system 14 execution, and allows resumed execution after hitting a breakpoint. Programs can be stepped one instruction at a time (single-stepping), or a group of instructions at a time. ICE 10 provides both hardware and software breakpoints with up to sixteen software breakpoints and nine hardware breakpoints that can be user-defined.

Software breakpoints are implemented by inserting an fmark instruction in the source code at the desired breakpoint location. When clearing, the breakpoint location is replaced with original data. There are four different types of hardware breakpoints: address, data, range, and special. ICE 10 provides two address breakpoints, two data breakpoints, one range breakpoint, and four 10 special breakpoints that can be set to break on branch, call, return, and supervisor instructions. Another control command, TP, allows the trace position count to be set in the range of zero to 65,535, thereby allowing execution to continue "n" number of cycles after a break condition has been recognized.

Trace Buffer

A trace buffer facility captures the most recent 8K events in a circular memory. Each event, representing a snapshot of bus activity during a single clock cycle, is arbitrarily numbered relative to the current event and is stored in real-time in a ring buffer while the target system 14 microprocessor continues executing the target system 14 program. Circuitry using a phase-locked loop (PLL) to recreate a system clock timed to be conducive to the hold times of the ring buffer registers is required for real-time operation as is described in herein. By using all the control information supplied by the target system 14 microprocessor and special emulator software, ICE 10 is able to provide a full reconstruction of the execution stream for target system 14 microprocessor programs. In particular, ICE 10 reconstructs programs executing from the on-board cache memory in the target system 14 microprocessor.

Bus trace data is displayed in three formats:

1. a reconstructed instruction trace (TR);

2. processor bus and controls trace (TD); and

3. user-defined external bits (TE).

Due to on-chip cache memory in some target microprocessors 26, code executed inside does not appear on the pins. This makes capturing and displaying a code trace via conventional means impossible. To solve this dilemma, a special bond-out interface is added to a RISC type microprocessor that provides a deterministic address stream. Address stream information must, at a minimum, show the instruction pointer any time the processor advances to a new non-sequential address. With a discontinuous address trace, it is possible to reconstruct the original path of execution. By starting at the earliest valid address in a trace buffer, a reconstruction process reads the instruction from target memory. This instruction is then disassembled and displayed, along with its corresponding address. At the same time, the number of words required are determined and that number is added to the instruction pointer. This new pointer then indicates that next instruction to be disassembled and the process is repeated. In the event a call, return, branch or interrupt occurs, a special flag or command must be issued over BUS 24, indicating that a discontinuous change to the address pointer has occurred and volunteering the value of the new destination address. The new instruction points to the new region of code to be executed. This new pointer is now used to read and display the next executed instruction and the process proceeds from there.

Trace screens (FIG. 10) can be scrolled forward or backward. Hooks are provided in the cross-compiler output file so as to allow ICE 10 to relate the disassembled trace data back to each respective line of source code that produced the machine code. Specifically, branch data supplied on a special bus of a bond-out chip substituted for the target system 14 microprocessor, for example, together with the target system 14 microprocessor's system interface signals, provides visibility behind any on-board cache to reconstruct actual program flow (and not the cache queue sequence). The raw data collected in the trace buffer is disassembled, any symbolic labels are attached, and the trace is presented on the screen of the PC/AT 20 to a user in assembler mnemonic format in one port of a split window display. As the user scrolls back and forth through the assembler mnemonic format listing the trace, another port in the split window presents a segment of the original high level source code, for example "C" code, and highlights the particular source code line that produced the particular disassembled machine code step under study. The advantage is the displayed representation of the target system 14 machine trace is more comprehensible and productivity is improved.

In-line Assembler/Disassembler

A built-in assembler/disassembler contained in ICE 10 software applications allows target system 14 memory to be examined and changes made by using instruction mnemonics rather than by insisting on the use of hexadecimal values. Preferably, the mnemonics used are the same as those publicly distributed by the manufacturer of the particular target system 14 microprocessor. This greatly minimizes the effort required by a user to alter the contents of the instruction memory. The lexical conventions and statement syntax are identical to a target system 14 microprocessor's instruction set, so there is no need for a user to learn alternative formats.

Hardware Debug Support

ICE 10 has means to address the so-called micro-debug stage of development. This stage is when a non-functioning target system 14 is being brought to life and various board-level options are being implemented and validated. These micro-debug control features allow the designer to test the target system 14 hardware memory, to find opens and shorts, and to verify proper microprocessor/register communication. With these features the designer begins to debug the target system 14, step-by-step, using the resources of ICE 10 when target system 14 resources are not yet functional. The micro-debug control features are:

memory test (Z3);

register test (Z4);

read loop diagnostic (Z0);

write loop diagnostic (Z1I);

write/read loop Diagnostic (Z2);

circuit analyzer interface (trigger I/O); and

32 user-defined external signals.

Trigger In/Out

ICE 10 provides a trigger in/out capability with two synchronization signals such that oscilloscopes, multiple ICE 10 units, or circuit analyzers can trigger relative to one another. Assuming a trigger is asynchronous to a target system 14
clock, the time between the trigger-in and trigger-out is one target system 14 clock cycle.

User-Defined External Signals

ICE 10 has 32 user-defined external bits that are captured into the trace buffer and tied into a hardware breakpoint. Any external signals are correlated to program execution and monitored through a trace facility, giving a cycle-by-cycle view of external status.

Low Level Control Interface 21

The low level control interface 21 allows several options to be performed from the command line. By invoking the low level control interface 21 at the PC/AT 20 keyboard, initialization of the target system 14 processor occurs. Initialization routines and data may be sourced from the target system 14 memory or from the PC/AT 20 memory. Refer to Intel i960 CA Users Manual Chapters 2 and 14 for further information regarding initialization requirements. In cases where the target system 14
memory system is not yet fully operational, an initial boot record (IBR) and an initial memory image (IMI) may be supplied by ICE 10. The IBR and IMI can be particularly troublesome for a user to generate, especially when encountering a microprocessor like the Intel i960 CA for the first time. The IBR and IMI will typically be stored in a target system PROM and has to be correctly implemented before any other user code will be entered. ICE 10 allows a model IMI/IBR to be substituted in during reset to get the target processor 26 bootstrapped up and executing program instructions. (IMI/IBR supplies basic parameters to, for example, an i960 CA that setup various registers, parameters, operational modes, and key memory addresses.)

In the default mode, the low level control interface 21 searches for a particular file, e.g., ICE 10.env. If the file is found, the reset and initialization are performed according to entry RESET TYPE (default is target system 14). If ICE
10.env has an entry RESET TYPE=ICE, ICE 10 will read the contents of the file for initialization. If the RESET TYPE=TARGET SYSTEM 14, the remaining entries will be ignored and the reset will be performed by the target system 14. A HA[LT] command is used to begin the debugging session.

The following parameters are preferably included in the low level interface means:

-e: The "e" parameter allows a user to specify an environment file name of choice, e.g., "init. 960". Once a filename has been specified with the "e" parameter, it will be the file used for all subsequent resets until another file is specified;

-i: Invoking low level control interface 21 with the "i" parameter causes ICE 10 to perform the initialization. A user must create a file which will describe the target system 14 hardware specifics for the initialization process;

-t: Invoking low level control interface 21 with a "t" parameter, the default, causes normal target system 14 memory initialization. A HA[LT] command begins a debugging session;

-rn: This option tells low level control interface 21 that an Ethernet connection should be attempted according to the config.tel file; and

-s: Invoking low level control interface 21 with the "s" parameter allows the user to specify a submit file which can execute a series of ICE 10 commands including RESET, HALT, DOWNLOAD, etc. This is very useful for automating the power-up sequence and for particular user preferred setups and configurations. A submit file can also be called from the command line or through the environment file.

External Trace Signals

ICE 10 allows the user to trace thirty-two (32) synchronous external signals by connecting them to an interface 32 (FIG. 2B).

Trigger In/Out

By providing a trigger signal, ICE 10 can trigger or be triggered by a circuit analyzer, and to trigger other units for tracing in a multi-processor system. The trigger signal is preferably TTL compatible, always enabled, and active high. When trigger in occurs, it takes one target system 14 clock cycle for the trigger out to become true.

A trigger in/out cable is connected to a SMB (small gold) connector to ICE 10 and the other end with a BNC connector to a circuit analyzer.

A hardware or software breakpoint is used to cause the trigger-out facility to halt the circuit analyzer or other ICE 10 units. By using the external trigger or the spare bits, for example, on the circuit analyzer, a trigger-in facility is used to halt ICE 10. The procedure necessary to implement a trigger-in facility depends on the type of circuit analyzer being used.

Source Level Debugger

Summary

A source level debugger 22 for the target system 14 microprocessor allows a user to do high-level and assembly level debugging with ICE 10. By providing complete control over the flow of execution, the user can isolate errors in the program easily. Program execution is controlled by setting breakpoints and single-stepping in either high-level or assembly level modes.

Free Software Foundation distributes GDB, which is a stand alone debugger that will run under the UNIX operating system. GDB can be used as a starting point in implementing source level debugger 22. The source code for GDB is converted to a format compatible with a Microsoft "C" compiler running under DOS. Certain standard functions used in the program are altered such that they call their equivalents in Microsoft "C" To obtain a communications interface with WINDOWS 3.0, the altered source code is linked to be a dynamic linked library (DLL). The GDB DLL retains its command line interface and does not allow WINDOWS applications to directly link to its modules. Thus the debugger retains its essential quality of being a standalone executable module, but it also is one which has provisions for communicating with other WINDOWS applications via ASCII strings in a manner parallel to its original operation.

The source level debugger 22 has five basic functions:

1. start of the program, specifying anything that might affect its behavior;

2. make the program stop on specified conditions;

3. examine what has happened when the program has stopped, such that a user can debug the code;

4. change things in the program, so a user can correct the effects of one bug and go on to learn about another without having to re-compile first; and

5. interface to and execute ICE 10 emulator commands.

The source level debugger 22 software loads on the PC/AT 20 or host system and preferably presents a user with a friendly, high-level interface to the target system 14. This computer-implemented process also communicates through a parallel interface to target system 14 microprocessor.

Invoking the Source Level Debugger

The source level debugger 22 is preferably invoked with DOS command line or a UNIX shell command. Once started, it reads commands from a terminal until a user tells it to exit. The source level debugger 22 usurps a dedicated PC software interrupt and is used to query a terminate and stay resident (TSR) program. The debugger 22 has a run-time library version of low level control interface 21, and has monitor level information. This interrupt defaults to "47", and it may be changed by specifying an alternative interrupt value when invoking source level debugger 22.

When source level debugger 22 starts up, it automatically executes "init" files on the host system. The source level debugger 22 reads and executes the init file (if any) in the home directory and then the init file (if any) in the current working directory. If an init file exists in both directories, then they are both executed. The init files are not executed if the -nx option has been given. Command files may also be called with the source command.

Input Conventions

Source level debugger 22 commands are input on a single line. There is preferably no limit on how long a command can be. Each line starts with a command name, and is followed by arguments that depend on the command type. A few commands do not require argument values.

The source level debugger 22 command names may alternatively be abbreviated if the abbreviation is not ambiguous. But sometimes even ambiguous abbreviations can be tolerated. For example, s is specially defined as equivalent to step, even though there are other commands whose names start with s. Possible command abbreviations should be stated in the user instructions for individual commands.

A blank line as input to the source level debugger 22 is used as a command to repeat the previous command. Certain commands do not allow such repeating. These are commands for which an unintentional repetition might cause trouble and for which a user is unlikely to want repetition. Certain others (e.g., list and x) permutate when being repeated.

Lines of input starting with "#" are comments, and do nothing more than document a file. This is useful mainly in command files. The source level debugger 22 prompts for commands with a cursor prompt.

set-prompt<string>: directs source level debugger 22 to use <string> as its prompt henceforth;

system <command>: directs source level debugger 22 to execute a command. If <command> is not given, a push to DOS will occur and the DOS prompt will appear on the command line. Type "exit" to return to the source level debugger 22; and

exmon <command>: directs source level debugger 22 to send a command to ICE 10 monitor and displays the result.

To exit the source level debugger 22, use the quit command (abbreviated q). Entering a Ctrl-C will terminate any currently executing source level debugger 22 command and return control to the command line prompt.

Specifying Files

The source level debugger 22 needs to input the filename of the program to be debugged. Various commands are associated with specifying source level debugger 22 files, as follows:

Specifying Files With Arguments--The usual way to specify the executable file name is with an argument given when a user starts the source level debugger 22. The first argument is the file for execution and symbols; and

Specifying Files with Commands--A user specifies the files for the source level debugger 22 to work with by inputting arguments when a user invokes the source level debugger 22. But occasionally, it is necessary to change files during a source level debugger 22 session. A user may alternatively run the source level debugger 22 and neglect to specify the files to use. In these situations, the source level debugger 22 commands to specify alternative files are useful.

The following commands are acceptable as input:

exec-file <filename>: Specifies that the program to be run is <filename>. If a user does not specify a directory and the file is not found in the source level debugger's working directory, the source level debugger 22 will use the environment variable PATH as a list of directories to search.

symbol-file <filename>: Reads symbol table information from file <filename>. PATH is searched when necessary. Most of the time a user will use both the exec-file and symbol-file commands on the same file. Symbol-file with no argument clears out the source level debugger's symbol table.

add-file <filename> <address>: When performing incremental linking, the symbol table of an incrementally linked file may be included in the link step, but the source level debugger 22 needs to be told where that the symbol table is in the address space. By issuing this command, it is possible to symbolically debug programs which make use of incremental loading in a completely natural fashion. GNU/960 may not support this option, so the implementer will need to check this point; and

info files: Prints the names the executable file currently in use by The source level debugger 22, and the file from which symbols were loaded.

While all file specifying commands allow both absolute and relative file names as arguments, the source level debugger 22 preferably always converts the file name to an absolute one and records the path name.

The symbol-file command causes the source level debugger 22 to discard the contents of its convenience variables, the value history, and all breakpoints and auto-display expressions. This is because they may contain pointers to the internal data recording symbols and data types, which are part the old symbol table data being discarded inside source level debugger 22.

Using the Source Level Debugger

When a user invokes the source level debugger 22, information can be passed concerning the files and type of operation. The following describes the various options a user has while typing on the source level debugger 22 command line.

Mode Options

-i: specifies the PC/AT 20 software interrupt;

-nx: do-not-execute-commands from within the initialization file gdbinit. Normally, the commands in these files are executed after all the command options and arguments have been processed;

-q: "quiet," inhibits the usual introductory messages; and

-batch: run in batch mode. Batch mode will exit with code "1" after processing all the command files specified with -x (and gdbinit, if not inhibited, see -nx). It will also exit if, due to an error, the source level debugger 22 would otherwise attempt to read a command from the terminal.

File-Specifying Options

All the options and command line arguments given are processed in sequential order. The order makes a difference when, for example, the -x command is used.

-s <file>: Read symbol table from file <file>.

-e <file>: Use file <file> as the executable file (program).

-se <file>: Read symbol table from file <file> and use it as the executable file.

-x <file>: Execute The source level debugger 22 commands from file <file>.

-d <directory>: Add <directory> to the path to search for source files.

Breakpoints

A breakpoint makes the program stop whenever a certain point in the program is reached. A user sets breakpoints explicitly with the source level debugger 22 commands, specifying the place where the program should stop by line number, function name or exact address in the program. A user can add various other conditions to control whether or not the program will stop.

Each breakpoint is assigned a number when it is created. These numbers are successive integers starting with "1". In many of the commands, the breakpoint number is used to communicate which breakpoint a user wants to change. Each breakpoint may be enabled or disabled. If disabled, the breakpoint will not effect the program. Breakpoints may be deleted by specifying their number or may be cleared from a section of code.

info break <bnums>: The command info break prints a list of all breakpoints showing their numbers, where in the program they are, and any special features associated with each. Disabled breakpoints are included in the list, but marked as disabled. Info break with a breakpoint number as argument lists only that breakpoint. The convenience variable "$" and the default examining-address for the x command are set to the address of the last breakpoint listed.

Setting Breakpoints

The source level debugger 22 allows a user to set any number of breakpoints (which can be hardware or software breakpoints) all at the same place in the program, or at different places. The command set follows:

break: Sets a breakpoint at the next instruction to be executed in the selected stack frame. The program will stop immediately if the break is invoked inside the innermost stack frame. If the break is invoked in any other stack frame, the program will halt as soon as control returns to that frame. This command is abbreviated b;

break <function>: Sets a breakpoint at entry to function <function>;

break <linenum>: Sets a breakpoint at line <linenum> in the current source file. The breakpoint will stop the program before it executes the specified line;

break <filename >:<linenum>: Set a breakpoint at line <linenum> in source file <filename>;

break <filename>:<function>: Set a breakpoint at entry to function <function> found in file <filename>. Specifying a filename as well as a function name is superfluous except when multiple files contain similarly named functions;

break *<address>: Set a breakpoint at address <address>. A user can use this to set breakpoints at absolute addresses where line numbers are not known;

break . . . if <cond>: Set a breakpoint with condition <cond>; evaluate the expression <cond> each time the breakpoint is reached, and stop only if the value is nonzero. ". . . " represents one of the possible arguments described above (or no argument) specifying where to break; and

tbreak <args>: Set a breakpoint enabled only for one stop. <Args> are the same as in the asynchronous halt command, and the breakpoint is set in the same way however, the breakpoint is automatically disabled the first time it is hit.

Clearing Breakpoints

It is often necessary to eliminate a breakpoint when a user no longer wants the program to halt. This is called "clearing" or "deleting" the breakpoint. Breakpoints that have been cleared or deleted no longer exist.

With a "clear" command, a user can clear breakpoints according to where they are in the program. With a "delete" command a user can clear individual breakpoints by specifying their breakpoint numbers. It is not necessary to clear or delete a breakpoint to proceed past it. Once a breakpoint has occurred, the source level debugger 22 will automatically proceed normally; it will not halt at the same breakpoint.

clear: clears any breakpoints at the next instruction to be executed in the selected stack frame. When the innermost frame is selected, this is a good way to clear a breakpoint that halted the program;

clear <function>: clears any breakpoints set at entry to the function <function>;

clear <filename>: <function>: clears any breakpoints set at entry to the function <function> with the source file <filename>;

clear <linenum>: clears any breakpoints set at or within the code the specified line <linenum>;

clear <filename>: <linenum>: clears any breakpoints set at the specified line <linenum> in the source file <filename>; and

delete <bnums . . . >: deletes the breakpoints the numbers specified as <bnums>.

Disabling Breakpoints

Rather than permanently clearing a breakpoint, a user might prefer to just temporarily disable it. This disables the breakpoint as if it had been cleared, but stores the information on the breakpoint such that a user may easily retrieve and re-enable it later.

A user disables and enables breakpoints with the enable and disable commands, by specifying one or more breakpoint numbers as arguments. Command info break is used to print a list of breakpoints when a user does not know which breakpoint numbers are available.

A breakpoint can be in any one of four different states:

Enabled. The breakpoint will stop the program. A breakpoint made with the asynchronous halt command starts out in this state;

Disabled. The breakpoint has no effect on the program;

Enabled once. The breakpoint will stop the program, but when it does so it will become disabled. A breakpoint made with the tasynchronous halt command starts out in this state; and

Enabled-for-deletion. The breakpoint will stop the program, but immediately after it does so the breakpoint is deleted.

The commands associated with breakpoint use are as follows:

disable <bnums . . . >: Disable the specified breakpoints. A disabled breakpoint has no effect, but is not forgotten;

enable <bnums . . . >: Enable the specified breakpoints;

enable once <bnums . . . >: Enable the specified breakpoints temporarily. Each breakpoint is disabled after finding a first match; and

enable delete <bnums . . . >: Enable the specified breakpoints to match once and then delete automatically.

Break Conditions

The simplest kind of breakpoint interrupts every time a target system 14 program's execution address matches a specified location. A user can also specify a conditional for a breakpoint. A conditional is a Boolean expression as used in standard programming language. A breakpoint with a conditional first looks for a match address and then looks to see if the target system 14 data and/or address satisfies the conditional, the program stops only if both are true (found matches).

Break conditions are specified when a breakpoint is set, by using it in the arguments to the asynchronous halt command. They can also be changed at any time with the condition command.

condition <bnum> <expression>: specify <expression> as the break condition for breakpoint number <bnum>. From now on, this breakpoint will stop the program only if the value of <expression> is true (nonzero, in C). <expression> is not evaluated at the time the condition command is given; and

condition <bnum>: remove the condition from breakpoint number <bnum>. It then becomes an ordinary unconditional breakpoint.

Ignore is a special kind of conditional. It disables a breakpoint for n number of times. The "ignore <count>" command is entered by a user. When a target system 14 program reaches a breakpoint with a positive ignore count, the count is decremented by one and tracing continues. But when the count reaches zero, the breakpoint takes effect and interrupts tracing.

ignore<bnum><count>: sets the ignore count of breakpoint number <bnum> to <count>. The next <count> times the breakpoint is reached, it will not stop. To make the breakpoint stop the next time it is reached, specify a count of zero; and

cont <count>: continues execution of the program, setting the ignore count the breakpoint that the program stopped at to <count> minus one. Continuing through the breakpoint does not itself count as one of <count>. Thus, the program will not stop at this breakpoint until the hit has repeated <count> number of times. This command is allowed only when the program stopped due to a breakpoint. At other times, the argument cont is ignored.

If a breakpoint has a positive ignore count and a condition, the condition need not be checked. Once the ignore count reaches zero, the condition is tested. A user could duplicate the effect of the ignore count with a condition such as "$foo-0" using a debugger convenience variable that is decremented each time.

Commands Executed on Breaking

A user can give any breakpoint a series of commands to execute when the program stops due to that breakpoint. For example, a user might want to print the values of certain expressions, or enable other breakpoints.

commands<bnum>: Specifies commands for breakpoint number <bnum>. The commands themselves appear on the following lines. A line containing haying the word end will terminate all commands.

It is possible for breakpoint commands to be able to restart the target's program with the cont, step, or any other command that resumes target system 14 execution. However, any breakpoints specified after the program resumes are ignored.

If the first command specified is silent, a message about stopping at a breakpoint is not printed. This may be desirable for breakpoints that are to print a specific message and then continue. If the remaining commands print nothing, a user will see no sign that the breakpoint was reached at all. The silent command is used only in conjunction with the commands command.

The commands echo and output allow a user to print precisely controlled output are useful in silent breakpoints. For example, a user could use breakpoint commands to print the value of x at the entry to foo whenever it is positive. Assuming that the newly created breakpoint is number 4; break will print the number that is assigned.

break foo if x>0

commands 4

silent

echo x is040

output x

echo n

cont

end

One use for the breakpoint commands is in correcting a known bug such that a user can test for more bugs. First, a breakpoint is inserted just after an erroneous line of code, a condition is given to detect the case in which something erroneous has been done, and a list of the commands is made to assign correct values to any variables that need them. Finally, the cont command ends such that the program does not stop, and starts with the silent command such that no output is produced. For example:

break -3

commands 5

silent

set x=y+4

cont

end

Continuing

cont: Continue running the program at the place where it stopped.

If a target system 14 program stops at a breakpoint, it will resume execution beginning at the breakpoint address. The "cont" command allows a target system 14 program to pass through the involved breakpoint. An ignore-count for the breakpoint may be added to the cont command.

Stepping

Stepping allows a target system 14 program to execute one line of code or one machine instruction per step. Breakpoints are active during stepping and a target system 14 program will stop for them even if it has not jumped as far ahead as the stepping command prescribes.

step: proceeds with execution of a target system 14 program until control reaches a different line, then stop and return to the debugger. This command is abbreviated s;

step <count> : proceeds as in step, but does so <count> times;

next similar to step, but any function calls appearing within the line of code are executed without stopping. Execution stops when control reaches a different line of code at the stack level which was executing when the next command was given. This command is abbreviated n;

next <count>: proceeds as in next, but does so <count> times;

finish: continues running until just after the selected stack frame returns or a breakpoint occurs;

stepi: proceeds one machine instruction, then stop and return to the debugger. It is often useful to do display/i $ip when stepping by machine instructions. This will cause the next instruction to be executed to be displayed automatically at each stop. This command is abbreviated si;

stepi <count>: proceeds as in stepi, but does so <count> times;

nexti: proceed one machine instruction; if it is a subroutine call, proceed until the subroutine returns. This command is abbreviated ni; and

nexti <count>: proceeds as in nexti, but does so <count> times.

Examining Stack Frame

After stopping with a breakpoint or a halt, a user needs to know the target machine's path of execution, such as calls, returns, etc. Each time a target system 14 program performs a function call, the information about where in a target system 14
program the call was made from is saved in a block of data called a stack frame. The stack frame also contains the arguments for the program calls and any local variables for the function called. All stack frames are allocated to a region of memory called a procedure stack. When a target system 14 program halts, the source level debugger 22 allows a user to examine the stack to inspect the register sets and pointers.

There are preferably included commands to select a single frame of interest. Many of the source level debugger 22 commands refer implicitly to a selected frame. In particular, whenever a user commands the source level debugger 22 to supply the value of a variable in a target system 14 program, the value is determined from the selected frame. When the target system 14 program stops, the source level debugger 22 automatically selects the innermost frame and the currently executing frame and outputs a brief description.

Frames

The procedure stack is divided into contiguous pieces called frames. Each frame is the data associated with one call to one function. The frame contains the arguments given to the function, the function s local variables, and the address at which the function is executing.

When a target system 14 program is started, the stack has only one function mainframe. This is called the initial frame or the outermost frame. Each time a function is called, a alternative frame is made. Each time a function returns, the frame for that function invocation is eliminated. If a function is recursive, there many frames for the same function. The frame for the function in in which execution is actually occurring is called the innermost frame. This is the most recently created of all the stack frames that still exist.

Inside a target system 14 program, stack frames are identified by their addresses. This address is kept in a register called the frame pointer.

The source level debugger 22 assigns numbers to all stack frames, starting with zero for the innermost frame, one for the frame that called it, and so on upward.

Backtrace

A backtrace is a summary of program execution. If more than one call occurs, multiple frame information will be shown on one line per frame starting with the currently executing frame (frame zero), followed by its caller (frame one), and on up the stack.

backtrace: prints a backtrace of the entire stack: one line per frame for all frames in the stack. This command is abbreviated bt; and

backtrace <n>: Same as backtrace, but stops after <n> frames. This command is abbreviated bt <n>.

Each line in a backtrace shows the frame number, a target system 14 program counter, the function and its arguments, and the source file name and line number (if known).

Selecting a Frame

Most commands for examining the stack and other data in a target system 14 program work on the selected stack frame.

frame <n>: Selects frame number <n>. Remember that frame zero is the innermost currently executing frame, frame one is the inner most, and so on. The highest-numbered frame is main's frame;

frame <addr>: Selects the frame at address <addr>. This may be used when the chaining of stack frames has been damaged by a bug, making it impossible for the source level debugger 22 to assign numbers properly to all frames. This can also be useful when a target system 14 program has multiple stacks and options between them;

up<n>: Selects a frame <n> number of frames up from the selected frame. For positive numbers <n>, this advances toward the outermost frame (e.g., higher frame numbers). <N> defaults to one; and

down <n>: Selects a frame <n> number of frames down from the selected frame. For positive numbers <n>, this advances toward the innermost frame (e.g., lower frame numbers). <N> defaults to one.

All of these commands end by printing information from the selected frame, e.g., the frame number, the function name, the arguments, the source file and line number, and the source line text. For example:

#3 main (argc=3, argv=??,env=??) at main.c,line 67

67 read,inputfiIe (argv[i]);

After such a printout, the list command with no arguments will print ten lines centered on the point of execution in the frame.

Information on a Frame

There are several other commands to print information about the selected stack frame.

frame: prints a brief description the selected stack frame. It is abbreviated f. With an argument, this command is used to select a stack frame; with no argument, it does not change which frame is selected, but still prints the information.

info frame: prints a verbose description of three frames centered on the selected stack frame, the frame addresses, the address of the frame's arguments, the program counter, and the registers.

info frame <addr>: prints a description the frame at address <addr>, without selecting that frame. The selected frame remains unchanged by this command.

info args: prints the arguments the selected frame, each on a separate line.

info locals: prints the local variables the selected frame, each on a separate line. These are all variables declared within a target system 14 program executed from this frame.

Examining Source Files

When target system 14 program stops, the source level debugger 22 prints the line where it halted. Likewise, when a user selects a stack frame, the source level debugger 22 prints the line where execution is halted. A user can also print parts of source files using explicit commands.

Printing Source Lines

The list command (abbreviated "1") prints lines from a source file. There are several ways to specify what part of the file a user wants to print.

Repeating a list command with RETURN discards the argument, so it is equivalent to typing in list. An exception is made for an argument of-, that argument is preserved in repetition such that each repetition moves up in the file.

list: prints ten lines. If the last lines printed were with a list command, ten more sequential lines are printed; however, if the last line printed was a single line from some other command, list will print ten lines centered around that line;

list <linenum1> <linenum2>: prints ten lines centered around line number <linenum1> in the current source file. When the list command has two linenums, it display the specified range. If <linenum1> equals <linenum2>, only the specified line will be printed;

list <function>: prints ten lines centered around the beginning of function <function>;

list <filename>:<linenum>: specifies line linenum> in the source file <filename>;

list <filename>:<function>: prints ten lines centered around the beginning the function <function> in the file <filename>. The is needed with a function name only for ambiguity resolution of identically named functions in different source files.

list -: prints ten lines just before the lines last printed;

list <first >,<last>: prints lines from <first> to <last>. Both arguments are linespecs.

list,<last>: Prints ten lines ending with <last>;

list <first>,: prints ten lines starting with <first>;

list+<offset>: prints ten lines just after the lines last printed. Specifies the offset down from the first line;

list<offset>: <offset>as a second parameter prints ten lines just before the lines last printed. <offset> as a second parameter specifies the offset up from the last line;

list * <address>: specifies the line containing a target system 14 program address <address>. <Address> may be any expression; and

info line <linenum>: prints the starting and ending addresses the compiled code for source line <linenum>.

Searching Source Files

There are two commands for searching through the current source file for a regular expression:

forward-search <regexp>: Checks each line, searching forward, for a match of regexp. Lines with matches found are listed. A user can abbreviate the command with fo.

reverse-search <regexp>: Checks each line, searching backward, for a match of regexp. Lines with matches found are listed. A user can abbreviate this command with rev.

Specifying Source Directories

The source level debugger 22 records a list of directories to search for source files, and is called a source path. Each time the source level debugger 22 wants a source file, it tries all the directories in the path, in the order they exist in the path, until a file with the desired name is found.

When a user starts the source level debugger 22, the source path contains only the current working directory. To add other directories, the directory command is used, as follows:

directory: resets the source path to the current working directory the source level debugger 22. This requires confirmation. Directory with no argument can cause source files previously found by The source level debugger 22 to be found in a different directory. This command also clears out the tables the source level debugger 22 maintains about the source files it has already found;

directory <dirname>: adds directory <dirname> to the end the source path; and

info directories: prints the source path and reports the directories it has stored.

Because the directory command adds to the end of the source path, it does not affect any file that the source level debugger 22 has already found. If the source path contains unwanted directories the procedure below is used to rearrange the directory path.

1. Choose the directory a user want at the beginning the source path.

2. Use the cd command to make that the current working directory.

3. Use directory with no argument to reset the source path to that directory.

4. Use directory with suitable arguments to add additional directories to the path.

Examining Data

The usual way of examining data in a target system 14 program is with the print command. It evaluates and prints the value of any valid "C" expression. Refer to the x command for examining raw data.

print<exp>: Where <exp> is any valid expression, and the value of <exp> is printed in a format appropriate to its data type. This command is abbreviated p.

Expressions

Many different source level debugger 22 commands will accept an expression and compute values. Any kind of constant, variable or operator defined by "C" is a legal expression in the source level debugger 22. This includes conditional expressions, function calls, casts and string constants.

In addition to supporting operators normally found in "C", the source level debugger 22 also supports some "C++" constructs. For example, one can call member functions (the source level debugger 22 automatically uses this when necessary), then examine and manipulate pointers to members, and set pointers to member functions (virtual or otherwise).

Source level debugger 22 supports three kinds of operators in addition to those of "C":

@ : "@" is a binary operator for treating parts of memory as arrays.

:: : "::" Allows a user to specify a variable in terms the file or function it is defined in. It also supports the "C++" convention of qualifying a variable reference according to a type name (or the global scope). For example, this makes it easy to examining static class variables.

<type> <addr>: Refers to an object of type <type> stored at address <addr> in memory. <Addr> may be any expression whose value is an integer or pointer (but parentheses are required around non-unary operators, just as in a case). This construct is allowed regardless of what kind of data actually resides at <addr>.

Program Variables

Variables in expressions are understood in the selected stack frame. Variables must either be global, static, or visible, according to the "C" scope rules. This means that in the following function:

foo (a);

int a;

bar (a);

{

int b=test ();

bar (b);

}

}

The variable "a" is visible whenever a target system 14 program is executing within the function foo, but the variable "b" is visible only while a target system 14 program is executing inside the block in which b is declared.

Artificial Arrays

An array, a section of an array, or an array having a dynamically determined size for which only a pointer exists in a target system 14 program may be displayed. An "artificial array" is constructed with binary operator @. The left operand of @ should be the first element the desired array. The right side operand should be the length the array. The result is an array value whose elements are all the type specified by the left side argument. For example, if a program says

"int *array=(int*) malloc (len *sizeof (int))";

a user can print the contents of array with,

"p *array@len".

The left operand of @ must reside in memory. Array values made with @ in this way act like other arrays, in terms of subscripting, and are coerced to pointers when used in expressions.

Formats

The source level debugger 22 prints all values according to their data types. However, a user might want to print numbers in hex, a pointer in decimal, or view data in memory at a certain address as a character string or an instruction. The arguments the print command start with a slash and a format letter. The format letters supported are listed below.

x: regard the bits the value as an integer, and prints the integer in hexadecimal.

d: prints as integer in signed decimal.

u: prints as integer in unsigned decimal.

o: prints as integer in octal.

a: prints as an address, both absolute in hex and relative to a symbol.

c: regard as an integer and prints it as a character constant.

f: regard the bits the value as a floating point number and prints using floating point syntax.

For example, to print the instruction pointer in hex the user would type:

p/x $ip. Note that no space is required before the slash.

To reprint the last value in the value history with a different format, a user can use the prints command with a format type and no expression. For example, p/x reprints the last value in hex.

Examining Memory

The x command is used to examine memory without reference to a program's data types. X examines data in memory at a specified address, and prints it in the specified format.

Command x can be followed by a slash and an output format specification, and by an address. The address need not have a pointer value.

The output format specifies both how big a unit of memory to examine and how to print the contents of that unit.

The default examine address for the x command is changed to the starting address of the line, such that x/i is sufficient to begin examining machine code. Also, this address is saved as the value the convenience variable $.sub.--.

These letters specify just the size of unit to examine:

b: Examine individual bytes;

h: Examine halfwords (two bytes each);

w: Examine words (four bytes each); and

g: Examine giant words (8 bytes).

These letters specify the format in which to print the contents:

x: Prints integers in unsigned hexadecimal;

d: Prints integers in signed decimal;

u: Prints integers in unsigned decimal;

o: Prints integers in unsigned octal;

a: Prints an address, both absolute in hex and relative to a symbol;

c: Prints character constants;

f: Prints floating point. This works only with unit sizes w and g;

s: Prints a null-terminated string of characters. The specified unit size is ignored Instead, the unit is however many bytes it takes to reach a null character (inclusive); and

i: Prints a machine instruction. The specified unit size is ignored. The number of bytes in an instruction varies depending on the type of machine, the o