32 Bit Emulation Controller

The embedded tools company
Static Memory Modules
3. Probes

32 Bit Emulation Controller
Universal Emulation Controller
8 .. 32 Bit Support
Trigger System
Banking Support
Code Coverage
Universal Counter
Pulse Generator
The ECU32 is the universal emulation system for all ICE emulation probes.

The system includes the general emulator functions like mapper, trigger system and runtime control system. The banking system supports emulation up to 16 MByte with 256 bank. The universal mapper can support mirroring and splitting for every 4K area. 4 different memory classes with each 16 MByte are supplied by the mapper.

The trigger system enables simple trigger functions on address breakpoints, on events and external signals. An trigger output for external DSOs or logic analyzers is available.

Additional many support systems like universal counter, VCO, pulse generator and glitch detector allow easy emulation and bug detection in complex applications.

Download full document

Symbolic Debugging

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.

Real-Time Debugging

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.

Edit/Debug Link

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.

On-Screen Assembler

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.

Multi-Step Operation

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

  • 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
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 multitasking systems.

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 simultaneously.

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

Wait States

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.

Flag System

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).

Trigger Outputs

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:
  • Master Start
  • Master Stop
  • Slave Start
  • Slave Stop
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.

Runtime Analyzer

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

Bus Timeout

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.

Conditional Breakpoints

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.

Delayed Triggering

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.
  • Time delay 100ns to 300 days
  • Cycles 0 to 2.8 E+14
  • Trace cycles 0 to 2.8 E+14
The triggering can either stop the target CPU or only the analyzers data capture.

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)

Event Triggering

Each of the above trigger events can be selected as the source for the event triggering. The following trigger modes are possible:
  • 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
N = 1 to 2.8E + 14, M = 1 to 65535, T = 100ns to 300 days

Access Counter

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.

Trigger Monitor

The status of all the trigger settings are visible within their own window and can be modified `on the fly`.

Power Consumption

  • 9 W

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

3. Probes



Clip Set

Copyright © 2019 Lauterbach GmbH, Altlaufstr.40, 85635 Höhenkirchen-Siegertsbrunn, Germany   Impressum     Privacy Policy
The information presented is intended to give overview information only.
Changes and technical enhancements or modifications can be made without notice. Report Errors
Last generated/modified: 06-May-2019