Will an external bus interface of the target microcontroller be supported?

From the point of view of the CPU, the external memory can be accessed similarly to the internal memory. Any wait states during the access to the external memory will delay the CPU clock generated by the clock control unit. This delayed CPU clock will also be transferred to the CPU emulation. Since there is only one clock, both CPUs run synchronously, even if the CPU clock is delayed, slowed down etc. In case of a read operation, the CPU emulation gets the same data as the microcontroller’s CPU. In case of a write operation, the microcontroller CPU writes to the local periphery or to the external bus. The CPU emulation writes to a “dummy” address; the write operation is only required to record a complete set of trace data.

Last update on 2016-02-07 by Administrator.

Which bandwidth should the hidICE port have?

The bandwidth which has to be provided by the hidICE port depends on

  • the CPU instruction set
  • hidICE FIFO size
  • acceptable delay of the emulation
  • implementation of the hidICE RAM emulation

The following table shows at which instruction types data must be output for the trace data record.

Information which has to be output from the target microcontroller to achieve a full set of trace data (frequency based on Patterson / Hennessy, Computer Organization and Design , Edition 3, 2005, pp. 315)

In general, the hidICE port bandwidth can be estimated as follows:

DR = f * LIO * BIO / CPI

DR Microcontroller-to-emulator data transmission ratef Processor frequency

LIO Percentage of load instructions

BIO Average transmitted bits (data and control)

CPI Min. cycles per load instruction

The following examples provide a frame of reference for required bandwidths:


16-bit microcontroller, 60 MHz:DR = 60 MHz * 5% * 17-bit / 2 = ~3.2 Mbps

32-bit microcontroller, 200 MHz: DR = 200 MHz * 5% * 34-bit / 1 = ~42.5 Mbps

To get a full set of trace information, the hidICE port requires only ~10% of the bandwidth required by an embedded trace module.

Last update on 2016-02-07 by Administrator.

Would it be possible to use bond-out chips for the CPU emulation?

Of course, instead of a CPU emulation by an FPGA or an ASIC, the hidICE emulator may contain a bond-out chip. In this case, the bond-out chip may only contain the CPU and, in case of RAM emulation, the DMA controller.

Last update on 2016-02-07 by Administrator.

Would it be possible to support complex breakpoints (e.g. conditional expressions, counts, memory access)?

Of course, complex breakpoints can be supported by hidICE. If the emulation is running without a delay, the emulator may stop the microcontroller just in time.

Should the hidICE emulation run with a delay (this delay may help to lower the required bandwidth of the hidICE port), the breakpoint stops the program execution with the same delay (similar to common embedded trace modules). Alternatively, the hidICE emulator may hold the microcontroller CPU program execution to evaluate the condition of the breakpoint. If the break condition is fulfilled, the emulator can stop the microcontroller’s CPU at the correct code address. Even on-chip debug support may be implemented in the microcontroller. When a breakpoint is reached, the hidICE emulator gets the information about the breakpoint interrupt.

Last update on 2016-02-07 by Administrator.

How is the microcontroller connected to the hidICE emulator?

The connection between microcontroller and hidICE emulator may be implemented via an LVDS system. A serializer (FPGA) may be soldered into the plug. The deserialization can be handled inside the hidICE emulator by the same FPGA which emulates the CPU.

The wire between the microcontroller and the hidICE emulator may have a length of up to 10 meters; the cable diameter may be about 5mm. With this cable and a small-size plug including the complete serializer, it would be possible to debug a microcontroller in difficult-to-access devices (e.g. motor control unit in a driving car).

Last update on 2016-02-07 by Administrator.

Will external interrupts be supported? What happens if external interrupts occur asynchronously to the microcontroller’s internal timing?

Of course, external interrupts will be supported.

However, the external interrupt controller is not emulated by the hidICE emulator. External interrupts (similar to any timer events, etc.) are handled only by the microcontroller’s external interrupt control unit (EICU).

If an external interrupt occurs, the corresponding interrupt will be applied to the microcontroller’s CPU. This interrupt is submitted via the hidICE port to the hidICE CPU emulation in parallel. If the microcontroller needs to read some control registers of the EICU, the data read from these registers is also transferred to the hidICE CPU emulation. As a consequence, both CPUs get the same interrupts and read the same data, and the hidICE CPU emulation is able to provide the correct trace data.

Last update on 2016-02-07 by Administrator.

Will the DMA transfer be supported?

Yes, the DMA controller can also be emulated. It is possible to set data breakpoints which are triggered by DMA events, too. In addition, all DMA activities can be traced.

Last update on 2016-02-07 by Administrator.

What happens during memory access wait states?

Since the hidICE CPU emulation is operated by the same clock as the microcontroller’s CPU, any wait states or delays of the microcontroller’s CPU have the same effect on the hidICE CPU emulation. For instance, if a delayed access to external memory holds the microcontroller’s CPU, the hidICE CPU emulation is similarly delayed due to the identical clock.

Last update on 2016-02-07 by Administrator.

clock. Is it possible, to slow down the microcontroller CPU clock or to put the microcontroller in sleep mode? Are different clock sources supported?

The hidICE CPU emulation is clocked by the same clock as the microcontroller’s CPU. In case of any changes in the microcontroller’s CPU clock rate (e.g. operation-mode transition, oscillation start-up, changing of the clock source), the emulation gets the same physical clock as the microcontroller – with both CPUs are running synchronously.

Last update on 2016-02-07 by Administrator.

“No loss of pins for the trace port, even during recording of trace data” - Is it really true?

The idea behind this feature is to emulate the pins used as hidICE port and the connected periphery with the hidICE emulator. In this case the pins should be implemented as outputs, e.g. for LED driver, LCD driver or PPG outputs. If the microcontroller is operated in debug mode, the hidICE port pins are used by the hidICE port. Inside the hidICE emulator the pins and the peripherals controlling the pins are emulated. Electrical signals can be transferred back to the target PCB using a flat ribbon cable (or, for longer distances, with a LVDS Serdes system).

If the microcontroller is operated in non-debug mode, the pins would be controlled directly by the microcontroller peripherals. From the application program’s point of view, all pins are accessible at any time.

Last update on 2016-02-07 by Administrator.

Is it really true that no microcontroller periphery has to be emulated in the hidICE emulator?

Yes, this is one of the big advantages of the hidICE system. The only job of the hidICE emulator is to provide trace data and to handle complex breakpoints. Data read by the microcontroller’s CPU will be transferred to the hidICE CPU emulation. Because of this, the hidICE CPU gets the same information as the microcontroller’s CPU – the emulation of periphery (ADC, CAN, UARTs…) in the hidICE emulator is unnecessary.

Two exceptions:

If the hidICE emulator should emulate the microcontroller’s RAM too, the DMA controller has to be emulated as well. When using the hidICE port as periphery output port, the periphery units, which control the I/O pins used as hidICE port, must also be emulated. The chip designer should use simple periphery (e.g. PPG, LED driver, LCD controller) which use the ports as outputs only.

Last update on 2016-02-07 by Administrator.