Navigation: Home | Downloads | Documentation | Support
NOTE: This is a DRAFT
The SST Configuration Tool will provide a mechanism to easily configure the SST Simulator to perform architectural experiments (particularly, parameter sweeps). It will do this by presenting a GUI interface to the user, avoiding the need to modify the low-level XML configuration tool.
The tool will allow a user to specify component parameter settings (cache size, network bandwidth) and which parameters to “sweep” for a given configuration. It will then generate XML configuration(s) for the SST Simulator, and (optionally) enqueue the configurations for execution.
This tool (in its first incarnation) will not:
To ensure the tool has a long lifetime, care should be taken in the implementation to allow support for these features in the future.
An architecture research team has proposed a new type of scratchpad memory. The new memory could be produced with a variety of different capacities and latencies, though these would all have different power and cost implications. Additionally, applications would have to be modified to take advantage of the new memory.
The architecture team creates a component model of the memory, and integrates it into the SST. They then work with an application team to show how an application could be modified and provide an XML Template File which describes the new architecture and the “tunable” parameters (scratchpad size, latency, etc…).
Using the SST Configuration Tool, the application team can turn the XML Template File into SST Configuration Files to explore the effect of different architectural parameters. The application team can explore different algorithmic or data structure options in combination while sweeping across a larger architectural space. Their findings can be communicated back to the architecture team to further refine the design.
The tool is required to:
The tool will take as input an XML Template file, use a GUI to select parameters, and output (multiple) XML configuration files.
The XML Template File is based on the existing SST configuration format. In fact, an XML Template File should be a valid SST configuration file. The only difference is that the XML Template File extends the current SST configuration syntax with additional information for use by the GUI.
The additional syntax is a series of attributes added to the variable name tags in the SST <variables>
section. The current form of this section looks like:
<variables>
<variableName1> Value1 </variableName1>
<variableName2> Value2 </variableName2>
<variableName3> Value3 </variableName3>
</variables>
Where each variable is defined by an element:
<variableName> Value </variableName>
Whenever $variableName
appears in the XML, it will be replaced by the string Value
.
This element will be extended with the following attributes:
type=
: Specify the type of the variable, so it can be represented by an appropriate GUI element. Possible types:
range
: A integer value (optionally, with min/max, units, and step-size)floatRange
: a floating point value (optionally, with min/max, units, and step-size)string
: An arbitrary text stringpathString
: A text string related to the filesystem (allowing tab completion if supported by the GUI)desc=
: Text description of the variable, to be shown to the user of the GUImin=
& max=
: Optional minimum and maximum allowed values for the user to select from for that value.units=
: Optional units (a text string) to be shown to the user, and to be appended to the integer or floating point value. (e.g. units=”ns”, so the value may be “3.2ns”).stepSize=
: Minimum step size for variables.stepPower=
: Base power for step. E.g. stepPower=2
indicates the variable can only advance in powers of 2 (e.g. 2,4,8,16…).An example XML template file may define <variables>
like this:
<variables>
<lat type=range min=1 max=4 units=ns desc="Latency of memory">
1ns
</lat>
<proc_width type=range min=1 max=8 desc="pipeline issue width">
4
</proc_width>
<execFile type=pathString desc="Path to Executable">
/home/sst/foo.x
</execFile>
</variables>
And later use them like this:
...
<link name=cc_link port=mem latency=$lat />
...
<pipeWidth> $proc_width </pipeWidth>
<issueUnits> $proc_width </issueUnits>
<binary> $execFile </binary>
In the above case, the template defines three variables: two integers, and a string. The first variable (lat
) specifies a latency and can be set from 1 to 4 nanoseconds. The second variable (‘proc_width’) defines a unitless integer representing processor issue width. The third variable (execFile
) is a path to an executable file to be loaded into the simulator. A GUI representation of these variables might look like this:
Note, the integer variables can be set by a slider (e.g. lat
). Also, if a “step” value is input, the variable is involved in a parameter sweep and the slider can have multiple values to indicate the bounds (e.g. proc_width
is being set to sweep across the values of 2, 4, and 6).
Once the user has selected the appropriate values, they can instruct the tool to generate the XML files. If parameter sweeps are being performed, many files may be produced.
Optionally, the configuration tool may automatically interact with a batch scheduling system to schedule each generated file to be queued for execution.
Once the simulation runs are complete, the configuration tool may compile a report summarizing the performance of the different configuration(s).
This summation will be constructed by collating data from the simulation output. The user will specify a series of key words/strings and fields to be selected from the output. The tool will then perform the equivalent of the following shell command on each output:
grep <keyword> <outputFile> | awk '{print $<field>}'
Optionally, these data points may be automatically graphed.