3.3 Using Simics for Hardware Bring-Up and Firmware

Development

Simics makes hardware bring-up, firmware development, and other low-level programming tasks easier in a number of ways:

Hardware replacement
A simulator replaces hardware. This has two key benefits during hardware bring-up: you can start working on the software before the hardware is available, and you can have as many copies of the simulated hardware as you like. Both of these translate directly to reduced total development time for the combined hardware+software product.
Inspection and modification
You can inspect the state of the entire simulation—memory, processor registers, device registers, anything—all entirely non-intrusively. And time is simply paused while you do so. You can restore a snapshot taken earlier, modify memory or register contents, and then run forward again and see the effects of this change.
Full debug support
The full power of Simics debugging (see chapter 3.2), with breakpoints, symbolic debugging, scripting, and so on, is available everywhere, even at the very lowest levels.

It is easy to write a handful of instructions directly to memory, fill the registers with any necessary values, and manually single-step through this little program:

simics> board.mb.cpu0.core[0][0]->cs[7] = 0 simics> board.mb.cpu0.core[0][0]->cs[8] = 0xffffffff simics> load-file test.bin 0xf000 simics> set-pc 0x10001 simics> %dx = 4711 simics> si [board.mb.cpu0.core[0][0]] cs:0x0000000000010001 p:0x000010001 mov ax,0x1 simics> si [board.mb.cpu0.core[0][0]] cs:0x0000000000010004 p:0x000010004 xor ebx,ebx

As always in Simics, this can be scripted if you expect to run it more than once:

test.simics:

run-script targets/qsp-x86/firststeps.simics
board.mb.cpu0.core[0][0]->cs[7] = 0
board.mb.cpu0.core[0][0]->cs[8] = 0xffffffff
load-file test.bin 0xf000
set-pc 0x10001
%dx = 4711
continue 12
expect %dx 4713
expect %pc 0x1001c
quit

Here, we first call another simics script to set up the machine for us, then run our test case. The expects will cause Simics to exit with an error code (as shown) if the conditions are not met; otherwise, the quit will cause Simics to quit successfully.

3.3.2 Going Further

The simple script in the last section can be extended in several directions:

load-file simply writes the contents of a file directly to memory. There are at least two other options:

Using set to write values directly to memory. This is useful if the test program is only a few instructions long.
Using load-binary to load an executable in one of the formats Simics recognizes, such as ELF. Unlike load-file, this command automatically loads the executable at the right address, and returns the entry point address.

You can have more complicated stop conditions than simply "run twelve instructions"; for example, you can use execution or data breakpoints (section 3.2.1.2), control register breakpoints (section 3.2.1.4), device I/O breakpoints (section 3.2.1.5), or magic instruction breakpoints (section 3.2.1.8).

Various conditions cause Simics to trigger haps; for example breakpoints, privilege level changes, magic instructions, and traps. You can easily write a small hap callback function that is called whenever this happens; such a callback could terminate the simulation (indicating success or failure), or simply log or change some value.

3.3 Using Simics for Hardware Bring-Up and Firmware

3.3.1 A Simple Example

3.3.2 Going Further