357 lines
11 KiB
Plaintext
357 lines
11 KiB
Plaintext
|
|
SIS - Sparc Instruction Simulator README file (v2.0, 05-02-1996)
|
|
-------------------------------------------------------------------
|
|
|
|
1. Introduction
|
|
|
|
The SIS is a SPARC V7 architecture simulator. It consist of two parts,
|
|
the simulator core and a user defined memory module. The simulator
|
|
core executes the instructions while the memory module emulates memory
|
|
and peripherals.
|
|
|
|
2. Usage
|
|
|
|
The simulator is started as follows:
|
|
|
|
sis [-uart1 uart_device1] [-uart2 uart_device2]
|
|
[-nfp] [-freq frequency] [-c batch_file] [files]
|
|
|
|
The default uart devices for SIS are /dev/ptypc and /dev/ptypd. The
|
|
-uart[1,2] switch can be used to connect the uarts to other devices.
|
|
Use 'tip /dev/ttypc' to connect a terminal emulator to the uarts.
|
|
The '-nfp' will disable the simulated FPU, so each FPU instruction will
|
|
generate a FPU disabled trap. The '-freq' switch can be used to define
|
|
which "frequency" the simulator runs at. This is used by the 'perf'
|
|
command to calculated the MIPS figure for a particular configuration.
|
|
The give frequency must be an integer indicating the frequency in MHz.
|
|
|
|
The -c option indicates that sis commands should be read from 'batch_file'
|
|
at startup.
|
|
|
|
Files to be loaded must be in one of the supported formats (see INSTALLATION),
|
|
and will be loaded into the simulated memory. The file formats are
|
|
automatically recognised.
|
|
|
|
The script 'startsim' will start the simulator in one xterm window and
|
|
open a terminal emulator (tip) connected to the UART A in a second
|
|
xterm window. Below is description of commands that are recognized by
|
|
the simulator. The command-line is parsed using GNU readline. A command
|
|
history of 64 commands is maintained. Use the up/down arrows to recall
|
|
previous commands. For more details, see the readline documentation.
|
|
|
|
batch <file>
|
|
|
|
Execute a batch file of SIS commands.
|
|
|
|
+bp <address>
|
|
|
|
Adds an breakpoint at address <address>.
|
|
|
|
bp
|
|
|
|
Prints all breakpoints
|
|
|
|
-bp <num>
|
|
|
|
Deletes breakpoint <num>. Use 'bp' to see which number is assigned to the
|
|
breakpoints.
|
|
|
|
cont [inst_count]
|
|
|
|
Continue execution at present position, optionally for [inst_count]
|
|
instructions.
|
|
|
|
dis [addr] [count]
|
|
|
|
Disassemble [count] instructions at address [addr]. Default values for
|
|
count is 16 and addr is the present address.
|
|
|
|
echo <string>
|
|
|
|
Print <string> to the simulator window.
|
|
|
|
float
|
|
|
|
Prints the FPU registers
|
|
|
|
go <address> [inst_count]
|
|
|
|
The go command will set pc to <address> and npc to <address> + 4, and start
|
|
execution. No other initialisation will be done. If inst_count is given,
|
|
execution will stop after the specified number of instructions.
|
|
|
|
help
|
|
|
|
Print a small help menu for the SIS commands.
|
|
|
|
hist [trace_length]
|
|
|
|
Enable the instruction trace buffer. The 'trace_length' last executed
|
|
instructions will be placed in the trace buffer. A 'hist' command without
|
|
a trace_length will display the trace buffer. Specifying a zero trace
|
|
length will disable the trace buffer.
|
|
|
|
load <file_name>
|
|
|
|
Loads a file into simulator memory.
|
|
|
|
mem [addr] [count]
|
|
|
|
Display memory at [addr] for [count] bytes. Same default values as above.
|
|
|
|
quit
|
|
|
|
Exits the simulator.
|
|
|
|
perf [reset]
|
|
|
|
The 'perf' command will display various execution statistics. A 'perf reset'
|
|
command will reset the statistics. This can be used if statistics shall
|
|
be calculated only over a part of the program. The 'run' and 'reset'
|
|
command also resets the statistic information.
|
|
|
|
reg [reg_name] [value]
|
|
|
|
Prints and sets the IU regiters. 'reg' without parameters prints the IU
|
|
registers. 'reg [reg_name] [value]' sets the corresponding register to
|
|
[value]. Valid register names are psr, tbr, wim, y, g1-g7, o0-o7 and
|
|
l0-l7.
|
|
|
|
reset
|
|
|
|
Performs a power-on reset. This command is equal to 'run 0'.
|
|
|
|
run [inst_count]
|
|
|
|
Resets the simulator and starts execution from address 0. If an instruction
|
|
count is given (inst_count), the simulator will stop after the specified
|
|
number of instructions. The event queue is emptied but any set breakpoints
|
|
remain.
|
|
|
|
step
|
|
|
|
Equal to 'trace 1'
|
|
|
|
tra [inst_count]
|
|
|
|
Starts the simulator at the present position and prints each instruction
|
|
it executes. If an instruction count is given (inst_count), the simulator
|
|
will stop after the specified number of instructions.
|
|
|
|
Typing a 'Ctrl-C' will interrupt a running simulator.
|
|
|
|
Short forms of the commands are allowed, e.g 'c' 'co' or 'con' are all
|
|
interpreted as 'cont'.
|
|
|
|
|
|
3. Simulator core
|
|
|
|
The SIS emulates the behavior of the 90C601E and 90C602E sparc IU and
|
|
FPU from Matra MHS. These are roughly equivalent to the Cypress C601
|
|
and C602. The simulator is cycle true, i.e a simulator time is
|
|
maintained and inremented according the IU and FPU instruction timing.
|
|
The parallel execution between the IU and FPU is modelled, as well as
|
|
stalls due to operand dependencies (FPU). The core interacts with the
|
|
user-defined memory modules through a number of functions. The memory
|
|
module must provide the following functions:
|
|
|
|
int memory_read(asi,addr,data,ws)
|
|
int asi;
|
|
unsigned int addr;
|
|
unsigned int *data;
|
|
int *ws;
|
|
|
|
int memory_write(asi,addr,data,sz,ws)
|
|
int asi;
|
|
unsigned int addr;
|
|
unsigned int *data;
|
|
int sz;
|
|
int *ws;
|
|
|
|
int sis_memory_read(addr, data, length)
|
|
unsigned int addr;
|
|
char *data;
|
|
unsigned int length;
|
|
|
|
int sis_memory_write(addr, data, length)
|
|
unsigned int addr;
|
|
char *data;
|
|
unsigned int length;
|
|
|
|
int init_sim()
|
|
|
|
int reset()
|
|
|
|
int error_mode(pc)
|
|
unsigned int pc;
|
|
|
|
memory_read() is used by the simulator to fetch instructions and
|
|
operands. The address space identifier (asi) and address is passed as
|
|
parameters. The read data should be assigned to the data pointer
|
|
(*data) and the number of waitstate to *ws. 'memory_read' should return
|
|
0 on success and 1 on failure. A failure will cause a data or
|
|
instruction fetch trap. memory_read() always reads one 32-bit word.
|
|
|
|
sis_memory_read() is used by the simulator to display and disassemble
|
|
memory contants. The function should copy 'length' bytes of the simulated
|
|
memory starting at 'addr' to '*data'.
|
|
The sis_memory_read() should return 1 on success and 0 on failure.
|
|
Failure should only be indicated if access to unimplemented memory is attempted.
|
|
|
|
memory_write() is used to write to memory. In addition to the asi
|
|
and address parameters, the size of the written data is given by 'sz'.
|
|
The pointer *data points to the data to be written. The 'sz' is coded
|
|
as follows:
|
|
|
|
sz access type
|
|
0 byte
|
|
1 halfword
|
|
2 word
|
|
3 double-word
|
|
|
|
If a double word is written, the most significant word is in data[0] and
|
|
the least significant in data[1].
|
|
|
|
sis_memory_write() is used by the simulator during loading of programs.
|
|
The function should copy 'length' bytes from *data to the simulated
|
|
memory starting at 'addr'. sis_memory_write() should return 1 on
|
|
success and 0 on failure. Failure should only be indicated if access
|
|
to unimplemented memory is attempted. See erc32.c for more details
|
|
on how to define the memory emulation functions.
|
|
|
|
The 'init_sim' is called once when the simulator is started. This function
|
|
should be used to perform initialisations of user defined memory or
|
|
peripherals that only have to be done once, such as opening files etc.
|
|
|
|
The 'reset' is called every time the simulator is reset, i.e. when a
|
|
'run' command is given. This function should be used to simulate a power
|
|
on reset of memory and peripherals.
|
|
|
|
error_mode() is called by the simulator when the IU goes into error mode,
|
|
typically if a trap is caused when traps are disabled. The memory module
|
|
can then take actions, such as issue a reset.
|
|
|
|
sys_reset() can be called by the memory module to reset the simulator. A
|
|
reset will empty the event queue and perform a power-on reset.
|
|
|
|
4. Events and interrupts
|
|
|
|
The simulator supports an event queue and the generation of processor
|
|
interrupts. The following functions are available to the user-defined
|
|
memory module:
|
|
|
|
event(cfunc,arg,delta)
|
|
void (*cfunc)();
|
|
int arg;
|
|
unsigned int delta;
|
|
|
|
set_int(level,callback,arg)
|
|
int level;
|
|
void (*callback)();
|
|
int arg;
|
|
|
|
clear_int(level)
|
|
int level;
|
|
|
|
sim_stop()
|
|
|
|
The 'event' functions will schedule the execution of the function 'cfunc'
|
|
at time 'now + delta' clock cycles. The parameter 'arg' is passed as a
|
|
parameter to 'cfunc'.
|
|
|
|
The 'set_int' function set the processor interrupt 'level'. When the interrupt
|
|
is taken, the function 'callback' is called with the argument 'arg'. This
|
|
will also clear the interrupt. An interrupt can be cleared before it is
|
|
taken by calling 'clear_int' with the appropriate interrupt level.
|
|
|
|
The sim_stop function is called each time the simulator stops execution.
|
|
It can be used to flush buffered devices to get a clean state during
|
|
single stepping etc.
|
|
|
|
See 'erc32.c' for examples on how to use events and interrupts.
|
|
|
|
5. Memory module
|
|
|
|
The supplied memory module (erc32.c) emulates the functions of memory and
|
|
the MEC asic developed for the 90C601/2. It includes the following functions:
|
|
|
|
* UART A & B
|
|
* Real-time clock
|
|
* General purpose timer
|
|
* Interrupt controller
|
|
* Breakpoint register
|
|
* Watchpoint register
|
|
* 512 Kbyte ROM
|
|
* 4 Mbyte RAM
|
|
|
|
See README.erc32 on how the MEC functions are emulated. For a detailed MEC
|
|
specification, look at the ERC32 home page at URL:
|
|
|
|
http://www.estec.esa.nl/wsmwww/erc32
|
|
|
|
6. Compile and linking programs
|
|
|
|
The directory 'examples' contain some code fragments for SIS.
|
|
The script gccx indicates how the native sunos gcc and linker can be used
|
|
to produce executables for the simulator. To compile and link the provided
|
|
'hello.c', type 'gccx hello.c'. This will build the executable 'hello'.
|
|
Start the simulator by running 'startsim hello', and issue the command 'run.
|
|
After the program is terminated, the IU will be force to error mode through
|
|
a software trap and halt.
|
|
|
|
The programs are linked with a start-up file, srt0.S. This file includes
|
|
the traptable and window underflow/overflow trap routines.
|
|
|
|
7. IU and FPU instruction timing.
|
|
|
|
The simulator provides cycle true simulation. The following table shows
|
|
the emulated instruction timing for 90C601E & 90C602E:
|
|
|
|
Instructions Cycles
|
|
|
|
jmpl, rett 2
|
|
load 2
|
|
store 3
|
|
load double 3
|
|
store double 4
|
|
other integer ops 1
|
|
fabs 2
|
|
fadds 4
|
|
faddd 4
|
|
fcmps 4
|
|
fcmpd 4
|
|
fdivs 20
|
|
fdivd 35
|
|
fmovs 2
|
|
fmuls 5
|
|
fmuld 9
|
|
fnegs 2
|
|
fsqrts 37
|
|
fsqrtd 65
|
|
fsubs 4
|
|
fsubd 4
|
|
fdtoi 7
|
|
fdots 3
|
|
fitos 6
|
|
fitod 6
|
|
fstoi 6
|
|
fstod 2
|
|
|
|
The parallel operation between the IU and FPU is modelled. This means
|
|
that a FPU instruction will execute in parallel with other instructions as
|
|
long as no data or resource dependency is detected. See the 90C602E data
|
|
sheet for the various types of dependencies. Tracing using the 'trace'
|
|
command will display the current simulator time in the left column. This
|
|
time indicates when the instruction is fetched. If a dependency is detetected,
|
|
the following fetch will be delayed until the conflict is resolved.
|
|
|
|
The load dependency in the 90C601E is also modelled - if the destination
|
|
register of a load instruction is used by the following instruction, an
|
|
idle cycle is inserted.
|
|
|
|
8. FPU implementation
|
|
|
|
The simulator maps floating-point operations on the hosts floating point
|
|
capabilities. This means that accuracy and generation of IEEE exceptions is
|
|
host dependent.
|