Differences

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

--- tools:interact:start [2026/03/12 09:25] – [ACT functions] rajit
+++ tools:interact:start [2026/03/12 09:46] (current) – [Global routing] rajit
@@ Line 33: / Line 33: @@
-===== Standard built-in commands =====
+===== Basic commands =====
+==== Standard built-ins ====
 The following commands are built into the scripting framework:
@@ Line 44: / Line 46: @@
 | quit | the same as ''exit'' |
-===== Basic I/O commands =====
+==== Interacting with the user and environment ====
 The following commands are used to interact with the environment, and for miscellaneous operations that are generic and not related to the ACT flow.
@@ Line 63: / Line 65: @@
 #!/usr/bin/env interact
-echo "Hello" (read "Who are you? ")
+echo "Hello" (read "Who are you? ") "Technology:" (getenv "ACT_TECH")
 </code>
-Running this script will prompt the user to enter a string, and then display ''Hello'' followed by the string. In this usage mode, a script might take command-line arguments. To handle this, the following commands are supported:
+Running this script will prompt the user to enter a string, and then display ''Hello'' followed by the string (which will likely include a newline), followed by "Technology:" and the name of the technology being used.
+Using ''#!'' and setting the permissions to executable makes a text script look like an executable. In this use case, the executable will often need command-line arguments. To handle this, the following commands are supported:
 ^ Command ^ Meaning ^
