Differences

This shows you the differences between two versions of the page.

--- asic:cells:start [2024/08/23 14:03] – rajit
+++ asic:cells:start [2025/07/31 13:11] (current) – [Using an existing cell library] rajit
@@ Line 124: / Line 124: @@
 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.
+===== Using an existing cell library =====
+The ACT flow is designed to be agnostic to circuit family. This means that the implementation flow does not change the circuit specified in ACT, with the possible exception of gate sizing and buffer insertion when attempting to satisfy timing constraints.
+If you have an existing cell library that needs to be used, this means that the cells must be defined using
+''defcell'' (as described above), but additionally that the cells must be explicitly instantiated in the ACT
+design. This is similar to what happens when using a commercial digital ASIC flow, where logic synthesis explicitly selects cells from the standard cell library and creates a netlist that instantiates technology-specific cells.
+If the ''.act'' file contains production rules, then those production rules are extracted and unique cells are generated based on the production rules directly as described above. Each production rule is mapped to a unique cell (note that the mapper doen't map multiple production rules to individual cells at present).
+Currently we do not provide automated mechanisms to map cells extracted from production rule descriptions to cell libraries in other formats. This is primarily because the legality of this mapping depends on the underlying circuit family. For example, mapping a three-input OR gate into multiple two-input OR gates may introduce timing-dependent switching hazards, and is therefore legal only in certain contexts.
+If you know, for example, the production rule in your ACT file
+<code act>
+prs {
+  a<8> & b<8> -> c-
+ ~a<8> | ~b<8> -> c+
+}
+</code>
+should be mapped to a ''library_NAND2X1'' cell in your cell library and you'd rather not explicitly instantiate the cell, then as a work-around you can do the following:
+**Step 1: create a dummy cell that matches this rule.** In this example, that would look like this:
+<code act>
+namespace cell {
+defcell gmycell0 (bool? in[2]; bool! out)
+{
+   prs {
+      in[0]<8> & in[1]<8> -> out-
+     ~in[0]<8> & ~in[1]<8> -> out+
+    }
+}
+}
+</code>
+Running the cell mapper will use your own cell. Note that you must follow the naming convention for cells used by ACT: (i) the cell name begins with ''g''; and (ii) the input and output port names are ''in'' and ''out'' (the default names; you can override this in the ACT [[config:netlist|netlist configuration]]).
+**Step 2: swap in your actual cell.**  At this point you can replace the cell with the one from your library as follows.
+<code act>
+namespace cell {
+defcell gmycell0 (bool? in[2]; bool! out)
+{
+   library_NAND2X1 n(in[0],in[1],out);
+}
+}
+</code>
+where ''library_NAND2X1'' is your library cell.  In this example, the assumption is that the order of ports in the library cell corresponds to ''in[0]'', ''in[1]'', and ''out''.