sim/rx/README.txt

   1 The RX simulator offers two rx-specific configure options:
   2
   3 --enable-cycle-accurate  (default)
   4 --disable-cycle-accurate
   5
   6 If enabled, the simulator will keep track of how many cycles each
   7 instruction takes.  While not 100% accurate, it is very close,
   8 including modelling fetch stalls and register latency.
   9
  10 --enable-cycle-stats  (default)
  11 --disable-cycle-stats
  12
  13 If enabled, specifying "-v" twice on the simulator command line causes
  14 the simulator to print statistics on how much time was used by each
  15 type of opcode, and what pairs of opcodes tend to happen most
  16 frequently, as well as how many times various pipeline stalls
  17 happened.
  18
  19
  20
  21 The RX simulator offers many command line options:
  22
  23 -v - verbose output.  This prints some information about where the
  24 program is being loaded and its starting address, as well as
  25 information about how much memory was used and how many instructions
  26 were executed during the run.  If specified twice, pipeline and cycle
  27 information are added to the report.
  28
  29 -d - disassemble output.  Each instruction executed is printed.
  30
  31 -t - trace output.  Causes a *lot* of printed information about what
  32   every instruction is doing, from math results down to register
  33   changes.
  34
  35 --ignore-*
  36 --warn-*
  37 --error-*
  38
  39   The RX simulator can detect certain types of memory corruption, and
  40   either ignore them, warn the user about them, or error and exit.
  41   Note that valid GCC code may trigger some of these, for example,
  42   writing a bitfield involves reading the existing value, which may
  43   not have been set yet.  The options for * are:
  44
  45     null-deref - memory access to address zero.  You must modify your
  46       linker script to avoid putting anything at location zero, of
  47       course.
  48
  49     unwritten-pages - attempts to read a page of memory (see below)
  50       before it is written.  This is much faster than the next option.
  51
  52     unwritten-bytes - attempts to read individual bytes before they're
  53       written.
  54
  55     corrupt-stack - On return from a subroutine, the memory location
  56       where $pc was stored is checked to see if anything other than
  57       $pc had been written to it most recently.
  58
  59 -i -w -e - these three options change the settings for all of the
  60   above.  For example, "-i" tells the simulator to ignore all memory
  61   corruption.
  62
  63 -E - end of options.  Any remaining options (after the program name)
  64   are considered to be options for the simulated program, although
  65   such functionality is not supported.
  66
  67
  68
  69 The RX simulator simulates a small number of peripherals, mostly in
  70 order to provide I/O capabilities for testing and such.  The supported
  71 peripherals, and their limitations, are documented here.
  72
  73 Memory
  74
  75 Memory for the simulator is stored in a hierarchical tree, much like
  76 the i386's page directory and page tables.  The simulator can allocate
  77 memory to individual pages as needed, allowing the simulated program
  78 to act as if it had a full 4 Gb of RAM at its disposal, without
  79 actually allocating more memory from the host operating system than
  80 the simulated program actually uses.  Note that for each page of
  81 memory, there's a corresponding page of memory *types* (for tracking
  82 memory corruption).  Memory is initially filled with all zeros.
  83
  84 GPIO Port A
  85
  86 PA.DR is configured as an output-only port (regardless of PA.DDR).
  87 When written to, a row of colored @ and * symbols are printed,
  88 reflecting a row of eight LEDs being either on or off.
  89
  90 GPIO Port B
  91
  92 PB.DR controls the pipeline statistics.  Writing a 0 to PB.DR disables
  93 statistics gathering.  Writing a non-0 to PB.DR resets all counters
  94 and enables (even if already enabled) statistics gathering.  The
  95 simulator starts with statistics enabled, so writing to PB.DR is not
  96 needed if you want statistics on the entire program's run.
  97
  98 SCI4
  99
 100 SCI4.TDR is connected to the simulator's stdout.  Any byte written to
 101 SCI4.TDR is written to stdout.  If the simulated program writes the
 102 bytes 3, 3, and N in sequence, the simulator exits with an exit value
 103 of N.
 104
 105 SCI4.SSR always returns "transmitter empty".
 106
 107
 108 TPU1.TCNT
 109 TPU2.TCNT
 110
 111 TPU1 and TPU2 are configured as a chained 32-bit counter which counts
 112 machine cycles.  It always runs at "ICLK speed", regardless of the
 113 clock control settings.  Writing to either of these 16-bit registers
 114 zeros the counter, regardless of the value written.  Reading from
 115 these registers returns the elapsed cycle count, with TPU1 holding the
 116 most significant word and TPU2 holding the least significant word.
 117
 118 Note that, much like the hardware, these values may (TPU2.CNT *will*)
 119 change between reads, so you must read TPU1.CNT, then TPU2.CNT, and
 120 then TPU1.CNT again, and only trust the values if both reads of
 121 TPU1.CNT were the same.