|TAMS / Java / Hades / applets: contents|
CosimulationOne of the research goals of the Hades framework was to study algorithms for system-simulation and fast hardware/software-cosimulation, including the coupling of an event-driven simulation engine with instruction-level processor simulators.
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 processorsAt the moment, the Hades framework includes simulation models for three different commercial microprocessors and several simplified processors used for teaching. In order of increasing complexity, these are:
Fast synchronizationMost microcontrollers include on-chip memories and a variety of on-chip system and interface components, for example parallel-ports, timers, UARTS, etc. Therefore, only a few external components are required for many applications and the simulation spends most of its time in the instruction-level simulation of the microcontroller CPU and the on-chip components. The external components are quiescent most of the time and are only active during external events (like the user pressing a button).
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:
DemosFor a live interactive demonstration of several PIC16-based systems, just select the PIC examples from our applet demos. Open the PIC microprocessor user-interface (popup-menu, edit-component) to watch data memory contents and the program execution.
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: