Home » SSTDocumentation » Design Doc for Config Tool - DRAFT

Design Doc for Config Tool - DRAFT

NOTE: This is a DRAFT

DRAFT Configuration Tool Functionality

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.

Futureproofing

This tool (in its first incarnation) will not:

Provide a fully generic mechanism for configuring the SST. Creating a tool which generates arbitrary connections between SST components is beyond the scope of this work. This is because the SST components’ do not yet provide documentation of their inter-connectivity requirements (i.e. who can connect to who) and partly to keep the tool simple
Provide a mechanism to change all of the component configurations for a given component. Again, this is because the SST components’ parameter documentation is not standardized, and to limit the complexity of the tool.
Provide an interface in to the SST’s programmatic (i.e. non-XML) configuration interface. The programmatic configuration interface is still evolving.

To ensure the tool has a long lifetime, care should be taken in the implementation to allow support for these features in the future.

Use Case Example

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.

Tool Requirements

The tool is required to:

Read an XML Template File (format based on the SST Configuration File).
Parse the XML Template to find architectural parameters which can be modified.
Present these parameters in a GUI with the appropriate graphical element (e.g. text box for strings, sliders for numeric values).
Allow the user to select configuration values through the GUI elements, including the ability to specify a range of values for a parameter sweep. (e.g. all cache sizes from 2K to 16K by doubling, or all pipeline lengths from 4 to 8.)
Produce XML Configuration files for use in the SST simulator based on the template, with the values specified by the GUI input. Note, multiple output files may be created if a range of parameters are specified.
(Optionally) Create appropriate scripts and commands to queue each of the produced XML files into a batch job system for execution.
(Optionally) Collate returned data and present it to the user.

Tool Architecture

High Level

The tool will take as input an XML Template file, use a GUI to select parameters, and output (multiple) XML configuration files.

XML & GUI

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 string
- pathString: 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 GUI
min= & 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).

Output & Job Launch

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.

Statistics Collection (Optional)

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.