Differences

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

--- config:runtime [2023/01/30 21:19] – [Attributes] rajit
+++ config:runtime [2025/05/27 18:12] (current) – [Verilog global signal prefix] rajit
@@ Line 33: / Line 33: @@
 This specifies a limit on array sizes that also have internal sub-connections (i.e. arrays that are not just simple memories, for example). The limit should be increased as needed, but can have a performance impact if you have a very large array with internal sub-connections.
-===== Attributes =====
-ACT supports attributes on both instances and production rules.
+===== Circuit level selection =====
-An ACT instance can be assigned an attribute in the following way:
+ACT has a number of [[language:langs:start|sub-languages]]. These sub-languages can be used to specify circuits at three basic levels of detail: the CHP level (dataflow is viewed as the same level of abstraction as CHP), the HSE level, and the PRS level. The PRS level syntax can also be converted to the DEVICE level (via ''prs2net'') for analog circuit simulation.
-<code act>
+A process can be described at multiple levels of abstraction. During analysis/simulation, it may be necessary to specify the level of abstraction that an ACT tool should use for either a process or for a specific instance of a process.
-bool v @ [attr=0];
-bool w;
+The default level of abstraction that should be used is specified as follows:
-w @ [attr=5];
+<code>
+begin level
+  # the default level: can be chp, prs, hse, or device
+  string default "prs"
+end
 </code>
+Beyond this, the default level can be over-ridden for any specific type as follows:
+<code>
+begin level
+  begin types
+     # the list of processes here should be modeled at the device level
+     string_table device "proc1<>"  "proc2<>"
+     # these should be modeled at the chp level
+     string_table chp "proc3<>"
+     # etc...
+     string_table hse "proc4<>"
+   end
+end
+</code>
+Finally, individual instance levels can be specified as follows:
+<code>
+begin level
+  begin inst
+     string_table device "i1.i2.i3" # instance i1.i2.i3 should be modeled at the device level
+  end
+end
+</code>
-Instance attributes
+Finally, ACT supports a [[language:langs:refine|refinement]] body using the ''refine { ... }'' syntax. The way this is selected is the following. When processing an ACT file, the library maintains a current refinement level. By default, the value is zero, but it can be set to any integer using either the ''-ref='' [[stdoptions:start|command-line option]], or by setting the configuration parameter
+<code>
+# set the initial refinement step to 4
+int act.refine_steps 4
+</code>
+If the current refinement step count is positive, then any ''refine { ... }'' block is used to replace all other sub-language blocks in the ACT definition. If a refine block is not present, then the ACT body is processed as usual. This functionality can be used to replace a CHP description with, for example, an implementation consisting of a number of other instances. Furthermore, when processing the ''refine'' body, the step count is decremented by one. This means that nested refinements can be processed as well, and the level of refinement is selected by either a command-line option or the ''act.refine_step'' configuration option.
-Production-rule attributes
-===== Circuit level selection =====
+===== Decomposition passes =====
+The memory decomposition and arbiter decomposition passes are used to replace memory structures and arbiters with a separate process, and introduce communication channels to interact with that process to re-create the original user-specified functionality. The process names used for this purpose can be modified using the following configuration options. The default values are provided below.
-===== Decomposition passes =====
+<code>
+begin act
+  begin decomp
+    string mem "std::mem"
+    string arbiter "std::arbiter"
+   end
+ end
+</code>
+===== External Black Box Support =====
+ACT also provides a mechanism for "black box" modules---components that are defined elsewhere, like external hard macros. We assume that the external specification of the macros includes:
+     * A LEF file, for layout generation, along with bounding box information in the LEF coordinate system
+     * A SPICE file, for circuit simulation
+     * A Verilog file, for Verilog exports
+     * TBD
+A process is treated as a black box if it is defined with an empty body. For example:
+<code act>
+defproc bbproc (bool? A, B, C; bool! D) { }
+</code>
+is interpreted as a black box by default. (Note that there is a configuration parameter that can be used to turn off this behavior, in which case this component will be eventually stripped out of the design since it does not contain any circuit component.)  For this to work correctly, direction flags for ports must be present.
+The location of the LEF/SPICE/Verilog/etc. for the black box must be included in an ACT configuration file using the following configuration section:
+<code>
+begin macros
+    begin <expanded-name>
+      string lef  "lef_file_path"
+      string spice "spice_file_path"
+      string verilog "verilog_file_path"
+      int llx <val>
+      int lly <val>
+      int urx <val>
+      int ury <val>
+     end
+end
+</code>
+The expanded name is the fully expanded name for the process (in this case ''bbproc<>''). The value (llx,lly,urx,ury) are the bounding box coordinates from the LEF. If some files are unavailable, use "/dev/null" as the file name (on Unix-based systems).
+==== Generalized External Black Box ====
+Sometimes we require a more sophisticated model for an external black box. In particular, we might want to specify internal nodes within the black box so that the timing model for the black box can be made more precise. For this purpose, a more general black box syntax is supported.
+<code act>
+defproc bbproc (bool? A, B, C; bool! D) { bool int1, int2; }
+</code>
+This process will also be treated as a black  box, but with the understanding that there are also internal nodes that might be used to build a more sophisticated timing model.
+A generalized black box body can only contain instances of signals that are of type ''bool''.