@@ Line 129: / Line 133: @@
 Given that options parsing is a standard use-case, ''interact'' comes with a simple command-line parsing package. After calling ''getopt'', load the ''act-opt.scm'' package using ''load-scm''. The two key functions are ''act:get-options'' and ''act:remaining-args''. Look at [[https://github.com/asyncvlsi/interact/blob/main/scripts/aflat|aflat as a script]] for an example. The parsing package treats options without arguments as flags that are stored in variables, and options with arguments as options that are stored as a string.
+==== Misc support functions ====
+The Galois parallel programming system is used for multi-threaded execution of some of the ACT tools.
+The number of threads used can be dynamically set the number of active threads used for parallel execution.
+^ Command ^ Meaning ^
+| sys:nthreads <num> | set number of threads used by Galois runtime to <num> |
+| sys:end-galois | shutdown Galois runtime |
+File I/O is supported via file handles, which are integers corresponding to open files.
+^ Command ^ Meaning ^
+| sys:open <name> <mode> | open a file in the specified <mode> (r = read, w = write, a = append), and return handle |
+| sys:close <handle> | close file corresponding to the specified <handle> |
+A transcript of interact commands can be saved to a log file to make it easier to create an interact command script for re-use later. Note that interact's execution is deterministic, so this can be used to reproduce results.
+^ Command ^ Meaning ^
+| sys:log <name> | open a command log file called <name> |
+| sys:endlog | close the currently open log file |
 ===== Technology parameters =====
@@ Line 137: / Line 165: @@
 | tech:scale | similar to ''tech:uscale'', except it returns scale factor in units of nanometers |
 | tech:getpitch <layer> | returns pitch of metal layer <layer> |
 ===== Configuration parameters =====
@@ Line 159: / Line 185: @@
 When the ''conf:set_{int,string,real}'' family of commands is used, reading a configuration file //will not// change the value of the configuration parameter. If instead the ''conf:set_default_{int,string,real}'' command is used, then its value can be changed by reading a configuration file.
-===== Misc support functions =====
-The Galois parallel programming system is used for multi-threaded execution of some of the ACT tools.
-The number of threads used can be dynamically set the number of active threads used for parallel execution.
-^ Command ^ Meaning ^
-| sys:nthreads <num> | set number of threads used by Galois runtime to <num> |
-| sys:end-galois | shutdown Galois runtime |
-File I/O is supported via file handles, which are integers corresponding to open files.
-^ Command ^ Meaning ^
-| sys:open <name> <mode> | open a file in the specified <mode> (r = read, w = write, a = append), and return handle |
-| sys:close <handle> | close file corresponding to the specified <handle> |
-A transcript of interact commands can be saved to a log file to make it easier to create an interact command script for re-use later. Note that interact's execution is deterministic, so this can be used to reproduce results.
-^ Command ^ Meaning ^
-| sys:log <name> | open a command log file called <name> |
-| sys:endlog | close the currently open log file |
 ===== ACT functions =====
@@ Line 264: / Line 267: @@
-===== ACT design query API =====
+==== ACT design query API ====
 Once the design is expanded, the query API can be used to inspect various aspects of the ACT data structures.
@@ Line 279: / Line 282: @@
 | act:display-type [<proc>] <name> | display type of instance <name> in process <proc> |
 | act:save-insts <file> | save circuit instance hierarchy to the specified file |
-===== ACT dynamic pass management =====
+==== ACT dynamic pass management ====
 ACT supports dynamically loaded passes. This allows a user to write any functionality that manipulates the ACT data structure and then load it in at run-time. This can be used to create a custom optimization tool or circuit analysis that directly operates on the core data structures. This dynamic pass feature is used to implement logic synthesis, layout generation, as well as static timing analysis. A template for how to implement an ACT dynamic pass is provided on [[https://github.com/asyncvlsi/actpass|github]].
@@ Line 335: / Line 338: @@
 These layout creation functions are called via ''phydb:create'' (look at ''phydb.scm'' in the same path), which is the standard first step in the [[asic:pnr:start|physical implementation flow]].
+===== Circuit manipulation =====
+==== Circuit generation ====
+   ckt:map - generate transistor-level description
+   ckt:save-sp <file> - save SPICE netlist to <file>
+   ckt:save-flatsp <file> - save flattened spice netlist to file after cell mapping
+   ckt:mk-nets - preparation for DEF generation
+   ckt:save-prs <file> - save flat production rule set to <file> for simulation
+   ckt:save-lvp <file> - save flat production rule set to <file> for lvp
+   ckt:save-sim <file-prefix> - save flat .sim/.al file
+   ckt:save-vnet [-nocell] <file> - save Verilog netlist to <file>
+==== Cell mapping ====
+   ckt:cell-map [-l] - map gates to cell library; -l lists used cells
+   ckt:cell-save <file> - save cells to file
+   ckt:cell-addbuf <proc> <inst> <pin> <buf> - add buffer to the pin within the process
+   ckt:cell-edit <proc> <inst> <newcell> - replace cell for instance within <proc>
+   ckt:cell-update - take the design back to the clean state
+   ckt:net->pins <net> - return pins that a net is connected to
+   ckt:cell->pins <inst> - return pins for a cell
+===== Timing and power analysis =====
+   timer:lib-read <file> - read liberty timing file and return handle
+   timer:lib-merge <lh> <file> - merge <file> into liberty file handle <lh>
+   timer:time-units - returns string for time units
+   timer:build-graph - build timing graph
+   timer:tick <net1>+/- <net2>+/- - add a tick (iteration boundary) to the timing graph
+   timer:add-constraint <root>+/- [*]<fast>[+/-] [*]<slow>[+/-] [margin] - add a timing fork constraint
+   timer:init <l1> <l2> ... - initialize analysis engine with specified liberty handles
+   timer:spef <file> - read in SPEF parasitics from <file>
+   timer:phydb-link - link timer to phydb for timing-driven physical design flow
+   timer:run - run timing analysis, and returns list (p M)
+   timer:crit - show critical cycle
+   timer:info <net> - display information about the net
+   timer:constraint [<net>] - display information about all timing forks that involve <net>
+   timer:num-constraints - returns the number of constraints in the design
+   timer:get-violations - returns a list of constraint ids (cids) that have violations
+   timer:check-constraint cid [ticks] - does a path analysis to check paths for timing fork #<cid> exist
+   timer:get-slack cid - returns the slack of the violating constraint id #cid
+   timer:get-witness cid - displays the witness for the violation
+   timer:get-rise <net> - returns rise time for <net>
+   timer:get-fall <net> - returns fall time for <net>
+   timer:rise-violations <time> - returns a list of drivers that have rise time worse than <time> in timer units
+   timer:fall-violations <time> - returns a list of drivers that have fall time worse than <time> in timer units
+   timer:save <file> - save abstract timing graph to file in graphviz format
+===== Physical database =====
+   phydb:init - initialize physical database
+   phydb:set-placement-grid <grid_value_x> <grid_value_y> - set placement grid
+   phydb:read-lef <file> - read LEF and populate database
+   phydb:get-used-lef - return list of macros used by the design
+   phydb:read-def <file> - read DEF and populate database
+   phydb:read-cell <file> - read CELL file and populate database
+   phydb:read-techconfig <file> - read technology configuration file
+   phydb:read-cluster <file> - read Cluster file and populate database
+   phydb:get-columns - return a list of coordinates of columns in grid point coords
+   phydb:get-gaps - return a list of coordinates of gaps in the minirows
+   phydb:place-cell <cell-type> <llx> <lly> <N|FS> - add a new cell to a fixed location
+   phydb:place-inst <inst> <llx> <lly> <N|FS> - place an instance at a fixed location
+   phydb:add-io <iopin_name> <net_name> <direction> <use> - add a new I/O pin
+   phydb:place-io <iopin_name> <metal_name> <lx> <ly> <ux> <uy> <placement_status> <x> <y> <orientation> - place an I/O pin at a fixed location
+   phydb:write-def <file> - write DEF from database
+   phydb:write-guide <file> - write GUIDE from database
+   phydb:write-cluster <file> - write CLUSTER from database
+   phydb:write-aux-rect <file> - write PP/NP cover and well rect files
+   phydb:close - tear down physical database
+===== Placement =====
+==== Partitioning ====
+   bipart:partition <file> [k] [depth] - compute a k-way partition (default 2)
+==== Dali placer ====
+   dali:init <verbosity_level(0-5)> - initialize Dali placement engine
+   dali:add-welltap <-cell cell_name -interval max_microns> [-checker_board] - add well-tap cell
+   dali:place-design <target_density> [number_of_threads] - place design
+   dali:place-io <metal_name> - place I/O pins
+   dali:global-place <target_density> [number_of_threads] - global placement
+   dali:refine-place <engine> - refine placement using an external placer
+   dali:export-phydb - export placement to phydb
+   dali:close - close Dali
+===== Routing =====
+==== Power detailed routing ====
+   pwroute:init <verbose> -initialize pwroute engine <verbose>
+   pwroute:set_parameters <reinforcement_width, reinforcement_step, cluster_mesh_width> - run pw route with mesh configuration. Default is <8, 16, 2>
+   pwroute:set_reinforcement <bool>, enable/disable reinforcement connection (default: 1)
+   pwroute:run run pwroute
+   pwroute:export-phydb -export power and ground wires to phydb
+   pwroute:close -close pwroute
+==== Global routing ====
+   sproute:init initialize sproute engine
+   sproute:set-num-threads set num threads, default = 1
+   sproute:set-algo Det/NonDet, default is NonDet
+   sproute:set-max-iterations set max iterations of maze routing, default = 30
+   sproute:run run sproute
+   sproute:close close sproute