Tools

In addition to the core ACT library, we have also implemented a number of tools for asynchronous circuit design. Some of the core tools are included as part of the main Github repository, while others have their own repository. For completeness, we also include links to other open-source tools that can be used to implement different parts of the VLSI flow.

• actsim: an ACT simulator.
• prs2net: a production rule to SPICE netlist generator
• prs2sim: a production rule to sim file converter
• ext2sp: converts magic extract files into a hierarchical spice file
• Layout generation
• lvp: layout versus production rules

These are core ACT tools–i.e. tools that use the core ACT library and take ACT files as input. They also accept the standard ACT command-line arguments, in addition to their own arguments. The standard ACT options include ways to specify technology-specific information, as well as local configuration overrides.

Standalone tools:

• prsim: a digital production-rule simulator
• aflat and prspack: a production rule flattener and compaction tool. See the documentation for prsim.
• AMC: an asynchronous memory compiler

External open-source tools:

• Xyce: An analog circuit simulator developed by Sandia National Labs
• magic: The Magic VLSI layout editor
• irsim: A switch-level circuit simulator
• Layout versus schematic (LVS) checking:
  • Gemini: a netlist comparison for strict layout-versus-schematic checking Gemini
  • netgen: another tool for LVS

Two useful concepts to keep in mind when using the ACT tools are expanded names and mangled names.

A concept one should be familiar with, especially when debugging and/or understanding error messages is the notion of expanded names. This is best illustrated with an example. Consider the following templated process definition:

template<pint A; pbool B; pint C[A]> defproc example(...) { ... }
 
example<1+1,true,{1,5}> e1;
example<1,false,{2}> e2;

The type of the process defined is example, but the instances e1 and e2 include specific template parameters. After the design is expanded and all template parameters are substituted, different variations of example are created for e1 and e2. These expanded versions of types are given different names within the ACT framework. In particular, the expanded type for e1 would be example<2,t,{1,5}> (here t is used as a stand-in for the value of the Boolean parameter true). If example did not take on any template parameters, the expanded version of the type would be named example<>.

If the template list contains multi-dimensional arrays, the expanded name contains a linear list of the parameters separated by commas.

Expanded ACT type names can contain characters like <, >, and , (among others). Instances can have names like a[3].b[5].z, including the characters [, ], and .. When exporting an ACT design to another format for use by a third-party tool, names with such characters in them can be potentially problematic. A good example of this is when exporting a SPICE netlist—different versions of SPICE have different syntactic restrictions. To handle this in a disciplined manner, the ACT library has the notion of a mangled name. A mangled name is generated by re-writing a user-specified list of special characters with an underscore and a number/character combination. This mapping is invertible, so a name can be unmangled as well. The set of characters to be mangled is specified in the ACT configuration option act.mangle_string (usually found in the global configuration file global.conf).

The standard name mangling prefix character is an underscore. Name mangling operates character-by-character as follows:

• An underscore is replaced by two underscores.
• A character that is not in the mangle string is a pass-through, so it is not modified.
• If a character is at position k in the name mangling string, it is replaced with an underscore followed by k. The position character is 0 to 9 for positions 0 to 9, followed by a-z. Up to 36 characters can be mangled.

Name mangling can at most double the length of the string.

Process names have a special case in terms of name mangling. If an expanded process has no parameters, its mangled name is obtained simply be omitting the trailing <>. This is to make the output more readable when templates are not being used.