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.

Once the routed cell library .rect files are ready, using the same script as above will create a layout problem for place and route that includes the correct LEF for the cells.

The next step is to run the placement engine called dali. To do so, continue with the following interact commands:

interact> dali:init 3
interact> dali:place-design 0.6
interact> dali:place-io "met1"
interact> dali:export-phydb
interact> dali:close
interact> phydb:write-aux-rect "output"
interact> phydb:update-lef "output"
interact>

The first command initializes the placement engine. The 3 is the verbosity level (0 turns off verbose messages). The next command runs the global and detailed placer, with a placement density of 0.6. Note that you should have provided sufficient area in the phydb:create command, otherwise this will fail. The next command places the I/O pins on metal1 in an automated fashion. (“met1” comes from the name for metal1 in the sky130l technology file.) Finally, the placed results are used to update the physical database, and the placement engine is terminated.

The last two commands are required because Dali uses a gridded cell placement approach. This means that wells and selects have to be superimposed once the gridded cell placement is complete. Hence, the LEF file needs to be updated to include these new parts of the design.

At any point, you can see the current state of the DEF file using:

interact> phydb:write-def "file.def"
interact>

This flow corresponds to a gridded placement flow. For gridded cells, the power buses are run after placement. To run this special power bus router, use the following commands:

interact> pwroute:init 3
interact> pwroute:set_reinforcement 0
interact> pwroute:run
interact> pwroute:export-phydb
interact> pwroute:close
interact>

Here we turn off reinforcements, as the technology does not have many metal layers. For a more modern process, the power router is capable of adding horizontal and vertical reinforcements of the power grid as well.

Finally, we can run the global router called sproute as follows:

interact> sproute:init 3
interact> sproute:run
interact> sproute:close
interact>

The routing guide file can be saved using

interact> phydb:write-guide "output.guide"
interact>

This contains the global routing guide that can be read by a number of open source tools (e.g. TritonRoute, which is installed as part of the actflow repo) to complete the detailed routing. For example, the command

$ TritonRoute -lef output.lef -def output.def -guide output.guide -output routed

would run detailed routing, saving the result to routed.def.

Asynchronous circuits contain cycles of gates. How do we time them? The following provides more detail on how static timing analysis for asynchronous circuits works.

• Timing model and graph
• Cell library and characterization
• Timing constraints