The ARMulator
=============


About the ARMulator
-------------------

ARMulator is a program which emulates the ARM architecture. It can also be 
extended by the user with different interfaces to emulate all other 
implementations of the ARM architecture. It has several uses:

 *  It provides an environment for the design, development and testing of 
    ARM-targetted software on non-ARM-based host systems.

 *  It allows accurate benchmarking of ARM-targetted programs.

 *  It supports the emulation of prototype ARM systems before the hardware is 
    available, allowing the development of hardware and low-level software to 
    proceed in parallel.

 *  It provides a generic ARM model which can easily be incorporated into 
    hardware simulation environments.

ARMulator can be transparently connected to <armsd> and <armwd> to provide a 
hardware independent ARM software development enviroment. The two programs 
communicate via the Remote Debug Interface (RDI): please refer to "<ARM Remote 
Debug Interface>" of the Technical Specifications for 
further information on the RDI. ARMulator also supports a full ANSI C library 
to allow complete C programs to run on the emulated system.


Modelling an ARM-Based System
-----------------------------

There are three levels of accuracy that can be supported:

 *  Instruction-accurate

 *  Cycle-accurate

 *  Timing-accurate

The first of these simply models the instruction set, without regard to the 
precise timing characteristics of the processor. As a result, it is 
considerably faster than the other variants, and is best suited to software 
development and benchmarking.

The second models accurately the signal transitions that would occur on each 
clock cycle around the periphery of the processor core, and is therefore slower 
than the instruction-accurate option.

The final level incorporates a timing veneer around the cycle-accurate model, 
which causes signal transitions to occur at the correct times within a clock 
cycle. At this level, the performance of the emulator becomes heavily dependent 
on the logic simulator into which the model is being integrated.

The rest of this chapter and the more technical chapter"<The ARMulator>" 
starting on page36 of the Reference Manual, describes instruction accurate 
emulation. Cycle- and timing- accurate emulation is discussed in the document 
<ARMulators for Hardware Modelling>, which is available from your supplier upon 
request.


ARMulator Release Components
----------------------------

The armul directory of the ARM Software Toolkit release contains the following 
files:

    Makefile      Used to build <armsd> (command line debugger) and <armwd>
                 (windowing debugger)

    readme        This directs you to read this manual

    armfast.c     ARMulator 'fast' memory model (samll contiguous memory)
    armvirt.c     ARMulator 'virtual' memory model (chunked memory) - default
    armproto.c    ARMulator 'prototype' memory model

    hostos.c      Support functions and headers for C-library on PIE Card
    hostos.h

    armos.c       Support functions and headers for C-library on ARMulator
    armos.h

    serdrive.c    Source and headers for serial line driver for PIE Card
    serdrive.h

    armcopro.c    ARMulator coprocessor model

    aif.h
    armdefs.h
    armfpe.h      Assorted files needed to build <armsd> and <armwd>
    dbg_conf.h
    dbg_hif.h
    pirdi.h

    armsd.a       <armsd> (command line debugger) library
    armwd.a       <armwd> (windowing debugger) library

    armsd         <armsd> executable - placed in binaries directory (not armul)
    armwd         <armwd> executable - placed in binaries directory (not armul)

The ARMulator is not a stand-alone product.  To use it, the parts must be 
linked together with a debugger to produce an executable file.  The debugger 
enables you to load and execute ARM Image Format images.

The ARMulator can be customised by  modifying the supplied C source files.


Building an ARMulator Variant
-----------------------------

To build a debugger with different options to that provided in the release type 
the following in the armul directory:

    make armsd              - to build the command line debugger

    make armwd              - to build the windowing debugger

    make                    - to build both armsd and armwd

    make MODEL=armfast      - to build both, using the 'fast' memory model

Any customised source files (eg. armfast.c, armos.c, serdrive.c) will be 
automatically recompiled by the Makefile and included in the generated debugger 
executables.


Memory Interfacing
------------------

For instruction and program based emulation, a memory interface must be 
constructed to allow ARMulator to load instructions and access data. The 
interface can be constructed in two ways. The first is designed to allow rapid 
prototyping of systems and consists of only two routines, ARMul_MemoryInit and 
ARMul_MemoryAccess. The second and more complex form of interface requires the 
construction of 17 separate routines for instruction and data accesses, word 
and byte accesses, etc. Please see chapter "<The ARMulator>" 
of the Reference Manual for further information.


Coprocessor interfacing
.......................

ARMulator defines two ways to model a coprocessor. One way is to access the 
modelled ARM's state directly through the ARMul_State structure. The other way 
is to build a software interface which uses ARMulator to handle the difficult 
handshaking and timing constraints of the simulation environment.


Event scheduling
................

There are two routines to assist with the handling of asynchronous events:

the routine ARMul_Time returns the number of clock ticks executed since system 
reset, modulo 2 ^32.

the routine ARMul_ScheduleEvent allows a function to be called a number of 
clock ticks into the future, to allow code such as multi-cycle floating point 
instructions to present their results at the appropriate time.


Adding an operating system
..........................

Rapid prototyping of operating systems is supported by the function 
ARMul_HandleSWI. The SWI numbers of all executed SWI (software interrupt) 
instructions are passed to this function, allowing support code to perform 
system-specific operations. The function may refuse to handle the SWI by 
returning FALSE, in which case a SWI exception will occur. If the function 
returns TRUE, execution will continue normally following the SWI instruction.


ANSI C Library
--------------

A full ANSI C Library is available to support the emulation of complete C 
programs with ARMulator. This library uses the ARMulator Operating System to 
perform filing operations on the emulation host, and an emulator for full 
floating point support.

For a complete description of ARMulator functionality and interfacing, please 
refer to  "<The ARMulator>" of the Reference Manual.

 

 

