FuncSimDesign

Introduction

This page describes some ideas on how the functional part of our simulator should look like. It also should define the external interfaces to both user and clock-precise model.

Command line arguments

Batch mode

The batch mode means that all the required data is passed with command-line arguments, then the execution starts and cannot be interrupted by a user until it finished.

funcsim --binary <binary>|--elf <binary> [--num-steps <num>] [--disasm] [--print-reg-state] [--print-mem-state] [--output-file <name>] [--trace]

Current options

--binary,-b — instructs simualtor to load raw machine code from file. You're allowed not to write this key.

--elf,-e — load binary ELF file sections to memory.

--num-steps,-n — do only specified amount of steps and then exit. By default core runs until it encounters hlt instruction or there is a simulation error.

--disasm,-d — print disassembly of every current instruction.

--help,-h — print help with this paragraph.

Planned list of options

--print-reg-state,-r — dump register state after simulation has finished.

--print-mem-state,-m — dump memory state after simulation has finished.

--output-file,-o — redirect normal output to the given file. By default we print to stdout.

--trace,-t — report all architectural state changes (register modified, memory written etc)

Planned list of features

Return values:

TODO Extend this table

code	meaning
0	simulation finished normally with HLT or amount of steps requested were done
1	simualtion encountered uninitialized memory
2	internal funcsim error (unknown instruction, crash etc)

Other error codes should correspond to environment problems (file not found, cannot write file etc).

Interactive mode

This mode assumes that a user is given with control line and is able to input commands to control the simulation flow.

funcsim -interactive [-binary <binary>|-elf <binary>]

Details

The interaction and communication of FuncSim components are show on the picture: TODO smaller picture, extend it

• core - the functions of instructions fetching, decoding, execution, memory accessing;

• scheduler - the main user interface: parsing command line arguments, user input; control of execution of core.

• register file - architecturally defined state of MDSP;

• memory - model of memory accessible by core;

Log and message system design

Purpose

To control all text messages generated by simulator objects. We should be able to mute certain messages, to dynamically redirect all messages to different files, and change the way messages are shown.

Abstraction

In this logging system we present all objects as playing on a stage, giving their cues one by one. It will look like this:

FuncSim: Creating the simulator
FuncSim.Core0: Created.
FuncSim.Core0.Decoder: Initialized.
FuncSim: Reading the config
FuncSim.Config: parsing command line options.
FuncSim.Config: -binary encountered, value 'simpl_test.bin'
FuncSim.Config[NOTIMPL]: -num_steps encountered, value 100

<... now we change log settings to show current instruction counter ...>

FuncSim.Core0.Decoder[100]: decoding instruction started
FuncSim.Core0.Decoder[100]: load %r1, %r2
FuncSim.Core0[100]: executing...
FuncSim.Core0[101]: done

The following ideas define this logging framework features.

1. Every object instance that logs should have its unique name
2. This object's name should be possible to print along with a message
3. All logging agents' common settings are controlled from one place
4. Each logging agent should have its own configuration as well.
5. The types of messages should cover these cases: 1. Debug messages 1. Warning messages 1. Not about not implemented yet features 1. Error messages 1. Normal messages (ones which purpose is to provide text data, like disassembly, trace record, memory inspection etc)
6. Error reports should inform user on line/function name of the problem, and specify the pre-defined error code

Sample definition

class Log
{

const char* name;
int log_level; // this object's own verbosity

public:

/* We might pass a parent_name in constructor, in this case the resulting name of this log will contain it as prefix
 * We must pass name and we should control it is unique across the all objects.
 */
Log(const char* parent_name, const char* name); 

print(const char* format, ...) const; // this variant ignores verbosity settings

print(int importance, const char* format, ...) const; // this case print only if importance > log_level

warning(const char* format, ...) const; // to print warnings

critical(const char* format, ...) const; // to print critical errors (see discussion below)

setLevel(int new_level); // set up this object's level
static setOutPutFormat(FormatMask); // bits of FormatMask defines misc things that are addedto the messages for all loggers
static setOutputFile(FILE* new_fd); // globally change the output destination
}

Logging vs error reporting

• Error reporting should be implemented with help of macroes because we want to supply line and function name information in this case, and it turned out to be troublesome to reliably acquire these data with help of other language/runtime features.
• For such behaiour the implementation would look like this:

#define ERROR(msg) this->error("%s at %s in file %s:%d", msg, __FUNCTION__, __FILE__, __LINENUM__)

Things to do

1. Design disassembler format (AT&T)
2. Design input language for interactive mode
3. Design register, memory dump formats.
4. Design trace file format