| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
asic:start [2023/07/08 12:26]
rajit [Logic synthesis] |
asic:start [2023/11/23 12:14] (current)
rajit |
| |
| If your design includes arbitration, then please ensure that the ''std'' namespace is imported in your file using ''import std;'' | If your design includes arbitration, then please ensure that the ''std'' namespace is imported in your file using ''import std;'' |
| ===== Cell libraries ===== | |
| |
| 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''. | ===== Physical Implementation ===== |
| |
| 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. | The physical implementation flow consists of the following major parts: |
| |
| 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. | * [[asic:cells:|Mapping production rules to a cell library]] |
| | * [[asic:pnr:|Place and route]] |
| |
| 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). | In addition, [[asic:timing:|timing analysis]] can be used to estimate the performance of the design, as well as check timing constraints. |
| |
| Here's a simple tripler that we will use as a running example: | All of these parts are integrated into the ''interact'' tool that is part of the ASIC flow repository. |
| <file act triple.act> | |
| defproc triple (chan?(int) L; chan!(int) R) | |
| { | |
| int x; | |
| chp { | |
| *[ L?x; R!(x*3) ] | |
| } | |
| } | |
| </file> | |
| |
| To synthesize this using ''abc'' as the logic synthesis engine and with bundled-data logic: | |
| <code> | |
| $ chp2prs -b -o abc triple.act triple out.act | |
| </code> | |
| 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.) | |
| |
| <code> | |
| $ interact -ref=1 -Tsky130l | |
| interact> act:read "out.act" | |
| interact> act:expand | |
| interact> act:top sdt_triple | |
| interact> | |
| </code> | |
| 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. | |
| |
| <code> | |
| 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> | |
| </code> | |
| 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: | |
| <code> | |
| interact> ckt:cell-save "cells.act" | |
| interact> | |
| </code> | |
| Here's a snippet from the saved file: | |
| <code act> | |
| ... | |
| export defcell gac1x0 (bool? in[2]; bool! out) | |
| { | |
| prs * { | |
| in[0]<10> & in[1]<10> -> out- | |
| ~in[0]<6> -> out+ | |
| } | |
| } | |
| ... | |
| </code> | |
| |
| We can re-run the same ''interact'' script using this ''cells.act'' file as the cell library as follows: | |
| <code> | |
| $ 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> | |
| </code> | |
| 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: | |
| |
| <code> | |
| interact> ckt:map | |
| interact> load-scm "phydb.scm" | |
| interact> phydb:create 1.8 1 "output.lef" | |
| interact> | |
| </code> | |
| 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: | |
| <code> | |
| interact> act:layout:rect | |
| interact> | |
| </code> | |
| 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. | |
| |
| ===== Placement and routing ===== | |
| |
| 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 [[https://ieeexplore.ieee.org/document/9256795|placement engine]] called ''dali''. To do so, continue with the following ''interact'' commands: | |
| |
| <code> | |
| 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> | |
| </code> | |
| |
| 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: | |
| <code> | |
| interact> phydb:write-def "file.def" | |
| interact> | |
| </code> | |
| |
| 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: | |
| <code> | |
| interact> pwroute:init 3 | |
| interact> pwroute:set_reinforcement 0 | |
| interact> pwroute:run | |
| interact> pwroute:export-phydb | |
| interact> pwroute:close | |
| interact> | |
| </code> | |
| 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: | |
| <code> | |
| interact> sproute:init 3 | |
| interact> sproute:run | |
| interact> sproute:close | |
| interact> | |
| </code> | |
| |
| The routing guide file can be saved using | |
| <code> | |
| interact> phydb:write-guide "output.guide" | |
| interact> | |
| </code> | |
| |
| 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. | |
| |
| ===== Timing and power analysis ===== | |
| |
| |