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.

3.3.1 A Simple Example

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:0x0000000010001  mov ax,0x1
simics> si
[board.mb.cpu0.core[0][0]] cs:0x0000000000010004 p:0x0000000010004  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

$ ./simics test.simics
*** Values differ in expect command: 4711 4713
$

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.