Cfg file

Cfg file

In Asim, CFG files are used to describe benchmarks. For historical reasons, CFG files are in the form of Tcl scripts.
The interpretation of the lines in the .cfg file are:

• Display name
• File name
• Description
• Feeder type
• Setup script
• General flags
• Feeder flags
• System flags
• Simulator commands (may span multiple lines)

An example for a HAsim .cfg is shown below:

BmAdd {
  towers
  towers
  {towers}
  vcs
  tools/scripts/bmark/setup-bmark --isa smips towers
  {}
  {program/towers.smips.vmh}
  {}
  {
    AwbStats dumponexit towers.stats
    AwbStats on
    AwbRun inst -1
    AwbExit
  }
}

A null configuration would like like this:

null
  null
  {null}
  none
  tools/scripts/bmark/setup-bmark null
  {}
  {}
  {}
  {
    AwbStats dumponexit null.stats
    AwbStats on
    AwbRun cycle 800000
    AwbExit
  }
}

Note that because .cfg files are parsed not only by a Tcl interpreter, but by other tools as well, there should be no blank lines or comments before the closing curly brace of the BmAdd call. Comments beginning with a hash mark may be added at the end of the file.

The most important line is number 6, which specifies, in uniondir form, a setup script used to set up the run directory for the benchmark. The commands on this line are passed to the shell for execution, after:

• Appending the directory of the setup script (the first item on the line), as the first of two additional arguments;
• Appending the destination “run” directory in the user’s workspace, as a second additional argument.
• Replacing the keyword BENCHMARKDIR in the command with the BENCHMARKDIR setting from the workspace’s awb.config file;

The setup script is responsible for populating the destination directory where the simulation will actually be run. This will include a ./run script and any needed files, such as files from the shared benchmarks area (which may be specified as an argument to the setup script). In the case of large files (such as traces), the setup script will typically just create soft links to the actual files.

The general, feeder, and system flags arguments are typically left empty in the .cfg file. This is because other mechanisms exist outside of .cfg files, e.g. command line arguments, for asserting detailed control over the simulator. Therefore the use of the general-, feeder- or system flags is deprecated.

The simulator commands in the last argument, in principle, allow arbitrary control over how the simulator behaves and what output it generates. In practice, little of this mechanism remains and the lines should not be changed from what is found in existing templates.

In fact, the use of .cfg files in general is not recommended for new workloads. Rather, the more powerful and succinct .cfx file format should be used instead.