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.
simics> @conf.cpu0.iface.simple_interrupt.interrupt(conf.cpu0, 0)The command line triggers the interrupt towards the CPU. The seconds parameter (zero) indicates that this is a normal interrupt. Critical interrupts should use the value 1. The external interrupt will only be serviced (when continuing execution) if the MSR[EE] bit is set, enabling external interrupts. To manually set this bit issue:
simics> %msr = %msr | 1<<15To lower the external interrupt manually issue:
simics> @conf.cpu0.iface.simple_interrupt.interrupt_clear(conf.cpu0, 0)
PowerPC instructions which manipulates the cache directly, such as dcbf can effect the cache model provided that the processor's icache and dcache are properly set.
The icache and dcache attributes should point to g-cache objects simulating instruction and data cache. For SMP configurations, the cpu_group attribute should point to a ppc-broadcast-bus object which will be informed about the caches the cpus uses. If the WIMG M-bit is set for a cache transaction, then memory coherency is required and the cache operation is sent down to the broadcast bus which distributes it to all known caches. For non-SMP configurations or if the M-bit is not set, the local cache is called directly.
The following operations are supported:
|PowerPC operation||Cache Operation|
|dcbf (data cache block flush)||Cache_Control_Invalidate_Line|
|dcbst (data cache block store)||Cache_Control_Copyback_Line|
|dcbt (data cache block touch)||Cache_Control_Fetch_Line|
|dcbtst (data cache block touch for store)||Cache_Control_Fetch_Line|