Embedded Simulator Statements

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

They allow

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.


.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.

.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

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.