URL https://opencores.org/ocsvn/openrisc/openrisc/trunk
Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [or1ksim/] [doc/] [or1ksim.info] - Blame information for rev 510

Go to most recent revision | Details | Compare with Previous | View Log

This is ../../doc/or1ksim.info, produced by makeinfo version 4.13 from
../../doc/or1ksim.texi.
 
INFO-DIR-SECTION Embedded development
START-INFO-DIR-ENTRY
* Or1ksim: (or32-elf-or1ksim).  The OpenRISC 1000 Architectural
                                        Simulator
END-INFO-DIR-ENTRY
 
This file documents the OpenRISC Architectural Simulator, Or1ksim.
 
Copyright (C) 2008, 2009 Embecosm Limited.
 
     Permission is granted to copy, distribute and/or modify this
     document under the terms of the GNU Free Documentation License,
     Version 1.2 or any later version published by the Free Software
     Foundation; with no Invariant Sections, with no Front-Cover Texts,
     and with no Back-Cover Texts.  A copy of the license is included
     in the section entitled "GNU Free Documentation License".
 

File: or1ksim.info,  Node: Top,  Next: Installation,  Up: (dir)
 
Scope of this Document
**********************
 
This document is the user guide for Or1ksim, the OpenRISC 1000
Architectural Simulator.
 
* Menu:
 
* Installation::
* Usage::
* Configuration::
* Interactive Command Line::
* Verification API::
 
* Code Internals::
 
* GNU Free Documentation License::  The license for this documentation
* Index::
 

File: or1ksim.info,  Node: Installation,  Next: Usage,  Prev: Top,  Up: Top
 
1 Installation
**************
 
Installation follows standard GNU protocols.
 
* Menu:
 
* Preparation::
* Configuring the Build::
* Build and Install::
* Known Issues::
 

File: or1ksim.info,  Node: Preparation,  Next: Configuring the Build,  Up: Installation
 
1.1 Preparation
===============
 
Unpack the software and create a _separate_ directory in which to build
it:
 
     tar jxf or1ksim-0.5.1rc1.tar.bz2
     mkdir builddir_or1ksim
     cd builddir_or1ksim
 

File: or1ksim.info,  Node: Configuring the Build,  Next: Build and Install,  Prev: Preparation,  Up: Installation
 
1.2 Configuring the Build
=========================
 
Configure the software using the `configure' script in the main
directory.
 
The most significant argument is `--target', which should specify the
OpenRISC 1000 32-bit architecture.  If this argument is omitted, it will
default to OpenRISC 1000 32-bit with a warning
 
     ../or1ksim-0.5.1rc1/configure --target=or32-elf ...
 
There are several other options available, many of which are standard
to GNU `configure' scripts.  Use `configure --help' to see all the
options.  The most useful is `--prefix' to specify a directory for
installation of the tools.
 
For testing (using `make check'), the `--target' parameter may be
specified, to allow the target tool chain to be selected.  If not
specified, it will default to `or32-elf', which is the same prefix used
with the standard OpenRISC toolchain installation script.
 
A number of Or1ksim specific features in the simulator do require
enabling at configuration.  These include
 
`--enable-profiling'
`--disable-profiling'
     If enabled, Or1ksim is compiled for profiling with `gprof'.  This
     is disabled by default.  Only really of value for developers of
     Or1ksim.
 
`--enable-execution=simple'
`--enable-execution=complex'
`--enable-execution=dynamic'
     Or1ksim has developed to improve functionality and performance.
     This feature allows three versions of Or1ksim to be built
 
    `--enable-execution=simple'
          Build the original simple interpreting simulator
 
    `--enable-execution=complex'
          Build a more complex interpreting simulator.  Experiments
          suggest this is 50% faster than the simple simulator.  This
          is the default.
 
    `--enable-execution=dynamic'
          Build a dynamically compiling simulator.  This is the way
          many modern ISS are built.  This represents a work in
          progress.  Currently Or1ksim will compile, but segfaults if
          configured with this option.
 
 
     The default is `--enable-execution=complex'.
 
`--enable-ethphy'
`--disable-ethphy'
     If enabled, this option allows the Ethernet to be simulated by
     connecting via a socket (the alternative reads and writes, from
     and to files).  This must then be configured using the relevant
     fields in the `ethernet' section of the configuration file.  *Note
     Ethernet Configuration: Ethernet Configuration.
 
     The default is for this to be disabled.
 
`--enable-unsigned-xori'
`--disable-unsigned-xori'
     Historically, `l.xori', has sign extended its operand.  This is
     inconsistent with the other logical opcodes (`l.andi', `l.ori'),
     but in the absence of `l.not', it allows a register to be inverted
     in a single instruction using:
 
          `l.xori  rD,rA,-1'
 
     This flag causes Or1ksim to treat the immediate operand as
     unsigned (i.e to zero-extend rather than sign-extend).
 
     The default is to sign-extend, so that existing code will continue
     to work.
 
          Caution: The GNU compiler tool chain makes heavy use of this
          instruction.  Using unsigned behavior will require the
          compiler to be modified accordingly.
 
          This option is provided for experimentation.  A future
          version of OpenRISC may adopt this more consistent behavior
          and also provide a `l.not' opcode.
 
`--enable-range-stats'
`--disable-range-stats'
     If enabled, this option allows statistics to be collected to
     analyse register access over time.  The default is for this to be
     disabled.
 
`--enable-debug'
`--disable-debug'
     This is a feature of the Argtable2 package used to process
     arguments.  If enabled, some debugging features are turned on in
     Argtable2.  It is provided for completeness, but there is no
     reason why this feature should ever be needed by any Or1ksim user.
 
`--enable-all-tests'
`--disable-all-tests'
     Some of the tests (at the time of writing just one) will not
     compile without error.  If enabled with this flag, all test
     programs will be compiled with `make check'.
 
     This flag is intended for those working on the test package, who
     wish to get the missing test(s) working.
 
 
A number of configuration flags have been removed since version 0.3.0,
because they led to invalid behavior of Or1ksim.  Those removed are:
 
