Hardware description and specification languages

ACT permits the specification and description of circuits at multiple levels of abstraction. These languages are embedded into ACT as sub-languages. These sub-languages can be used to specify circuits in a variety of ways and at different levels of abstraction. Some sub-languages are only useful when combined with others.

ACT has the following four sub-languages that are used to specify circuits:

• Communicating hardware processes: a programming language for describing hardware
• Dataflow: a language for specifying static dataflow graphs
• Handshaking expansions: an intermediate form between CHP and PRS
• Production rules: gate-level and transistor-level circuit specification

When simulating a design or translating the circuit to an implementation, the designer must select one of the descriptions in a process. The default level of abstraction selected is PRS followed by HSE (if PRS doesn't exist) followed by CHP (if HSE doesn't exist). Note that dataflow can be viewed as subset of CHP. Often the selection of the sub-language is implicit in the functionality provided by a particular ACT tool/transform. For example, generation of SPICE output selects the PRS level of abstraction; translation of CHP to PRS selects the CHP level of abstraction. In the case of simulation, configuration files can be used to specify the level of abstraction selected when there is more than one option for a process.

The CHP sub-language is used to describe the circuits using a programming notation. The HSE sub-language operates on Boolean-valued variables, and has syntax similar to the CHP block. A process can have at most one CHP block and at most one HSE block; if multiple blocks of the same type are detected, an error will be flagged.

The dataflow sub-language can be used to specify computations as a static dataflow graph. The PRS sub-language can be used to specify gates as well as transistor-level implementations of circuits. These blocks can be repeated in a process, and the result is the concurrent composition of the blocks.

When translating circuits from one level of abstraction to another (especially going down to production rules), it may be helpful to add additional levels of design hierarchy (e.g. by instantiating standard gates). To support this, ACT includes a refinement body.

• Refinement: specifying circuits using sub-components

The refinement body is simply a standard ACT body. When the refinement body is selected, the other circuit languages are omitted. Similarly when one of CHP/HSE/PRS are selected, the refinement body is omitted. The refinement body can be selected using the -ref=N command-line option for any ACT tool.

Auxiliary sub-languages augment the circuit specification in some way. The sizing sub-language can be used to specify gate sizing directives that apply to the prs sub-language. The spec sub-language can be used to apply a range of directives to Boolean-valued variables. These directives include timing requirements, mutual exclusion requirements, and specifications of signals that can have switching hazards.

• Gate sizing directives
• Specifications

There are four possible levels of detail at which to model a circuit component:

• CHP, where channels and full expression syntax is permitted
• HSE, where sequencing can be specified, but all variables are Boolean-valued
• PRS, which corresponds to individual pull-up and pull-down networks (gates)
• device, which corresponds to the transistor-level implementation of the gates. The device level doesn't have an explicit syntax, as the PRS language has enough detail to be able to capture this level of abstraction.

A configuration file can be specified that selects the level of detail for a process type / instance name. This file is typically passed via the command-line option -cnf=file.conf to ACT tools. The parameters you can specify are:

begin level
# valid strings are "chp", "hse", "prs", and "device"
   string default "chp"
end

This specifies the default level selected for every process. (Dataflow is treated as fine-grained parallel CHP.)

begin level
   begin types
   # chp process model
     string_table chp "procname<5>"  "proc2<>"
   # prs process model
     string_table prs "proc3<>"
   end
end

This specifies that the particular process names should be modeled at the specified level of abstraction.