Simulation Model Generator
The premadona tool allows to generate simulation models from XML specifications of NoC-based MPSoC systems. These XML specifications include a number of applications (in the form of SDF, CSDF or SADF graphs), a description of the MPSoC platform and a mapping of the applications on this platform. In addition, certain settings can be specified to indicate what aspects of the system should be monitored for performance analysis or traced. The sources of the premadona tool that you can download here compile and run on Linux and assumes NoC-based MPSoC platforms without resource management. The simulator required for executing models generated by the premadona tool can be downloaded from this webpage.
The command-line syntax for the premadona tool is as follows:
premadona -n <number> -a <applist> -p <mpsocfile> -m <mapfile> [-s <settings>] [-o <modelfile>] [-l <logfile>]
The mandatory -n argument indicates the <number> of applications that will be mapped on the platform. The mandatory argument -a should refer to a space-saparated list <applist> of XML files. The number of files in this list must not be less than <number>. Each file in the <applist> describes one application. Aplications can be specified as an SDF, CSDF or SADF graph using similar XML formats as used by the sdf3 tool, see below. The mandatory -p argument denotes the XML file <mpsocfile> describing the NoC-based MPSoC platform. The final mandatory argument is -m, which specifies the XML file <mapfile> that describes how the tasks of each application are mapped onto the nodes of the NoC-based MPSoC platform.
There are three optional arguments for the premadona tool. Argument -s can be used to specify an XML file <settings> with settings for performance monitoring and tracing certain parts of the system. The -o option allows to specify the file to which the generated model is written. The default <modelfile> is model.p4r. Argument -l enables specifying the file in which the performance results obatained during the simulation are written. The default <logfile> is results.log.
The premadona uses several different XML formats to specify applications, a platform and mapping as well as monitoring and tracing settings. Click on any of the links below to obtained detailed information of the different XML formats.
- XML formats for specifying applications
- Describing NoC-based MPSoC platforms
- Specifying a mapping
- Optional specification of monitoring, tracing and other simulation settings (including an explanation of the monitored performance metrics)
Specifying a Platform
A platform is specified according to the XML format defined in platform.xsd. The layout of an XML file following this format is shown below.
<?xml version='1.0' encoding='UTF-8'?>
<platform name=PlatformName version='1.0' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns='uri:platform' xsi:schemaLocation='uri:platform http://www.es.ele.tue.nl/premadona/tools/platform.xsd'>
<node name=NodeName processor_type=Type scheduling_policy=Policy voltage_scale_factor=Value local_bandwidth=Value local_setup_latency=Value />
<processor_type name=Type clock_frequency=Value context_switching_time=Value power=Value />
<noc bandwidth=Value setup_latency=Value />
<power storage=Value communication=Value />
A platform has an optional name (default is MPSoC) and involves four different mandatory elements. A node specifies the instantiation of a specific node, which must have a name and a processor_type. The Type must match with the name of one of the processor_type elements (see below). Each node requires specifying a scheduling_policy, which represents the scheduling behaviour of the operating system running on the processor included in the node. Currently, the premadona tool supports a non-preemptive FCFS scheduling policy (Policy is FCFS) and a preemptive priority-based scheduling policy (Policy equals PB). Other options will be added in the future. The optional voltage_scale_factor allows to scale down the voltage of each node (0 < Value <= 1), where the effects on execution time and power consumption are automatically taken into account. The default voltage_scale_factor is 1. The mandatory attribute local_bandwidth specifies the bandwith for communicating tokens between tasks mapped onto the involved node. Each communication of such tokens includes an additional latency given by local_setup_latency, which is 0 by default.
Each processor_type has a mandatory name for identification purposes. The clock_frequency specifies the base clock frequency of the processor type. The optional context_switching_time allows to specify a fixed amount of clock cycles that represent the overhead when switching the execution of a new or a different task. Default context_switching_time is 0. The power attribute allows specifying the power consumed by the processor when actively used (power consumption is considered to be 0 when no tasks are executing on the processor.
The noc element specifies the properties of the NoC. It requires the bandwidth attribute to define the bandwidth of a connection through the NoC. The optional setup_latency enables specifying a fixed delay for each communication of tokens that is performed, which may for example represent any contention due to setting up a route through the NoC. The mandatory power element requires specifying the amount of active power consumed for storing and communicating a byte.
We remark that the platform model generated by the premadona tool is too abstract to be adequate for most realistic systems. This concerns especially the evaluation of the consumed power. Nevertheless, the model will give quite a good impression of the effects of distributing an application over multiple nodes and voltage scaling. Future work includes the development of more precise model of platforms like CoMPSoC and MPARM - this is a vacant master project ;).
An example set of XML files that specify a NoC-based MPSoC platform on which one fictitious application (in the form of an SADF graph) is mapped can be downloaded here. The example origimates from a master course on multiprocessor design. The example can be run by executing: premadona -n 1 -a application.xml -p platform.xml -m mapping.xml -s settings.xml followed by the command: rotalumis model.p4r.
For more information about the premadona tool, you can write an email to B.D.Theelen @ tue.nl