JACK WHITHAM PhD MEng
 Professional Activities - Publications - Software - Articles 		   
       
    Home -> Software -> RTEMS/Simplescalar    

Note: If you are interested in accurate CPU simulation for either a single program (system call emulation) or an entire system, you should look into the more recent M5 simulator, which improves upon Simplescalar in a number of important ways.

RTEMS/Simplescalar: Why?

During the first year of my PhD work, I experimented with running a real-time operating system (RTOS) within the ARM7TDMI simulator Simplescalar. I needed to be able to simulate systems in which many applications were competing for resources, and it was not sufficient to just run these systems on genuine ARM hardware, because I wished to add non-standard architectural extensions such as custom instructions.

RTEMS proves ideal for this purpose because it is an open source RTOS that already supports the ARM architecture. Only minimal changes to RTEMS were required to support the work: basically just creating a new board support package for Simplescalar.

The official version of Simplescalar-ARM (from here) doesn't support the features required by RTEMS: it doesn't provide the MRS and MSR instructions, interrupt support or a programmable timer. I added these features.

Instructions

  1. First you will need to download Simplescalar-ARM, version 0.2. You can find it at http://www.simplescalar.com/v4test.html.
  2. Then you will need to apply the errno patch, and (if you want simulated "hardware" floating point) the LFM/SFM bug fix patch. You can find these patches here on my website.
  3. Now apply my RTOS support patch:
    simplescalar-rtos-support-0.1-patch (version 0.1).
  4. Also apply this second patch which adds idle task support:
    simplescalar-rtos-support-0.1a-patch (version 0.1a).
  5. This makes Simplescalar ready for use. However, you must now use sim-outorder. The other simulators are broken by the patch at present. I don't think this is a problem because sim-outorder is the most accurate simulator anyway.
  6. Compile GCC with newlib for the arm-rtems target. You will probably need to add some RTEMS patches. The RTEMS getting started guide (here) tells you how all of this is done - see "Building the GNU Cross Compiler Toolset".
  7. Now, download the source for RTEMS 4.6.2. Find it here: http://www.rtems.com/rtems-4.6/.
  8. Patch the source with my Simplescalar support patch:
    rtems-ss-0.1-patch (version 0.1).
  9. Patch the source again with this second patch:
    rtems-ss-0.1b-patch (version 0.1b).
  10. And then yet again with this third patch:
    rtems-ss-0.1c-patch (version 0.1c).
  11. In the RTEMS directory, run the bootstrap script to set up the automake system. You will need automake, autoconf, and related tools.
  12. Configure and compile the patched RTEMS, for the 'simplescalar' BSP, and the 'arm-rtems' target. These instructions will tell you most of what you need to know. You need to give configure options including the following: --target=arm-rtems --enable-rtemsbsp=simplescalar. You may also want --disable-networking (networking won't work in Simplescalar anyway).
  13. Programs built using the patched RTEMS will be executable directly using the modified Simplescalar binary. You will be able to use timeslicing and preemptive multitasking. By default, the modified Simplescalar assumes that the simulated clock frequency is 25MHz for the purposes of timing.

Issues

I haven't implemented fast interrupts, exceptions, or the LDM/STM instructions that allow access to user-mode registers. RTEMS does not normally appear to use these features.

Memory accesses to very low memory addresses (i.e. bootstrap code and interrupt vector table) are not cached. This is because Simplescalar uses a cache tag of 0 to indicate that a cache line is empty. Unfortunately, very low memory addresses legitimately have a tag of 0. My workaround was to turn off caching for these addresses completely.

RTEMS will take several million clock cycles to fully start up within Simplescalar. This would only be a matter of milliseconds on a real processor, but it is quite noticeable here. There is not much that can be done. If you are brave, you could consider using the Simplescalar fast-forward option to run initialisation at high speed. However I have not tested this. Using it *may* break the interrupt system.


       
  Copyright (C) Jack Whitham 1997-2008