The Simics/IA64-460GX package contains a firmware implementation called the ia64-fakeprom. The fakeprom handles initial bootstrapping, and is basically an emulation of the PAL, SAL, and EFI layers of a real Itanium system.
The ia64-fakeprom accepts a number of arguments, passed as register values when
calling the firmware entry point. These arguments are located in input register
0 to 7. A complete list is given in
| ||||||||||||||||||||||||||||||||||||||||||
| Figure 1. The interface to the ia64-fakeprom |
In the IA-64 architectures, instructions are encoded in bundles, which are 128 bits (16 bytes). Each instruction uses 41 bits, and there is an extra 5-bit template in the bundle. The first instruction in a bundle is said to be in slot 0 of the bundle, the second instruction in slot 1, and the last instruction in slot 2.
Since individual instruction do not have well-defined addresses, Simics uses the encoding scheme (bundle address + slot number) when dissassembling instructions. Bundle addresses are always 16-byte aligned, and thus the lower 4 bits in the bundle address are always zero. When encoding the slot number, the lowest two bits of the address is used.
This encoding is also used when setting execution breakpoints. To break on execution of the instruction in slot 1 in the bundle located at the address 0x12340, execute the command break 0x12341.
The clock frequency of a simulated processor can be set arbitrarily in Simics. This will not affect the actual speed of simulation, but it will affect the number of instructions that need to be executed for a certain amount of simulated time to pass. If your execution only depends on executing a certain number of instructions, increasing the clock frequency will take the same amount of host time (but a shorter amount of target time). However, if there are time based delays of some kind in the simulation, these will take longer to execute.
At a simulated 1 MHz, one million target instructions will correspond to a simulated second (assuming the simple default timing of one cycle per instruction). At 100 MHz, on the other hand, it will take 100 million target instructions to complete a simulated second. So with a higher clock frequency, less simulated target time is going to pass for a certain period of host execution time.
If Simics is used to emulate an interactive system (especially one with a graphical user interface) it is a good idea to set the clock frequency quite low. Keyboard and mouse inputs events are handled by periodic interrupts in most operating systems, using a higher clock frequency will result in longer delays between invocations of periodic interrupts. Thus, the simulated system will feel slower in its user response, and update the mouse cursor position etc. less frequently. If this is a problem, the best technique for running experiments at a high clock frequency is to first complete the configuration of the machine using a low clock frequency. Save all configuration changes to a disk diff (like when installing operating systems). Then change the configuration to use a higher a clock frequency and reboot the target machine.
Note that for a lightly-loaded machine (for example, working at an interactive prompt on a serial console to an embedded Linux system), Simics will often execute quickly enough at the real target clock frequency that there is no need to artifically lower it.