Embedded Simulator Statements

The following statements are used to control interation between an executing program and the simulator.

.print
.open
.close
.read
.write
.breakpoint
.xcsim

They allow

• values to be displayed in the trace window
• values to be read and written between files and simulation RAM
• complex break points to be implemented.
• user defined virtual hardware to be integrated into the simulation
• user defined popup dialogs to be tailored for complex simulations

Simulation statements do not occupy any code space within the generated machine code, so the machine code can be safely downloaded to the micro without the need to remove the statements and obviates subsequent retesting.

Simulation statements are executed when the simulator reachs their embedded position within the assembler source.

Acessing Simulation RAM

When the assembler encounters embedded simulation statements, it partially processes them and converts assembler labels into simulation RAM references which the simulator can subsequently use to access the specified simulated RAM locations. The assembler does not otherwise validate any of the .xcsim embedded simulator statements.

Anything between matching '{' and '}' is evaluated and processed by the assember, and anything else is evaluated by the simulator.

The '[' and ']' delimters when combined with the '{' and '}' delimters specify 'contents of' to the simulator.

Expressions such as [{data_in}][1] allow successive RAM locations to be accessed.

The expression [{0}][indx] allows any RAM location with the absolute address indx to be accessed.

e.g.

.print  "lab %s = " : { STR(data_in) }, "abC %d xyZ": [{data_in}]

where data_in is an assembler variable with the value i2c_data_in and i2c_data_in is a label corresponding to the RAM location 35 generates the string

.print  "lab %s = " : "i2c_data_in",  "abC %d xyZ" : [{35}]

the '[' and ']' delimters when combined with the '{' and '}' delimters specify 'contents of' to the simulator (i.e. get the value held in RAM location 35)

the reset of the statement is standard XPE

"ABC%s" : "x"

is an XPE string format expression that generates the string "ABCx"

String formats correspond directly to 'C' language format string specification (except only one format specifier is allowed per string)

Simulation RAM can also be written to.
e.g.

.xcsim   for  j=0  while  j<10  step  j+=1  do
.xcsim   [{buff}][j] = j+31
.xcsim   done

This writes the values 31 to 40 to the simulated RAM locations at buff[0] to buff[9]

File I/O Involving Simulation RAM

File I/O facilities are provided that allow the data to be manipulated in a manor and format that is natural to the programmer (no having to build special programs to simulate serial interfaces with data presented as logic levels with critical timing)

.xcsim   for  j=0  while  j<10  step  j+=1  do
.write    "results-file.txt",  "buff[%d]=":j,  "%d":([{buff}][j])
.xcsim   done

Complex Break Points

Complex sequences of events can easily be monitored and used to trigger a simulator trap condition. e.g. it is possible to check that a data location is within a given range whenever the simulation passes through a given execution path. This is done by simply writing the tests in situ in the assembler source using the .xcsim statements. Variables that are external to the simulated program (not stored in the simulated programs data space) can easily be used to maintain the status of the complex condition being investigated.

.xcsim   if  [{xfr_len}] < 5  ||  [{xfr_len}] > 10  then
.breakpoint
.xcsim   endif

User Defined Virtual Hardware

The simulator uses XPE to interact with the GUI and provides mechanisms through which XPE code can be passed through from the program being simulated to the underlying GUI. This allows the user to use XEBOT to build virtual hardware (e.g. sliders driven A/D convertor, gages readouts for D/A convertors) and use it to interactively drive and monitor a simulated system.

User Defined Popup Dialogs

The same capabilities that allow a user to build virtual hardware (the XPE interface and XEBOT) allow the user to build complex user defined popup dialogs. These dialogs can be used to interactively monitor and change simulation data.

Black Box Testing

The data read and write facilities allow sections of code to quickly and easily process test data and generate test results without the need to produce complex external I/O stimulation tools. e.g. given an existing program written in C that takes a set of data and returns a set of results, the program can be converted into assembler for the target (mybe even a complex multiprocessor system) then fed the same data and the generated results compared to those of the original program  by using a standard utility such as diff. Changies to the program would require very little interaction during the testing phase using the black box approach.