====== 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''.
===== Cell libraries and mapping =====
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 [[config:netlist#miscellaneous|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:
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 [[https://people.eecs.berkeley.edu/~alanmi/abc/abc.htm|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 [[language:impl|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 [[config:start|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.
===== Cell physical design =====
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 [[tools:layout:start|''.rect'' files]]. This is a good point to stop the flow and take a look at the [[tools:layout:start|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 [[config:netlist#lef_def_configuration_options|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.
===== Cell characterization =====
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 [[asic:timing:cells|characterizer]] for this purpose.