ACT Runtime Configuration

The behavior of the core ACT library and the way an ACT file is interpreted is typically controlled by command-line options to specific tools. However, there are some common settings that can be selected using a local ACT configuration file and then passed to the ACT tool using the -cnf=file standard ACT command-line option.

The following warnings can be turned on/off using an ACT configuration setting. They can also be adjusted via the standard act command-line options. These are integer ACT configuration variables that should be set to either zero (turn off warning) or one (turn on warning).

• act.warn.empty_select: warn if all the guards in a selection statement in ACT (the core language, not the CHP/HSE sub-language) are false.
• act.warn.double_expand: warn if an ACT tool attempts to expand an already expanded ACT object.
• act.warn.no_local_driver: warn if a local variable doesn't have a driver if detected during some of the ACT analysis passes.
• act.warn.dup_pass: warn if an ACT tool registers a duplicate pass.
• act.warn.lang_subst: warn if an ACT tool uses a different language body within a process than the default choice.

begin act

int max_recurse_depth 1000
int max_loop_iterations 1000

end

These two parameters control the expansion/elaboration phase of ACT. ACT language constructs include while loops, as well as recursive circuit constructions. To ensure that the ACT expansion phase will always terminate (albeit with an error), these two parameters control the maximum depth of recursive expansions as well as the maximum number of iterations of a while loop.

begin act
int subconnection_limit 16384
end

This specifies a limit on array sizes that also have internal sub-connections (i.e. arrays that are not just simple memories, for example). The limit should be increased as needed, but can have a performance impact if you have a very large array with internal sub-connections.

ACT supports attributes on both instances and production rules. An ACT instance can be assigned an attribute in the following way:

bool v @ [attr=0];
bool w;
w @ [attr=5];

In these two examples, the signal v has an attribute called attr with value 0, and signal w has attribute attr with value 5. These attributes can be inspected by tools. Instead of having a hard-coded set of instance attributes, an ACT configuration file can specify the list of supported attributes.

begin act
string_table instance_attr "i:s:autokeeper" "i:s:iscomb" "i:s:sigtype"
end

This specifies three instance attributes: autokeeper, iscomb, and sigtype. In general, an attribute is specified as a string of the form x:y:name

• The first component x can be either i for an integer attribute, b for a Boolean attribute, or r for a real attribute.
• The second component y specifies how to unify two attributes (which can happen if two instances with different attributes are connected). Supported methods are
  • s : for strict; the two attributes must be equal, otherwise an error is reported.
  • + : sum, so the attributes are summed
  • M : max, so the maximum value is used
  • m : min, so the minimum value is used
  • | : or, so a logical OR is used
  • &: and, so a logical AND is used

A second set of attributes can be specified per-production rule.

string_table prs_attr "i:s:after" "i:s:keeper" "i:s:iskeeper"

The syntax for these is the same, except the attributes are applied per production rule. These attributes are interpreted by the simulator as well as netlist generator.

ACT has a number of sub-languages. These sub-languages can be used to specify circuits at three basic levels of detail: the CHP level (dataflow is viewed as the same level of abstraction as CHP), the HSE level, and the PRS level. The PRS level syntax can also be converted to the DEVICE level (via prs2net) for analog circuit simulation.

A process can be described at multiple levels of abstraction. During analysis/simulation, it may be necessary to specify the level of abstraction that an ACT tool should use for either a process or for a specific instance of a process.

The default level of abstraction that should be used is specified as follows:

begin level
  # the default level: can be chp, prs, hse, or device
  string default "prs"
end

Beyond this, the default level can be over-ridden for any specific type as follows:

begin level
  begin types
     # the list of processes here should be modeled at the device level
     string_table device "proc1<>"  "proc2<>" 
     
     # these should be modeled at the chp level
     string_table chp "proc3<>"
     
     # etc...                         
     string_table hse "proc4<>"
   end
end

Finally, individual instance levels can be specified as follows:

begin level
  begin inst
     string_table device "i1.i2.i3" # instance i1.i2.i3 should be modeled at the device level
  end
end

Finally, ACT supports a refinement body using the refine { … } syntax. The way this is selected is the following. When processing an ACT file, the library maintains a current refinement level. By default, the value is zero, but it can be set to any integer using either the -ref= command-line option, or by setting the configuration parameter

# set the initial refinement step to 4
int act.refine_steps 4

If the current refinement step count is positive, then any refine { … } block is used to replace all other sub-language blocks in the ACT definition. If a refine block is not present, then the ACT body is processed as usual. This functionality can be used to replace a CHP description with, for example, an implementation consisting of a number of other instances. Furthermore, when processing the refine body, the step count is decremented by one. This means that nested refinements can be processed as well, and the level of refinement is selected by either a command-line option or the act.refine_step configuration option.

The memory decomposition and arbiter decomposition passes are used to replace memory structures and arbiters with a separate process, and introduce communication channels to interact with that process to re-create the original user-specified functionality. The process names used for this purpose can be modified using the following configuration options. The default values are provided below.

begin act
  begin decomp
    string mem "std::mem"
    string arbiter "std::arbiter"
   end
 end

Since ACT can refer to global signals, this functionality may be needed when converting ACT files into Verilog netlists. Different systems may have different ways that a user can access signals starting from the top-level in Verilog.

begin act
  string global_signal_prefix "top."
end

This specifies that a global signal foo can be accessed from Verilog using top.foo.

ACT also provides a mechanism for “black box” modules—components that are defined elsewhere, like external hard macros. We assume that the external specification of the macros includes:

• A LEF file, for layout generation, along with bounding box information in the LEF coordinate system
• A SPICE file, for circuit simulation
• A Verilog file, for Verilog exports
• TBD

A process is treated as a black box if it is defined with an empty body. For example:

defproc bbproc (bool? A, B, C; bool! D) { }

is interpreted as a black box by default. (Note that there is a configuration parameter that can be used to turn off this behavior, in which case this component will be eventually stripped out of the design since it does not contain any circuit component.) For this to work correctly, direction flags for ports must be present.

The location of the LEF/SPICE/Verilog/etc. for the black box must be included in an ACT configuration file using the following configuration section:

begin macros
    begin <expanded-name>
      string lef  "lef_file_path"
      string spice "spice_file_path"
      string verilog "verilog_file_path"
      int llx <val>
      int lly <val>
      int urx <val>
      int ury <val>
     end
end

The expanded name is the fully expanded name for the process (in this case bbproc<>). The value (llx,lly,urx,ury) are the bounding box coordinates from the LEF. If some files are unavailable, use “/dev/null” as the file name (on Unix-based systems).