Low level simulation
Using another system to simulate parts of the code is all well and good, but what about low level code such as initialisation routines? There are simulation tools available for these routines as well. CPU simulators can simulate a processor, memory system and, in some cases, some peripherals and allow low level assembler code and small HLL programs to be tested without the need for the actual hardware. These tools tend to fall into two categories: the first simulate the program-ming model and memory system and offer simple debugging tools similar to those found with an onboard debugger. These are inevitably slow, when compared to the real thing, and do not provide timing information or permit different memory configurations to be tested. However, they are very cheap and easy to use and can provide a low cost test bed for individuals within a large software team. There are even shareware simu-lators for the most common processors such as the one from the University of North Carolina which simulates an MC68000 processor.
<D0> =00000000 <D4> =00000000 <A0> =00000000 <A4> =00000000 <D1> =00000000 <D5> =0000abcd <A1> =00000000 <A5> =00000000 <D2> =00000000 <D6> =00000000 <A2> =00000000 <A6> =00000000 <D3> =00000000 <D7> =00000000 <A3> =00000000 <A7> =00000000
trace: on sstep: on cycles: 416 <A7'>= 00000f00
cn tr st rc T S INT XNZVC <PC> = 00000090
port1 00 00 82 00 SR = 1010101111011111
executing a ANDI instruction at location 58
executing a ANDI instruction at location 5e
executing a ANDI instruction at location 62
executing a ANDI_TO_CCR instruction at location 68
executing a ANDI_TO_SR instruction at location 6c
executing a OR instruction at location 70
executing a OR instruction at location 72
executing a OR instruction at location 76
executing a ORI instruction at location 78
executing a ORI instruction at location 7e
executing a ORI instruction at location 82
executing a ORI_TO_CCR instruction at location 88
executing a ORI_TO_SR instruction at location 8c
TRACE exception occurred at location 8c.
Example display from the University of North Carolina 68k simulator
The second category extends the simulation to provide timing information based on the number of clock cycles. Some simulators can even provide information on cache perform-ance, memory usage and so on, which is useful data for making hardware decisions. Different performance memory systems can be exercised using the simulator to provide performance data. This type of information is virtually impossible to obtain without using such tools. These more powerful simulators often require very powerful hosts with large amounts of memory. SDS provide a suite of such tools that can simulate a processor and memory and with some of the integrated proc-essors that are available, even emulate onboard peripherals such as LCD controllers and parallel ports.
Simulation tools are becoming more and more impor-tant in providing early experience of and data about a system before the hardware is available. They can be a little impractical due to their performance limitations — one second of process-ing with a 25 MHz RISC processor taking 2 hours of simulation time was not uncommon a few years ago — but as workstation performance improves, the simulation speed increases. With instruction level simulators it is possible with a top of the range workstation to get simulation speeds of 1 to 2 MHz.