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.

For the ASIC flow, each production rule in the design is mapped to a cell. Cells are simply special processes that are used to specify the leaf cells in the layout generation flow. ACT assumes that each cell has associated with it some layout and an associated LEF file. Cells are specified using the same syntax as a process, but using defcell rather than defproc.

Given that different asynchronous circuit families use different types of gates, the ACT ASIC flow assumes that the production rules that have been specified must be implemented as-is: in other words, any technology mapping step to a group of standard cells has been handled by logic synthesis.

Any instance in the ACT design that is defined to be a defcell is assumed to be a cell; for all other processes (specified with defproc), the cell mapping step walks through every single production rule in the entire design and replaces it with a cell instance. If a cell is found in the cell namespace (the name of the namespace can be changed via configuration options), then that cell is used; otherwise a fresh cell is generated and added to the cell namespace. As a result, this process can also be used to create a standard cell library that includes the cells needed to implement a design. Once the library has been created, it can be re-used for other designs.

While there are standalone tools to do this, we recommend using the interact tool for the implementation flow. Interact is a command-line based tool that has a rich set of commands that can be used to drive the ASIC flow (try help on the command-line to see the list of options).

Here's a simple tripler that we will use as a running example:

triple.act

defproc triple (chan?(int) L; chan!(int) R)
{
   int x;
   chp {
      *[ L?x; R!(x*3) ]
   }
}

To synthesize this using abc as the logic synthesis engine and with bundled-data logic:

$ chp2prs -b -o abc triple.act triple out.act

The -b option selects bundled-data and the -o abc option selects Berkeley's ''abc'' engine for logic optimization. The file triple.act is the input ACT file, triple is the name of the top-level process that has to be synthesized, and out.act is the output file that contains the synthesized design. In addition, the file expr.act is generated that contains ACT datapath components that were optimized by abc.

chp2prs maps the synthesized processes using the ACT implementation relation and refine { … } body. The names of the synthesized versions are prefixed with sdt_ for syntax-directed translation.

The following interact script can be used to do the cell mapping. To do this, we need to select a technology configuration, and we use sky130l as the running example for the technology. (To setup a technology, what is needed are all the configuration files for the technology.)

$ interact -ref=1 -Tsky130l 
interact> act:read "out.act"
interact> act:expand
interact> act:top sdt_triple
interact>

This reads in the ACT file generated by chp2prs, elaborates the design, and sets the top-level of the design to be implemented as sdt_triple.

Next, we can map the production rules to cells.

intearct> ckt:cell-map
WARNING: new cells generated; please update your cell library.
(Use ckt:cell-save to see the new cells.) New cell names are:
   ginvx0
   gnor2x0
   g1n_0x0
   gcelem2x0
   ginvx1
   ginvx2
   ginvx3
   ginvx4
   ggc3n11x0
   g0n1n2naa_01ox0
   gac1x0
interact> 

Since we started this design without a cell library, this report indicates the list of fresh cells that are needed to implement the design. To see the production rules for each of these cells, a cell namespace file can be saved as follows:

interact> ckt:cell-save "cells.act"
interact>

Here's a snippet from the saved file:

...
export defcell gac1x0 (bool? in[2]; bool! out)
{
   prs * {
   in[0]<10> & in[1]<10> -> out-
   ~in[0]<6> -> out+
   }
}
...

We can re-run the same interact script using this cells.act file as the cell library as follows:

$ interact -ref=1 -Tsky130l 
interact> act:read "out.act"
interact> act:merge "cells.act"
interact> act:expand
interact> act:top sdt_triple
interact> ckt:cell-map
interact>

This time, we merge in the cells.act file with the design. Note that when the circuit is mapped to cells, there is no warning of freshly generated cells because all the cells needed for the design were found in the cell namespace that was merged in.

ACT provides some support to help create the cell library for you as long as the configuration files for the technology includes some of the layout design rules. To start on the physical design flow, we load the physical database module, and populate it with a preliminary implementation as follows:

interact> ckt:map 
interact> load-scm "phydb.scm"
interact> phydb:create 1.8 1  "output.lef"
interact>

The ckt:map command generates the transistor-level netlist from the production rules. This is needed to keep track of all the port and internal signal names in the design. We load in the phydb (physical database) module and create a place and route problem using the phydb:create command.

The arguments to phydb:create (try help “phydb:create” to see more information) are:

• The area multiplier. We specify 1.8 here, which says that the layout area allocated is 1.6 times the area of the cell (i.e. we are using a cell density of at most 1/1.8).
• The aspect ratio. We specify 1 here, for a square area.
• The output LEF file. The layout.conf file includes enough information to generate the technology LEF. The output LEF file contains the LEF for all the cells needed to implement the design, as well as the technology LEF.

Where did the cell LEF come from? It turns out that the ACT layout generation module includes support for transistor-level placement, and so the circuits generated via the ckt:map command for each cell are placed using technology design rules, and a LEF for that particular design is generated. Note that this LEF will not have any information about wires in the cell, since the generator currently only places transistors, and does not route the individual cells.

To see the layout generated for each cell, use:

interact> act:layout:rect
interact>

This will create a number of ''.rect'' files. This is a good point to stop the flow and take a look at the generated cell layout. For all the new cells, at this point you would need to finish the cell layout.

You may notice that there are many more cells than just the freshly created ones in the cells.act file. That's because there are additional defcells that are instantiated by the chp2prs tool. (Those are contained in the syn namespace, and can be found in the ACT library installed by chp2prs in $ACT_HOME/act/syn/).

Once you have completed layout and newly generated .rect files, those files should be placed in a technology-specific directory, and the configuration option for ''rect_inpath'' should be set to the right path. Once that is setup, the layout generation pass will use the user-specified .rect files rather than generating new ones. The LEF generated will now include obstacles and pins for the metal that was added for routing in the cells.

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.