ACT ASIC flow

The ASIC flow for asynchronous logic provided by the actflow repository includes a number of different components. The key components provided are those that require something different in the case of asynchronous design. For the remaining tools, we use the same tools as synchronous logic as there is no significant difference.

Design entry in the ACT flow can begin at different levels of abstraction, depending on your needs/requirements. The ACT language can describe circuits at different levels of abstraction, because circuits can be described using different sub-languages.

• CHP: The highest level of abstraction for design entry is the CHP language.
• Dataflow: A circuit can also be described directly as a static dataflow machine.
• Handshaking expansion: This uses a restricted subset of CHP without channels, where all operations are on Booleans.
• Production rules: This is used for low-level design, where one directly specifies the circuits.

To be ready for the implementation flow, the design must be mapped to the gate level abstraction of production rules. This step corresponds to logic synthesis.

The actsim simulator can be used to simulate an ACT description at any level of abstraction, including interacting components operating at different levels of abstraction.

Currently we provide two methods to generate production rules from a higher level description:

A bit more detail about the techniques used by these tools:

• chp2prs: This uses a logic synthesis technique known as syntax-directed translation to convert CHP programs into a set of standard components, along with production rule implementations of the standard components. For datapath/arithmetic functions, it invokes standard synthesis tools for combinational logic optimization (yosys, abc).
• dflowmap: This translates dataflow components into their corresponding CHP programs. An optional module also provides standard production rule implementations of the building blocks for each dataflow component. Since the dataflow language is restricted, good circuit templates can be used to map dataflow to production rules to produce high quality dataflow implementations.

As these tools generate circuits using standard building blocks that are in a pre-specified ACT library, the synthesized design contains new instances that are not in the original implementation. Both chp2prs and dflowmap use the ACT refine { … } sub-language to augment the definition of the synthesized processes, which has been introduced explicitly to support this design refinement use case. To select the synthesized design, use the -ref=1 ACT command-line option to the ACT tools; otherwise you will see the original, un-synthesized implementation (for example, without this option, place and route will see an empty netlist and give up). Note that if you had directly provided production rules in your design, then this command-line option will not be needed unless you placed the production rules within a refine { … } sub-language body.

If your design includes arbitration, then please ensure that the std namespace is imported in your file using import std;

The physical implementation flow consists of the following major parts:

• Mapping production rules to a cell library
• Place and route

In addition, timing analysis can be used to estimate the performance of the design, as well as check timing constraints.

All of these parts are integrated into the interact tool that is part of the ASIC flow repository.