Cosimulation

While instruction-level simulators are available for most microprocessor families (often provided as part of the vendor's development environment), very few simulators allow to include and simulate external components. That is, you can read and write data to your parallel and serial ports, and the simulator will react to interrupt requests - but external data is provided by stimuli files instead of an actual system model. Not surprisingly, bugs resulting from wrong assumptions about the environment are pretty common.

Naturally, high-quality simulation models are available commercially (VHDL/Verilog), but the costs are simply prohibitive. Therefore, we had to develop our own system-level simulation models for memories and peripheral components.

The processors

• PRIMA: As its name says, our primitive machine is a really simple 8-bit accumulator machine with a total of four registers, and the complete hardware easily fits on a single lecture slide. Used as a first example of the von-Neumann architecture and introductory machine- and assembly-programming.

• DCORE: 16-bit RISC-style demonstration processor. Used to teach processor hardware organization, microprogramming, and assembly programming in our "T3" lab-courses.

• MCS-4: System-level simulation of the Intel 4004 processor and its support chips, the first microprocessor in history. Unusual instruction set and memory architecture.

• PIC16C84 and PIC16F628: several example systems built around the PIC16-series microcontrollers from Arizona Microchip. Used to demonstrate system-simulation and a typical microcontroller architecture with separate program and data memories and direct access to peripheral devices. Also demonstrates assembly programming including interrupts.

• TinyMips: System-level simulation of a simplified 32-bit microprocessor based on the MIPS R-3000 architecture. Demonstrates a clean instruction set, flat-address space, memory-mapped I/O, MMU, and embedded-systems software development via cross-compiler.

• IDT R3051: System-level simulation of the IDT R3051 microcontroller from IDT. Includes visualization of the on-chip execution pipeline and caches.

Fast synchronization

One experiment with an early version of our 'simple' PIC16C84 microcontroller model showed that more than 70 percent of the total CPU time was wasted on simulation of the microcontroller clock signal when the rest of the circuit was quiescent. (The PIC16C84 uses four clock cycles per instruction, and three events per clock cycle). Even worse, most of the simulation time was spent in software wait-loops.

This motivated a series of improved simulation models for the PIC16 family processors, and improved simulation algorithms including fast synchronization between the instruction-level simulation and the event-based simulation engine.

For example, the 'FastPic16C84' simulation model uses an internally generated clock signal with regular wakeup events for the synchronisation with the simulation engine. As long as no external I/O activity occurs, this generates one Hades simulation event per processor instruction cycle (which is much more efficient than using an external component like hades.models.io.ClockGen to feed the PIC clock input at 12 Hades events per processor instruction cycle). As a result, simulation performance is greatly improved (up to a factor of five) for many applications.

The 'SmartPic16C84' simulation model does not use a clock signal at all. Instead, the instruction-level simulation checks the event-based simulator for the time of the next pending external event, and executes instructions until the external event time is reached. It then generates a 'wakeup' event for the event-based simulator, so that the microcontroller will regain control once the external events have been processed. Note that this synchronization would not be possible with a standard simulator.

However, the improved performance comes at reduced accuracy. The 'FastPic16C84' processor ignores its Clkin pin, and internal processor cycles may desynchronize up to 1 clk-period with the rest of the external simulation. For example, sampling of the Port A/B inputs may occur 1/4 cycle too early, and also the timing of Port B interrupts detection differs a little from the real device. If exact timing is a requirement for your system, use the hades.models.Pic16C84 instead of the FastPic16C84.

Click on the following thumbnail to open a screen shot of the PIC16 microcontroller user-interface with the data registers and EEPROM-memory on the left, and the program memory (with disassembled program) on the right. Naturally, all memories are editable during the simulation and single-stepping through a program is possible:

Demos

Click the following thumbnail to open screenshot of a PIC16-based ultrasonic range detector ('tapebox') with alphanumeric LC-display and simulated ultrasonic transmitter and receiver: