A simulator for the Untimed, Synchronous, and Timed models of computation, as described in Modeling Embedded Systems and SoC's: Concurrency and Time in Models of Computation by Axel Jantsch.

This simulator was built using Python 2.6, and should run on any Python version 2.x later than 2.6 (any 2.6 or 2.7 release should work). Due to breaking API changes, Python releases 3.0 and later are not supported.

Mac OS 10.6 and most recent distributions of Linux should include a compatible version of Python out of the box (run 'python' from a terminal window); Windows users can download Python 2.7 from the Python download page.

You can download the simulator in two ways. Either:

• Download a snapshot of the most recent version of the simulator: Windows (zip), Linux/OSX (tar.gz)

• Or, if you have git installed, clone the repository with:

  git clone git@github.com:jonathonw/moc-sim.git
  

The simulator is designed as a command-line utility; it takes in an XML file specifying the model and its input signals, and outputs the output signals which were generated after the model has been executed.

On Windows, you can run the simulator from the command prompt with:

python Simulator.py sample.xml

where sample.xml is the XML file containing the model to be simulated. Also note that Python must be in the system PATH for the simulator to run; for more information, see the Python documentation.

On Linux or Mac OS X, Python is typically already in the system path. On such systems, you should be able to run the simulator with:

./Simulator.py sample.xml

where sample.xml is the XML file containing the model to be simulated.

• User must explicitly specify the interfaces between different MoCs.
• User must explicitly specify a splitter process for a signal that is consumed by multiple processes. (Note: Splitter processes cannot connect to a global input, else the system will fail)
• Process functions must be valid python code.
• No syntactical verification for the input file.
• Doesn't implent the full fix-point solution algorithm, require a delay for feedback loop solution.

The XML system file is defined in a global system container <system>, which encapsulates the <inputs>, <outputs>, and <processes> in the overall structure:

<?xml version='1.0' ?>
<system>
    <inputs>
    </inputs>
    <outputs>
    </outputs>
    <processes>
    </processes>
</system>

These sections are created in the following way:

• Inputs: Each input must have a tag and an input value string. The string is a comma separated value string of floating point numbers. All floating point numbers are accepted in this string, as is the 'Absent' input. Here are two example inputs loaded within the global inputs:

  <inputs>
      <input1>
      23.0,10,0,2,45.56
      </input1>
      <myinput>
      Absent,0.23,55,Absent,0
      </myinput>
  </inputs>
  

• Outputs: The outputs follow the same convention as the inputs, with the exception that they cannot have strings (initial values). An example of two outputs loaded within the global outputs:

  <outputs>
      <namedoutput>
      </namedoutput>
      <output1>
      </output1>
  </outputs>
  

• Processes: The processes are generated similarly to the inputs and outputs, with the exception that they have many more fields within each process. The fields can be named whatever the user wishes, as long as they retain the same order as the examples provided. Generically, processes are defined this way:

  <processes>
      <process1>
      </process1>
      <namedprocess>
      </namedprocess>
  </processes>
  

  Processes can be of these forms:

  • Models of Computation (MoCs): For processes falling within MoCs, the first two fields are <MoC> and <Type>.
    <MoC> accepts as valid text: Untimed, Timed, and Synchronous (for each type of MoC).
    <Type> accepts as valid processes, all the processes listed in Supported Processes. The fields following <MoC> and <Type> are specific to each process and follow the order of the init functions for each process. This order is reproduced in Supported Processes after each respective supported process. Again, the tags for the fields can be renamed by the user, but their order must remain intact. For functions that are to be supplied by the user (such as <PartFunc>, <OutFunc>, or <StateFunc>), the functions must be valid python functions, with correct python indentation. These three fields (<PartFunc>, <OutFunc>, or <StateFunc>) cannot have their names changed. They must go by these tags and must be in the correct order: PartFunc, OutFunc, then StateFunc. An example process is defined this way:

    <process1>
        <MoC>
            Untimed
        </MoC>
        <Type>
            Zip
        </Type>
        <Count1>
            3
        </Count1>
        <Count2>
            3
        </Count2>
        <In1>
            inputs/input1
        </In1>
        <In2>
            process2/Out1
        </In2>
        <Out1>
        </Out1>
    </process1>
    

  • Splitters: Splitters simply take one input and reproduce it on both outputs. Therefore the only fields they have are <In1>,<Out1>,and <Out2>, although these can be named whatever the user wishes as long as the order is maintained (1:input,2:first output, 3:second output). Splitter processes are defined this way:

    <process4>
        <type>
            Splitter
        </type>
        <In1>
            myProcess/Out1
        </In1>
        <Out1>
            outputs/output3
        </Out1>
        <Out2>
        </Out2>
    </process4>
    

  • Interfaces: Interfaces are defined by the user to transform a signal from one model of computation into another model of computation. Interface must be specified as the <type> of the prcoess. The specific interface is defined by the field <Transform>. It accepts as valid text all of the interfaces listed in the interfaces section of Supported Processes. The <PartConst> field, if the process supports it, accepts a number which is used as the partition constant for the input signal. Interface processes are defined this way:

    <process6>
        <type>
            Interface
        </type>
        <Transform>
            StripT2S
        </Transform>
        <PartConst>
            3
        </PartConst>
        <In1>
        </In1>
        <Out1>
        </Out1>
    </process6>