High-Level Modeling and Exploration of a Powerline Communication Network Based on System-on-Chip - Multi-objective Design Space Exploration of Multiprocessor SoC Architectures - page 154

unit="s" desired="small"/>
</system_metrics>
</design_space>

All these parameters and metrics will be further explained in following sections of
this study.
As we can see in the dse.xml file, we explicitly specify to modeFRONTIER which
is the command that has to be launched by the tool in order to run a single simulation.
If we take a closer look to this file, we have:

#!
echo "---> Running simulation"
$EXAMPLE_PATH/storm -xml $EXAMPLE_PATH/platform.xml $1 \
-xmd $EXAMPLE_PATH/metrics.xml $2 \
mv output.xml system_metrics.xml

In this bash shell we can identify three types of information passed to the platform:

￿ The configuration files from the platform itself (which are implicit in the storm

executable)

￿ The configuration files that drive the behavior of M3SCoPE (platform.xml and

metrics.xml) and that are fixed for all the simulations

￿ The configuration files that are fixed by modeFRONTIER ($1 and $2). The first

parameter is the system configuration file (in this case system_config.xml) and the
name of the output file to be used by the platform (in this case system_metrics.xml)

The last line of the bash file makes only some adaptation in the output XML file to
be read by modeFRONTIER.

7.2.2.4 M3-SCoPE: Interface and Description Tool

Once the executable is run, we have still to inject the parameters extracted from
the interface file into the internals of the platform. This is done through the use of
MULTICUBE-SCoPE tool developed within the project. This tool has been built
as a plug-in of the above-mentioned tool SCoPE and its modeling capabilities are
described in Chap. 2 of the topic.
M3-SCoPE needs different configuration files to run:

￿ platform.xml: This file describes in a proprietary format the parameters that have

to be read from the interface file created by modeFRONTIER. It may be used also
to describe the topology of the top level. However, for the purpose of this test, the
architectural description is already hard coded in the SystemC virtual platform

￿ metric.xml: This file describes the output metrics that M3-SCoPE will extract

at the end of each simulation and is included in the interface file that will be
sent towards modeFRONTIER. It is interesting to note that for the purposes of
this use case, the output metrics are either generated by M3-SCoPE or directly
created by the platform itself (using DS2_SC libraries). In the end, both results
are concatenated and passed to modeFRONTIER