A hierarchical symbol database enables structured symbolic debugging.
Symbol names can be up to 255 significant characters long and can be
used to show single program addresses, module names and memory classes.
With 6 Mbyte of free memory (within the System Control Unit),
approximately 200000 symbols may be loaded. The disassembler can use
the symbols for labels and/or operands.
High-Level Language Debugging
The high-level debugger can support all common high-level languages
but includes special support for C and PASCAL in that it recognizes
and uses all data types. The screen display can be in assembler, high-level
or a mixture of the two. It is possible to construct both assembler
and high-level windows on the screen simultaneously. All variable types
specific to the high-level language can be displayed and modified.
Addresses can be absolute, relative or line number based.
A newly developed multitasking debugger is provided which allows up to
16 processes or independent programs to be run simultaneously.
Each task can be defined as a foreground or background task.
For systems that require certain aspects of their operation
to be maintained at all times (e.g. interrupts, timer operations etc),
the background programs can be executed so that these real-time dependencies
can be serviced. The foreground task is then debugged in the normal manner
but even when not executing the foreground task, the background programs
still operate in real-time.
The editor window can be synchronised to the debugging window so that
when an error is found, the source text can immediately be shown and
if required, edited. Also during debugging, it is possible to place markers
in the source text at appropriate points so that all corrections can be made
at the same time, but later. When the source text is re-opened, the system
will present each line marked for correction in sequence.
The on-screen assembler is provided in place of the more common line assembler
found on other systems. With the on-screen assembler, short programs can be
written quickly and reliably. It is a full assembler whose output code is
linkable in the usual way to the main body of the program.
Separate Emulation Control Processor
The emulator is controlled by a separate processor with approximately
1 MIPs performance. Functions such as task changing or memory refresh are
done independently of the main system controller or the emulation CPU.
2 Emulator Operating Modes
- Stand Alone Mode
The emulator operates without being connected to the target system. In this mode all emulator capabilities can be used to debug software.
- Active Mode
The emulator operates with the target system (with internal or external clock).
This mode provides the ability to test software and hardware using all the functions of TRACE32.
A step mode is provided whereby the emulator simply steps the CPU instruction
by instruction as fast as it can. In this mode, operating speed of the target
is reduced by a factor of approximately 100, but all register values are available
at each step.
Bus Structure for 64 Bit Emulation
The emulation bus is 64 bit wide in order to support future processors.
High Clock Frequency
Because of the compact, layered construction, bus lengths are kept to a minimum
and clock frequencies of 50MHz are possible for the support of fast 32 bit CPUs.
Memory Orientated Breakpoint System with up to 16 Mbyte Breakpoint Memory
Most currently available emulators use multiple address and data comparators to
form the breakpoint system. This technique not only restricts the number of breakpoints
available it also means that systems using bank selection are difficult to support.
The breakpoint, memory on the TRACE32 is basically a bytewide memory structure that
can be mapped in a similar way to the overlay memory. When any memory location is accessed,
the corresponding breakpoint byte is also accessed so that there are effectively
8 kinds of breakpoints for each addressable location.
8 Breakpoint Types
In each group there are up to 16 million breakpoints available depending upon the
amount of breakpoint ram fitted. Breakpoints can be specified as a single address
or an address range. Each breakpoint group can be made task specific so that for
example, they are only operative during foreground program execution on
- Program Breakpoint
- High-Level Breakpoint
- Spot Breakpoint
- Data Read Breakpoint
- Data Write Breakpoint
- General Purpose Point A
- General Purpose Point B
- General Purpose Point C
Hardware Support for High-Level Language Debugging
By using a specially reserved bit in the breakpoint memory, high-speed debugging
of systems using high-level languages is available.
Memory Test on Power up with Access Time Test
After turning on the system, an optional memory test can be performed on both
emulation and breakpoint memories.
Support for External Bank Switching (up to 256 banks)
External bank switching schemes or MMUs can be supported by the memory mapper.
For this there are separate probe inputs to the emulator. This option is only
sensible on CPUs with less than 16 Mbyte addressing range.
Support for EPROMs with Inbuilt Paging
EPROMs of the types 27513 or 27011 are supported without external logic.
The address area within the EPROM has to be defined by the user, so that
the emulator can support the device.
Support for Dynamic Memory in the Target System
In order to refresh target dynamic RAM when the emulation is stopped, a memory
refresh function is provided. The address range and memory class over which
the refresh occurs can be defined.
Selective Mapping of Memory Classes (Memory, I/O, User, Data etc.)
The address mapper can segment the memory into 4 segments. Using this segmentation,
it is possible for example to split the memory such that a USER area can be mapped
to the emulators ram whilst the SUPERVISORY area remains mapped as target memory.
It is also possible to have totally separate physical memory areas displayed
Memory Mapping in 4K Blocks and bytewise
The main mapping of memory is done in 4K blocks. However within two address
ranges 16K long mapping can also be performed down to a single byte resolution
(useful for I/O mapping).
Memory Mapping Functions
- Static emulation RAM
- Dynamic emulation RAM
- Static breakpoint RAM
- Dynamic breakpoint RAM
- Flag RAM
0 to 250 wait cycles can be specified within any particular address range.
Access Protection and Write Protection
Data access in specific address areas can be prevented. Using this feature
for example, it is possible to prevent an I/O access occurring at a specific
address (if bytewise mapping is operative).
Most Emulation Functions can be used whilst the target CPU is running ('on the fly' operation)
Dual-Ported Access to All Emulation Memory
The whole emulation memory system (emulation and breakpoint memory) in dual-ported.
This allows the emulator to read or write memory whilst the target system is running
in real-time e.g. to show variables, port contents etc. For low to medium speed CPU
clock frequencies (e.g. 12MHz 68000) there is no degradation in performance of the
target system due to the operation of the dual-port access mechanism. At higher CPU
clock frequencies, the performance may be slightly reduced in accordance with the
number of accesses made by the control system. The dual-port access mechanism can be
switched off, but if this is done, then memory access by the emulator can only
take place when the target system is stopped.
Maximum 16 Mbyte Emulation RAM and 16 Mbyte Breakpoint RAM
In order to store programs in the emulator during the development phase, the address
space of the emulator can be as high as 16 Mbyte. This memory can be implemented using
static or dynamic rams.
2 Mbyte Emulation and Breakpoint Memory in the ECU Module
In the ECU module, up to 2 Mbyte of memory may be fitted. This can be user defined
to be either emulation memory or breakpoint memory.
In a special memory, all addresses which are read or written are marked with read
or write flags. This memory therefore can supply a lot of important information:
- In the passive mode, the flag memory will show which memory locations contain valid information.
- Detection of uninitialised memory.
- Reading of uninitialised memory can be forced to generate an automatic break or to trigger the Trace Analyzer.
- Systematic Program test due to the fact that each executed module will be marked in the flag ram.
- Detection of unused or unexecuted code.
- Systematic system test through visible code coverage analysis.
- Detecting accesses to unused or illegal address locations.
External Trigger Inputs
8 external inputs are provided which can be used as even trigger sources.
- Each input signal can be specified as active HIGH, LOW or DON'T CARE.
- Synchronous triggering - clock source selectable from 5 sources.
- Indication of the current levels of the trigger lines (Trigger Monitor).
8 trigger/status outputs are provided. These outputs are mainly intended for triggering
or controlling certain functions within the target system. External Analyzers can be
triggered using the Trace Analyzer outputs.
- Emulator trigger output
- Emulator RUN signal
- Address signal from the breakpoint memory
- Trigger event signal
- Event counter input signal (source event selectable)
- Pulse generator output
- Reset output (hardware reset for target system)
- Trigger output for oscilloscope (address signal from breakpoint memory) on instrument backpanel (BNC)
Internal Frequency Generator
- Variable VCO with frequency range from 1 to 70 MHz
- No phase change when frequency changed - this can be used to test the limiting frequencies of the target system. Output available for direct connection to the target system (BNC)
- Emulation CPU clock frequency programming is done via the emulation control unit
Integrated Universal Counter
- Frequency 0 to 20MHz
- System clock 0 to 80MHz
- Pulse width 100ns to 300 days
- Positive or negative edge count
- 0 to 2.8E + 14
- Use for measuring of internal and external signals like cycle frequency, CPU clock frequency, interrupt frequency etc.
Inbuilt GLITCH Detector for all important CPU Signals
- Detection of glitches down to 5ns wide within a CPU cycle.
- Break on glitch detection.
- Data transfer rates
- Interrupt rates
- System performance
Slave StopMaster/Slave Synchronisation of several Emulators and Analyzers
Each of the following functions can be enabled or disabled individually:
In the slave mode the emulator follows whichever instrument is defined as the master.
In the master mode, the emulator controls all other emulators designated as slaves.
The synchronisation timing error between individual instruments is less 1ms.
- Master Start
- Master Stop
- Slave Start
- Slave Stop
Program runtime is recorded automatically.
- Time from initial start
300ns to 300 days
- Time from last breakpoint
100ns to 300 days
- Time difference between 3 refs
300ns to 300 days
- Timers can be interrogated at any time and their values displayed
Inbuilt Pulse Generator
- Pulse output 50 Ohm/ 5V
- Output level static HIGH, LOW, LOWPULSE or HIGHPULSE.
- Pulse width 100ns to 6.5ms
- Period 200ns to 500s
- Single shot mode via keypress, analyzer or periodically
Cycle time programmable from 10 us to 10s. Expiry of the timeout period can be made to generate an emulator break.
Clock Monitor for Target System
If the clock period becomes bigger 10us the system will alert the user. If programmed
to do so, the emulator can go into a standby mode if this occurs.
In each breakpoint group a PASS count can be specified.
Trigger Event Storage
Independently of any analyzer functions, the addresses or address range, status and
trigger source of each trigger event can be stored.
A trigger delay between the trigger event and the emulation break can be specified
in terms of time, a cycle count or trace cycle count.
The triggering can either stop the target CPU or only the analyzers data capture.
- Time delay 100ns to 300 days
- Cycles 0 to 2.8 E+14
- Trace cycles 0 to 2.8 E+14
Trigger Event Sources
- Exception break (e.g. RESET, NMI etc.)
- Bus timeout
- Synchronous external trigger event
- Asynchronous external trigger event
- Spike detection
- High-level breakpoint
- Normal breakpoint
- General purpose breakpoint A
- General purpose breakpoint B
- General purpose breakpoint C
- Data read breakpoint
- Data write breakpoint
- Data event (analyzer)
- Trigger inputs (analyzer)
Each of the above trigger events can be selected as the source for the event triggering.
The following trigger modes are possible:
N = 1 to 2.8E + 14, M = 1 to 65535, T = 100ns to 300 days
- Trigger direct
- Trigger after N cycle delay
- Trigger after T time delay
- Trigger after N events
- Event, then trigger after N cycles
- Event, then trigger after T time
- Trigger if after M bus cycles there is no event
- Trigger if after T time there is no event
Each of the general purpose address breakpoints A, B & C has an associated 48 bit counter. Using these it is possible for example to count the number of accesses to specific variables within an address range before a trigger is generated.
The status of all the trigger settings are visible within their own window and can be modified `on the fly`.
Static Memory Modules
- 128K emulation memory
- 128K breakpoint memory
- 128K flag memory
- 512K emulation memory
- 512K breakpoint memory
- 512K flag memory
- 2M emulation memory
- 2M breakpoint memory
- 2M flag memory