`--enable-arith-flag'
`--disable-arith-flag'
     If enabled, this option caused certain instructions to set the flag
     (`F' bit) in the supervision register if the result were zero.
     The instructions affected by this were `l.add', `l.addc',
     `l.addi', `l.and' and `l.andi'.
 
     If set, this caused incorrect behavior.  Whether or not flags are
     set is part of the OpenRISC 1000 architectural specification.  The
     only flags which should set this are the "set flag" instructions:
     `l.sfeq', `l.sfeqi', `l.sfges', `l.sfgesi', `l.sfgeu', `l.sfgeui',
     `l.sfgts', `l.sfgtsi', `l.sfgtu', `l.sfgtui', `l.sfles',
     `l.sflesi', `l.sfleu', `l.sfleui', `l.sflts', `l.sfltsi',
     `l.sfltu', `l.sfltui', `l.sfne' and `l.sfnei'.
 
`--enable-ov-flag'
`--disable-ov-flag'
     This flag caused certain instructions to set the overflow flag.
     If not, those instructions would not set the overflow flat.  The
     instructions affected by this were `l.add', `l.addc', `l.addi',
     `l.and', `l.andi', `l.div', `l.divu', `l.mul', `l.muli', `l.or',
     `l.ori', `l.sll', `l.slli', `l.srl', `l.srli', `l.sra', `l.srai',
     `l.sub', `l.xor' and `l.xori'.
 
     This guaranteed incorrect behavior.  The OpenRISC 1000 architecture
     specification defines which flags are set by which instructions.
 
     Within the above list, the arithmetic instructions (`l.add',
     `l.addc', `l.addi', `l.div', `l.divu', `l.mul', `l.muli' and
     `l.sub'), together with `l.addic' which is missed out, set the
     overflow flag.  All the others (`l.and', `l.andi', `l.or',
     `l.ori', `l.sll', `l.slli', `l.srl', `l.srli', `l.sra', `l.srai',
     `l.xor' and `l.xori') do not.
 
 

File: or1ksim.info,  Node: Build and Install,  Next: Known Issues,  Prev: Configuring the Build,  Up: Installation
 
1.3 Building and Installing
===========================
 
Build the tool with:
 
     make all
 
If you have the OpenRISC tool chain and DejaGNU installed, you can
verify the tool as follows (otherwise omit this step):
 
     make check
 
Install the tool with:
 
     make install
 
This will install the three variations of the Or1ksim tool,
`or32-elf-sim', `or32-elf-psim' and `or32-elf-mpsim', the Or1ksim
library, `libsim', the header file, `or1ksim.h' and this documentation
in `info' format.
 
The documentation may be created and installed in alternative formats
(PDF, Postscript, DVI, HTML) with for example:
 
     make pdf
     make install-pdf
 

File: or1ksim.info,  Node: Known Issues,  Prev: Build and Install,  Up: Installation
 
1.4 Known Problems and Issues
=============================
 
Full details of outstanding issues may be found in the `NEWS' file in
the main directory of the distribution.  The OpenRISC tracker may be
used to see the current state of these issues and to raise new problems
and feature requests.  It may be found at bugtracker.
 
The following issues are long standing and unlikely to be fixed in
Or1ksim in the near future.
 
   * The Supervision Register Little Endian Enable (LEE) bit is
     ignored.  Or1ksim can be built for either little endian or big
     endian use, but that behavior cannot be changed dynamically.
 
   * Or1ksim is not reentrant, so a program cannot instantiate multiple
     instances using the library.  This is clearly a problem when
     considering multi-core applications.  However it stems from the
     original design, and can only be fixed by a complete rewrite.  The
     entire source code uses static global constants liberally!
 
 

File: or1ksim.info,  Node: Usage,  Next: Configuration,  Prev: Installation,  Up: Top
 
2 Usage
*******
 
* Menu:
 
* Standalone Simulator::
* Profiling Utility::
* Memory Profiling Utility::
* Trace Generation::
* Simulator Library::
* Ethernet TUN/TAP Interface::
* l.nop Support::
 

File: or1ksim.info,  Node: Standalone Simulator,  Next: Profiling Utility,  Up: Usage
 
2.1 Standalone Simulator
========================
 
The general form the standalone command is:
 
     or32-elf-sim [-vhiqVt] [-f FILE] [--nosrv] [--srv=[N]]
                      [-m ][-d STR]
                      [--enable-profile] [--enable-mprofile] [FILE]
 
Many of the options have both a short and a long form.  For example
`-h' or `--help'.
 
`-v'
`--version'
     Print out the version and copyright notice for Or1ksim and exit.
 
`-h'
`--help'
     Print out help about the command line options and what they mean.
 
`-i'
`--interactive'
     After starting, drop into the Or1ksim interactive command shell.
 
`-q'
`--quiet'
     Do not generate any information messages, only error messages.
 
`-V'
`--verbose'
     Generate extra output messages (equivalent of specifying the
     "verbose" option in the simulator configuration section (see *note
     Simulator Behavior: Simulator Behavior.).
 
`-t'
`--trace'
     Dump instruction just executed and any register/memory location
     chaged after each instruction (one line per instruction).
 
`--trace-physical'
`--trace-virtual'
     When tracing instructions, show the physical address
     (`--trace-physical') and/or the virtual address
     (`--trace-virtual') of the instruction being executed.  Both flags
     may be specified, in which case both physical and virtual
     addresses are shown, physical first.
 
          Note: Either or both flags may be specified without
          `--trace', to indicate how addresses should be shown if
          subsequently enabled by a `SIGUSER1' signal or `l.nop 8'
          opcode (*note Trace Generation: Trace Generation.).
 
`-f FILE'
`--file=FILE'
     Read configuration commands from the specified file, looking first
     in the current directory, and otherwise in the `$HOME/.or1k'
     directory.  If this argument is not specified, the file `sim.cfg'
     in those two locations is used.  Failure to find the file is a
     fatal error.  *Note Configuration: Configuration, for detailed
     information on configuring Or1ksim.
 
`--nosrv'
     Do not start up the "Remote Serial Protocol" debug server.  This
     overrides any setting specified in the configuration file.  This
     option may not be specified with `--srv'.  If it is, a rude
     message is printed and the `--nosrv' option is ignored.
 
`--srv'
 
`--srv=N'
     Start up the "Remote Serial Protocol" debug server.  This
     overrides any setting specified in the configuration file.  If the
     parameter, N, is specified, use that as the TCP/IP port for the
     server, otherwise a random value from the private port range
     (41920-65535) will be used.  This option may not be specified with
     `--nosrv'.  If it is, a rude message is printed and the `--nosrv'
     option is ignored.
 
`-m SIZE'
`--memory=SIZE'
     Configure a memory block of SIZE bytes, starting at address zero.
     The size may be followed by `k', `K', `m', `M', `g', `G', to
     indicate kilobytes (2^10 bytes), megabytes (2^20 bytes) and
     gigabytes (2^30 bytes).
 
     This is mainly intended for use when Or1ksim is used without a
     configuration file, to allow just the processor and memory to be
     set up.  This is the equivalent of specifying a configuration
     memory section with `baseaddr = 0' and `size = SIZE' and all other
     parameters taking their default value.
 
     If a configuration file is also used, it should be sure not to
     specify an overlapping memory block.
 
`-d CONFIG_STRING'
`--debug-config=CONFIG_STRING'
     Enable selected debug messages in Or1ksim.  This parameter is for
     use by developers only, and is not covered further here.  See the
     source code for more details.
 
`--report-memory-errors'
     By default all exceptions are now handled silently.  If this
     option is specified, bus exceptions will be reported with a
     message to standard error indicating the address at which the
     exception occurred.
 
     This was the default behaviour up to Or1ksim 0.4.0.  This flag is
     provided for those who wish to keep that behavior.
 
`--strict-npc'
     In real hardware, setting the next program counter (NPC, SPR 16),
     flushes the processor pipeline.  The consequence of this is that
     until the pipeline refills, reading the NPC will return zero.
     This is typically the case when debugging, since the processor is
     stalled.
 
     Historically, Or1ksim has always returned the value of the NPC,
     irrespective of when it is changed.  If the `--strict-npc' option
     is used, then Or1ksim will mirror real hardware more accurately.
     If the NPC is changed while the processor is stalled, subsequent
     reads of its value will return 0 until the processor is unstalled.
 
     This is not currently the default behavior, since tools such as
     GDB have been implemented assuming the historic Or1ksim behavior.
     However at some time in the future it will become the default.
 
`--enable-profile'
     Enable instruction profiling.
 
`--enable-mprofile'
     Enable memory profiling.
 
 

File: or1ksim.info,  Node: Profiling Utility,  Next: Memory Profiling Utility,  Prev: Standalone Simulator,  Up: Usage
 
2.2 Profiling Utility
=====================
 
This utility analyses instruction profile data generated by Or1ksim.
It may be invoked as a standalone command, or from the Or1ksim CLI.
The general form the standalone command is:
 
     or32-elf-profile [-vhcq] [-g=FILE]
 
Many of the options have both a short and a long form.  For example
`-h' or `--help'.
 
`-v'
`--version'
     Print out the version and copyright notice for the Or1ksim
     profiling utility and exit.
 
`-h'
`--help'
     Print out help about the command line options and what they mean.
 
`-c'
`--cumulative'
     Show cumulative sum of cycles in functions
 
`-q'
`--quiet'
     Suppress messages
 
`-g=FILE'
`--generate=FILE'
     The data file to analyse.  If omitted, the default file,
     `sim.profile' is used.
 
 

File: or1ksim.info,  Node: Memory Profiling Utility,  Next: Trace Generation,  Prev: Profiling Utility,  Up: Usage
 
2.3 Memory Profiling Utility
============================
 
This utility analyses memory profile data generated by Or1ksim.  It may
be invoked as a standalone command, or from the Or1ksim CLI.  The
general form the standalone command is:
 
     or32-elf-mprofile  [-vh] [-m=M] [-g=N] [-f=FILE] FROM TO
 
Many of the options have both a short and a long form.  For example
`-h' or `--help'.
 
`-v'
`--version'
     Print out the version and copyright notice for the Or1ksim memory
     profiling utility and exit.
 
`-h'
`--help'
     Print out help about the command line options and what they mean.
 
`-m=M'
`--mode=M'
     Specify the mode out output.  Permitted options are
 
    `detailed'
    `d'
          Detailed output.  This is the default if no mode is specified.
 
    `pretty'
    `p'
          Pretty printed output.
 
    `access'
    `a'
          Memory accesses only.
 
    `width'
    `w'
          Access width only.
 
 
`-g=N'
`--group=N'
     Group 2^n bits of successive addresses together.
 
`-f=FILE'
`--filename=FILE'
     The data file to analyse.  If not specified, the default,
     `sim.profile' is used.
 
`FROM'
`TO'
     FROM and TO are respectively the start and end address of the
     region of memory to be analysed.
 
 

File: or1ksim.info,  Node: Trace Generation,  Next: Simulator Library,  Prev: Memory Profiling Utility,  Up: Usage
 
2.4 Trace Generation
====================
 
An execution trace can be generated at run time with options passed by
the command line, or via the operating system's signal passing
mechanism, or by `l.nop' opcodes in an application program.
 
The following flag can be used to create an execution dump.
 
`-t'
`--trace'
     Dump instruction just executed and any register/memory location
     changed after each instruction (one line per instruction).  Each
     line starts with either "S" or "U" to indicate whether the
     processor was in supervisor or user mode _when the instruction
     completed_.  It is worth bearing in mind that tracing happens at
     completion of instruction execution and shows the state at that
     time.
 
Passing a signal `SIGUSR1' while the simulator is running toggles trace
generation. This can be done with the following command, assuming
Or1ksim's executable name is `or32-elf-sim':
 
     pkill -SIGUSR1 or32-elf-sim
 
This is useful in the case where trace output is desired after a
significant amount of simulation time, where it would be inconvenient to
generate trace up to that point.
 
If the `pkill' utility is not available, the `kill' utility can be used
if Or1ksim's process number is known. Use the following to determine
the process ID of the `or32-elf-sim' and then send the `SIGUSR1'
command to toggle execution trace generation:
 
     ps a | grep or32-elf-sim
     kill -SIGUSR1 _process-number_
 
Tracing can also be enabled and disabled from within a target program
using the `l.nop 8' and `l.nop 9' opcodes to enable and disable tracing
respectively.
 
By default tracing will show the virtual address of each instruction
traced.  This may be controlled by two options, `--trace-physical' to
show the physical address and/or `--trace-virtual' to show the virtual
address. If neither is specified, the virtual address is shown.
 
     Note: Either or both flags may be specified without `--trace', to
     indicate how addresses should be shown if subsequently enabled by a
     `SIGUSER1' signal or `l.nop 8' opcode.
 

File: or1ksim.info,  Node: Simulator Library,  Next: Ethernet TUN/TAP Interface,  Prev: Trace Generation,  Up: Usage
 
2.5 Simulator Library
=====================
 
Or1ksim may be used as a static of dynamic library, `libsim.a' or
`libsim.so'.  When compiling with the static library, the flag, `-lsim'
should be added to the link command.
 
The header file `or1ksim.h' contains appropriate declarations of the
functions exported by the Or1ksim library.  These are:
 
 -- `or1ksim.h': int or1ksim_init (int ARGC, char *ARGV, void
          *CLASS_PTR, int (*UPR)(void *CLASS_PTR, unsigned long int
          ADDR, unsigned char MASK[], unsigned char RDATA[], int
          DATA_LEN), int (*UPW)(void *CLASS_PTR, unsigned long int
          ADDR, unsigned char MASK[], unsigned char WDATA[], int
          DATA_LEN))
     The initialization function is supplied with a vector of arguments,
     which are interpreted as arguments to the standalone version (see
     *note Standalone Simulator: Standalone Simulator.), a pointer to
     the calling class, CLASS_PTR (since the library may be used from
     C++) and two up-call functions, one for reads, UPR, and one for
     writes, UPW.
 
     UPW is called for any write to an address external to the model
     (determined by a `generic' section in the configuration file).
     UPR is called for any reads to an external address.  The CLASS_PTR
     is passed back with these upcalls, allowing the function to
     associate the call with the class which originally initialized the
     library.  Both UPW and UPR should return zero on success and
     non-zero otherwise.  At the present time the meaning of non-zero
     values is not defined but this may change in the future.
 
     MASK indicates which bytes in the data are to be written or read.
     Bytes to be read/written should have 0xff set in MASK.  Otherwise
     the byte should be zero.  The adddress, ADDR, is the _full_
     address, since the upcall function must handle all generic
     devices, using the full address for decoding.
 
     Endianness is not a concern, since Or1ksim is transferring byte
     vectors, not multi-byte values.
 
     The result indicates whether the initialization was successful.
     The integer values are available as an `enum or1ksim', with
     possible values `OR1KSIM_RC_OK' and `OR1KSIM_RC_BADINIT'.
 
          Caution: This is a change from versions 0.3.0 and 0.4.0.  It
          further simplifies the interface, and makes Or1ksim more
          consistent with payload representation in SystemC TLM 2.0.
 
          Note: The current implementation of Or1ksim always transfers
          single words (4 bytes), using masks if smaller values are
          required.  In this it mimcs the behavior of the WishBone bus.
 
 
 -- `or1ksim.h': int or1ksim_run (double DURATION)
     Run the simulator for the simulated duration specified (in
     seconds).  A duration of -1 indicates `run forever'
 
     The result indicates how the run terminated.  The integer values
     are available as an `enum or1ksim', with possible values
     `OR1KSIM_RC_OK' (ran for the full duration), `OR1KSIM_RC_BRKPT'
     (terminated early due to hitting a breakpoint) and
     `OR1KSIM_RC_HALTED' (terminated early due to hitting `l.nop 1').
 
 
 -- `or1ksim.h': void or1ksim_reset_duration (double DURATION)
     Change the duration of a run specified in an earlier call to
     `or1ksim_run'.  Typically this is called from an upcall, which
     realizes it needs to change the duration of the run specified in
     the call to `or1ksim_run' that has been interrupted by the upcall.
 
     The time specified is the amount of time that the run must continue
     for (i.e the duration from _now_, not the duration from the
     original call to `or1ksim_run').
 
 
 -- `or1ksim.h': void or1ksim_set_time_point ()
     Set a timing point.  For use with `or1ksim_get_time_period'.
 
 
 -- `or1ksim.h': double or1ksim_get_time_period ()
     Return the simulated time (in seconds) that has elapsed since the
     last call to `or1ksim_set_time_point'.
 
 
 -- `or1ksim.h': int or1ksim_is_le ()
     Return 1 (logical true) if the Or1ksim simulation is
     little-endian, 0 otherwise.
 
 
 -- `or1ksim.h': unsigned long int or1ksim_clock_rate ()
     Return the Or1ksim clock rate (in Hz).  This is the value
     specified in the configuration file.
 
 
 -- `or1ksim.h': void or1ksim_interrupt (int I)
     Generate an edge-triggered interrupt on interrupt line I.  The
     interrupt must be cleared separately by clearing the corresponding
     bit in the PICSR SPR.  Until the interrupt is cleared, any further
     interrupts on the same line will be ignored with a warning.  A
     warning will be generated and the interrupt request ignored if
     level sensitive interrupts have been configured with the
     programmable interrupt controller (*note Interrupt Configuration:
     Interrupt Configuration.).
 
 
 -- `or1ksim.h': void or1ksim_interrupt_set (int I)
     Assert a level-triggered interrupt on interrupt line I.  The
     interrupt must be cleared separately by an explicit call to
     `or1ksim_interrupt_clear'.  Until the interrupt is cleared, any
     further setting of interrupts on the same line will be ignored
     with a warning.  A warning will be generated, and the interrupt
     request ignored if edge sensitive interrupts have been configured
     with the programmable interrupt controller (*note Interrupt
     Configuration: Interrupt Configuration.).
 
 
 -- `or1ksim.h': void or1ksim_interrupt_clear (int I)
     Clear a level-triggered interrupt on interrupt line I, which was
     previously asserted by a call to `or1ksim_interrupt_set'.  A
     warning will be generated, and the interrupt request ignored if
     edge sensitive interrupts have been configured with the
     programmable interrupt controller (*note Interrupt Configuration:
     Interrupt Configuration.).
 
 
 -- `or1ksim.h': double or1ksim_jtag_reset ()
     Drive a reset sequence through the JTAG interface.  Return the
     (model) time taken for this action.  Remember that the JTAG has
     its own clock, which can be an order of magnitude slower than the
     main clock, so even a reset (5 JTAG cycles) could take 50
     processor clock cycles to complete.
 
 
 -- `or1ksim.h': double or1ksim_jtag_shift_ir (unsigned char *JREG, int
          NUM_BITS)
     Shift the supplied register through the JTAG instruction register.
     Return the (model) time taken for this action.  The register is
     supplied as a byte vector, with the least significant bits in the
     least significant byte.  If the total number of bits is not an
     exact number of bytes, then the odd bits are found in the least
     significant end of the highest numbered byte.
 
     For example a 12-bit register would have bits 0-7 in byte 0 and
     bits 11-8 in the least significant 4 bits of byte 1.
 
 
 -- `or1ksim.h': double or1ksim_jtag_shift_dr (unsigned char *JREG, int
          NUM_BITS)
     Shift the supplied register through the JTAG data register.
     Return the (model) time taken for this action.  The register is
     supplied as a byte vector, with the least significant bits in the
     least significant byte.  If the total number of bits is not an
     exact number of bytes, then the odd bits are found in the least
     significant end of the highest numbered byte.
 
     For example a 12-bit register would have bits 0-7 in byte 0 and
     bits 11-8 in the least significant 4 bits of byte 1.
 
 
 -- `or1ksim.h': int or1ksim_read_mem (unsigned long int ADDR, unsigned
          char *BUF, int LEN)
     Read LEN bytes from ADDR, placing the result in BUF.  Return LEN
     on success and 0 on failure.
 
          Note: This function was added in Or1ksim 0.5.0.
 
 
 -- `or1ksim.h': int or1ksim_write_mem (unsigned long int ADDR, const
          unsigned char *BUF, int LEN)
     Write LEN bytes to ADDR, taking the data from BUF.  Return LEN on
     success and 0 on failure.
 
          Note: This function was added in Or1ksim 0.5.0.
 
 
 -- `or1ksim.h': int or1ksim_read_spr (int SPRNUM, unsigned long int
          *SPRVAL_PTR)
     Read the SPR specified by SPRNUM, placing the result in
     SPRVAL_PTR.  Return non-zero on success and 0 on failure.
 
          Note: This function was added in Or1ksim 0.5.0.
 
 
 -- `or1ksim.h': int or1ksim_write_spr (int SPRNUM, unsigned long int
          SPRVA)
     Write SPRVAL to the SPR specified by SPRNUM.  Return non-zero on
     success and 0 on failure.
 
          Note: This function was added in Or1ksim 0.5.0.
 
 
 -- `or1ksim.h': int or1ksim_read_reg (int REGNUM, unsigned long int
          *REGVAL_PTR)
     Read the general purpose register specified by REGNUM, placing the
     result in REGVAL_PTR.  Return non-zero on success and 0 on failure.
 
          Note: This function was added in Or1ksim 0.5.0.
 
 
 -- `or1ksim.h': int or1ksim_write_reg (int REGNUM, unsigned long int
          REGVA)
     Write REGVAL to the general purpose register specified by REGNUM.
     Return non-zero on success and 0 on failure.
 
          Note: This function was added in Or1ksim 0.5.0.
 
 
 -- `or1ksim.h': void or1ksim_set_stall_state (int STATE)
     Set the processor's state according to STATE (1 = stalled, 0 = not
     stalled).
 
          Note: This function was added in Or1ksim 0.5.0.
 
 
The libraries will be installed in the `lib' sub-directory of the main
installation directory (as specified with the `--prefix' option to the
`configure' script).
 
For example if the main installation directory is `/opt/or1ksim', the
library will be found in the `/opt/or1ksim/lib' directory.  It is
available as both a static library (`libsim.a') and a shared object
(`libsim.so').
 
To link against the library add the `-lsim' flag when linking and do
one of the following:
 
   * Add the library directory to the `LD_LIBRARY_PATH' environment
     variable during execution.  For example:
 
          export LD_LIBRARY_PATH=/opt/or1ksim/lib:$LD_LIBRARY_PATH
 
   * Add the library directory to the `LD_RUN_PATH' environment
     variable during linking.  For example:
 
          export LD_RUN_PATH=/opt/or1ksim/lib:$LD_RUN_PATH
 
   * Use the linker `--rpath' option and specify the library directory
     when linking your program.  For example
 
          gcc ...  -Wl,--rpath -Wl,/opt/or1ksim/lib ...
 
   * Add the library directory to `/etc/ld.so.conf'
 
 

File: or1ksim.info,  Node: Ethernet TUN/TAP Interface,  Next: l.nop Support,  Prev: Simulator Library,  Up: Usage
 
2.6 Ethernet TUN/TAP Interface
==============================
 
When an Ethernet peripheral is configured (*note Ethernet
Configuration: Ethernet Configuration.), one option is to tunnel
traffic through a TUN/TAP interface.  The low level TAP interface is
used to tunnel raw Ethernet datagrams.
 
The TAP interface can then be connected to a physical Ethernet through a
bridge, allowing the Or1ksim model to connect to a physical network.
This is particularly when Or1ksim is running the OpenRISC Linux kernel
image.
 
This section explains how to set up a bridge for use by Or1ksim. It does
require superuser access to the host machine (or at least the relevant
network capabilities). A system administrator can modify these
guidelines so they are executed on reboot if appropriate.
 
* Menu:
 
* Setting Up a Persistent TAP device::
* Establishing a Bridge::
* Opening the Firewall::
* Disabling Ethernet Filtering::
* Networking from OpenRISC Linux and BusyBox::
* Tearing Down a Bridge::
 

File: or1ksim.info,  Node: Setting Up a Persistent TAP device,  Next: Establishing a Bridge,  Up: Ethernet TUN/TAP Interface
 
2.6.1 Setting Up a Persistent TAP device
----------------------------------------
 
TUN/TAP devices can be created dynamically, but this requires superuser
privileges (or at least `CAP_NET_ADMIN' capability).  The solution is
to create a persistent TAP device.  This can be done using either
`openvpn' or `tunctl'.  In either case the package must be installed on
the host system.  Using `openvpn', the following would set up a TAP
interface for a specified user and group.
 
     openvpn --mktun --dev tap_n_ --user _username_ --group _groupname_
 

File: or1ksim.info,  Node: Establishing a Bridge,  Next: Opening the Firewall,  Prev: Setting Up a Persistent TAP device,  Up: Ethernet TUN/TAP Interface
 
2.6.2 Establishing a Bridge
---------------------------
 
A bridge is a "virtual" local area network interfaces, subsuming two or
more existing network interfaces.  In this case we will bridge the
physical Ethernet interface of the host with the TAP interface that
will be used by Or1ksim.
 
The Ethernet and TAP must lose their own individual IP addresses (by
setting them to 0.0.0.0) and are replaced by the IP address of the
bridge interface. To do this we use the `bridge-utils' package, which
must be installed on the host system. These commands are require
superuser privileges or `CAP_NET_ADMIN' capability. To create a new
interface `br_n_' the following commands are appropriate.
 
     brctl addbr br_n_
     brctl addif br_n_ eth_x_
     brctl addif br_n_ tap_y_
 
     ifconfig eth_x_ 0.0.0.0 promisc up
     ifconfig tap_y_ 0.0.0.0 promisc up
 
     dhclient br_n_
 
The last command instructs the bridge to obtain its IP address, netmask,
broadcast address, gateway and nameserver information using DHCP.  In a
network without DHCP it should be replaced by `ifconfig' to set a
static IP address, netmask and broadcast address.
 
     Note: This will leave a spare dhclient process running in the
     background, which should be killed for tidiness. There is a
     technique to avoid this using `omshell', but that is beyond the
     scope of this guide.
 
     Note: It is not clear to the author why the existing interfaces
     need to be brought up in promiscuous mode, but it seems to cure
     various problems.
 

File: or1ksim.info,  Node: Opening the Firewall,  Next: Disabling Ethernet Filtering,  Prev: Establishing a Bridge,  Up: Ethernet TUN/TAP Interface
 
2.6.3 Opening the Firewall
--------------------------
 
Firewall rules should be added to ensure traffic flows freely through
the TAP and bridge interfaces. As superuser the following commands are
appropriate.
 
     iptables -A INPUT -i tap_y_ -j ACCEPT
     iptables -A INPUT -i br_n_ -j ACCEPT
     iptables -A FORWARD -i br_n_ -j ACCEPT
 

File: or1ksim.info,  Node: Disabling Ethernet Filtering,  Next: Networking from OpenRISC Linux and BusyBox,  Prev: Opening the Firewall,  Up: Ethernet TUN/TAP Interface
 
2.6.4 Disabling Ethernet Filtering
----------------------------------
 
Some systems may have ethernet filtering enabled (`ebtables',
`bridge-nf', `arptables') which will stop traffic flowing through the
bridge.
 
The easiest way to disable this is by writing zero to all `bridge-nf-*'
entries in `/proc/sys/net/bridge'. As superuser the following commands
will achieve this.
 
     cd /proc/sys/net/bridge
     for f in bridge-nf-*; do echo 0 > $f; done
 

File: or1ksim.info,  Node: Networking from OpenRISC Linux and BusyBox,  Next: Tearing Down a Bridge,  Prev: Disabling Ethernet Filtering,  Up: Ethernet TUN/TAP Interface
 
2.6.5 Networking from OpenRISC Linux and BusyBox
------------------------------------------------
 
The main use of this style of Ethernet interface to Or1ksim is when
running the OpenRISC Linux kernel with BusyBox. The following commands
in the BusyBox console window will configure the Ethernet interface
(assumed to be `eth0') and bring it up with a DHCP assigned address.
 
     ifconfig eth0
     ifup eth0
 
At this stage interface to IP addresses will work correctly.
 
For DNS to work the BusyBox system needs to know where to find a
nameserver.  Under BusyBox, `udhcp' does not configure
`/etc/resolv.conf' automatically.
 
The solution is to duplicate the nameserver entry from the
`/etc/resolv.conf' file of the host on the BusyBox system. A typical
file might be as follows:
 
     `nameserver 192.168.0.1'
 
It is convenient to make this permanent within the Linux initramfs. Add
the file as `arch/openrisc/support/initramfs/etc/resolv.conf' within
the Linux source tree and rebuild `vmlinux'. It will then be present
automatically.
 
One of the most useful functions that is possible is to mount the host
file system through NFS. For example, from the BusyBox console:
 
     mount -t nfs -o nolock 192.168.0.60:/home /mnt
 
Another useful technique is to telnet into the BusyBox system from the
host. This is particularly valuable when a console process locks up,
since the `xterm' console will not recognize ctrl-C. Instead the rogue
process can be killed from a telnet connection.
 

File: or1ksim.info,  Node: Tearing Down a Bridge,  Prev: Networking from OpenRISC Linux and BusyBox,  Up: Ethernet TUN/TAP Interface
 
2.6.6 Tearing Down a Bridge
---------------------------
 
There is little reason why a bridge should ever need to be torn down,
but if desired, the following commands will achieve the effect.
 
     ifconfig br_n_ down
     brctl delbr br_n_
 
     dhclient eth_x_
 
As before this will leave a spare `dhclient' process in the background
which should be killed.
 
If desired the TAP interface can be deleted using
 
     openvpn --rmtun -dev tap_y_
 
     Caution: The TAP interface should not be in use when running this
     command. For example any OpenRISC Linux/BusyBox sessions should be
     closed first.
 

File: or1ksim.info,  Node: l.nop Support,  Prev: Ethernet TUN/TAP Interface,  Up: Usage
 
2.7 l.nop Opcode Support
========================
 
The OpenRISC `l.nop' opcode can take a parameter.  This has no effect
on the semantics of the opcode, but can be used to trigger side effect
behavior in a simulator.  Within Or1ksim, the following parameters are
supported.
 
`l.nop 0'
     The equivalent to `l.nop' with no parameter. Has no side effects.
 
`l.nop 1'
     Execution of Or1ksim is terminated. This is used to implement the
     library `exit' functions.
 
`l.nop 2'
     Report the value in `r3' on the console as a 32-bit hex value.
 
`l.nop 3'
     In earlier versions of Or1ksim this treated `r3' as a pointer to a
     `printf' style format string, and registers `r4' through `r8' as
     parameters for that format string.
 
     This opcode is no longer supported, and has no effect if used.
 
`l.nop 4'
     The value in `r3' is printed to standard output as an ASCII
     character.  All library output routines are implemented using this
     opcode.
 
`l.nop 5'
     The statistics counters are reset.
 
`l.nop 6'
     The number of clock ticks since start of execution (a 64-bit
     value) is returned in `r11' (low 32 bits) and `r12' (high 32 bits).
 
`l.nop 7'
     The number of picoseconds per clock cycle is returned in `r11'.
     This is used with `l.nop 6' to implement timing functions.
 
`l.nop 8'
     Instruction tracing is turned on.
 
`l.nop 9'
     Instruction tracing is turned off.
 
`l.nop 10'
     A 32-bit random number is returned in `r11'.
 
     The random numbers are generated using `random', which in turn is
     seeded through `srandom' using the host `/dev/urandom' if
     available, or else the process ID of the Or1ksim instance.
 
     This opcode is particularly useful for situations where a target
     program running on Or1ksim needs to obtain genuine system entropy
     to generate random numbers.
 
`l.nop 11'
     Return a non-zero value in `r11'.
 
     This opcode can be used to detect if a target is running under
     Or1ksim.  Set `r11' to zero, issue this opcode, and look to see if
     `r11' is non-zero.
 
 

File: or1ksim.info,  Node: Configuration,  Next: Interactive Command Line,  Prev: Usage,  Up: Top
 
3 Configuration
***************
 
Or1ksim is configured through a configuration file.  This is specified
through the `-f' parameter to the Or1ksim command, or passed as a
string when initializing the Or1ksim library.  If no file is specified,
the default `sim.cfg' is used.  The file is looked for first in the
current directory, then in the `$HOME/.or1ksim' directory of the user.
 
* Menu:
 
* Configuration File Format::
* Simulator Configuration::
* Core OpenRISC Configuration::
* Peripheral Configuration::
 

File: or1ksim.info,  Node: Configuration File Format,  Next: Simulator Configuration,  Up: Configuration
 
3.1 Configuration File Format
=============================
 
The configuration file is a plain text file.  A reference example,
`sim.cfg', is included in the top level directory of the distribution.
 
* Menu:
 
* Configuration File Preprocessing::
* Configuration File Syntax::
 

File: or1ksim.info,  Node: Configuration File Preprocessing,  Next: Configuration File Syntax,  Up: Configuration File Format
 
3.1.1 Configuration File Preprocessing
--------------------------------------
 
The configuration file may include C style comments (i.e.  delimited by
`/*' and `*/').
 

File: or1ksim.info,  Node: Configuration File Syntax,  Prev: Configuration File Preprocessing,  Up: Configuration File Format
 
3.1.2 Configuration File Syntax
-------------------------------
 
The configuration file is divided into a series of sections, with the
general form:
 
     section SECTION_NAME
 
       ...
 
     end
 
Sections may also have sub-sections within them (currently only the
ATA/ATAPI disc interface uses this).
 
Within a section, or sub-section are a series of parameter assignments,
one per line, withe the general form
 
       PARAMETER = VALUE
 
Depending on the parameter, the value may be a named value (an
enumeration), an integer (specified in any format acceptable in C) or a
string in doubple quotes.  For flag parameters, the value 1 is used to
mean "true" or "on" and the value "0" to mean "false" or "off".  An
example from a memory section shows each of these
 
     section memory
       type    = random
       pattern = 0x00
       name    = "FLASH"
       ...
     end
 
Many parameters are optional and take reasonable default values if not
specified.  However there are some parameters (for example the `ce'
parameter in `section memory') _must_ be specified.
 
Subsections are introduced by a keyword, with a parameter value (no `='
sign), and end with the same keyword prefixed by `end'.  Thus the
ATA/ATAPI inteface (`section ata') has a `device' subsection, thus:
 
     section ata
       ...
       device 0
         type    = 1
         file = "FILENAME"
         ...
       enddevice
       ...
     end
 
Some sections (for example `section sim') should appear only once.
Others (for example `section memory' may appear multiple times.
 
Sections may be omitted, _unless they contain parameters which are
non-optional_.  If the section describes a part of the simulator which
is optional (for example whether it has a UART), then that
functionality will not be provided.  If the section describes a part of
the simulator which is not optional (for example the CPU), then all the
parameters of that section will take their default values.
 
All optional parts of the functionality are always described by
sections including a `enabled' parameter, which can be set to 0 to
ensure that functionality is explicitly omitted.
 
Even if a section is disabled, all its parameters will be read and
stored.  This is helpful if the section is subsequently enabled from
the Or1ksim command line (*note Interactive Command Line: Interactive
Command Line.).
 
     Tip: It generally clearer to have sections describing _all_
     components, with omitted functionality explicitly indicated by
     setting the `enabled' parameter to 0
 
The following sections describe the various configuration sections and
the parameters which may be set in each.
 

File: or1ksim.info,  Node: Simulator Configuration,  Next: Core OpenRISC Configuration,  Prev: Configuration File Format,  Up: Configuration
 
3.2 Simulator Configuration
===========================
 
* Menu:
 
* Simulator Behavior::
* Verification API Configuration::
* CUC Configuration::
 

File: or1ksim.info,  Node: Simulator Behavior,  Next: Verification API Configuration,  Up: Simulator Configuration
 
3.2.1 Simulator Behavior
------------------------
 
Simulator behavior is described in `section sim'.  This section should
appear only once.  The following parameters may be specified.
 
`verbose = 0|1'
     If 1 (true), print extra messages.  Default 0.
 
`debug = 0-9'
 
     higher the value the greater the number of messages.  Default 0.
     Negative values will be treated as 0 (with a warning).  Values
     that are too large will be treated as 9 (with a warning).
 
`profile = 0|1'
     If 1 (true) generate a profiling file using the file specified in
     the `prof_file' parameter or otherwise `sim.profile'.  Default 0.
 
`prof_file = ``FILENAME'''
     Specifies the file to be used with the `profile' parameter.
     Default `sim.profile'.  For backwards compatibility, the
     alternative name `prof_fn' is supported for this parameter, but
     deprecated.  Default `sim.profile'.
 
`mprofile = 0|1'
     If 1 (true) generate a memory profiling file using the file
     specified in the `mprof_file' parameter or otherwise
     `sim.mprofile'.  Default 0.
 
`mprof_file = ``FILENAME'''
     Specifies the file to be used with the `mprofile' parameter.
     Default `sim.mprofile'.  For backwards compatibility, the
     alternative name `mprof_fn' is supported for this parameter, but
     deprecated.  Default `sim.mprofile'.
 
`history = 0|1'
     If 1 (true) track execution flow.  Default 0.
 
          Note: Setting this parameter seriously degrades performance.
 
          Note: If this execution flow tracking is enabled, then
          `dependstats' must be enabled in the CPU configuration
          section (*note CPU Configuration: CPU Configuration.).
 
`exe_log = 0|1'
     If 1 (true), generate an execution log.  Log is written to the
     file specified in parameter `exe_log_file'.  Default 0.
 
          Note: Setting this parameter seriously degrades performance.
 
`exe_log_type = default|hardware|simple|software'
     Type of execution log to produce.
 
    `default'
          Produce default output for the execution log.  In the current
          implementation this is the equivalent of `hardware'.
 
    `hardware'
          After each instruction execution, log the number of
          instructions executed so far, the next instruction to execute
          (in hex), the general purpose registers (GPRs), status
          register, exception program counter, exception, effective
          address register and exception status register.
 
    `simple'
          After each instruction execution, log the number of
          instructions executed so far and the next instruction to
          execute, symbolically disassembled.
 
    `software'
          After each instruction execution, log the number of
          instructions executed so far and the next instruction to
          execute, symbolically disassembled.  Also show the value of
          each operand to the instruction.
 
 
     Default value `hardware'.  Any unrecognized keyword (case
     insensitive) will be treated as the default with a warning.
 
          Note: Execution logs can be _very_ big.
 
`exe_log_start = VALUE'
     Address of the first instruction to start logging.  Default 0.
 
`exe_log_end = VALUE'
     Address of the last instruction to log.  Default no limit (i.e
     once started logging will continue until the simulator exits).
 
`exe_log_marker = VALUE'
     Specifies the number of instructions between printing horizontal
     markers.  Default is to produce no markers.
 
`exe_log_file = FILENAME'
     Filename for the execution log filename if `exe_log' is enabled.
     Default `executed.log'.  For backwards compatibility, the
     alternative name `exe_log_fn' is supported for this parameter, but
     deprecated.
 
`exe_bin_insn_log = 0|1'
     Enable logging of executed instructions to a file in binary format.
     This is helpful for off-line dynamic execution analysis.
 
          Note: Execution logs can be _very_ big.  For example, while
          booting the Linux kernel, version 2.6.34, a log file 1.2GB in
          size was generated.
 
`exe_bin_insn_log_file = FILENAME'
     Filename for the binary execution log filename if
     `exe_bin_insn_log' is enabled.  Default `exe-insn.bin'.
 
`clkcycle = VALUE[ps|ns|us|ms]'
     Specify the time taken by one clock cycle.  If no units are
     specified, `ps' is assumed.  Default 4000ps (250MHz).
 
 

File: or1ksim.info,  Node: Verification API Configuration,  Next: CUC Configuration,  Prev: Simulator Behavior,  Up: Simulator Configuration
 
3.2.2 Verification API (VAPI) Configuration
-------------------------------------------
 
The Verification API (VAPI) provides a TCP/IP interface to allow
components of the simulation to be controlled externally.  *Note
Verification API: Verification API, for more details.
 
Verification API configuration is described in `section vapi'.  This
section may appear at most once.  The following parameters may be
specified.
 
`enabled = 0|1'
     If 1 (true), verification API is enabled and its server started.
     If 0 (the default), it is disabled.
 
`server_port = VALUE'
     When VAPI is enabled, communication will be via TCP/IP on the port
     specified by VALUE.  The value must lie in the range 1 to 65535.
     The default value is 50000.
 
          Tip: There is no registered port for Or1ksim VAPI.  Good
          practice suggests users should adopt port values in the
          "Dynamic" or "Private" port range, i.e.  49152-65535.
 
`log_enabled = 0|1'
     If 1 (true), all VAPI requests and sent commands will be logged.
     If 0 (the default), logging is diabled.  Logs are written to the
     file specified by the `vapi_log_file' field (see below).
 
          Caution: This can generate a substantial amount of file I/O
          and seriously degrade simulator performance.
 
`hide_device_id = 0|1'
     If 1 (true) don't log the device ID.  If 0 (the default), log the
     device ID.  This feature (when set to 1) is provided for backwards
     compatibility with an old version of VAPI.
 
`vapi_log_file = "FILENAME"'
     Use `filename' as the file for logged data is logging is enabled
     (see `log_enabled' above).  The default is `"vapi.log"'.  For
     backwards compatibility, the alternative name `vapi_log_fn' is
     supported for this parameter, but deprecated.
 
 

File: or1ksim.info,  Node: CUC Configuration,  Prev: Verification API Configuration,  Up: Simulator Configuration
 
3.2.3 Custom Unit Compiler (CUC) Configuration
----------------------------------------------
 
The Custom Unit Compiler (CUC) was a project by Marko Mlinar to generate
Verilog from ANSI C functions.  The project seems to not have progressed
beyond the initial prototype phase.  The configuration parameters are
described here for the record.
 
CUC configuration is described in `section cuc'.  This section may
appear at most once.  The following parameters may be specified.
 
`memory_order = none|weak|strong|exact'
     This parameter specifies the memory ordering required:
 
    `memory_order=none'
          Different memory ordering, even if there are dependencies.
          Bursts can be made, width can change.
 
    `memory_order=weak'
          Different memory ordering, even if there are dependencies.  If
          dependencies cannot occur, then bursts can be made, width can
          change.
 
    `memory_order=strong'
          Same memory ordering.  Bursts can be made, width can change.
 
    `memory_order=exact'
          Exactly the same memory ordering and widths.
 
 
     The default value is `memory_order=exact'.  Invalid memory
     orderings are ignored with a warning.
 
`calling_convention = 0|1'
     If 1 (true), programs follow OpenRISC calling conventions.  If 0
     (the default), they may use other convenitions.
 
`enable_bursts = 0 | 1'
     If 1 (true), bursts are detected.  If 0 (the default), bursts are
     not detected.
 
`no_multicycle = 0 | 1'
     If 1 (true), no multicycle logic paths will be generated.  If 0
     (the default), multicycle logic paths will be generated.
 
`timings_file = "FILENAME"'
     FILENAME specifies a file containing timing information.  The
     default value is `"virtex.tim"'.  For backwards compatibility, the
     alternative name `timings_fn' is supported for this parameter, but
     deprecated.
 
 

File: or1ksim.info,  Node: Core OpenRISC Configuration,  Next: Peripheral Configuration,  Prev: Simulator Configuration,  Up: Configuration
 
3.3 Configuring the OpenRISC Architectural Components
=====================================================
 
* Menu:
 
* CPU Configuration::
* Memory Configuration::
* Memory Management Configuration::
* Cache Configuration::
* Interrupt Configuration::
* Power Management Configuration::
* Branch Prediction Configuration::
* Debug Interface Configuration::
 

File: or1ksim.info,  Node: CPU Configuration,  Next: Memory Configuration,  Up: Core OpenRISC Configuration
 
3.3.1 CPU Configuration
-----------------------
 
CPU configuration is described in `section cpu'.  This section should
appear only once.  At present Or1ksim does not model multi-CPU systems.
The following parameters may be specified.
 
`ver = VALUE'
 
`cfg = VALUE'
 
`rev = VALUE'
     The values are used to form the corresponding fields in the `VR'
     Special Purpose Register (SPR 0).  Default values 0.  A warning is
     given and the value truncated if it is too large (8 bits for `ver'
     and `cfg', 6 bits for `rev').
 
`upr = VALUE'
     Used as the value of the Unit Present Register (UPR) Special
     Purpose Register (SPR 1) to VALUE.  Default value is 0x0000075f,
     i.e.
        * UPR present (0x00000001)
 
        * Data cache present (0x00000002)
 
        * Instruction cache present (0x00000004)
 
        * Data MMY present (0x00000008)
 
        * Instruction MMU present (0x00000010)
 
        * Debug unit present (0x00000040)
 
        * Power management unit present (0x00000100)
 
        * Programmable interrupt controller present (0x00000200)
 
        * Tick timer present (0x00000400)
 
     However, with the exection of the UPR present (0x00000001) and tick
     timer present, the various fields will be modified with the values
     specified in their corresponding configuration sections.
 
`cfgr = VALUE'
     Sets the CPU configuration register (Special Purpose Register 2) to
     VALUE.  Default value is 0x00000020, i.e.  support for the ORBIS32
     instruction set.  Attempts to set any other value are accepted, but
     issue a warning that there is no support for the instruction set.
 
`sr = VALUE'
     Sets the supervision register Special Purpose Register (SPR 0x11)
     to VALUE.  Default value is 0x00008001, i.e.  start in supervision
     mode (0x00000001) and set the "Fixed One" bit (0x00008000).
 
          Note: This is particularly useful when an image is held in
          Flash at high memory (0xf0000000).  The EPH  bit can be set,
          so that interrupt vectors are basedf at 0xf0000000, rather
          than 0x0.
 
`superscalar = 0|1'
     If 1, the processor operates in superscalar mode.  Default value is
     0.
 
     In the current simulator, the only functional effect of superscalar
     mode is to affect the calculation of the number of cycles taken to
     execute an instruction.
 
          Caution: The code for this does not appear to be complete or
          well tested, so users are advised not to use this option.
 
`hazards = 0|1'
     If 1, data hazards are tracked in a superscalar CPU.  Default
     value is 0.
 
     In the current simulator, the only functional effect is to cause
     logging of hazard waiting information if the CPU is superscalar.
     However nowhere in the simulator is this data actually computed,
     so the net result is probably to have no effect.
 
     if harzards are tracked, current hazards can be displayed using the
     simulator's `r' command.
 
          Caution: The code for this does not appear to be complete or
          well tested, so users are advised not to use this option.
 
`dependstats = 0|1'
     If 1, inter-instruction dependencies are calculated.  Default
     value 0.
 
     If these values are calculated, the depencies can be displayed
     using the simulator's `stat' command.
 
          Note: This field must be enabled, if execution execution flow
          tracking (field `history') has been requested in the simulator
          configuration section (*note Simulator Behavior: Simulator
          Behavior.).
 
`sbuf_len = VALUE'
     The length of the store buffer is set to VALUE, which must be no
     greater than 256.  Larger values will be truncated to 256 with a
     warning.  Negative values will be treated as 0 with a warning.
     Use 0 to disable the store buffer.
 
     When the store buffer is active, stores are accumulated and
     committed when I/O is idle.
 
`hardfloat = 0|1'
     If 1, hardfloat instructions are enabled.  Default value 0.
 
 

File: or1ksim.info,  Node: Memory Configuration,  Next: Memory Management Configuration,  Prev: CPU Configuration,  Up: Core OpenRISC Configuration
 
3.3.2 Memory Configuration
--------------------------
 
Memory configuration is described in `section memory'.  This section
may appear multiple times, specifying multiple blocks of memory.
 
     Caution: The user may choose whether or not to enable a memory
     controller.  If a memory controller is enabled, then appropriate
     initalization code must be provided.  The section describing
     memory controller configuration describes the steps necessary for
     using smaller or larger memory sections (*note Memory Controller
     Configuration: Memory Controller Configuration.).
 
     The "uClibc" startup code initalizes a memory controller, assumed
     to be mapped at 0x93000000.  If a memory controller is _not_
     enabled, then the standard C library code will generate memory
     access errors.  The solution is to declare an additional writable
     memory block, mimicing the memory controller's register bank as
     follows.
 
          section memory
            pattern = 0x00
            type = unknown
            name = "MC shadow"
            baseaddr = 0x93000000
            size     = 0x00000080
            delayr = 2
            delayw = 4
          end
 
 
The following parameters may be specified.
 
`type=random|pattern|unknown|zero|exitnops'
     Specifies the values to which memory should be initialized.  The
     default value is `unknown'.
 
    `random'
          Set the memory values to be a random value.  A seed for the
          random generator may be set using the `random_seed' field in
          this section (see below), thus ensuring the same "random"
          values are used each time.
 
    `pattern'
          Set the memory values to be a pattern value, which is set
          using the `pattern' field in this section (see below).
 
    `unknown'
          The memory values are not initialized (i.e.  left "unknown").
          This option will yield faster initialization of the
          simulator.  This is the default.
 
    `zero'
          Set the memory values to be 0.  This is the equivalent of
          `type=pattern' and a `pattern' value of 0, and implemented as
          such.
 
               Note: As a consequence, if the `pattern' field is
               _subsequently_ specified in this section, the value in
               that field will be used instead of zero to initialize
               the memory.
 
    `exitnops'
          Set the memory values to be an instruction used to signal end
          of simulation. This is useful for causing immediate end of
          simulation when PC corruption occurs.
 
 
`random_seed = VALUE'
     Set the seed for the random number generator to VALUE.  This only
     has any effect for memory type `random'.
 
     The default value is -1, which means the seed will be set from a
     call to the `time' function, thus ensuring different random values
     are used on each run.  The simulator prints out the seed used in
     this case, allowing repeat runs to regenerate the same random
     values used in any particular run.
 
`pattern = VALUE'
     Set the pattern to be used when initializing memory to VALUE.  The
     default value is 0.  This only has any effect for memory type
     `pattern'.  The least significant 8 bits of this value is used to
     initialize each byte.  More than 8 bits can be specified, but will
     ignored with a warning.
 
          Tip: The default value, is equivalent to setting the memory
          `type' to be `zero'.  If that is what is intended, then using
          `type=zero' explicitly is better than using `type=pattern'
          and not specifying a value for `pattern'.
 
`baseaddr = VALUE'
     Set the base address of the memory to VALUE.  It should be aligned
     to a multiple of the memory size rounded up to the nearest 2^n.
     The default value is 0.
 
`size = VALUE'
     Set the size of the memory block to be VALUE bytes.  This should
     be a multiple of 4 (i.e.  word aligned).  The default value is
     1024.
 
          Note: When allocating memory, the simulator will allocate the
          nearest 2^n bytes greater than or equal to VALUE, and will not
          notice memory misses in any part of the memory between VALUE
          and the amount allocated.
 
          As a consequence users are strongly recommended to specify
          memory sizes that are an exact power of 2.  If some other
          amount of memory is required, it should be specified as
          separate, contiguous blocks, each of which is a power of 2 in
          size.
 
`name = "TEXT"'
     Name the block.  Typically these describe the type of memory being
     modeled (thus `"SRAM"' or `"Flash"'.  The default is
     `"anonymous memory block"'.
 
          Note: It is not clear that this information is currently ever
          used in normal operation of the simulator.  Even the `info'
          command of the simulator ignores it.
 
`ce = VALUE'
     Set the chip enable index of the memory instance.  Each memory
     instance should have a unique chip enable index, which should be
     greater than or equal to zero.  This is used by the memory
     controller when identifying different memory instances.
 
     There is no requirement to set `ce' if a memory controller is not
     enabled.  The default value is -1 (invalid).
 
`mc = VALUE'
     Specifies the memory controller this memory is connected to.  It
     should correspond to the `index' field specified in a `section mc'
     for a memory controller (*note Memory Controller Configuration:
     Memory Controller Configuration.).
 
     There is no requirement to set `mc' if a memory controller is not
     enabled.  Default value is 0, which is also the default value of a
     memory controller `index' field.  This is suitable therefore for
     designs with just one memory controller.
 
`delayr = VALUE'
     The number of cycles required for a read access.  Set to -1 if the
     memory does not support reading.  Default value 1.  The simulator
     will add this number of cycles to the total instruction cycle
     count when reading from main memory.
 
`delayw = VALUE'
     The number of cycles required for a write access.  Set to -1 if the
     memory does not support writing.  Default value 1.  The simulator
     will add this number of cycles to the total instruction cycle
     count when writing to main memory.
 
`log = "FILE"'
     If specified, `file' names a file for all memory accesses to be
     logged.  If not specified, the default value, NULL is used, meaning
     that the memory is not logged.
 
 

File: or1ksim.info,  Node: Memory Management Configuration,  Next: Cache Configuration,  Prev: Memory Configuration,  Up: Core OpenRISC Configuration
 
3.3.3 Memory Management Configuration
-------------------------------------
 
Memory Management Unit (MMU) configuration is described in `section
dmmu' (for the data MMU) and `section immu' (for the instruction MMU).
Each section should appear at most once.  The following parameters may
be specified.
 
`enabled = 0|1'
     If 1 (true), the data or instruction (as appropriate) MMU is
     enabled.  If 0 (the default), it is disabled.
 
`nsets = VALUE'
     Sets the number of data or instruction (as appropriate) TLB sets to
     VALUE, which must be a power of two, not exceeding 128.  Values
     which do not fit these criteria are ignored with a warning.  The
     default value is 1.
 
`nways = VALUE'
     Sets the number of data or instruction (as appropriate) TLB ways to
     VALUE.  The value must be in the range 1 to 4.  Values outside
     this range are ignored with a warning.  The default value is 1.
 
`pagesize = VALUE'
     The data or instruction (as appropriate) MMU page size is set to
     VALUE, which must be a power of 2.  Values which are not a power
     of 2 are ignored with a warning.  The default is 8192 (0x2000).
 
`entrysize = VALUE'
     The data or instruction (as appropriate) MMU entry size is set to
     VALUE, which must be a power of 2.  Values which are not a power
     of 2 are ignored with a warning.  The default value is 1.
 
          Note: Or1ksim does not appear to use the `entrysize' parameter
          in its simulation of the MMUs.  Thus setting this value does
          not seem to matter.
 
`ustates = VALUE'
     The number of instruction usage states for the data or instruction
     (as appropriate) MMU is set to VALUE, which must be 2, 3 or 4.
     Values outside this range are ignored with a warning.  The default
     value is 2.
 
          Note: Or1ksim does not appear to use the `ustates' parameter
          in its simulation of the MMUs.  Thus setting this value does
          not seem to matter.
 
`hitdelay = VALUE'
     Set the number of cycles a data or instruction (as appropriate) MMU
     hit costs.  Default value 1.
 
`missdelay = VALUE'
     Set the number of cycles a data or instruction (as appropriate) MMU
     miss costs.  Default value 1.
 
 

File: or1ksim.info,  Node: Cache Configuration,  Next: Interrupt Configuration,  Prev: Memory Management Configuration,  Up: Core OpenRISC Configuration
 
3.3.4 Cache Configuration
-------------------------
 
Cache configuration is described in `section dc' (for the data cache)
and `seciton ic' (for the instruction cache).  Each section should
appear at most once.  The following parameters may be specified.
 
`enabled = 0|1'
     If 1 (true), the data or instruction (as appropriate) cache is
     enabled.  If 0 (the default), it is disabled.
 
`nsets = VALUE'
     Sets the number of data or instruction (as appropriate) cache sets
     to VALUE, which must be a power of two, not exceeding
     `MAX_DC_SETS' (for the data cache) or `MAX_IC_SETS' (for the
     instruction cache).  At the time of writing, these constants are
     both defined in the code to be 1024).  The default value is 1.
 
`nways = VALUE'
     Sets the number of data or instruction (as appropriate) cache ways
     to VALUE, which must be a power of two, not exceeding
     `MAX_DC_WAYS' (for the data cache) or `MAX_IC_WAYS' (for the
     instruction cache).  At the time of writing, these constants are
     both defined in the code to be 32).  The default value is 1.
 
`blocksize = VALUE'
     The data or instruction (as appropriate) cache block size is set to
     VALUE bytes, which must be either 16 or 32.  The default is 16.
 
`ustates = VALUE'
     The number of instruction usage states for the data or instruction
     (as appropriate) cache is set to VALUE, which must be 2, 3 or 4.
     The default value is 2.
 
`hitdelay = VALUE'
     _Instruction cache only_.  Set the number of cycles an instruction
     cache hit costs.  Default value 1.
 
`missdelay = VALUE'
     _Instruction cache only_.  Set the number of cycles an instruction
     cache miss costs.  Default value 1.
 
`load_hitdelay = VALUE'
     _Data cache only_.  Set the number of cycles a data load cache hit
     costs.  Default value 2.
 
`load_missdelay = VALUE'
     _Data cache only_.  Set the number of cycles a data load cache
     miss costs.  Default value 2.
 
`store_hitdelay = VALUE'
     _Data cache only_.  Set the number of cycles a data store cache hit
     costs.  Default value 0.
 
`store_missdelay = VALUE'
     _Data cache only_.  Set the number of cycles a data store cache
     miss costs.  Default value 0.
 
 

File: or1ksim.info,  Node: Interrupt Configuration,  Next: Power Management Configuration,  Prev: Cache Configuration,  Up: Core OpenRISC Configuration
 
3.3.5 Interrupt Configuration
-----------------------------
 
Programmable Interrupt Controller (PIC) configuration is described in
`section pic'.  This section may appear at most once--Or1ksim has no
mechanism for handling multiple interrupt controllers.  The following
parameters may be specified.
 
`enabled = 0|1'
     If 1 (true), the programmable interrupt controller is enabled.  If
 
 
`edge_trigger = 0|1'
     If 1 (true, the default), the programmable interrupt controller is
     edge triggered.  If 0 (false), it is level triggered.
 
     The library interface (*note Simulator Library: Simulator Library.)
     provides different functions for setting the different types of
     interrupt, and a function to clear level sensitive interrupts. Edge
     sensitive interrupts must be cleared by clearing the corresponding
     bit in the PICSR SPR.
 
     Internal functions to set and clear interrupts are also provided
     for peripherals implemented within Or1ksim. *Note Interrupts
     Internal: Interrupts Internal for more details.
 
`use_nmi = 0|1'
     If 1 (true, the default), interrupt lines 0 and 1 are
     non-maskable. In other words the least significant 2 bits of the
     PICMR SPR are hard-wired to 1.  If 0 (false), all interrupt lines
     are treated as equivalent.
 
          Note: These are not non-maskable in the true sense that they
          will pre-empt other interrupts.  Rather they can never be
          masked out using the PICMR register. It is up the interrupt
          exception handler to give these interrupt lines priority, and
          indeed to decide on the priority order in general.
 
 

File: or1ksim.info,  Node: Power Management Configuration,  Next: Branch Prediction Configuration,  Prev: Interrupt Configuration,  Up: Core OpenRISC Configuration
 
3.3.6 Power Management Configuration
------------------------------------
 
Power management implementation is incomplete.  At present the effect
(which only happens when the power management unit is enabled) of
setting the different bits in the power management Special Purpose
Register (PMR, SPR 0x4000) is
 
`SDF (bit mask 0x0000000f)'
     No effect - these bits are ignored
 
`DME (bit mask 0x00000010)'
`SME (bit mask 0x00000020)'
     Both these bits cause the processor to stop executing
     instructions.  However all other functions (debug interaction, CLI,
     VAPI etc) carry on as normal.
 
`DCGE (bit mask 0x00000004)'
     No effect - this bit is ignored
 
`SUME (bit mask 0x00000008)'
     Enabling this bit causes a message to be printed, advising that the
     processor is suspending and the simulator exits.
 
 
On reset all bits are cleared.
 
Power management configuration is described in `section pm'.  This
section may appear at most once.  The following parameter may be
specified.
 
`enabled = 0|1'
     If 1 (true), power management is enabled.  If 0 (the default), it
     is disabled.
 
 

File: or1ksim.info,  Node: Branch Prediction Configuration,  Next: Debug Interface Configuration,  Prev: Power Management Configuration,  Up: Core OpenRISC Configuration
 
3.3.7 Branch Prediction Configuration
-------------------------------------
 
From examining the code base, it seems the branch prediction function
is not fully implemented.  At present the functionality seems
restricted to collection of statistics.
 
Branch prediction configuration is described in `section bpb'.  This
section may appear at most once.  The following parameters may be
specified.
 
`enabled = 0|1'
     If 1 (true), branch prediction is enabled.  If 0 (the default), it
     is disabled.
 
`btic = 0|1'
     If 1 (true), the branch target instruction cache model is enabled.
     If 0 (the default), it is disabled.
 
`sbp_bf_fwd = 0|1'
     If 1 (true), use forward prediction for the `l.bf' instruction.  If
 
     instruction.
 
`sbp_bnf_fwd = 0|1'
     If 1 (true), use forward prediction for the `l.bnf' instruction.
     If 0 (the default), do not use forward prediction for this
     instruction.
 
`hitdelay = VALUE'
     Set the number of cycles a branch prediction hit costs.  Default
     value 0.
 
`missdelay = VALUE'
     Set the number of cycles a branch prediction miss costs.  Default
     value 0.
 
 

File: or1ksim.info,  Node: Debug Interface Configuration,  Prev: Branch Prediction Configuration,  Up: Core OpenRISC Configuration
 
3.3.8 Debug Interface Configuration
-----------------------------------
 
The debug unit and debug interface configuration is described in
`section debug'.  This section may appear at most once.  The following
parameters may be specified.
 
`enabled = 0|1'
     If 1 (true), the debug unit is enabled.  If 0 (the default), it is
     disabled.
 
          Note: This enables the functionality of the debug unit (its
          registers etc) within the mode.  It does not provide any
          external interface to the debug unit.  For that, see
          `rsp_enabled' below.
 
`rsp_enabled = 0|1'
     If 1 (true), the GDB "Remote Serial Protocol" server is started,
     provding an interface to an external GNU debugger, using the port
     specified in the `rsp_port' field (see below), or the
     `or1ksim-rsp' TCP/IP service.  If 0 (the default), the server is
     not started, and no external interface is provided.
 
     For more detailed information on the interface to the GNU Debugger
     see Embecosm Application Note 2, `Howto: Porting the GNU Debugger
     Practical Experience with the OpenRISC 1000 Architecture', by
     Jeremy Bennett, published by Embecosm Limited (`www.embecosm.com').
 
`rsp_port = VALUE'
     VALUE specifies the port to be used for the GDB "Remote Serial
     Protocol" interface to the GNU Debugger (GDB).  Default value
     51000.  If the value 0 is specified, Or1ksim will instead look for
     a TCP/IP service named `or1ksim-rsp'.
 
          Tip: There is no registered port for Or1ksim "Remote Serial
          Protocol" service `or1ksim-rsp'.  Good practice suggests
          users should adopt port values in the "Dynamic" or "Private"
          port range, i.e.  49152-65535.
 
`vapi_id = VALUE'
     VALUE specifies the value of the Verification API (VAPI) base
     address to be used with the debug unit.  *Note Verification API:
     Verification API, for more details.
 
     If this is specified and VALUE is non-zero, all OpenRISC Remote
     JTAG protocol transactions will be logged to the VAPI log file, if
     enabled.  This is the only functionality associated with VAPI for
     the debug unit.  No VAPI commands are sent, nor requests handled.
 
 

File: or1ksim.info,  Node: Peripheral Configuration,  Prev: Core OpenRISC Configuration,  Up: Configuration
 
3.4 Configuring Memory Mapped Peripherals
=========================================
 
All peripheral components are optional.  If they are specified, then
(unlike other components) by default they are enabled.
 
* Menu:
 
* Memory Controller Configuration::
* UART Configuration::
* DMA Configuration::
* Ethernet Configuration::
* GPIO Configuration::
* Display Interface Configuration::
* Frame Buffer Configuration::
* Keyboard Configuration::
* Disc Interface Configuration::
* Generic Peripheral Configuration::
 

File: or1ksim.info,  Node: Memory Controller Configuration,  Next: UART Configuration,  Up: Peripheral Configuration
 
3.4.1 Memory Controller Configuration
-------------------------------------
 
The memory controller used in Or1ksim is the component implemented at
OpenCores, and found in the top level SVN directory, `mem_ctrl'.  It is
described in the document `Memory Controller IP Core' by Rudolf
Usselmann, which can be found in the `doc' subdirectory.  It is a
memory mapped component, which resides on the main OpenRISC Wishbone
data bus.
 
The memory controller configuration is described in `section mc'.  This
section may appear multiple times, specifying multiple memory
controllers.
 
     Warning: There are known to be problems with the current memory
     controller, which currently is not included in the regression test
     suite. Users are advised not to use the memory controller in the
     current release.
 
     Caution: There is no initialization code in the standard "newlib"
     library.
 
     The standard "uClibc" library assumes a memory controller mapped
     at 0x93000000 and will initialize the memory controller to expect
     64MB memory blocks, and any memory declarations _must_ reflect
     this.
 
     If smaller memory blocks are declared with a memory controller,
     then sufficient memory will not be allocated by Or1ksim, but out of
     range memory accesses will not be trapped.  For example declaring a
     memory section from 0-4MB with a memory controller enabled would
     mean that accesses between 4MB and 64MB would be permitted, but
     having no allocated memory would likely cause a segmentation fault.
 
     If the user is determined to use smaller memories with the memory
     controller, then custom initialization code must be provided, to
     ensure the memory controller traps out-of-memory accesses.
 
The following parameters may be specified.
 
`enabled = 0|1'
     If 1 (true, the default), this memory controller is enabled.  If
     0, it is disabled.
 
          Note: The memory controller can effectively also be disabled
          by setting an appropriate power on control register value
          (see below).  However this should only be used if it is
          desired to specifically model this behavior of the memory
          controller, not as a way of disabling the memory controller
          in general.
 
`baseaddr = VALUE'
     Set the base address of the memory controller's memory mapped
     registers to VALUE.  The default is 0, which is probably not a
     sensible value.
 
     The memory controller has a 7 bit address bus, with a total of 19
     32-bit registers, at addresses 0x00 through 0x4c (address 0x0c and
     addresses 0x50 through 0x7c are not used).
 
`poc = VALUE'
     Specifies the value of the power on control register, The least
     signficant two bits specify the bus width (use 0 for an 8-bit bus,
     1 for a 16-bit bus and 2 for a 32-bit bus) and the next two bits
     the type of memory connected (use 0 for a disabled interface, 1
     for SSRAM, 2 for asyncrhonous devices and 3 for synchronous
     devices).
 
     If other bits are specified, they are ignored with a warning.
 
          Caution: The default value, 0, corresponds to a disabled
          8-bit bus, and is likely not the most suitable value
 
`index = VALUE'
     Specify the index of this memory controller amongst all the memory
     controllers.  This value should be unique for each memory
     controller, and is used to associate specific memories with the
     controller, through the `mc' field in the `section memory'
     configuration (*note Memory Configuration: Memory Configuration.).
 
     The default value, 0, is suitable when there is only one memory
     controller.
 
 

File: or1ksim.info,  Node: UART Configuration,  Next: DMA Configuration,  Prev: Memory Controller Configuration,  Up: Peripheral Configuration
 
3.4.2 UART Configuration
------------------------
 
The UART implemented in Or1ksim follows the specification of the
National Semiconductor 16450 and 16550 parts.  It is a memory mapped
component, which resides on the main OpenRISC Wishbone data bus.
 
The component provides a number of interfaces to emulate the behavior
of an external terminal connected to the UART.
 
UART configuration is described in `section uart'.  This section may
appear multiple times, specifying multiple UARTs.  The following
parameters may be specified.
 
`enabled = 0|1'
     If 1 (true, the default), this UART is enabled.  If 0, it is
     disabled.
 
`baseaddr = VALUE'
     Set the base address of the UART's memory mapped registers to
     VALUE.  The default is 0, which is probably not a sensible value.
 
     The UART has a 3 bit address bus, with a total of 8 8-bit
     registers, at addresses 0x0 through 0x7.
 
`channel = "TYPE:ARGS"'
     Specify the channel representing the terminal connected to the UART
     Rx & Tx pins.
 
    `channel="file:`rxfile',`txfile'"'
          Read input characters from the file `rxfile' and write output
          characters to the file `txfile' (which will be created if
          required).
 
    `channel="xterm:ARGS"'
          Create an xterm on startup, write UART Tx traffic to the
          xterm and take Rx traffic from the keyboard when the xterm
          window is selected.  Additional arguments to the xterm
          command (for example specifying window size may be specified
          in ARGS, or this may be left blank.
 
    `channel="tcp:VALUE"'
          Open the TCP/IP port specified by VALUE and read and write
          UART traffic from and to it.
 
          Typically a telnet session is connected to the other end of
          this port.
 
               Tip: There is no registered port for Or1ksim telnet UART
               connection.  Priviledged access is required to read
               traffic on the registered "well-known" telnet port (23).
               Instead users should use port values in the "Dynamic" or
               "Private" port range, i.e.  49152-65535.
 
    `channel="fd:`rxfd',`txfd'"'
          Read and write characters from and to the existing open
          numerical file descriptors, file `rxfd' and `txfd'.
 
    `channel="tty:device=/dev/ttyS0,baud=9600"'
          Read and write characters from and to a physical serial port.
          The precise device (shown here as `/dev/ttyS0') may vary from
          machine to machine.
 
 
     The default value for this field is `"xterm:"'.
 
`irq = VALUE'
     Use VALUE as the IRQ number of this UART.  Default value 0.
 
`16550 = 0|1'
     If 1 (true), the UART has the functionality of a 16550.  If 0 (the
     default), it has the functionality of a 16450.  The principal
     difference is that the 16550 can buffer multiple characters.
 
`jitter = VALUE'
     Set the jitter, modeled as a time to block, to VALUE milliseconds.
     Set to -1 to disable jitter modeling.  Default value 0.
 
          Note: This functionality has yet to be implemented, so this
          parameter has no effect.
 
`vapi_id = VALUE'
     VALUE specifies the value of the Verification API (VAPI) base
     address to be used with the UART.  *Note Verification API:
     Verification API, for more details, which details the use of the
     VAPI with the UART.
 
 

File: or1ksim.info,  Node: DMA Configuration,  Next: Ethernet Configuration,  Prev: UART Configuration,  Up: Peripheral Configuration
 
3.4.3 DMA Configuration
-----------------------
 
The DMA controller used in Or1ksim is the component implemented at
OpenCores, and found in the top level SVN directory, `wb_dma'.  It is
described in the document `Wishbone DMA/Bridge IP Core' by Rudolf
Usselmann, which can be found in the `doc' subdirectory.  It is a
memory mapped component, which resides on the main OpenRISC Wishbone
data bus.  The present implementation is incomplete, intended only to
support the Ethernet interface (*note Ethernet Configuration::),
although the Ethernet interface is not yet completed.
 
DMA configuration is described in `section dma'.  This section may
appear multiple times, specifying multiple DMA controllers.  The
following parameters may be specified.
 
`enabled = 0|1'
     If 1 (true, the default), this DMA controller is enabled.  If 0,
     it is disabled.
 
`baseaddr = VALUE'
     Set the base address of the DMA's memory mapped registers to
     VALUE.  The default is 0, which is probably not a sensible value.
 
     The DMA controller has a 10 bit address bus, with a total of 253
     32-bit registers.  The first 5 registers at addresses 0x000 through
     0x010 control the overall behavior of the DMA controller.  There
     are then 31 blocks of 8 registers, controlling each of the 31 DMA
     channels available.  Addresses 0x014 through 0x01c are not used.
 
`irq = VALUE'
     Use VALUE as the IRQ number of this DMA controller.  Default value
     0.
 
`vapi_id = VALUE'
     VALUE specifies the value of the Verification API (VAPI) base
     address to be used with the DMA controller.  *Note Verification
     API: Verification API, for more details, which details the use of
     the VAPI with the DMA controller.
 
 

File: or1ksim.info,  Node: Ethernet Configuration,  Next: GPIO Configuration,  Prev: DMA Configuration,  Up: Peripheral Configuration
 
3.4.4 Ethernet Configuration
----------------------------
 
Ethernet configuration is described in `section ethernet'.  This
section may appear multiple times, specifying multiple Ethernet
interfaces.  The following parameters may be specified.
 
The Ethernet MAC used in Or1ksim corresponds to the Verilog
implementation in project "ethmac". It's source code can be found in
the top level SVN directory, `ethmac'.  It also forms part of the
OpenRISC reference SoC, ORPSoC.  It is described in the document
`Ethernet IP Core Specification' by Igor Mohor, which can be found in
the `doc' subdirectory.  It is a memory mapped component, which resides
on the main OpenRISC Wishbone data bus.
 
`enabled = 0|1'
     If 1 (true, the default), this Ethernet MAC is enabled.  If 0, it
     is disabled.
 
`baseaddr = VALUE'
     Set the base address of the MAC's memory mapped registers to
     VALUE.  The default is 0, which is probably not a sensible value.
 
     The Ethernet MAC has a 7-bit address bus, with a total of 21
     32-bit registers.  Addresses 0x54 through 0x7c are not used.
 
          Note: The Ethernet specification describes a Tx control
          register, `TXCTRL', at address 0x50.  However this register
          is not implemented in the Or1ksim model.
 
`dma = VALUE'
     VALUE specifies the DMA controller with which this Ethernet is
     associated.  The default value is 0.
 
          Note: Support for external DMA is not provided in the current
          implementation, and this value is ignored.  In any case there
          is no equivalent field to which this can be matched in the
          current DMA component implementation (*note DMA
          Configuration: DMA Configuration.).
 
`irq = VALUE'
     Use VALUE as the IRQ number of this Ethernet MAC.  Default value 0.
 
`rtx_type = "file"|"tap"'
     Specifies whether to use a TUN/TAP interface or file interface
     (the default) to model the external connection of the Ethernet.
 
     If a TUN/TAP interface is requested, Ethernet packets will be sent
     and received through the pesistent TAP interface specified in
     parameter `tap_dev' (see below).
 
     More details on configuring the TUN/TAP interface are given in the
     Usage section (*note Ethernet TUN/TAP Interface: Ethernet TUN/TAP
     Interface.).
 
     If a file interface (the default), is requested, the Ethernet will
     be modelled by reading and writing from and to the files specified
     in the `rxfile' and `txfile' parameters (see below).
 
          Caution: If a file interface is specified, Or1ksim will
          terminate once the receive file specified by `rxfile' is
          exhausted.
 
`rx_channel = RXVALUE'
`tx_channel = TXVALUE'
     RXVALUE specifies the DMA channel to use for receive and TXVALUE
     the DMA channel to use for transmit.  Both default to 0.
 
          Note: As noted above, support for external DMA is not
          provided in the current implementation, and so these values
          are ignored.
 
`rxfile = "RXFILE"'
`txfile = "TXFILE"'
     When `rtx_type' is 0 (see above), RXFILE specifies the file to use
     as input and TXFILE specifies the fie to use as output.
 
     The file contains a sequence of packets.  Each packet consists of a
     packet length (32 bits), followed by that many bytes of data.
     Once the input file is empty, the Ethernet MAC behaves as though
     there were no data on the Ethernet.  The default values of these
     parameters are `"eth_rx"' and `"eth_tx"' respectively.
 
     The input file must exist and be readable.  The output file must be
     writable and will be created if necessary.  If either of these
     conditions is not met, a warning will be given.
 
          Caution: Or1ksim will terminate once the RXFILE is exhausted.
 
`tap_dev = "TAP"'
     When `rtx_type' is `"tap"' (see above), TAP_DEV specifies the TAP
     device to use for communication.  This should be a persistent TAP
     device configured for the system (*note Ethernet TUN/TAP
     Interface: Ethernet TUN/TAP Interface.)
 
`phy_addr = VALUE'
     VALUE specifies the address for emulated ethernet PHY (default 0).
     If there are multiple Ethernet peripherals, they should each have a
     different PHY value.
 
`dummy_crc = 0|1'
     If 1 (true, the default), the length of the data transferred to
     the core will be increased by 4 bytes, as though the CRC were
     included.
 
          Note: This is for historical consistency with the OpenRISC
          Ethernet hardware MAC, which passes on the CRC in the data
          packet. This is unusual behavior for a MAC, but the OpenRISC
          Linux device drivers have been written to expect it.
 
`phy_addr = VALUE'
     VALUE specifies the address for emulated ethernet PHY (default 0).
     If there are multiple Ethernet peripherals, they should each have a
     different PHY value.
 
`vapi_id = VALUE'
     VALUE specifies the value of the Verification API (VAPI) base
     address to be used with the Ethernet PHY.  *Note Verification API:
     Verification API, for more details, which details the use of the
     VAPI with the DMA controller.
 
 

File: or1ksim.info,  Node: GPIO Configuration,  Next: Display Interface Configuration,  Prev: Ethernet Configuration,  Up: Peripheral Configuration
 
3.4.5 GPIO Configuration
------------------------
 
The GPIO used in Or1ksim is the component implemented at OpenCores, and
found in the top level SVN directory, `gpio'.  It is described in the
document `GPIO IP Core Specification' by Damjan Lampret and Goran
Djakovic, which can be found in the `doc' subdirectory.  It is a memory
mapped component, which resides on the main OpenRISC Wishbone data bus.
 
GPIO configuration is described in `section gpio'.  This section may
appear multiple times, specifying multiple GPIO devices.  The following
parameters may be specified.
 
`enabled = 0|1'
     If 1 (true, the default), this GPIO is enabled.  If 0, it is
     disabled.
 
`baseaddr = VALUE'
     Set the base address of the GPIO's memory mapped registers to
     VALUE.  The default is 0, which is probably not a sensible value.
 
     The GPIO has a 6 bit address bus, with a total of 10 32-bit
     registers, although the number of bits that are actively used
     varies.  Addresses 0x28 through 0x3c are not used.
 
`irq = VALUE'
     Use VALUE as the IRQ number of this GPIO.  Default value 0.
 
`vapi_id = VALUE'
     VALUE specifies the value of the Verification API (VAPI) base
     address to be used with the GPIO.  *Note Verification API:
     Verification API, for more details, which details the use of the
     VAPI with the GPIO controller.  For backwards compatibility, the
     alternative name `base_vapi_id' is supported for this parameter,
     but deprecated.
 
 

File: or1ksim.info,  Node: Display Interface Configuration,  Next: Frame Buffer Configuration,  Prev: GPIO Configuration,  Up: Peripheral Configuration
 
3.4.6 Display Interface Configuration
-------------------------------------
 
Or1ksim models a VGA interface to an external monitor.  The VGA
controller used in Or1ksim is the component implemented at OpenCores,
and found in the top level SVN directory, `vga_lcd', with no support
for the optional hardware cursors.  It is described in the document
`VGA/LCD Core v2.0 Specifications' by Richard Herveille, which can be
found in the `doc' subdirectory.  It is a memory mapped component,
which resides on the main OpenRISC Wishbone data bus.
 
The current implementation provides only functionality to dump the
screen to a file at intervals.
 
VGA controller configuration is described in `section vga'.  This
section may appear multiple times, specifying multiple VGA controllers.
The following parameters may be specified.
 
`enabled = 0|1'
     If 1 (true, the default), this VGA is enabled.  If 0, it is
     disabled.
 
`baseaddr = VALUE'
     Set the base address of the VGA controller's memory mapped
     registers to VALUE.  The default is 0, which is probably not a
     sensible value.
 
     The VGA controller has a 12-bit address bus, with 7 32-bit
     registers, at addresses 0x000 through 0x018, and two color lookup
     tables at addresses 0x800 through 0xfff.  The hardware cursor
     registers are not implemented, so addresses 0x01c through 0x7fc
     are not used.
 
`irq = VALUE'
     Use VALUE as the IRQ number of this VGA controller.  Default value
     0.
 
`refresh_rate = VALUE'
     VALUE specifies number of cycles between screen dumps.  Default
     value is derived from the simulation clock cycle time (*note
     Simulator Behavior: Simulator Behavior.), to correspond to dumping
     50 times per simulated second.
 
`txfile = "FILE"'
     FILE specifies the base of the filename for screen dumps.
     Successive screen dumps will be in BMP format, in files with the
     name `FILENNNN.bmp', where NNNN is a sequential count of the
     screen dumps starting at zero.  The default value is `"vga_out"'.
     For backwards compatibility, the alternative name `filename' is
     supported for this parameter, but deprecated.
 
 

File: or1ksim.info,  Node: Frame Buffer Configuration,  Next: Keyboard Configuration,  Prev: Display Interface Configuration,  Up: Peripheral Configuration
 
3.4.7 Frame Buffer Configuration
--------------------------------
 
     Caution: The frame buffer is only partially implemented.  Its
     configuration fields are described here, but the component should
     not be used at this time.  Like the VGA controller, it is designed
     to make screen dumps to file.
 
Frame buffer configuration is described in `section fb'.  This section
may appear multiple times, specifying multiple frame buffers.  The
following parameters may be specified.
 
`enabled = 0|1'
     If 1 (true, the default), this frame buffer is enabled.  If 0, it
     is disabled.
 
`baseaddr = VALUE'
     Set the base address of the frame buffer's memory mapped registers
     to VALUE.  The default is 0, which is probably not a sensible
     value.
 
     The frame buffer has an 121-bit address bus, with 4 32-bit
     registers, at addresses 0x000 through 0x00c, and a PAL lookup
     table at addresses 0x400 through 0x4ff.  Addresses 0x010 through
     0x3fc and addresses 0x500 through 0x7ff are not used.
 
`refresh_rate = VALUE'
     VALUE specifies number of cycles between screen dumps.  Default
     value is derived from the simulation clock cycle time (*note
     Simulator Behavior: Simulator Behavior.), to correspond to dumping
     50 times per simulated second.
 
`txfile = "FILE"'
     FILE specifies the base of the filename for screen dumps.
     Successive screen dumps will be in BMP format, in files with the
     name `FILENNNN.bmp', where NNNN is a sequential count of the
     screen dumps starting at zero.  The default value is `"fb_out"'.
     For backwards compatibility, the alternative name `filename' is
     supported for this parameter, but deprecated.
 
 

File: or1ksim.info,  Node: Keyboard Configuration,  Next: Disc Interface Configuration,  Prev: Frame Buffer Configuration,  Up: Peripheral Configuration
 
3.4.8 Keyboard Configuration (PS2)
----------------------------------
 
The PS2 interface provided by Or1ksim is not documented.  It may be
based on the PS2 project at OpenCores, and found in the top level SVN
directory, `ps2'.  However this project lacks any documentation beyond
its project webpage.  Since most PS2 interfaces follow the Intel i8042
standard, this is presumably what is expected with this device.
 
The implementation only provides for keyboard support, which is
modelled as a file of keystrokes.  There is no mouse support.
 
     Caution: A standard i8042 device has two registers at addresses
     0x60 (command) and 0x64 (status).  Inspection of the code,
     suggests that the Or1ksim component places these registers at
     addresses 0x00 and 0x04.
 
     The port of Linux for the OpenRISC 1000, which runs on Or1ksim
     implements the i8042 device driver, anticipating these registers
     reside at their conventional address.  It seems unlikel that this
     code will work.
 
     This component should be used with caution.
 
Keyboard configuration is described in `section kbd'.  This section may
appear multiple times, specifying multiple keyboard interfaces.  The
following parameters may be specified.
 
`enabled = 0|1'
     If 1 (true, the default), this keyboard is enabled.  If 0, it is
     disabled.
 
`baseaddr = VALUE'
     Set the base address of the keyboard's memory mapped registers to
     VALUE.  The default is 0, which is probably not a sensible value.
 
     The keyboard PS/2 interface has an 3-bit address bus, with 2 8-bit
     registers, at addresses 0x000 and 0x004.
 
          Caution: As noted above, a standard Intel 8042 interface
          would expect to find these registers at locations 0x60 and
          0x64, thus requiring at least a 7-bit bus.
 
`irq = VALUE'
     Use VALUE as the IRQ number of this Keyboard interface.  Default
     value 0.
 
`rxfile = "FILE"'
     `file' specifies a file containing raw key stroke data, which
     models the input from a physical keyboard.  The default value is
     `"kbd_in"'.
 
 

File: or1ksim.info,  Node: Disc Interface Configuration,  Next: Generic Peripheral Configuration,  Prev: Keyboard Configuration,  Up: Peripheral Configuration
 
3.4.9 Disc Interface Configuration
----------------------------------
 
The ATA/ATAPI disc controller used in Or1ksim is the OCIDEC (OpenCores
IDE Controller) component implemented at OpenCores, and found in the
top level SVN directory, `ata'.  It is described in the document
`ATA/ATAPI-5 Core Specification' by Richard Herveille, which can be
found in the `doc' subdirectory.  It is a memory mapped component,
which resides on the main OpenRISC Wishbone data bus.
 
     Warning: In the current release of Or1ksim, parsing of the ATA
     section is broken. Users should not configure the disc interface
     in this release.
 
ATA/ATAPI configuration is described in `section ata'.  This section
may appear multiple times, specifying multiple disc controllers.  The
following parameters may be specified.
 
`enabled = 0|1'
     If 1 (true, the default), this ATA/ATAPI interface is enabled.  If
     0, it is disabled.
 
`baseaddr = VALUE'
     Set the base address of the ATA/ATAPI interface's memory mapped
     registers to VALUE.  The default is 0, which is probably not a
     sensible value.
 
     The ATA/ATAPI PS/2 interface has an 5-bit address bus, with 8
     32-bit registers.  Depending on the version of the OCIDEC
     ATA/ATAPI interface selected (see `dev_id' below), not all
     registers will be available.
 
`irq = VALUE'
     Use VALUE as the IRQ number of this ATA/ATAPI interface.  Default
     value 0.
 
`dev_id = 1|2|3'
     This parameter specifies which version of the OCIDEC ATA/ATAPI
     interface to model.  The default value is 1.
 
     Version 1 supports only the `CTRL', `STAT' and `PCTR' registers.
     Versions 2 & 3 add the `FCTR' registers, Version 3 adds the `DTR'
     registers and the `RXD'/`TXD' registers.
 
`rev = VALUE'
     Set the VALUE as the revision of the OCIDEC ATA/ATAPI interface.
     The default value is 1.  The default value is 0.  Its value should
     be in the range 0-15.  Larger values are truncated with a warning.
     This only affects the reset value of the `STAT' register, where it
     forms bits 24-27.
 
`pio_mode0_t1 = VALUE'
`pio_mode0_t2 = VALUE'
`pio_mode0_t4 = VALUE'
`pio_mode0_teoc = VALUE'
     These parameters specify the timings for use with Programmed
     Input/Output (PIO) transfers.  They are specified as the number of
     clock cycles - 2, rounded up to the next highest integer, or zero
     if that would be negative.  The values should not exceed 255.  If
     they do, they will be ignored with a warning.
 
     See the ATA/ATAPI-5 specification for explanations of each of these
     timing parameters.  The default values are:
 
          pio_mode0_t1   =  6
          pio_mode0_t2   = 28
          pio_mode0_t4   =  2
          pio_mode0_teoc = 23
 
`dma_mode0_tm = VALUE'
`dma_mode0_td = VALUE'
`dma_mode0_teoc = VALUE'
     These parameters specify the timings for use with DMA transfers.
     They are specified as the number of clock cycles - 2, rounded up
     to the next highest integer, or zero if that would be negative.
     The values should not exceed 255.  If they do, they will be
     ignored with a warning.
 
     See the ATA/ATAPI-5 specification for explanations of each of these
     timing parameters.  The default values are:
 
          dma_mode0_tm   =  4
          dma_mode0_td   = 21
          dma_mode0_teoc = 21
 
 
3.4.9.1 ATA/ATAPI Device Configuration
......................................
 
Within the `section ata', each device is specified separately.  The
device subsection is introduced by
 
     device VALUE
 
VALUE is the device number, which should be 0 or 1.  The subsection
ends with `enddevice'.  Note that if the same device number is
specified more than once, the previous values will be overwritten.
Within the `device' subsection, the following parameters may appear:
 
`type = VALUE'
     VALUEspecifies the type of device: 0 (the default) for "not
     connected", 1 for hard disk simulated in a file and 2 for local
     system hard disk.
 
`file = "FILENAME"'
     `filename' specifies the file to be used for a simulated ATA
     device if the file type (see `type' above) is 1.  Default value
     `"ata_fileN"', where N is the device number.
 
`size = VALUE'
     VALUE specifies the size of a simulated ATA device if the file
     type (see `type' above) is 1.  The default value is zero.
 
`packet = 0|1'
     If 1 (true), implement the PACKET command feature set.  If 0 (the
     default), do not implement the PACKET command feature set.
 
`firmware = "STR"'
     Firmware to report in response to the "Identify Device" command.
     Default `"02207031"'.
 
`heads = VALUE'
     Number of heads in the device.  Default 7, use -1 to disable all
     heads.
 
`sectors = VALUE'
     Number of sectors per track in the device.  Default 32.
 
`mwdma = 0|1|2|-1'
     Highest multi-word DMA mode supported.  Default 2, use -1 to
     disable.
 
`pio = 0|1|2|3|4'
     Highest PIO mode supported.  Default 4.
 
 

File: or1ksim.info,  Node: Generic Peripheral Configuration,  Prev: Disc Interface Configuration,  Up: Peripheral Configuration
 
3.4.10 Generic Peripheral Configuration
---------------------------------------
 
When used as a library (*note Simulator Library: Simulator Library.),
Or1ksim makes provision for any additional peripheral to be implemented
externally.  Any read or write access to this peripheral's memory map
generates "upcall"s to an external handler.  This interface can support
either C or C++, and was particularly designed to facilitate support
for OSCI SystemC (see `http://www.systemc.org').
 
Generic peripheral configuration is described in `section generic'.
This section may appear multiple times, specifying multiple external
peripherals.  The following parameters may be specified.
 
`enabled = 0|1'
     If 1 (true, the default), this ATA/ATAPI interface is enabled.  If
     0, it is disabled.
 
`baseaddr = VALUE'
     Set the base address of the generic peripheral's memory mapped
     registers to VALUE.  The default is 0, which is probably not a
     sensible value.
 
     The size of the memory mapped register space is controlled by the
     `size' paramter, described below.
 
`size = VALUE'
     Set the size of the generic peripheral's memory mapped register
     space to VALUE bytes.  Any read or write accesses to addresses with
     offsets of 0 to VALUE-1 bytes from the base address specified in
     parameter `baseaddr' (see above) will be directed to the external
     interface.
 
     VALUE will be rounded up the nearest power of 2.  It's default
     value is zero.  If VALUE is not an exact power of two, accesses to
     address offsets of VALUE or above up to the next power of 2 will
     generate a warning, and have no effect (reads will return zero).
 
`name = "STR"'
     This gives the peripheral the name `"STR"'.  This is used to
     identify the peripheral in error messages and warnings, and when
     reporting its status.  The default value is
     `"anonymous external peripheral"'.
 
`byte_enabled = 0|1'
`hw_enabled = 0|1'
`word_enabled = 0|1'
     If 1 (true, the default), these parameters respectively enable the
     device for byte wide, half-word wide and word wide accesses.  If 0,
     accesses of that width will fail.
 
 

File: or1ksim.info,  Node: Interactive Command Line,  Next: Verification API,  Prev: Configuration,  Up: Top
 
4 Interactive Command Line
**************************
 
If started with the `-f' flag, or if interrupted with `ctrl-C', Or1ksim
provides the user with an interactive command line.  The commands
available, which may not be abbreviated, are:
 
`q'
     Exit the simulator
 
`r'
     Display all the General Purpose Registers (GPRs).  Also shows the
     just executed and next to be executed instructions symbolically
     and the state of the flag in the Supervision Register.
 
`t'
     Execute the next instruction and then display register/instruction
     information as with the `r' command (see above).
 
`run NUM [ hush ]'
     Execute NUM instructions.  The register/instruction information is
     displayed after each instruction, as with the `r' command (see
     above) _unless_ `hush' is specified.
 
`pr REG VALUE'
     Patch register REG with VALUE.
 
`dm FROMADDR [ TOADDR ]'
     Display memory bytes between FROMADDR and TOADDR.  If TOADDR is
     not given, 64 bytes are displayed, starting at FROMADDR.
 
          Caution: The output from this command is broken (a bug).
          Or1ksim attempts to print out 16 bytes per row.  However,
          instead of printing out the address at the start of each row,
          it prints the address (of the first of the 16 bytes) before
          _each_ byte.
 
`de FROMADDR [ TOADDR ]'
     Disassemble code between FROMADDR and TOADDR.  If TOADDR is not
     given, 16 instructions are disassembled.
 
     The disassembly is entirely numerical, and gives no symbolic
     information.
 
`pm ADDR VALUE'
     Patch the 4 bytes in memory starting at ADDR with the 32-bit VALUE.
 
`pc VALUE'
     Patch the program counter with VALUE.
 
`cm FROMADDR TOADDR SIZE'
     Copy SIZE bytes in memory from FROMADDR to TOADDR.
 
`break ADDR'
     Toggle the breakpoint set at ADDR.
 
`breaks'
     List all set breakpoints
 
`reset'
     Reset the simulator.  Includes modeling a reset of the processor,
     so execution will restart from the reset vector location, 0x100.
 
`hist'
     If saving the execution history has been configured (*note
     Simulator Behavior: Simulator Behavior.), display the execution
     history.
 
`stall'
     Stall the processor, so that control is passed to the debug unit.
     When stalled, the processor can execute no instructions.  This
     command is useful when debugging the JTAG interface, used by
     debuggers such as GDB.
 
`unstall'
     Unstall the processor, so that normal execution can continue.
     This command is useful when debugging the JTAG interface, used by
     debuggers such as GDB.
 
`stats CATEGORY | clear'
     Print the statistics for the given CATEGORY, if available, or
     clear if `clear' is specified.  The categories are:
 
    1
          Miscellaneous statistics: branch predictions (if branch
          predictions are enabled), branch target cache model (if
          enabled), cache (if enbaled), MMU (if enabled) and number of
          addtional load & store cycles.
 
          *Note Configuring the OpenRisc Achitectural Components: Core
          OpenRISC Configuration, for details of how to enable these
          various features.
 
    2
          Instruction usage statistics.  Requires hazard analysis to be
          enabled (*note CPU Configuration: CPU Configuration.).
 
    3
          Instruction dependency statistics.  Requires hazard analysis
          to be enabled (*note CPU Configuration: CPU Configuration.).
 
    4
          Functional unit dependency statistics.  Requires hazard
          analysis to be enabled (*note CPU Configuration: CPU
          Configuration.).
 
    5
          Raw register usage over time.  Requires hazard analysis to be
          enabled (*note CPU Configuration: CPU Configuration.).
 
    6
          Store buffer statistics.  Requires the store buffer to be
          enabled (*note CPU Configuration: CPU Configuration.).
 
 
`info'
     Display detailed information about the simulator configuration.
     This is quite a lengthy about, because all MMU TLB information is
     displayed.
 
`dv FROMADDR [ TOADDR ] [ MODULE ]'
     Dump the area of memory between FROMADDR and TOADDR as Verilog
     code for a synchronous, 23-bit wide SRAM module, named MODULE.  If
     TOADDR is not specified, then 64 bytes are dumped (as 16 32-bit
     words).  If MODULE is not specified, `or1k_mem' is used.
 
     To save to a file, use the redirection function (described after
     this table, below).
 
`dh FROMADDR [ TOADDR ]'
     Dump the area of memory between FROMADDR and TOADDR as 32-bit hex
     numbers (no `0x', or `32'h' prefix).  If TOADDR is not specified,
     then 64 bytes are dumped (as 16 32-bit words).
 
     To save to a file, use the redirection function (described after
     this table, below).
 
`setdbch'
     Toggle debug channels on/off.  *Note Standalone Simulator:
     Standalone Simulator, for a description of specifying debug
     channels on the command line.
 
`set SECTION PARAM = VALUE'
     Set the configuration parameter PARA in section SECTION to VALUE.
     *Note Configuration: Configuration, for details of configuration
     parameters and their settings.
 
`debug'
     Toggle the simulator debug mode.  *Note Debug Interface
     Configuration: Debug Interface Configuration, for information on
     this parameter.
 
          Caution: This is effectively enabling or disabling the debug
          unit.  It does not effect the remote GDB debug interface.
          However using the remote debug interface while the debug unit
          is disabled will lead to undefined behavior and likely crash
          Or1ksim
 
`cuc'
     Enter the the Custom Unit Compiler command prompt (*note CUC
     Configuration: CUC Configuration.).
 
          Caution: The CUC must be properly configured, for this to
          succeed.  In particular a timing file must be available and
          readable.  Otherwise Or1ksim will crash.
 
`help'
     Print out brief information about each command available.
 
`mprofile [-vh] [-m M] [-g N] [-f FILE] FROM TO'
     Run the memory profiling utility.  This follows the same usage as
     the standalone command (*note Memory Profiling Utility: Memory
     Profiling Utility.).
 
`profile [-vhcq] [-g FILE]'
     Run the instruction profiling utility.  This follows the same
     usage as the standalone command (*note Profiling Utility:
     Profiling Utility.).
 
 
For all commands, it is possible to redirect the output to a file, by
using the redirection operator, `>'.
 
     COMMAND > FILENAME
 
This is particularly useful for commands dumping a large amount of
output, such as `dv'.
 
     Caution: Unfortunately there is a serious bug with the redirection
     operator.  It does not return output to standard output after the
     command completes.  Until this bug is fixed, file redirection
     should not be used.
 

File: or1ksim.info,  Node: Verification API,  Next: Code Internals,  Prev: Interactive Command Line,  Up: Top
 
5 Verification API (VAPI)
*************************
 
The Verification API (VAPI) provides a TCP/IP interface to allow
components of the simulation to be controlled externally.  The
interface is polled for new requests on each simulated clock cycle.
Components within the simulator may send responses to such requests.
 
The inteface is an asynchronous duplex protocol.  On the request side
it provides for simple commands, known as VAPI IDs (a 32 bit integer),
with a single piece of data (also a 32 bit integer).  On the send side,
it provides for sending a single VAPI ID and data.  However there is no
explicit command-response structure.  Some components just accept
requests (e.g.  to set values), some just generate sends (to report
values), and some do both.
 
Each component has a base ID (32 bit) and its commands will start from
that base ID.  This provides a simple partitioning of the command space
amongst components.  Request commands will be directed to the component
with the closest base ID lower than the VAPI ID of the command.
 
Thus if there are two components with base IDs of 0x200 and 0x300, and
a request with VAPI ID of 0x203 is received, it will be directed to the
first component as its command #3.
 
The results of VAPI interactions are logged (by default in `vapi.log'
unless an alternative is specified in `section vapi').
 
Currently the following components support VAPI:
 
Debug Unit
     Although the Debug Unit can specify a base VAPI ID, it is not used
     to send commands or receive requests.
 
     Instead, if the base VAPI ID is set, all remote JTAG protocol
     exchanges are logged in the VAPI log file.
 
UART
     If a base VAPI ID is specified, the UART sends details of any
     chars or break characters sent, with dteails of the line control
     register etc encoded in the data packet sent.
 
     This supports a single VAPI command request, but encodes a
     sub-command in the top 8 bits of the associated data.
 
    `0x00'
          This stuffs the least significant 8 bits of the data into the
          serial register of the UART and the next 8 bits into the line
          control register, effectively providing control of the next
          character to be sent or received.
 
    `0x01'
          The divisor latch bytes are set from the least significant 16
          bits of the data.
 
    `0x02'
          The line control register is set from bits 15-8 of the data.
 
    `0x03'
          The UART skew is set from the least significant 16 bits of
          the data
 
    `0x04'
          If the 16th most significant bit of the data is 1, start
          sending breaks, otherwise stop sending breaks.  The breaks
          are sent or cleared after the number of UART clock divider
          ticks specified by the data (immediately if the data is zero).
 
 
DMA
     Although the DMA unit supports a base VAPI ID in its configuration
     (`section dma'), no VAPI data is sent, nor VAPI requests currently
     implemented.
 
Ethernet
     The following requests are handled by the Ethernet.  Specified
     symbolically, these are the increments from the base VAPI ID of the
     Ethernet.  At present no implementation is provided behind these
     VAPI requests.
 
    `ETH_VAPI_DATA (0)'
 
    `ETH_VAPI_CTRL (0)'
 
GPIO
     If a base VAPI ID is specified, the GPIO sends out on its base
     VAPI ID (symbolically, GPIO_VAPI_DATA (0) offset from the base
     VAPI ID) any changes in outputs.
 
     The following requests are handled by the GPIO.  Specified
     symbolically, these are the increments from the VAPI base ID of the
     GPIO.
 
    `GPIO_VAPI_DATA (0)'
          Set the next input to the commands data field
 
    `GPIO_VAPI_AUX (1)'
          Set the GPIO auxiliary inputs to the data field
 
    `GPIO_VAPI_CLOCK (2)'
          Add an external GPIO clock trigger of period specified in the
          data field.
 
    `GPIO_VAPI_RGPIO_OE (3)'
          Set the GPIO output enable to the data field
 
    `GPIO_VAPI_RGPIO_INTE (4)'
          Set the next interrupt to the data field
 
    `GPIO_VAPI_RGPIO_PTRIG (5)'
          Set the next trigger to the data field
 
    `GPIO_VAPI_RGPIO_AUX (6)'
          Set the next auxiliary input to the data field
 
    `GPIO_VAPI_RGPIO_CTRL (7)'
          Set th next control input to the data field
 
 
 

File: or1ksim.info,  Node: Code Internals,  Next: GNU Free Documentation License,  Prev: Verification API,  Up: Top
 
6 A Guide to Or1ksim Internals
******************************
 
These are notes to help those wanting to extend Or1ksim.  This section
assumes the use of a tag file, so file locations of entities'
definitions are not in general provided.  For more on tags, see the
Linux manual page for `etags'.  A tag file can be created with:
 
     make tags
 
* Menu:
 
* Coding Conventions::
* Global Data Structures::
* Concepts::
* Internal Debugging::
* Regression Testing::
 

File: or1ksim.info,  Node: Coding Conventions,  Next: Global Data Structures,  Up: Code Internals
 
6.1 Coding Conventions for Or1ksim
==================================
 
This chapter provides some guidelines for coding, to facilitate
extensions to Or1ksim
 
_GNU Coding Standard_
     Code should follow the GNU coding standard for C
     (`http://www.gnu.org/prep/standards/'.  If in doubt, put your code
     through the `indent' program.
 
_`#include' headers_
     All C source code files should include `config.h' before any other
     file.
 
     This should be followed by inclusion of any system headers (but see
     the comments about portability and `port.h' below) and then by any
     Or1ksim package headers.
 
     If `port.h' is required, it should be the first package header to
     be included after the system headers.
 
     All C source code and header files should directly include any
     system or package header they depend on, i.e.  not rely on any
     other header having already included it.  The two exceptions are
 
       1. All header files may assume that `config.h' has already been
          included.
 
       2. System headers which impose portability problems should be
          included by using the package header `port.h', rather than
          the system headers themselves.  This is the case for code
          requiring
 
             * `strndup' (from `string.h')
 
             * Integer types (`intN_t', `uintN_t') (from `inttypes.h').
 
             * `isblank' (from `ctype.h')
 
 
 
_`#include' files once only_
     All include files should be protected by `#ifndef' to ensure their
     definitions are only included once.  For instance a header file
     `X-Y.H' should surround its contents with:
 
          #ifndef X_Y__H
          #define X_Y__H
 
          
 
          #endif  /* X_Y__H */
 
_Avoid `typedef'_
     The GNU coding style for C does not have a clear way to distinguish
     between user type name and user variables.  For this reason
     `typedef' should be avoided except for the most ubiquitous user
     defined types.  This makes the code much easier to read.
 
     There are some `typedef' declarations in the `argtable2' library
     and the ELF and COFF headers, because this code is taken from
     other places.
 
     Within Or1ksim legacy uses of `typedef' have largely been purged,
     except in the Custom Unit Compiler (*note Custom Unit Compiler
     (CUC) Configuration: CUC Configuration.).
 
     The remaining uses of `typedef' occur in two places:
 
        * `port/port.h' defines types to replace those in header files
          that are not available (character functions, string
          duplication, integer types).
 
          `cpu/or1k/arch.h' defines types for the key Or1ksim entities:
          addresses (`oraddr_t'), unsigned register values (`uorreg_t')
          and signed register (`orreg_t') values.
 
 
     Where new types are defined, they should appear in one of these two
     files as appropriate.  Or1ksim specific types appearing in
     `arch.h' should always have the suffix `_h'.
 
_Don't begin names with underscore_
     Names beginning with `_' are intended to be part of the C
     infrastructure.  They should not be used in the simulator code.
 
_Keep Non-global top level entities static_
     All top level entities (functions, variables), which are not
     explicitly part of a global interface should be declared static.
     This ensures that unwanted connections are not inadvertently built
     across the program.
 
_Use of `inline'_
     Code should not be declared `inline'.  Modern compilers can work
     out for themselves what is best in this respect.
 
_Initialization_
     All data structures should be explicitly initialized.  In
     particular code should not rely on static data structures being
     initialized to zero.
 
     The rationale is that in future static data structures may become
     dynamic.  This has been a particular source of bugs in Or1ksim
     historically.
 
     A specific case is with new peripherals, which should always
     include a `start' function to pre-initialize all configuration
     parameters to sensible defaults
 
_Configuration Validation_
     All configuration values should be validated, preferably when
     encountered, if not when the `section' is closed, or otherwise at
     run time when the parameter is first used.
 
 

File: or1ksim.info,  Node: Global Data Structures,  Next: Concepts,  Prev: Coding Conventions,  Up: Code Internals
 
6.2 Global Data Structures
==========================
 
`config'
     The global variable `config' of type `struct config' holds the
     configuration data for some of the Or1ksim components which are
     always present.  At present the components are:
 
        * The simulator defined in `section sim' (*note Simulator
          Configuration: Simulator Configuration.).
 
        * The Verification API (VAPI) defined  in `section vapi' (*note
          Verification API (VAPI) Configuration: Verification API
          Configuration.).
 
        * The Custom Unit Compiler (CUC), defined in `section cuc'
          (*note Custom Unit Compiler (CUC) Configuration: CUC
          Configuration.).
 
        * The CPU, defined in `section cpu' (*note CPU Configuration:
          CPU Configuration.).
 
        * The data cache (but not the instruction cache), defined in
          `section dc' (*note Cache Configuration: Cache
          Configuration.).
 
        * The power management unit, defined in `section pm' (*note
          Power Management Configuration: Power Management
          Configuration.).
 
        * The programmable interrupt controller, defined in
          `section pic' (*note Interrupt Configuration: Interrupt
          Configuration.).
 
        * Branch prediciton, defined in `section bpb' (*note Branch
          Prediction Configuration: Branch Prediction Configuration.).
 
        * The debug unit, defined in `section debug' (*note Debug
          Interface Configuration: Debug Interface Configuration.).
 
 
     This struct is made of a collection of structs, one for each
     component.  For example the simulator configuration is held in
     `config.sim'.
 
`config'
     This is a linked list of data structures holding configuration data
     for all sections which are not held in the main `config' data
     structure.  In general these are components (such as peripherals
     and memory) which may occur multiple times.  However it also
     handles some architectural components which may occur only once,
     such as the memory management units, the instruction cache, the
     interrupt controller and branch prediction.
 
`runtime'
     The global variable `runtime' of type `struct runtime' holds all
     the runtime information about the simulation.  To access this
     variable, `sim-config.h' must be included.
 
     This struct is itself made of 3 other structs, `cpu' (for CPU run
     time state), `vapi' (for Verification API state) and `cuc' (for
     Custom Unit Compiler state).
 
 

File: or1ksim.info,  Node: Concepts,  Next: Internal Debugging,  Prev: Global Data Structures,  Up: Code Internals
 
6.3 Concepts
============
 
_Output Redirection_
     The current output stream is held in `runtime.cpu.fout'.  Output
     should be explicitly written to this stream, or may use the
     `PRINTF' macro, which will write its arguments to this output
     stream.
 
_Reset Hooks_
     Any peripheral may register a routine to be called when the the
     processor is reset by calling `reg_sim_reset', providing a
     function and pointer to a data structure as arguments.  On reset
     that function will be called with the data stucture pointer as
     argument.
 
_Interrupts_
     An internal peripheral can model the effect of an interrupt being
     asserted by calling `report_interrupt'.  This is used for both edge
     and level sensitive interrupts.
 
     The effect is to set the corresponding bit in the PICSR SPR and to
     queue an interrupt exception to take place after the current
     instruction completes execution.
 
     Externally, the different interrupts require different mechanisms
     for clearing.  Level sensitive interrupts should be cleared by
     deasserting the interrupt line, edge sensitive interrupts by
     clearing the corresponding bit in the PICSR SPR.
 
     Internally this amounts to the same thing (clearing the PICSPR
     bit), so a single function is provided, `clear_interrupt'.  Note
     however that when level sensitive interrupts are configured, PICSR
     is read only, and can only be cleared by calling
     `clear_interrupt'.  Using the two functions provided will ensure
     the peripheral works correctly whichever type of interrupt is used.
 
          Note: Until an interrupt is cleared, all subsequent
          interrupts are ignored with a warning.
 
 

File: or1ksim.info,  Node: Internal Debugging,  Next: Regression Testing,  Prev: Concepts,  Up: Code Internals
 
6.4 Internal Debugging
======================
 
The function `debug' is like `printf', but with an extra first
argument, which is the debug level.  If the debug level specified in
the simulator configuration (*note Simulator Behavior: Simulator
Behavior.) is greater than or equal to this value, the remaining
arguments are printed to the current output stream (*note Output
Redirection: Output Redirection.).
 

File: or1ksim.info,  Node: Regression Testing,  Prev: Internal Debugging,  Up: Code Internals
 
6.5 Regression Testing
======================
 
Or1ksim now includes a regression test suite for both standalone and
library usage as described earlier (*note Building and Installing:
Build and Install.).  Running the tests requires that the OpenRISC
toolchain and DejaGNU are both installed.
 
Tests are written using `expect', a derivative of TCL.  Documentation
of DejaGnu, `expect' and TCL are freely available on the Web.  The
Embecosm Application Note 8, `Howto: Using DejaGnu for Testing: A
Simple Introduction' (`http://www.embecosm.com/download/ean8.html')
provides a concise introduction.
 
All test code is found in the `testsuite' directory.  The key files and
directories used are as follows.
 
`global-conf.exp'
     This is the global DejaGNU configuration file used to set up
     parameters common to all tests.  If the user has the environment
     varialbe `DEJAGNU' defined, it will be used instead, but this is
     not recommended.
 
`Makefile.am'
     This is the top level `automake' file for the testsuite.  The only
     changes likely to be needed here is additional local cleanup of
     files created by new tests.
 
`README'
     This contains details of all the tests
 
`config'
     This contains DejaGnu board configurations.  Since the tests are
     generally run on a Unix host, this should just contain `Unix.exp'.
 
`lib'
     This contains DejaGnu tool specific configurations.  "Tool" has a
     specific meaning in DejaGNU, referring just to a grouping of
     tests.  In this case there are two such "tools", "or1ksim" and
     "libsim" for tests of the standalone tool and tests of the library.
 
     Corresponding to this, there are two tool specific configuration
     files, `or1ksim.exp' and `libsim.exp'.  These contain `expect'/TCL
     procedures for common use among the tests.
 
`libsim.tests'
`or1ksim.tests'
     These are the directories of tests of the Or1ksim library.  They
     also include Or1ksim configuration files and each has a
     `Makefile.am' file.  `Makefile.am' should be updated whenever
     files are added to this directory, to ensure they are included in
     the distribution.
 
`test-code'
     These are all the test programs to be compiled on the host (each
     in its own directory).  In general these are programs to support
     testing of the library, and build various programs linking in the
     library.
 
`test-code'
     These are all the test programs to be compiled with the OpenRISC
     tool chain to run with either standalone Or1ksim or the library.
     This directory includes its own `configure.ac', since it must set
     up a separate tool chain based on the target, not the host.
 
 
To add a new test needs the following steps.
 
   * Put new host C code in its own directory within `test-code'.  Add
     the directory to the existing `Makefile.am' in the `test-code'
     directory and create a `Makefile.am' in the new directory to drive
     building the test program(s).  Don't forget to add the new
     `Makefile' to the top level `configure.ac' so it gets generated.
     Not all tests require code here.
 
   * Put new target C code in its own directory within `test-code-or1k'.
     Once again modify & create `Makefile.am'.  This time modify the
     `configure.ac' in the `test-code-or1k' so the `Makefile' gets
     generated.  The existing programs provide examples to start from,
     including custom linker scripts where needed.
 
   * Add one or more tests and configuration files to the relevant
     "tool" test directory.  Use the existing tests as templates.  They
     make heavy use of the `expect'/TCL procedures in the `config'
     directory to facilitate driving the tests.
 
 

File: or1ksim.info,  Node: GNU Free Documentation License,  Next: Index,  Prev: Code Internals,  Up: Top
 
7 GNU Free Documentation License
********************************
 
                      Version 1.2, November 2002
 
     Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
     51 Franklin St, Fifth Floor, Boston, MA  02110-1301, USA
 
     Everyone is permitted to copy and distribute verbatim copies
     of this license document, but changing it is not allowed.
 
  0. PREAMBLE
 
     The purpose of this License is to make a manual, textbook, or other
     functional and useful document "free" in the sense of freedom: to
     assure everyone the effective freedom to copy and redistribute it,
     with or without modifying it, either commercially or
     noncommercially.  Secondarily, this License preserves for the
     author and publisher a way to get credit for their work, while not
     being considered responsible for modifications made by others.
 
     This License is a kind of "copyleft", which means that derivative
     works of the document must themselves be free in the same sense.
     It complements the GNU General Public License, which is a copyleft
     license designed for free software.
 
     We have designed this License in order to use it for manuals for
     free software, because free software needs free documentation: a
     free program should come with manuals providing the same freedoms
     that the software does.  But this License is not limited to
     software manuals; it can be used for any textual work, regardless
     of subject matter or whether it is published as a printed book.
     We recommend this License principally for works whose purpose is
     instruction or reference.
 
  1. APPLICABILITY AND DEFINITIONS
 
     This License applies to any manual or other work, in any medium,
     that contains a notice placed by the copyright holder saying it
     can be distributed under the terms of this License.  Such a notice
     grants a world-wide, royalty-free license, unlimited in duration,
     to use that work under the conditions stated herein.  The
     "Document", below, refers to any such manual or work.  Any member
     of the public is a licensee, and is addressed as "you".  You
     accept the license if you copy, modify or distribute the work in a
     way requiring permission under copyright law.
 
     A "Modified Version" of the Document means any work containing the
     Document or a portion of it, either copied verbatim, or with
     modifications and/or translated into another language.
 
     A "Secondary Section" is a named appendix or a front-matter section
     of the Document that deals exclusively with the relationship of the
     publishers or authors of the Document to the Document's overall
     subject (or to related matters) and contains nothing that could
     fall directly within that overall subject.  (Thus, if the Document
     is in part a textbook of mathematics, a Secondary Section may not
     explain any mathematics.)  The relationship could be a matter of
     historical connection with the subject or with related matters, or
     of legal, commercial, philosophical, ethical or political position
     regarding them.
 
     The "Invariant Sections" are certain Secondary Sections whose
     titles are designated, as being those of Invariant Sections, in
     the notice that says that the Document is released under this
     License.  If a section does not fit the above definition of
     Secondary then it is not allowed to be designated as Invariant.
     The Document may contain zero Invariant Sections.  If the Document
     does not identify any Invariant Sections then there are none.
 
     The "Cover Texts" are certain short passages of text that are
     listed, as Front-Cover Texts or Back-Cover Texts, in the notice
     that says that the Document is released under this License.  A
     Front-Cover Text may be at most 5 words, and a Back-Cover Text may
     be at most 25 words.
 
     A "Transparent" copy of the Document means a machine-readable copy,
     represented in a format whose specification is available to the
     general public, that is suitable for revising the document
     straightforwardly with generic text editors or (for images
     composed of pixels) generic paint programs or (for drawings) some
     widely available drawing editor, and that is suitable for input to
     text formatters or for automatic translation to a variety of
     formats suitable for input to text formatters.  A copy made in an
     otherwise Transparent file format whose markup, or absence of
     markup, has been arranged to thwart or discourage subsequent
     modification by readers is not Transparent.  An image format is
     not Transparent if used for any substantial amount of text.  A
     copy that is not "Transparent" is called "Opaque".
 
     Examples of suitable formats for Transparent copies include plain
     ASCII without markup, Texinfo input format, LaTeX input format,
     SGML or XML using a publicly available DTD, and
     standard-conforming simple HTML, PostScript or PDF designed for
     human modification.  Examples of transparent image formats include
     PNG, XCF and JPG.  Opaque formats include proprietary formats that
     can be read and edited only by proprietary word processors, SGML or
     XML for which the DTD and/or processing tools are not generally
     available, and the machine-generated HTML, PostScript or PDF
     produced by some word processors for output purposes only.
 
     The "Title Page" means, for a printed book, the title page itself,
     plus such following pages as are needed to hold, legibly, the
     material this License requires to appear in the title page.  For
     works in formats which do not have any title page as such, "Title
     Page" means the text near the most prominent appearance of the
     work's title, preceding the beginning of the body of the text.
 
     A section "Entitled XYZ" means a named subunit of the Document
     whose title either is precisely XYZ or contains XYZ in parentheses
     following text that translates XYZ in another language.  (Here XYZ
     stands for a specific section name mentioned below, such as
     "Acknowledgements", "Dedications", "Endorsements", or "History".)
     To "Preserve the Title" of such a section when you modify the
     Document means that it remains a section "Entitled XYZ" according
     to this definition.
 
     The Document may include Warranty Disclaimers next to the notice
     which states that this License applies to the Document.  These
     Warranty Disclaimers are considered to be included by reference in
     this License, but only as regards disclaiming warranties: any other
     implication that these Warranty Disclaimers may have is void and
     has no effect on the meaning of this License.
 
  2. VERBATIM COPYING
 
     You may copy and distribute the Document in any medium, either
     commercially or noncommercially, provided that this License, the
     copyright notices, and the license notice saying this License
     applies to the Document are reproduced in all copies, and that you
     add no other conditions whatsoever to those of this License.  You
     may not use technical measures to obstruct or control the reading
     or further copying of the copies you make or distribute.  However,
     you may accept compensation in exchange for copies.  If you
     distribute a large enough number of copies you must also follow
     the conditions in section 3.
 
     You may also lend copies, under the same conditions stated above,
     and you may publicly display copies.
 
  3. COPYING IN QUANTITY
 
     If you publish printed copies (or copies in media that commonly
     have printed covers) of the Document, numbering more than 100, and
     the Document's license notice requires Cover Texts, you must
     enclose the copies in covers that carry, clearly and legibly, all
     these Cover Texts: Front-Cover Texts on the front cover, and
     Back-Cover Texts on the back cover.  Both covers must also clearly
     and legibly identify you as the publisher of these copies.  The
     front cover must present the full title with all words of the
     title equally prominent and visible.  You may add other material
     on the covers in addition.  Copying with changes limited to the
     covers, as long as they preserve the title of the Document and
     satisfy these conditions, can be treated as verbatim copying in
     other respects.
 
     If the required texts for either cover are too voluminous to fit
     legibly, you should put the first ones listed (as many as fit
     reasonably) on the actual cover, and continue the rest onto
     adjacent pages.
 
     If you publish or distribute Opaque copies of the Document
     numbering more than 100, you must either include a
     machine-readable Transparent copy along with each Opaque copy, or
     state in or with each Opaque copy a computer-network location from
     which the general network-using public has access to download
     using public-standard network protocols a complete Transparent
     copy of the Document, free of added material.  If you use the
     latter option, you must take reasonably prudent steps, when you
     begin distribution of Opaque copies in quantity, to ensure that
     this Transparent copy will remain thus accessible at the stated
     location until at least one year after the last time you
     distribute an Opaque copy (directly or through your agents or
     retailers) of that edition to the public.
 
     It is requested, but not required, that you contact the authors of
     the Document well before redistributing any large number of
     copies, to give them a chance to provide you with an updated
     version of the Document.
 
  4. MODIFICATIONS
 
     You may copy and distribute a Modified Version of the Document
     under the conditions of sections 2 and 3 above, provided that you
     release the Modified Version under precisely this License, with
     the Modified Version filling the role of the Document, thus
     licensing distribution and modification of the Modified Version to
     whoever possesses a copy of it.  In addition, you must do these
     things in the Modified Version:
 
       A. Use in the Title Page (and on the covers, if any) a title
          distinct from that of the Document, and from those of
          previous versions (which should, if there were any, be listed
          in the History section of the Document).  You may use the
          same title as a previous version if the original publisher of
          that version gives permission.
 
       B. List on the Title Page, as authors, one or more persons or
          entities responsible for authorship of the modifications in
          the Modified Version, together with at least five of the
          principal authors of the Document (all of its principal
          authors, if it has fewer than five), unless they release you
          from this requirement.
 
       C. State on the Title page the name of the publisher of the
          Modified Version, as the publisher.
 
       D. Preserve all the copyright notices of the Document.
 
       E. Add an appropriate copyright notice for your modifications
          adjacent to the other copyright notices.
 
       F. Include, immediately after the copyright notices, a license
          notice giving the public permission to use the Modified
          Version under the terms of this License, in the form shown in
          the Addendum below.
 
       G. Preserve in that license notice the full lists of Invariant
          Sections and required Cover Texts given in the Document's
          license notice.
 
       H. Include an unaltered copy of this License.
 
       I. Preserve the section Entitled "History", Preserve its Title,
          and add to it an item stating at least the title, year, new
          authors, and publisher of the Modified Version as given on
          the Title Page.  If there is no section Entitled "History" in
          the Document, create one stating the title, year, authors,
          and publisher of the Document as given on its Title Page,
          then add an item describing the Modified Version as stated in
          the previous sentence.
 
       J. Preserve the network location, if any, given in the Document
          for public access to a Transparent copy of the Document, and
          likewise the network locations given in the Document for
          previous versions it was based on.  These may be placed in
          the "History" section.  You may omit a network location for a
          work that was published at least four years before the
          Document itself, or if the original publisher of the version
          it refers to gives permission.
 
       K. For any section Entitled "Acknowledgements" or "Dedications",
          Preserve the Title of the section, and preserve in the
          section all the substance and tone of each of the contributor
          acknowledgements and/or dedications given therein.
 
       L. Preserve all the Invariant Sections of the Document,
          unaltered in their text and in their titles.  Section numbers
          or the equivalent are not considered part of the section
          titles.
 
       M. Delete any section Entitled "Endorsements".  Such a section
          may not be included in the Modified Version.
 
       N. Do not retitle any existing section to be Entitled
          "Endorsements" or to conflict in title with any Invariant
          Section.
 
       O. Preserve any Warranty Disclaimers.
 
     If the Modified Version includes new front-matter sections or
     appendices that qualify as Secondary Sections and contain no
     material copied from the Document, you may at your option
     designate some or all of these sections as invariant.  To do this,
     add their titles to the list of Invariant Sections in the Modified
     Version's license notice.  These titles must be distinct from any
     other section titles.
 
     You may add a section Entitled "Endorsements", provided it contains
     nothing but endorsements of your Modified Version by various
     parties--for example, statements of peer review or that the text
     has been approved by an organization as the authoritative
     definition of a standard.
 
     You may add a passage of up to five words as a Front-Cover Text,
     and a passage of up to 25 words as a Back-Cover Text, to the end
     of the list of Cover Texts in the Modified Version.  Only one
     passage of Front-Cover Text and one of Back-Cover Text may be
     added by (or through arrangements made by) any one entity.  If the
     Document already includes a cover text for the same cover,
     previously added by you or by arrangement made by the same entity
     you are acting on behalf of, you may not add another; but you may
     replace the old one, on explicit permission from the previous
     publisher that added the old one.
 
     The author(s) and publisher(s) of the Document do not by this
     License give permission to use their names for publicity for or to
     assert or imply endorsement of any Modified Version.
 
  5. COMBINING DOCUMENTS
 
     You may combine the Document with other documents released under
     this License, under the terms defined in section 4 above for
     modified versions, provided that you include in the combination
     all of the Invariant Sections of all of the original documents,
     unmodified, and list them all as Invariant Sections of your
     combined work in its license notice, and that you preserve all
     their Warranty Disclaimers.
 
     The combined work need only contain one copy of this License, and
     multiple identical Invariant Sections may be replaced with a single
     copy.  If there are multiple Invariant Sections with the same name
     but different contents, make the title of each such section unique
     by adding at the end of it, in parentheses, the name of the
     original author or publisher of that section if known, or else a
     unique number.  Make the same adjustment to the section titles in
     the list of Invariant Sections in the license notice of the
     combined work.
 
     In the combination, you must combine any sections Entitled
     "History" in the various original documents, forming one section
     Entitled "History"; likewise combine any sections Entitled
     "Acknowledgements", and any sections Entitled "Dedications".  You
     must delete all sections Entitled "Endorsements."
 
  6. COLLECTIONS OF DOCUMENTS
 
     You may make a collection consisting of the Document and other
     documents released under this License, and replace the individual
     copies of this License in the various documents with a single copy
     that is included in the collection, provided that you follow the
     rules of this License for verbatim copying of each of the
     documents in all other respects.
 
     You may extract a single document from such a collection, and
     distribute it individually under this License, provided you insert
     a copy of this License into the extracted document, and follow
     this License in all other respects regarding verbatim copying of
     that document.
 
  7. AGGREGATION WITH INDEPENDENT WORKS
 
     A compilation of the Document or its derivatives with other
     separate and independent documents or works, in or on a volume of
     a storage or distribution medium, is called an "aggregate" if the
     copyright resulting from the compilation is not used to limit the
     legal rights of the compilation's users beyond what the individual
     works permit.  When the Document is included in an aggregate, this
     License does not apply to the other works in the aggregate which
     are not themselves derivative works of the Document.
 
     If the Cover Text requirement of section 3 is applicable to these
     copies of the Document, then if the Document is less than one half
     of the entire aggregate, the Document's Cover Texts may be placed
     on covers that bracket the Document within the aggregate, or the
     electronic equivalent of covers if the Document is in electronic
     form.  Otherwise they must appear on printed covers that bracket
     the whole aggregate.
 
  8. TRANSLATION
 
     Translation is considered a kind of modification, so you may
     distribute translations of the Document under the terms of section
     4.  Replacing Invariant Sections with translations requires special
     permission from their copyright holders, but you may include
     translations of some or all Invariant Sections in addition to the
     original versions of these Invariant Sections.  You may include a
     translation of this License, and all the license notices in the
     Document, and any Warranty Disclaimers, provided that you also
     include the original English version of this License and the
     original versions of those notices and disclaimers.  In case of a
     disagreement between the translation and the original version of
     this License or a notice or disclaimer, the original version will
     prevail.
 
     If a section in the Document is Entitled "Acknowledgements",
     "Dedications", or "History", the requirement (section 4) to
     Preserve its Title (section 1) will typically require changing the
     actual title.
 
  9. TERMINATION
 
     You may not copy, modify, sublicense, or distribute the Document
     except as expressly provided for under this License.  Any other
     attempt to copy, modify, sublicense or distribute the Document is
     void, and will automatically terminate your rights under this
     License.  However, parties who have received copies, or rights,
     from you under this License will not have their licenses
     terminated so long as such parties remain in full compliance.
 
 10. FUTURE REVISIONS OF THIS LICENSE
 
     The Free Software Foundation may publish new, revised versions of
     the GNU Free Documentation License from time to time.  Such new
     versions will be similar in spirit to the present version, but may
     differ in detail to address new problems or concerns.  See
     `http://www.gnu.org/copyleft/'.
 
     Each version of the License is given a distinguishing version
     number.  If the Document specifies that a particular numbered
     version of this License "or any later version" applies to it, you
     have the option of following the terms and conditions either of
     that specified version or of any later version that has been
     published (not as a draft) by the Free Software Foundation.  If
     the Document does not specify a version number of this License,
     you may choose any version ever published (not as a draft) by the
     Free Software Foundation.
 
ADDENDUM: How to use this License for your documents
====================================================
 
To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and license
notices just after the title page:
 
       Copyright (C)  YEAR  YOUR NAME.
       Permission is granted to copy, distribute and/or modify this document
       under the terms of the GNU Free Documentation License, Version 1.2
       or any later version published by the Free Software Foundation;
       with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
       Texts.  A copy of the license is included in the section entitled ``GNU
       Free Documentation License''.
 
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
replace the "with...Texts." line with this:
 
         with the Invariant Sections being LIST THEIR TITLES, with
         the Front-Cover Texts being LIST, and with the Back-Cover Texts
         being LIST.
 
If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.
 
If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License, to
permit their use in free software.
 

File: or1ksim.info,  Node: Index,  Prev: GNU Free Documentation License,  Up: Top
 
Index
*****
 
 
* Menu:

* --cumulative:                          Profiling Utility.   (line  26)
* --debug-config:                        Standalone Simulator.
                                                              (line  99)
* --disable-all-tests:                   Configuring the Build.
                                                              (line 105)
* --disable-arith-flag:                  Configuring the Build.
                                                              (line 118)
* --disable-debug:                       Configuring the Build.
                                                              (line  98)
* --disable-ethphy:                      Configuring the Build.
                                                              (line  59)
* --disable-ov-flag:                     Configuring the Build.
                                                              (line 133)
* --disable-profiling:                   Configuring the Build.
                                                              (line  30)
* --disable-range-stats:                 Configuring the Build.
                                                              (line  92)
* --disable-unsigned-xori:               Configuring the Build.
                                                              (line  69)
* --enable-all-tests:                    Configuring the Build.
                                                              (line 104)
* --enable-arith-flag:                   Configuring the Build.
                                                              (line 117)
* --enable-debug:                        Configuring the Build.
                                                              (line  97)
* --enable-ethphy:                       Configuring the Build.
                                                              (line  58)
* --enable-execution:                    Configuring the Build.
                                                              (line  37)
* --enable-mprofile:                     Standalone Simulator.
                                                              (line 133)
* --enable-ov-flag:                      Configuring the Build.
                                                              (line 132)
* --enable-profile:                      Standalone Simulator.
                                                              (line 130)
* --enable-profiling:                    Configuring the Build.
                                                              (line  29)
* --enable-range-stats:                  Configuring the Build.
                                                              (line  91)
* --enable-unsigned-xori:                Configuring the Build.
                                                              (line  68)
* --file:                                Standalone Simulator.
                                                              (line  57)
* --filename:                            Memory Profiling Utility.
                                                              (line  51)
* --generate:                            Profiling Utility.   (line  34)
* --group:                               Memory Profiling Utility.
                                                              (line  47)
* --help:                                Standalone Simulator.
                                                              (line  21)
* --help (memory profiling utility):     Memory Profiling Utility.
                                                              (line  22)
* --help (profiling utility):            Profiling Utility.   (line  22)
* --interactive:                         Standalone Simulator.
                                                              (line  25)
* --memory:                              Standalone Simulator.
                                                              (line  83)
* --mode:                                Memory Profiling Utility.
                                                              (line  26)
* --nosrv:                               Standalone Simulator.
                                                              (line  65)
* --quiet <1>:                           Profiling Utility.   (line  30)
* --quiet:                               Standalone Simulator.
                                                              (line  29)
* --report-memory-errors:                Standalone Simulator.
                                                              (line 104)
* --srv:                                 Standalone Simulator.
                                                              (line  73)
* --strict-npc:                          Standalone Simulator.
                                                              (line 113)
* --trace <1>:                           Trace Generation.    (line  14)
* --trace:                               Standalone Simulator.
                                                              (line  39)
* --trace-physical <1>:                  Trace Generation.    (line  44)
* --trace-physical:                      Standalone Simulator.
                                                              (line  44)
* --trace-virtual <1>:                   Trace Generation.    (line  44)
* --trace-virtual:                       Standalone Simulator.
                                                              (line  44)
* --verbose:                             Standalone Simulator.
                                                              (line  33)
* --version:                             Standalone Simulator.
                                                              (line  17)
* --version (memory profiling utility):  Memory Profiling Utility.
                                                              (line  17)
* --version (profiling utility):         Profiling Utility.   (line  17)
* -c:                                    Profiling Utility.   (line  26)
* -d:                                    Standalone Simulator.
                                                              (line  99)
* -f <1>:                                Memory Profiling Utility.
                                                              (line  51)
* -f:                                    Standalone Simulator.
                                                              (line  57)
* -g <1>:                                Memory Profiling Utility.
                                                              (line  47)
* -g:                                    Profiling Utility.   (line  34)
* -h:                                    Standalone Simulator.
                                                              (line  21)
* -h (memory profiling utility):         Memory Profiling Utility.
                                                              (line  22)
* -h (profiling utility):                Profiling Utility.   (line  22)
* -i:                                    Standalone Simulator.
                                                              (line  25)
* -m <1>:                                Memory Profiling Utility.
                                                              (line  26)
* -m:                                    Standalone Simulator.
                                                              (line  83)
* -q <1>:                                Profiling Utility.   (line  30)
* -q:                                    Standalone Simulator.
                                                              (line  29)
* -t <1>:                                Trace Generation.    (line  14)
* -t:                                    Standalone Simulator.
                                                              (line  39)
* -V:                                    Standalone Simulator.
                                                              (line  33)
* -v:                                    Standalone Simulator.
                                                              (line  17)
* -v (memory profiling utility):         Memory Profiling Utility.
                                                              (line  17)
* -v (profiling utility):                Profiling Utility.   (line  17)
* 0x00 UART VAPI sub-command (UART verification): Verification API.
                                                              (line  49)
* 0x01 UART VAPI sub-command (UART verification): Verification API.
                                                              (line  55)
* 0x02 UART VAPI sub-command (UART verification): Verification API.
                                                              (line  59)
* 0x03 UART VAPI sub-command (UART verification): Verification API.
                                                              (line  62)
* 0x04 UART VAPI sub-command (UART verification): Verification API.
                                                              (line  66)
* 16550 (UART configuration):            UART Configuration.  (line  73)
* all tests enabled:                     Configuring the Build.
                                                              (line 105)
* Argtable2 debugging:                   Configuring the Build.
                                                              (line  98)
* ATA/ATAPI configuration:               Disc Interface Configuration.
                                                              (line   6)
* ATA/ATAPI device configuration:        Disc Interface Configuration.
                                                              (line  92)
* base_vapi_id (GPIO configuration - deprecated): GPIO Configuration.
                                                              (line  32)
* baseaddr (ATA/ATAPI configuration):    Disc Interface Configuration.
                                                              (line  26)
* baseaddr (DMA configuration):          DMA Configuration.   (line  24)
* baseaddr (Ethernet configuration):     Ethernet Configuration.
                                                              (line  23)
* baseaddr (frame buffer configuration): Frame Buffer Configuration.
                                                              (line  20)
* baseaddr (generic peripheral configuration): Generic Peripheral Configuration.
                                                              (line  22)
* baseaddr (GPIO configuration):         GPIO Configuration.  (line  21)
* baseaddr (keyboard configuration):     Keyboard Configuration.
                                                              (line  36)
* baseaddr (memory configuration):       Memory Configuration.
                                                              (line  94)
* baseaddr (memory controller configuration): Memory Controller Configuration.
                                                              (line  55)
* baseaddr (UART configuration):         UART Configuration.  (line  22)
* baseaddr (VGA configuration):          Display Interface Configuration.
                                                              (line  26)
* blocksize (cache configuration):       Cache Configuration. (line  29)
* BPB configuration:                     Branch Prediction Configuration.
                                                              (line   6)
* branch prediction configuration:       Branch Prediction Configuration.
                                                              (line   6)
* break (Interactive CLI):               Interactive Command Line.
                                                              (line  57)
* breakpoint list (Interactive CLI):     Interactive Command Line.
                                                              (line  60)
* breakpoint set/clear (Interactive CLI): Interactive Command Line.
                                                              (line  57)
* breaks (Interactive CLI):              Interactive Command Line.
                                                              (line  60)
* bridge setup:                          Establishing a Bridge.
                                                              (line   6)
* btic (branch prediction configuration): Branch Prediction Configuration.
                                                              (line  19)
* BusyBox and Ethernet:                  Networking from OpenRISC Linux and BusyBox.
                                                              (line   6)
* byte_enabled (generic peripheral configuration): Generic Peripheral Configuration.
                                                              (line  48)
* cache configuration:                   Cache Configuration. (line   6)
* calling_convention (CUC configuration): CUC Configuration.  (line  37)
* ce (memory configuration):             Memory Configuration.
                                                              (line 124)
* cfgr (CPU configuration):              CPU Configuration.   (line  47)
* channel (UART configuration):          UART Configuration.  (line  29)
* clear breakpoint (Interactive CLI):    Interactive Command Line.
                                                              (line  57)
* clear_interrupt:                       Concepts.            (line  20)
* clkcycle (simulator configuration):    Simulator Behavior.  (line 115)
* cm (Interactive CLI):                  Interactive Command Line.
                                                              (line  54)
* command line for Or1ksim standalone use: Standalone Simulator.
                                                              (line   6)
* complex model:                         Configuring the Build.
                                                              (line  37)
* config:                                Global Data Structures.
                                                              (line   7)
* config.bpb:                            Global Data Structures.
                                                              (line  37)
* config.cpu:                            Global Data Structures.
                                                              (line  22)
* config.cuc:                            Global Data Structures.
                                                              (line  18)
* config.dc:                             Global Data Structures.
                                                              (line  25)
* config.debug:                          Global Data Structures.
                                                              (line  40)
* config.pic:                            Global Data Structures.
                                                              (line  33)
* config.pm:                             Global Data Structures.
                                                              (line  29)
* config.sim:                            Global Data Structures.
                                                              (line  11)
* config.vapi:                           Global Data Structures.
                                                              (line  14)
* configuration dynamic structure:       Global Data Structures.
                                                              (line  49)
* configuration file structure:          Configuration File Format.
                                                              (line   6)
* configuration global structure:        Global Data Structures.
                                                              (line   7)
* configuration info (Interactive CLI):  Interactive Command Line.
                                                              (line 119)
* configuration of generic peripherals:  Generic Peripheral Configuration.
                                                              (line   6)
* configuration parameter setting (Interactive CLI): Interactive Command Line.
                                                              (line 146)
* configuring branch prediction:         Branch Prediction Configuration.
                                                              (line   6)
* configuring data & instruction caches: Cache Configuration. (line   6)
* configuring data & instruction MMUs:   Memory Management Configuration.
                                                              (line   6)
* configuring DMA:                       DMA Configuration.   (line   6)
* configuring memory:                    Memory Configuration.
                                                              (line   6)
* configuring Or1ksim:                   Configuration.       (line   6)
* configuring power management:          Power Management Configuration.
                                                              (line   6)
* configuring the ATA/ATAPI interfaces:  Disc Interface Configuration.
                                                              (line   6)
* configuring the behavior of Or1ksim:   Simulator Behavior.  (line   6)
* configuring the CPU:                   CPU Configuration.   (line   6)
* configuring the Custom Unit Compiler (CUC): CUC Configuration.
                                                              (line   6)
* configuring the debug unit and interface to external debuggers: Debug Interface Configuration.
                                                              (line   6)
* configuring the Ethernet interface:    Ethernet Configuration.
                                                              (line   6)
* configuring the Ethernet TUN/TAP interface: Ethernet TUN/TAP Interface.
                                                              (line   6)
* configuring the frame buffer:          Frame Buffer Configuration.
                                                              (line   6)
* configuring the GPIO:                  GPIO Configuration.  (line   6)
* configuring the interrupt controller:  Interrupt Configuration.
                                                              (line   6)
* configuring the keyboard interface:    Keyboard Configuration.
                                                              (line   6)
* configuring the memory controller:     Memory Controller Configuration.
                                                              (line   6)
* configuring the processor:             CPU Configuration.   (line   6)
* configuring the PS2 interface:         Keyboard Configuration.
                                                              (line   6)
* configuring the UART:                  UART Configuration.  (line   6)
* configuring the Verification API (VAPI): Verification API Configuration.
                                                              (line   6)
* configuring the VGA interface:         Display Interface Configuration.
                                                              (line   6)
* copying memory (Interactive CLI):      Interactive Command Line.
                                                              (line  54)
* CPU configuration:                     CPU Configuration.   (line   6)
* CUC configuration:                     CUC Configuration.   (line   6)
* Custom Unit Compiler (Interactive CLI): Interactive Command Line.
                                                              (line 162)
* Custom Unit Compiler Configuration:    CUC Configuration.   (line   6)
* data cache configuration:              Cache Configuration. (line   6)
* data MMU configuration:                Memory Management Configuration.
                                                              (line   6)
* DCGE (power management register):      Power Management Configuration.
                                                              (line  21)
* debug (Interactive CLI):               Interactive Command Line.
                                                              (line 151)
* debug (simulator configuration):       Simulator Behavior.  (line  13)
* debug channel toggle (Interactive CLI): Interactive Command Line.
                                                              (line 141)
* debug interface configuration:         Debug Interface Configuration.
                                                              (line   6)
* debug mode toggle (Interactive CLI):   Interactive Command Line.
                                                              (line 151)
* debug unit configuration:              Debug Interface Configuration.
                                                              (line   6)
* Debug Unit verification (VAPI):        Verification API.    (line  34)
* debugging enabled (Argtable2):         Configuring the Build.
                                                              (line  98)
* DejaGnu board configurations:          Regression Testing.  (line  35)
* DejaGnu configuration:                 Regression Testing.  (line  21)
* DejaGNU tests directories:             Regression Testing.  (line  50)
* DejaGnu tool specific configuration:   Regression Testing.  (line  39)
* delayr (memory configuration):         Memory Configuration.
                                                              (line 144)
* delayw (memory configuration):         Memory Configuration.
                                                              (line 150)
* dependstats (CPU configuration):       CPU Configuration.   (line  89)
* dev_id (ATA/ATAPI configuration):      Disc Interface Configuration.
                                                              (line  40)
* disassemble (Interactive CLI):         Interactive Command Line.
                                                              (line  41)
* disc interface configuration:          Disc Interface Configuration.
                                                              (line   6)
* disc interface device configuration:   Disc Interface Configuration.
                                                              (line  92)
* display interface configuration:       Display Interface Configuration.
                                                              (line   6)
* displaying memory (Interactive CLI):   Interactive Command Line.
                                                              (line  31)
* displaying registers (Interactive CLI): Interactive Command Line.
                                                              (line  14)
* dm (Interactive CLI):                  Interactive Command Line.
                                                              (line  31)
* dma (Ethernet configuration):          Ethernet Configuration.
                                                              (line  34)
* DMA configuration:                     DMA Configuration.   (line   6)
* DMA verification (VAPI):               Verification API.    (line  73)
* dma_mode0_td (ATA/ATAPI configuration): Disc Interface Configuration.
                                                              (line  74)
* dma_mode0_teoc (ATA/ATAPI configuration): Disc Interface Configuration.
                                                              (line  75)
* dma_mode0_tm (ATA/ATAPI configuration): Disc Interface Configuration.
                                                              (line  73)
* DME (power management register):       Power Management Configuration.
                                                              (line  15)
* DMMU configuration:                    Memory Management Configuration.
                                                              (line   6)
* doze mode (power management register): Power Management Configuration.
                                                              (line  15)
* dummy_crc (Ethernet configuration):    Ethernet Configuration.
                                                              (line 104)
* dv (Interactive CLI):                  Interactive Command Line.
                                                              (line 124)
* dynamic clock gating (power management register): Power Management Configuration.
                                                              (line  21)
* dynamic model:                         Configuring the Build.
                                                              (line  37)
* dynamic ports, use of:                 Verification API Configuration.
                                                              (line  23)
* edge_trigger (interrupt controller):   Interrupt Configuration.
                                                              (line  16)
* enable_bursts (CUC configuration):     CUC Configuration.   (line  41)
* enabled (ATA/ATAPI configuration):     Disc Interface Configuration.
                                                              (line  22)
* enabled (branch prediction configuration): Branch Prediction Configuration.
                                                              (line  15)
* enabled (cache configuration):         Cache Configuration. (line  11)
* enabled (debug interface configuration): Debug Interface Configuration.
                                                              (line  11)
* enabled (DMA configuration):           DMA Configuration.   (line  20)
* enabled (Ethernet configuration):      Ethernet Configuration.
                                                              (line  19)
* enabled (frame buffer configuration):  Frame Buffer Configuration.
                                                              (line  16)
* enabled (generic peripheral configuration): Generic Peripheral Configuration.
                                                              (line  18)
* enabled (GPIO configuration):          GPIO Configuration.  (line  17)
* enabled (interrupt controller):        Interrupt Configuration.
                                                              (line  12)
* enabled (keyboard configuration):      Keyboard Configuration.
                                                              (line  32)
* enabled (memory controller configuration): Memory Controller Configuration.
                                                              (line  44)
* enabled (MMU configuration):           Memory Management Configuration.
                                                              (line  12)
* enabled (power management configuration): Power Management Configuration.
                                                              (line  35)
* enabled (UART configuration):          UART Configuration.  (line  18)
* enabled (verification API configuration): Verification API Configuration.
                                                              (line  15)
* enabled (VGA configuration):           Display Interface Configuration.
                                                              (line  22)
* enabling Ethernet via socket:          Configuring the Build.
                                                              (line  59)
* entrysize (MMU configuration):         Memory Management Configuration.
                                                              (line  32)
* ETH_VAPI_CTRL (Ethernet verification): Verification API.    (line  86)
* ETH_VAPI_DATA (Ethernet verification): Verification API.    (line  84)
* Ethernet bridge setup:                 Establishing a Bridge.
                                                              (line   6)
* Ethernet configuration:                Ethernet Configuration.
                                                              (line   6)
* Ethernet verification (VAPI):          Verification API.    (line  78)
* Ethernet via socket, enabling:         Configuring the Build.
                                                              (line  59)
* exclusive-OR immediate operand:        Configuring the Build.
                                                              (line  69)
* exe_bin_insn_log (simulator configuration): Simulator Behavior.
                                                              (line 103)
* exe_bin_insn_log_file (simulator configuration): Simulator Behavior.
                                                              (line 111)
* exe_log (simulator configuration):     Simulator Behavior.  (line  49)
* exe_log_end (simulator configuration): Simulator Behavior.  (line  89)
* exe_log_file (simulator configuration): Simulator Behavior. (line  97)
* exe_log_fn (simulator configuration - deprecated): Simulator Behavior.
                                                              (line  97)
* exe_log_marker (simulator configuration): Simulator Behavior.
                                                              (line  93)
* exe_log_start (simulator configuration): Simulator Behavior.
                                                              (line  86)
* exe_log_type (simulator configuration): Simulator Behavior. (line  55)
* exe_log_type=default (simulator configuration): Simulator Behavior.
                                                              (line  58)
* exe_log_type=hardware (simulator configuration): Simulator Behavior.
                                                              (line  62)
* exe_log_type=simple (simulator configuration): Simulator Behavior.
                                                              (line  69)
* exe_log_type=software (simulator configuration): Simulator Behavior.
                                                              (line  74)
* executing code (Interactive CLI):      Interactive Command Line.
                                                              (line  23)
* execution history (Interactive CLI):   Interactive Command Line.
                                                              (line  67)
* file (ATA/ATAPI device configuration): Disc Interface Configuration.
                                                              (line 108)
* file (keyboard configuration):         Keyboard Configuration.
                                                              (line  51)
* filename (frame buffer configuration - deprecated): Frame Buffer Configuration.
                                                              (line  36)
* filename (VGA configuration - deprecated): Display Interface Configuration.
                                                              (line  47)
* firewall with Ethernet bridge and TAP/TUN: Opening the Firewall.
                                                              (line   6)
* firmware (ATA/ATAPI device configuration): Disc Interface Configuration.
                                                              (line 121)
* flag setting by instructions:          Configuring the Build.
                                                              (line 118)
* frame buffer configuration:            Frame Buffer Configuration.
                                                              (line   6)
* generic peripheral configuration:      Generic Peripheral Configuration.
                                                              (line   6)
* GPIO configuration:                    GPIO Configuration.  (line   6)
* GPIO verification (VAPI):              Verification API.    (line  88)
* GPIO_VAPI_AUX (GPIO verification):     Verification API.    (line 100)
* GPIO_VAPI_CLOCK (GPIO verification):   Verification API.    (line 103)
* GPIO_VAPI_CTRL (GPIO verification):    Verification API.    (line 119)
* GPIO_VAPI_DATA (GPIO verification):    Verification API.    (line  97)
* GPIO_VAPI_INTE (GPIO verification):    Verification API.    (line 110)
* GPIO_VAPI_PTRIG (GPIO verification):   Verification API.    (line 113)
* GPIO_VAPI_RGPIO (GPIO verification):   Verification API.    (line 107)
* hardfloat (CPU configuration):         CPU Configuration.   (line 110)
* hazards (CPU configuration):           CPU Configuration.   (line  74)
* heads (ATA/ATAPI device configuration): Disc Interface Configuration.
                                                              (line 125)
* help (Interactive CLI):                Interactive Command Line.
                                                              (line 170)
* hexadecimal memory dump (Interactive CLI): Interactive Command Line.
                                                              (line 133)
* hide_device_id (verification API configuration): Verification API Configuration.
                                                              (line  36)
* hist (Interactive CLI):                Interactive Command Line.
                                                              (line  67)
* history (simulator configuration):     Simulator Behavior.  (line  40)
* history of execution (Interactive CLI): Interactive Command Line.
                                                              (line  67)
* hitdelay (branch prediction configuration): Branch Prediction Configuration.
                                                              (line  33)
* hitdelay (instruction cache configuration): Cache Configuration.
                                                              (line  38)
* hitdelay (MMU configuration):          Memory Management Configuration.
                                                              (line  51)
* host test code:                        Regression Testing.  (line  57)
* hw_enabled (generic peripheral configuration): Generic Peripheral Configuration.
                                                              (line  49)
* IMMU configuration:                    Memory Management Configuration.
                                                              (line   6)
* index (memory controller configuration): Memory Controller Configuration.
                                                              (line  77)
* info (Interactive CLI):                Interactive Command Line.
                                                              (line 119)
* installing Or1ksim:                    Installation.        (line   6)
* instruction cache configuration:       Cache Configuration. (line   6)
* instruction MMU configuration:         Memory Management Configuration.
                                                              (line   6)
* instruction profiling for Or1ksim:     Profiling Utility.   (line   6)
* instruction profiling utility (Interactive CLI): Interactive Command Line.
                                                              (line 178)
* internal debugging:                    Internal Debugging.  (line   6)
* interrupt controller configuration:    Interrupt Configuration.
                                                              (line   6)
* interrupts:                            Concepts.            (line  20)
* irq (ATA/ATAPI configuration):         Disc Interface Configuration.
                                                              (line  36)
* irq (DMA configuration):               DMA Configuration.   (line  34)
* irq (GPIO configuration):              GPIO Configuration.  (line  29)
* irq (keyboard configuration):          Keyboard Configuration.
                                                              (line  47)
* irq (UART configuration):              UART Configuration.  (line  70)
* irq (VGA configuration):               Display Interface Configuration.
                                                              (line  37)
* jitter (UART configuration):           UART Configuration.  (line  78)
* keyboard configuration:                Keyboard Configuration.
                                                              (line   6)
* l.nop 0:                               l.nop Support.       (line  12)
* l.nop 1 (end simulation):              l.nop Support.       (line  15)
* l.nop 10 (return a random number):     l.nop Support.       (line  51)
* l.nop 11 (return a non-zero value):    l.nop Support.       (line  62)
* l.nop 2 (report):                      l.nop Support.       (line  19)
* l.nop 3 (printf, now obsolete):        l.nop Support.       (line  22)
* l.nop 4 (putc):                        l.nop Support.       (line  29)
* l.nop 5 (reset statistics counters):   l.nop Support.       (line  34)
* l.nop 6 (get clock ticks):             l.nop Support.       (line  37)
* l.nop 7 (get picoseconds per cycle):   l.nop Support.       (line  41)
* l.nop 8 (turn off tracing):            Trace Generation.    (line  40)
* l.nop 8 (turn on tracing) <1>:         l.nop Support.       (line  45)
* l.nop 8 (turn on tracing):             Trace Generation.    (line  40)
* l.nop 9 (turn off tracing):            l.nop Support.       (line  48)
* l.nop opcode effects:                  l.nop Support.       (line   6)
* library version of Or1ksim:            Simulator Library.   (line   6)
* license for Or1ksim:                   GNU Free Documentation License.
                                                              (line   6)
* Linux (OpenRISC) and Ethernet:         Networking from OpenRISC Linux and BusyBox.
                                                              (line   6)
* list breakpoints (Interactive CLI):    Interactive Command Line.
                                                              (line  60)
* load_hitdelay (data cache configuration): Cache Configuration.
                                                              (line  46)
* load_missdelay (data cache configuration): Cache Configuration.
                                                              (line  50)
* log (memory configuration):            Memory Configuration.
                                                              (line 156)
* log_enabled (verification API configuration): Verification API Configuration.
                                                              (line  28)
* long:                                  Simulator Library.   (line  94)
* make file for tests:                   Regression Testing.  (line  27)
* mc (memory configuration):             Memory Configuration.
                                                              (line 133)
* memory configuration:                  Memory Configuration.
                                                              (line   6)
* memory controller configuration:       Memory Controller Configuration.
                                                              (line   6)
* memory copying (Interactive CLI):      Interactive Command Line.
                                                              (line  54)
* memory display (Interactive CLI):      Interactive Command Line.
                                                              (line  31)
* memory dump, hexadecimal (Interactive CLI): Interactive Command Line.
                                                              (line 133)
* memory dump, Verilog (Interactive CLI): Interactive Command Line.
                                                              (line 124)
* memory patching (Interactive CLI):     Interactive Command Line.
                                                              (line  48)
* memory profiling end address:          Memory Profiling Utility.
                                                              (line  56)
* memory profiling start address:        Memory Profiling Utility.
                                                              (line  56)
* memory profiling utility (Interactive CLI): Interactive Command Line.
                                                              (line 173)
* memory profiling version of Or1ksim:   Memory Profiling Utility.
                                                              (line   6)
* memory_order (CUC configuration):      CUC Configuration.   (line  15)
* memory_order=exact (CUC configuration): CUC Configuration.  (line  30)
* memory_order=none (CUC configuration): CUC Configuration.   (line  18)
* memory_order=strong (CUC configuration): CUC Configuration. (line  27)
* memory_order=weak (CUC configuration): CUC Configuration.   (line  22)
* missdelay (branch prediction configuration): Branch Prediction Configuration.
                                                              (line  37)
* missdelay (instruction cache configuration): Cache Configuration.
                                                              (line  42)
* missdelay (MMU configuration):         Memory Management Configuration.
                                                              (line  55)
* MMU configuration:                     Memory Management Configuration.
                                                              (line   6)
* mprof_file (simulator configuration):  Simulator Behavior.  (line  34)
* mprof_fn (simulator configuration - deprecated): Simulator Behavior.
                                                              (line  34)
* mprofile (Interactive CLI):            Interactive Command Line.
                                                              (line 173)
* mprofile (simulator configuration):    Simulator Behavior.  (line  29)
* mtspr:                                 Concepts.            (line  20)
* mwdma (ATA/ATAPI device configuration): Disc Interface Configuration.
                                                              (line 132)
* name (generic peripheral configuration): Generic Peripheral Configuration.
                                                              (line  42)
* name (memory configuration):           Memory Configuration.
                                                              (line 115)
* no_multicycle (CUC configuration):     CUC Configuration.   (line  45)
* nsets (cache configuration):           Cache Configuration. (line  15)
* nsets (MMU configuration):             Memory Management Configuration.
                                                              (line  16)
* nways (cache configuration):           Cache Configuration. (line  22)
* nways (MMU configuration):             Memory Management Configuration.
                                                              (line  22)
* or1ksim_get_time_period:               Simulator Library.   (line  84)
* or1ksim_init:                          Simulator Library.   (line  19)
* or1ksim_interrupt:                     Simulator Library.   (line  99)
* or1ksim_interrupt_clear:               Simulator Library.   (line 121)
* or1ksim_interrupt_set:                 Simulator Library.   (line 110)
* or1ksim_is_le:                         Simulator Library.   (line  89)
* or1ksim_jtag_reset:                    Simulator Library.   (line 130)
* or1ksim_jtag_shift_dr:                 Simulator Library.   (line 152)
* or1ksim_jtag_shift_ir:                 Simulator Library.   (line 139)
* or1ksim_read_mem:                      Simulator Library.   (line 165)
* or1ksim_read_reg:                      Simulator Library.   (line 197)
* or1ksim_read_spr:                      Simulator Library.   (line 181)
* or1ksim_reset_duration:                Simulator Library.   (line  69)
* or1ksim_run:                           Simulator Library.   (line  58)
* or1ksim_set_stall_state:               Simulator Library.   (line 212)
* or1ksim_set_time_point:                Simulator Library.   (line  80)
* or1ksim_write_mem:                     Simulator Library.   (line 173)
* or1ksim_write_reg:                     Simulator Library.   (line 205)
* or1ksim_write_spr:                     Simulator Library.   (line 189)
* output rediretion:                     Concepts.            (line   7)
* overflow flag setting by instructions: Configuring the Build.
                                                              (line 133)
* packet (ATA/ATAPI device configuration): Disc Interface Configuration.
                                                              (line 117)
* pagesize (MMU configuration):          Memory Management Configuration.
                                                              (line  27)
* patching memory (Interactive CLI):     Interactive Command Line.
                                                              (line  48)
* patching registers (Interactive CLI):  Interactive Command Line.
                                                              (line  28)
* patching the program counter (Interactive CLI): Interactive Command Line.
                                                              (line  51)
* pattern (memory configuration):        Memory Configuration.
                                                              (line  82)
* pc (Interactive CLI):                  Interactive Command Line.
                                                              (line  51)
* persistent TAP device creation:        Setting Up a Persistent TAP device.
                                                              (line   6)
* phy_addr:                              Ethernet Configuration.
                                                              (line  99)
* PIC configuration:                     Interrupt Configuration.
                                                              (line   6)
* pio (ATA/ATAPI device configuration):  Disc Interface Configuration.
                                                              (line 136)
* pio_mode0_t1 (ATA/ATAPI configuration): Disc Interface Configuration.
                                                              (line  55)
* pio_mode0_t2 (ATA/ATAPI configuration): Disc Interface Configuration.
                                                              (line  56)
* pio_mode0_t4 (ATA/ATAPI configuration): Disc Interface Configuration.
                                                              (line  57)
* pio_mode0_teoc (ATA/ATAPI configuration): Disc Interface Configuration.
                                                              (line  58)
* pm (Interactive CLI):                  Interactive Command Line.
                                                              (line  48)
* PMR - DGCE:                            Power Management Configuration.
                                                              (line  21)
* PMR - DME:                             Power Management Configuration.
                                                              (line  15)
* PMR - SDF:                             Power Management Configuration.
                                                              (line  12)
* PMR - SME:                             Power Management Configuration.
                                                              (line  16)
* PMR - SUME:                            Power Management Configuration.
                                                              (line  24)
* PMU configuration:                     Power Management Configuration.
                                                              (line   6)
* poc (memory controller configuration): Memory Controller Configuration.
                                                              (line  64)
* port range for TCP/IP:                 Verification API Configuration.
                                                              (line  23)
* power management configuration:        Power Management Configuration.
                                                              (line   6)
* power management register, DGCE:       Power Management Configuration.
                                                              (line  21)
* power management register, DME:        Power Management Configuration.
                                                              (line  15)
* power management register, SDF:        Power Management Configuration.
                                                              (line  12)
* power management register, SME:        Power Management Configuration.
                                                              (line  16)
* power management register, SUME:       Power Management Configuration.
                                                              (line  24)
* pr (Interactive CLI):                  Interactive Command Line.
                                                              (line  28)
* private ports, use of:                 Verification API Configuration.
                                                              (line  23)
* processor configuration:               CPU Configuration.   (line   6)
* processor stall (Interactive CLI):     Interactive Command Line.
                                                              (line  72)
* processor unstall (Interactive CLI):   Interactive Command Line.
                                                              (line  78)
* prof_file (simulator configuration):   Simulator Behavior.  (line  23)
* prof_fn (simulator configuration - deprecated): Simulator Behavior.
                                                              (line  23)
* profile (simulator configuration):     Simulator Behavior.  (line  19)
* profiling for Or1ksim:                 Profiling Utility.   (line   6)
* profiling utility (Interactive CLI):   Interactive Command Line.
                                                              (line 178)
* program counter patching (Interactive CLI): Interactive Command Line.
                                                              (line  51)
* programmable interrupt controller configuration: Interrupt Configuration.
                                                              (line   6)
* PS2 configuration:                     Keyboard Configuration.
                                                              (line   6)
* q (Interactive CLI):                   Interactive Command Line.
                                                              (line  11)
* quitting (Interactive CLI):            Interactive Command Line.
                                                              (line  11)
* r (Interactive CLI):                   Interactive Command Line.
                                                              (line  14)
* random_seed (memory configuration):    Memory Configuration.
                                                              (line  72)
* refresh_rate (frame buffer configuration): Frame Buffer Configuration.
                                                              (line  30)
* refresh_rate (VGA configuration):      Display Interface Configuration.
                                                              (line  41)
* reg_sim_reset:                         Concepts.            (line  13)
* register display (Interactive CLI):    Interactive Command Line.
                                                              (line  14)
* register over time statistics:         Configuring the Build.
                                                              (line  92)
* register patching (Interactive CLI):   Interactive Command Line.
                                                              (line  28)
* regression testing:                    Regression Testing.  (line   6)
* Remote Serial Protocol:                Debug Interface Configuration.
                                                              (line  20)
* Remote Serial Protocol, --nosrv:       Standalone Simulator.
                                                              (line  65)
* Remote Serial Protocol, --srv:         Standalone Simulator.
                                                              (line  73)
* report_interrupt:                      Concepts.            (line  20)
* reset (Interactive CLI):               Interactive Command Line.
                                                              (line  63)
* reset hooks:                           Concepts.            (line  13)
* reset the simulator (Interactive CLI): Interactive Command Line.
                                                              (line  63)
* rev (ATA/ATAPI configuration):         Disc Interface Configuration.
                                                              (line  48)
* rev (CPU configuration):               CPU Configuration.   (line  15)
* rsp_enabled (debug interface configuration): Debug Interface Configuration.
                                                              (line  20)
* rsp_port (debug interface configuration): Debug Interface Configuration.
                                                              (line  32)
* rtx_type (Ethernet configuration):     Ethernet Configuration.
                                                              (line  47)
* run (Interactive CLI):                 Interactive Command Line.
                                                              (line  23)
* running code (Interactive CLI):        Interactive Command Line.
                                                              (line  23)
* running Or1ksim:                       Usage.               (line   6)
* runtime:                               Global Data Structures.
                                                              (line  58)
* runtime global structure:              Global Data Structures.
                                                              (line  58)
* runtime.cpu:                           Global Data Structures.
                                                              (line  62)
* runtime.cpu.fout:                      Concepts.            (line   7)
* runtime.cuc:                           Global Data Structures.
                                                              (line  62)
* runtime.vapi:                          Global Data Structures.
                                                              (line  62)
* rx_channel (Ethernet configuration):   Ethernet Configuration.
                                                              (line  67)
* rxfile (Ethernet configuration):       Ethernet Configuration.
                                                              (line  76)
* sbp_bf_fwd (branch prediction configuration): Branch Prediction Configuration.
                                                              (line  23)
* sbp_bnf_fwd (branch prediction configuration): Branch Prediction Configuration.
                                                              (line  28)
* sbuf_len (CPU configuration):          CPU Configuration.   (line 101)
* SDF (power management register):       Power Management Configuration.
                                                              (line  12)
* section ata:                           Disc Interface Configuration.
                                                              (line   6)
* section bpb:                           Branch Prediction Configuration.
                                                              (line   6)
* section cpio:                          GPIO Configuration.  (line   6)
* section cpu:                           CPU Configuration.   (line   6)
* section cuc:                           CUC Configuration.   (line   6)
* section dc:                            Cache Configuration. (line   6)
* section debug:                         Debug Interface Configuration.
                                                              (line   6)
* section dma:                           DMA Configuration.   (line   6)
* section dmmu:                          Memory Management Configuration.
                                                              (line   6)
* section ethernet:                      Ethernet Configuration.
                                                              (line   6)
* section fb:                            Frame Buffer Configuration.
                                                              (line   6)
* section generic:                       Generic Peripheral Configuration.
                                                              (line   6)
* section ic:                            Cache Configuration. (line   6)
* section immu:                          Memory Management Configuration.
                                                              (line   6)
* section kb:                            Keyboard Configuration.
                                                              (line   6)
* section mc:                            Memory Controller Configuration.
                                                              (line   6)
* section memory:                        Memory Configuration.
                                                              (line   6)
* section pic:                           Interrupt Configuration.
                                                              (line   6)
* section pmu:                           Power Management Configuration.
                                                              (line   6)
* section sim:                           Simulator Behavior.  (line   6)
* section uart:                          UART Configuration.  (line   6)
* section vapi:                          Verification API Configuration.
                                                              (line   6)
* section vga:                           Display Interface Configuration.
                                                              (line   6)
* sections:                              Global Data Structures.
                                                              (line  49)
* sectors (ATA/ATAPI device configuration): Disc Interface Configuration.
                                                              (line 129)
* server_port (verification API configuration): Verification API Configuration.
                                                              (line  19)
* set (Interactive CLI):                 Interactive Command Line.
                                                              (line 146)
* set breakpoint (Interactive CLI):      Interactive Command Line.
                                                              (line  57)
* setdbch (Interactive CLI):             Interactive Command Line.
                                                              (line 141)
* simple model:                          Configuring the Build.
                                                              (line  37)
* simulator configuration:               Simulator Behavior.  (line   6)
* simulator configuration info (Interactive CLI): Interactive Command Line.
                                                              (line 119)
* simulator reset (Interactive CLI):     Interactive Command Line.
                                                              (line  63)
* simulator statistics (Interactive CLI): Interactive Command Line.
                                                              (line  83)
* size (ATA/ATAPI device configuration): Disc Interface Configuration.
                                                              (line 113)
* size (generic peripheral configuration): Generic Peripheral Configuration.
                                                              (line  30)
* size (memory configuration):           Memory Configuration.
                                                              (line  99)
* sleep mode (power management register): Power Management Configuration.
                                                              (line  16)
* slow down factor (power management register): Power Management Configuration.
                                                              (line  12)
* SME (power management register):       Power Management Configuration.
                                                              (line  16)
* sr (CPU configuration):                CPU Configuration.   (line  53)
* stall (Interactive CLI):               Interactive Command Line.
                                                              (line  72)
* stall the processor (Interactive CLI): Interactive Command Line.
                                                              (line  72)
* statistics, register over time:        Configuring the Build.
                                                              (line  92)
* statistics, simulation (Interactive CLI): Interactive Command Line.
                                                              (line  83)
* stats (Interactive CLI):               Interactive Command Line.
                                                              (line  83)
* stepping code (Interactive CLI):       Interactive Command Line.
                                                              (line  19)
* store_hitdelay (data cache configuration): Cache Configuration.
                                                              (line  54)
* store_missdelay (data cache configuration): Cache Configuration.
                                                              (line  58)
* SUME (power management register):      Power Management Configuration.
                                                              (line  24)
* superscalar (CPU configuration):       CPU Configuration.   (line  63)
* suspend mode (power management register): Power Management Configuration.
                                                              (line  24)
* t (Interactive CLI):                   Interactive Command Line.
                                                              (line  19)
* TAP device creation:                   Setting Up a Persistent TAP device.
                                                              (line   6)
* tap_dev (Ethernet configuration):      Ethernet Configuration.
                                                              (line  93)
* target test code:                      Regression Testing.  (line  63)
* TCP/IP port range:                     Verification API Configuration.
                                                              (line  23)
* TCP/IP port range for or1ksim-rsp service: Debug Interface Configuration.
                                                              (line  37)
* test code for host:                    Regression Testing.  (line  57)
* test code for target:                  Regression Testing.  (line  63)
* test make file:                        Regression Testing.  (line  27)
* test README:                           Regression Testing.  (line  32)
* testing:                               Regression Testing.  (line   6)
* tests, all enabled.:                   Configuring the Build.
                                                              (line 105)
* timings_file (CUC configuration):      CUC Configuration.   (line  49)
* timings_fn (CUC configuration - deprecated): CUC Configuration.
                                                              (line  49)
* toggle breakpoint (Interactive CLI):   Interactive Command Line.
                                                              (line  57)
* toggle debug channels (Interactive CLI): Interactive Command Line.
                                                              (line 141)
* toggle debug mode (Interactive CLI):   Interactive Command Line.
                                                              (line 151)
* trace generation of Or1ksim:           Trace Generation.    (line   6)
* tx_channel (Ethernet configuration):   Ethernet Configuration.
                                                              (line  68)
* txfile (Ethernet configuration):       Ethernet Configuration.
                                                              (line  77)
* txfile (frame buffer configuration):   Frame Buffer Configuration.
                                                              (line  36)
* txfile (VGA configuration):            Display Interface Configuration.
                                                              (line  47)
* type (ATA/ATAPI device configuration): Disc Interface Configuration.
                                                              (line 103)
* type (memory configuration):           Memory Configuration.
                                                              (line  37)
* type=exitnops (memory configuration):  Memory Configuration.
                                                              (line  66)
* type=pattern (memory configuration):   Memory Configuration.
                                                              (line  47)
* type=random (memory configuration):    Memory Configuration.
                                                              (line  41)
* type=unknown (memory configuration):   Memory Configuration.
                                                              (line  51)
* type=zero (memory configuration):      Memory Configuration.
                                                              (line  56)
* UART configuration:                    UART Configuration.  (line   6)
* UART I/O from/to a physical serial port: UART Configuration.
                                                              (line  62)
* UART I/O from/to an xterm:             UART Configuration.  (line  38)
* UART I/O from/to files:                UART Configuration.  (line  33)
* UART I/O from/to open file descriptors: UART Configuration. (line  58)
* UART I/O from/to TCP/IP:               UART Configuration.  (line  45)
* UART verification (VAPI):              Verification API.    (line  41)
* unstall (Interactive CLI):             Interactive Command Line.
                                                              (line  78)
* unstall the processor (Interactive CLI): Interactive Command Line.
                                                              (line  78)
* upr (CPU configuration):               CPU Configuration.   (line  21)
* use_nmi (interrupt controller):        Interrupt Configuration.
                                                              (line  30)
* ustates (cache configuration):         Cache Configuration. (line  33)
* ustates (MMU configuration):           Memory Management Configuration.
                                                              (line  41)
* VAPI configuration:                    Verification API Configuration.
                                                              (line   6)
* VAPI for Debug Unit:                   Verification API.    (line  34)
* VAPI for DMA:                          Verification API.    (line  73)
* VAPI for Ethernet:                     Verification API.    (line  78)
* VAPI for GPIO:                         Verification API.    (line  88)
* VAPI for UART:                         Verification API.    (line  41)
* vapi_id (debug interface configuration): Debug Interface Configuration.
                                                              (line  43)
* vapi_id (DMA configuration) <1>:       Ethernet Configuration.
                                                              (line 119)
* vapi_id (DMA configuration):           DMA Configuration.   (line  38)
* vapi_id (GPIO configuration):          GPIO Configuration.  (line  32)
* vapi_id (UART configuration):          UART Configuration.  (line  85)
* vapi_log_file (verification API configuration): Verification API Configuration.
                                                              (line  41)
* vapi_log_fn (verification API configuration - deprecated): Verification API Configuration.
                                                              (line  41)
* ver (CPU configuration):               CPU Configuration.   (line  15)
* verbose (simulator configuration):     Simulator Behavior.  (line  10)
* Verification API configuration:        Verification API Configuration.
                                                              (line   6)
* Verilog memory dump (Interactive CLI): Interactive Command Line.
                                                              (line 124)
* VGA configuration:                     Display Interface Configuration.
 
 
                                                              (line  50)



Tag Table:
Node: Top810
Node: Installation1220
Node: Preparation1467
Node: Configuring the Build1760
Node: Build and Install7898
Node: Known Issues8664
Node: Usage9719
Node: Standalone Simulator10003
Node: Profiling Utility15147
Node: Memory Profiling Utility16053
Node: Trace Generation17413
Node: Simulator Library19598
Node: Ethernet TUN/TAP Interface30030
Node: Setting Up a Persistent TAP device31135
Node: Establishing a Bridge31810
Node: Opening the Firewall33493
Node: Disabling Ethernet Filtering33984
Node: Networking from OpenRISC Linux and BusyBox34609
Node: Tearing Down a Bridge36271
Node: l.nop Support37014
Node: Configuration39176
Node: Configuration File Format39788
Node: Configuration File Preprocessing40173
Node: Configuration File Syntax40470
Node: Simulator Configuration43255
Node: Simulator Behavior43546
Node: Verification API Configuration48127
Node: CUC Configuration50067
Node: Core OpenRISC Configuration52059
Node: CPU Configuration52561
Node: Memory Configuration56680
Node: Memory Management Configuration63402
Node: Cache Configuration65779
Node: Interrupt Configuration68165
Node: Power Management Configuration69998
Node: Branch Prediction Configuration71275
Node: Debug Interface Configuration72635
Node: Peripheral Configuration74978
Node: Memory Controller Configuration75604
Node: UART Configuration79384
Node: DMA Configuration82903
Node: Ethernet Configuration84770
Node: GPIO Configuration90049
Node: Display Interface Configuration91682
Node: Frame Buffer Configuration93991
Node: Keyboard Configuration95855
Node: Disc Interface Configuration98093
Node: Generic Peripheral Configuration103197
Node: Interactive Command Line105492
Node: Verification API112466
Node: Code Internals116896
Node: Coding Conventions117479
Node: Global Data Structures121906
Node: Concepts124563
Ref: Output Redirection124708
Ref: Interrupts Internal125246
Node: Internal Debugging126399
Node: Regression Testing126923
Node: GNU Free Documentation License130712
Line No.	Rev	Author	Line
1	450	jeremybenn	`This is ../../doc/or1ksim.info, produced by makeinfo version 4.13 from`
2			`../../doc/or1ksim.texi.`
3	19	jeremybenn
4			`INFO-DIR-SECTION Embedded development`
5			`START-INFO-DIR-ENTRY`
6	442	julius	`* Or1ksim: (or32-elf-or1ksim). The OpenRISC 1000 Architectural`
7	19	jeremybenn	`Simulator`
8			`END-INFO-DIR-ENTRY`
9
10			`This file documents the OpenRISC Architectural Simulator, Or1ksim.`
11
12			`Copyright (C) 2008, 2009 Embecosm Limited.`
13
14			`Permission is granted to copy, distribute and/or modify this`
15			`document under the terms of the GNU Free Documentation License,`
16			`Version 1.2 or any later version published by the Free Software`
17			`Foundation; with no Invariant Sections, with no Front-Cover Texts,`
18			`and with no Back-Cover Texts. A copy of the license is included`
19			`in the section entitled "GNU Free Documentation License".`
20
21
22			`File: or1ksim.info, Node: Top, Next: Installation, Up: (dir)`
23
24			`Scope of this Document`
25			`**********************`
26
27			`This document is the user guide for Or1ksim, the OpenRISC 1000`
28			`Architectural Simulator.`
29
30			`* Menu:`
31
32			`* Installation::`
33			`* Usage::`
34			`* Configuration::`
35			`* Interactive Command Line::`
36			`* Verification API::`
37
38			`* Code Internals::`
39
40			`* GNU Free Documentation License:: The license for this documentation`
41			`* Index::`
42
43
44			`File: or1ksim.info, Node: Installation, Next: Usage, Prev: Top, Up: Top`
45
46			`1 Installation`
47			`**************`
48
49			`Installation follows standard GNU protocols.`
50
51			`* Menu:`
52
53			`* Preparation::`
54			`* Configuring the Build::`
55			`* Build and Install::`
56			`* Known Issues::`
57
58
59			`File: or1ksim.info, Node: Preparation, Next: Configuring the Build, Up: Installation`
60
61			`1.1 Preparation`
62			`===============`
63
64			`Unpack the software and create a _separate_ directory in which to build`
65			`it:`
66
67	510	jeremybenn	`tar jxf or1ksim-0.5.1rc1.tar.bz2`
68	19	jeremybenn	`mkdir builddir_or1ksim`
69			`cd builddir_or1ksim`
70
71
72			`File: or1ksim.info, Node: Configuring the Build, Next: Build and Install, Prev: Preparation, Up: Installation`
73
74			`1.2 Configuring the Build`
75			`=========================`
76
77			Configure the software using the `configure' script in the main
78			`directory.`
79
80			The most significant argument is `--target', which should specify the
81	82	jeremybenn	`OpenRISC 1000 32-bit architecture. If this argument is omitted, it will`
82	19	jeremybenn	`default to OpenRISC 1000 32-bit with a warning`
83
84	510	jeremybenn	`../or1ksim-0.5.1rc1/configure --target=or32-elf ...`
85	19	jeremybenn
86			`There are several other options available, many of which are standard`
87	82	jeremybenn	to GNU `configure' scripts. Use `configure --help' to see all the
88			options. The most useful is `--prefix' to specify a directory for
89	19	jeremybenn	`installation of the tools.`
90
91	385	jeremybenn	For testing (using `make check'), the `--target' parameter may be
92			`specified, to allow the target tool chain to be selected. If not`
93			specified, it will default to `or32-elf', which is the same prefix used
94			`with the standard OpenRISC toolchain installation script.`
95	19	jeremybenn
96	104	jeremybenn	`A number of Or1ksim specific features in the simulator do require`
97			`enabling at configuration. These include`
98
99	19	jeremybenn	`--enable-profiling'
100			`--disable-profiling'
101	82	jeremybenn	If enabled, Or1ksim is compiled for profiling with `gprof'. This
102			`is disabled by default. Only really of value for developers of`
103	19	jeremybenn	`Or1ksim.`
104
105			`--enable-execution=simple'
106			`--enable-execution=complex'
107			`--enable-execution=dynamic'
108			`Or1ksim has developed to improve functionality and performance.`
109			`This feature allows three versions of Or1ksim to be built`
110
111			`--enable-execution=simple'
112			`Build the original simple interpreting simulator`
113
114			`--enable-execution=complex'
115	82	jeremybenn	`Build a more complex interpreting simulator. Experiments`
116			`suggest this is 50% faster than the simple simulator. This`
117			`is the default.`
118	19	jeremybenn
119			`--enable-execution=dynamic'
120	82	jeremybenn	`Build a dynamically compiling simulator. This is the way`
121			`many modern ISS are built. This represents a work in`
122			`progress. Currently Or1ksim will compile, but segfaults if`
123			`configured with this option.`
124	19	jeremybenn
125
126			The default is `--enable-execution=complex'.
127
128			`--enable-ethphy'
129			`--disable-ethphy'
130			`If enabled, this option allows the Ethernet to be simulated by`
131			`connecting via a socket (the alternative reads and writes, from`
132	82	jeremybenn	`and to files). This must then be configured using the relevant`
133			fields in the `ethernet' section of the configuration file. *Note
134	19	jeremybenn	`Ethernet Configuration: Ethernet Configuration.`
135
136			`The default is for this to be disabled.`
137
138	127	jeremybenn	`--enable-unsigned-xori'
139			`--disable-unsigned-xori'
140	346	jeremybenn	Historically, `l.xori', has sign extended its operand. This is
141	127	jeremybenn	inconsistent with the other logical opcodes (`l.andi', `l.ori'),
142			but in the absence of `l.not', it allows a register to be inverted
143			`in a single instruction using:`
144
145			`l.xori rD,rA,-1'
146
147			`This flag causes Or1ksim to treat the immediate operand as`
148			`unsigned (i.e to zero-extend rather than sign-extend).`
149
150			`The default is to sign-extend, so that existing code will continue`
151			`to work.`
152
153			`Caution: The GNU compiler tool chain makes heavy use of this`
154			`instruction. Using unsigned behavior will require the`
155			`compiler to be modified accordingly.`
156
157			`This option is provided for experimentation. A future`
158			`version of OpenRISC may adopt this more consistent behavior`
159			and also provide a `l.not' opcode.
160
161	19	jeremybenn	`--enable-range-stats'
162			`--disable-range-stats'
163			`If enabled, this option allows statistics to be collected to`
164	82	jeremybenn	`analyse register access over time. The default is for this to be`
165	19	jeremybenn	`disabled.`
166
167			`--enable-debug'
168			`--disable-debug'
169			`This is a feature of the Argtable2 package used to process`
170	82	jeremybenn	`arguments. If enabled, some debugging features are turned on in`
171			`Argtable2. It is provided for completeness, but there is no`
172			`reason why this feature should ever be needed by any Or1ksim user.`
173	19	jeremybenn
174	82	jeremybenn	`--enable-all-tests'
175			`--disable-all-tests'
176			`Some of the tests (at the time of writing just one) will not`
177			`compile without error. If enabled with this flag, all test`
178			programs will be compiled with `make check'.
179	19	jeremybenn
180	82	jeremybenn	`This flag is intended for those working on the test package, who`
181			`wish to get the missing test(s) working.`
182
183
184	112	jeremybenn	`A number of configuration flags have been removed since version 0.3.0,`
185	346	jeremybenn	`because they led to invalid behavior of Or1ksim. Those removed are:`
186	112	jeremybenn
187	124	jeremybenn	`--enable-arith-flag'
188			`--disable-arith-flag'
189			`If enabled, this option caused certain instructions to set the flag`
190			(`F' bit) in the supervision register if the result were zero.
191			The instructions affected by this were `l.add', `l.addc',
192			`l.addi', `l.and' and `l.andi'.
193
194	346	jeremybenn	`If set, this caused incorrect behavior. Whether or not flags are`
195	124	jeremybenn	`set is part of the OpenRISC 1000 architectural specification. The`
196			`only flags which should set this are the "set flag" instructions:`
197			`l.sfeq', `l.sfeqi', `l.sfges', `l.sfgesi', `l.sfgeu', `l.sfgeui',
198			`l.sfgts', `l.sfgtsi', `l.sfgtu', `l.sfgtui', `l.sfles',
199			`l.sflesi', `l.sfleu', `l.sfleui', `l.sflts', `l.sfltsi',
200			`l.sfltu', `l.sfltui', `l.sfne' and `l.sfnei'.
201
202	112	jeremybenn	`--enable-ov-flag'
203			`--disable-ov-flag'
204	124	jeremybenn	`This flag caused certain instructions to set the overflow flag.`
205			`If not, those instructions would not set the overflow flat. The`
206			instructions affected by this were `l.add', `l.addc', `l.addi',
207			`l.and', `l.andi', `l.div', `l.divu', `l.mul', `l.muli', `l.or',
208			`l.ori', `l.sll', `l.slli', `l.srl', `l.srli', `l.sra', `l.srai',
209			`l.sub', `l.xor' and `l.xori'.
210	112	jeremybenn
211			`This guaranteed incorrect behavior. The OpenRISC 1000 architecture`
212			`specification defines which flags are set by which instructions.`
213
214			Within the above list, the arithmetic instructions (`l.add',
215			`l.addc', `l.addi', `l.div', `l.divu', `l.mul', `l.muli' and
216			`l.sub'), together with `l.addic' which is missed out, set the
217			overflow flag. All the others (`l.and', `l.andi', `l.or',
218			`l.ori', `l.sll', `l.slli', `l.srl', `l.srli', `l.sra', `l.srai',
219			`l.xor' and `l.xori') do not.
220
221
222	19	jeremybenn
223			`File: or1ksim.info, Node: Build and Install, Next: Known Issues, Prev: Configuring the Build, Up: Installation`
224
225			`1.3 Building and Installing`
226			`===========================`
227
228	82	jeremybenn	`Build the tool with:`
229	19	jeremybenn
230			`make all`
231	82	jeremybenn
232			`If you have the OpenRISC tool chain and DejaGNU installed, you can`
233			`verify the tool as follows (otherwise omit this step):`
234
235			`make check`
236
237			`Install the tool with:`
238
239	19	jeremybenn	`make install`
240
241			`This will install the three variations of the Or1ksim tool,`
242	442	julius	`or32-elf-sim', `or32-elf-psim' and `or32-elf-mpsim', the Or1ksim
243			library, `libsim', the header file, `or1ksim.h' and this documentation
244			in `info' format.
245	19	jeremybenn
246			`The documentation may be created and installed in alternative formats`
247			`(PDF, Postscript, DVI, HTML) with for example:`
248
249			`make pdf`
250			`make install-pdf`
251
252
253			`File: or1ksim.info, Node: Known Issues, Prev: Build and Install, Up: Installation`
254
255			`1.4 Known Problems and Issues`
256			`=============================`
257
258	346	jeremybenn	Full details of outstanding issues may be found in the `NEWS' file in
259			`the main directory of the distribution. The OpenRISC tracker may be`
260			`used to see the current state of these issues and to raise new problems`
261			`and feature requests. It may be found at bugtracker.`
262	19	jeremybenn
263	346	jeremybenn	`The following issues are long standing and unlikely to be fixed in`
264			`Or1ksim in the near future.`
265
266	19	jeremybenn	`* The Supervision Register Little Endian Enable (LEE) bit is`
267	82	jeremybenn	`ignored. Or1ksim can be built for either little endian or big`
268	19	jeremybenn	`endian use, but that behavior cannot be changed dynamically.`
269
270			`* Or1ksim is not reentrant, so a program cannot instantiate multiple`
271	82	jeremybenn	`instances using the library. This is clearly a problem when`
272			`considering multi-core applications. However it stems from the`
273			`original design, and can only be fixed by a complete rewrite. The`
274	19	jeremybenn	`entire source code uses static global constants liberally!`
275
276
277
278			`File: or1ksim.info, Node: Usage, Next: Configuration, Prev: Installation, Up: Top`
279
280			`2 Usage`
281			`*******`
282
283			`* Menu:`
284
285			`* Standalone Simulator::`
286			`* Profiling Utility::`
287			`* Memory Profiling Utility::`
288	442	julius	`* Trace Generation::`
289	19	jeremybenn	`* Simulator Library::`
290	440	jeremybenn	`* Ethernet TUN/TAP Interface::`
291	460	jeremybenn	`* l.nop Support::`
292	19	jeremybenn
293
294			`File: or1ksim.info, Node: Standalone Simulator, Next: Profiling Utility, Up: Usage`
295
296			`2.1 Standalone Simulator`
297			`========================`
298
299			`The general form the standalone command is:`
300
301	442	julius	`or32-elf-sim [-vhiqVt] [-f FILE] [--nosrv] [--srv=[N]]`
302	346	jeremybenn	`[-m ][-d STR]`
303	19	jeremybenn	`[--enable-profile] [--enable-mprofile] [FILE]`
304
305	82	jeremybenn	`Many of the options have both a short and a long form. For example`
306			`-h' or `--help'.
307	19	jeremybenn
308			`-v'
309			`--version'
310			`Print out the version and copyright notice for Or1ksim and exit.`
311
312			`-h'
313			`--help'
314			`Print out help about the command line options and what they mean.`
315
316	346	jeremybenn	`-i'
317			`--interactive'
318			`After starting, drop into the Or1ksim interactive command shell.`
319
320			`-q'
321			`--quiet'
322			`Do not generate any information messages, only error messages.`
323
324			`-V'
325			`--verbose'
326			`Generate extra output messages (equivalent of specifying the`
327			`"verbose" option in the simulator configuration section (see *note`
328			`Simulator Behavior: Simulator Behavior.).`
329
330	385	jeremybenn	`-t'
331			`--trace'
332	420	jeremybenn	`Dump instruction just executed and any register/memory location`
333			`chaged after each instruction (one line per instruction).`
334	385	jeremybenn
335	472	jeremybenn	`--trace-physical'
336			`--trace-virtual'
337			`When tracing instructions, show the physical address`
338			(`--trace-physical') and/or the virtual address
339			(`--trace-virtual') of the instruction being executed. Both flags
340			`may be specified, in which case both physical and virtual`
341			`addresses are shown, physical first.`
342
343			`Note: Either or both flags may be specified without`
344			`--trace', to indicate how addresses should be shown if
345			subsequently enabled by a `SIGUSER1' signal or `l.nop 8'
346			`opcode (*note Trace Generation: Trace Generation.).`
347
348	19	jeremybenn	`-f FILE'
349	385	jeremybenn	`--file=FILE'
350	19	jeremybenn	`Read configuration commands from the specified file, looking first`
351			in the current directory, and otherwise in the `$HOME/.or1k'
352	82	jeremybenn	directory. If this argument is not specified, the file `sim.cfg'
353			`in those two locations is used. Failure to find the file is a`
354			`fatal error. *Note Configuration: Configuration, for detailed`
355			`information on configuring Or1ksim.`
356	19	jeremybenn
357			`--nosrv'
358	235	jeremybenn	`Do not start up the "Remote Serial Protocol" debug server. This`
359			`overrides any setting specified in the configuration file. This`
360			option may not be specified with `--srv'. If it is, a rude
361			message is printed and the `--nosrv' option is ignored.
362	19	jeremybenn
363			`--srv'
364
365			`--srv=N'
366	235	jeremybenn	`Start up the "Remote Serial Protocol" debug server. This`
367			`overrides any setting specified in the configuration file. If the`
368			`parameter, N, is specified, use that as the TCP/IP port for the`
369			`server, otherwise a random value from the private port range`
370			`(41920-65535) will be used. This option may not be specified with`
371			`--nosrv'. If it is, a rude message is printed and the `--nosrv'
372			`option is ignored.`
373	19	jeremybenn
374	385	jeremybenn	`-m SIZE'
375	346	jeremybenn	`--memory=SIZE'
376			`Configure a memory block of SIZE bytes, starting at address zero.`
377			The size may be followed by `k', `K', `m', `M', `g', `G', to
378			`indicate kilobytes (2^10 bytes), megabytes (2^20 bytes) and`
379			`gigabytes (2^30 bytes).`
380
381			`This is mainly intended for use when Or1ksim is used without a`
382			`configuration file, to allow just the processor and memory to be`
383			`set up. This is the equivalent of specifying a configuration`
384			memory section with `baseaddr = 0' and `size = SIZE' and all other
385			`parameters taking their default value.`
386
387			`If a configuration file is also used, it should be sure not to`
388			`specify an overlapping memory block.`
389
390	385	jeremybenn	`-d CONFIG_STRING'
391	19	jeremybenn	`--debug-config=CONFIG_STRING'
392	82	jeremybenn	`Enable selected debug messages in Or1ksim. This parameter is for`
393			`use by developers only, and is not covered further here. See the`
394	19	jeremybenn	`source code for more details.`
395
396	346	jeremybenn	`--report-memory-errors'
397			`By default all exceptions are now handled silently. If this`
398			`option is specified, bus exceptions will be reported with a`
399			`message to standard error indicating the address at which the`
400			`exception occurred.`
401	19	jeremybenn
402	346	jeremybenn	`This was the default behaviour up to Or1ksim 0.4.0. This flag is`
403			`provided for those who wish to keep that behavior.`
404
405	19	jeremybenn	`--strict-npc'
406			`In real hardware, setting the next program counter (NPC, SPR 16),`
407	82	jeremybenn	`flushes the processor pipeline. The consequence of this is that`
408			`until the pipeline refills, reading the NPC will return zero.`
409			`This is typically the case when debugging, since the processor is`
410	19	jeremybenn	`stalled.`
411
412			`Historically, Or1ksim has always returned the value of the NPC,`
413	82	jeremybenn	irrespective of when it is changed. If the `--strict-npc' option
414			`is used, then Or1ksim will mirror real hardware more accurately.`
415			`If the NPC is changed while the processor is stalled, subsequent`
416	19	jeremybenn	`reads of its value will return 0 until the processor is unstalled.`
417
418			`This is not currently the default behavior, since tools such as`
419			`GDB have been implemented assuming the historic Or1ksim behavior.`
420			`However at some time in the future it will become the default.`
421
422			`--enable-profile'
423			`Enable instruction profiling.`
424
425			`--enable-mprofile'
426			`Enable memory profiling.`
427
428
429
430			`File: or1ksim.info, Node: Profiling Utility, Next: Memory Profiling Utility, Prev: Standalone Simulator, Up: Usage`
431
432			`2.2 Profiling Utility`
433			`=====================`
434
435	82	jeremybenn	`This utility analyses instruction profile data generated by Or1ksim.`
436			`It may be invoked as a standalone command, or from the Or1ksim CLI.`
437			`The general form the standalone command is:`
438	19	jeremybenn
439	442	julius	`or32-elf-profile [-vhcq] [-g=FILE]`
440	19	jeremybenn
441	82	jeremybenn	`Many of the options have both a short and a long form. For example`
442			`-h' or `--help'.
443	19	jeremybenn
444			`-v'
445			`--version'
446			`Print out the version and copyright notice for the Or1ksim`
447			`profiling utility and exit.`
448
449			`-h'
450			`--help'
451			`Print out help about the command line options and what they mean.`
452
453			`-c'
454			`--cumulative'
455			`Show cumulative sum of cycles in functions`
456
457			`-q'
458			`--quiet'
459			`Suppress messages`
460
461			`-g=FILE'
462			`--generate=FILE'
463	82	jeremybenn	`The data file to analyse. If omitted, the default file,`
464	19	jeremybenn	`sim.profile' is used.
465
466
467
468	442	julius	`File: or1ksim.info, Node: Memory Profiling Utility, Next: Trace Generation, Prev: Profiling Utility, Up: Usage`
469	19	jeremybenn
470			`2.3 Memory Profiling Utility`
471			`============================`
472
473	82	jeremybenn	`This utility analyses memory profile data generated by Or1ksim. It may`
474			`be invoked as a standalone command, or from the Or1ksim CLI. The`
475	19	jeremybenn	`general form the standalone command is:`
476
477	442	julius	`or32-elf-mprofile [-vh] [-m=M] [-g=N] [-f=FILE] FROM TO`
478	19	jeremybenn
479	82	jeremybenn	`Many of the options have both a short and a long form. For example`
480			`-h' or `--help'.
481	19	jeremybenn
482			`-v'
483			`--version'
484			`Print out the version and copyright notice for the Or1ksim memory`
485			`profiling utility and exit.`
486
487			`-h'
488			`--help'
489			`Print out help about the command line options and what they mean.`
490
491			`-m=M'
492			`--mode=M'
493	82	jeremybenn	`Specify the mode out output. Permitted options are`
494	19	jeremybenn
495			`detailed'
496			`d'
497	82	jeremybenn	`Detailed output. This is the default if no mode is specified.`
498	19	jeremybenn
499			`pretty'
500			`p'
Browse

Tools

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [or1ksim/] [doc/] [or1ksim.info] - Blame information for rev 510
