Mapping a design to a cell library

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.8 times the area of the cell (i.e. we are using a cell density of 1/1.8 or higher).
• 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.

Finally, the delay and power profile of the cells can be used during timing and power analysis of the design. The ACT tools also contain a cell library characterizer for this purpose.