Differences

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

--- config:start [2021/10/19 06:56]
rajit [Technology-independent configuration]
+++ config:start [2024/03/31 13:38] (current)
rajit [Devices]
@@ Line 65: / Line 65: @@
    * ''od18'': I/O device for 1.8V
-==== Generic ====
+==== Generic configuration settings ====
+These settings have to do with various options that can impact ACT circuit construction and output generation.
+=== Circuit construction complexity ===
 <code>
@@ Line 77: / Line 81: @@
 These two parameters control the expansion/elaboration phase of ACT. ACT language constructs
 include while loops, as well as recursive circuit constructions. To ensure that the ACT expansion phase will always terminate (albeit with an error), these two parameters control the maximum depth of recursive expansions as well as the maximum number of iterations of a while loop.
+<code>
+begin act
+int subconnection_limit 16384
+end
+</code>
+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.
+=== Warnings ===
+The following warnings can be turned on/off using an ACT configuration setting. They can also be adjusted via the standard act [[stdoptions:start|command-line options]]. These are integer ACT configuration variables that should be set to either zero (turn off warning) or one (turn on warning).
+   * ''act.warn.empty_select'': warn if all the guards in a selection statement in ACT (the core language, not the CHP/HSE sub-language) are false.
+   * ''act.warn.double_expand'': warn if an ACT tool attempts to expand an already expanded ACT object.
+   * ''act.warn.no_local_driver'': warn if a local variable doesn't have a driver if detected during some of the ACT analysis passes.
+   * ''act.warn.dup_pass'': warn if an ACT tool registers a duplicate pass.
+   * ''act.warn.lang_subst'': warn if an ACT tool uses a different language body within a process than the default choice.
+=== Output generation and name mangling ===
 <code>
@@ Line 83: / Line 106: @@
 end
 </code>
-Sometimes it is useful to export files from the ACT format to other formats to interact with external tools. Examples of such formats include Verilog and SPICE. Since these are different languages, they use different syntax for identifiers. (Different commercial SPICE simulators use different identifier syntax too.) ACT identifiers and names include characters including ''['', '']'', ''.'', ''<'', ''>'' (among others). The ACT library provides a generic //name mangling// feature that can be used to convert them into identifiers that only use alphanumeric characters (i.e. basic C-style identifiers). The ''mangle_chars'' string specifies which characters should be //mangled//. Up to 36 characters can be mangled. By default, the ''_'' character is used to mangle characters. If this needs to be changed, then a different character can be set by modifying the ''mangle_letter'' setting.
+Sometimes it is useful to export files from the ACT format to other formats to interact with external tools. Examples of such formats include Verilog and SPICE. Since these are different languages, they use different syntax for identifiers. (Different commercial SPICE simulators use different identifier syntax too.) ACT identifiers and names include characters including ''['', '']'', ''.'', ''<'', ''>'' (among others). The ACT library provides a generic //name mangling// feature that can be used to convert them into identifiers that only use alphanumeric characters (i.e. basic C-style identifiers). The ''mangle_chars'' string specifies which characters should be //mangled//. Up to 36 characters can be mangled. By default, the ''_'' character is used to mangle characters.
 <code>
 begin act
@@ Line 89: / Line 113: @@
 end
 </code>
+If the mangle character needs to be changed, then a different character can be set by modifying the ''mangle_letter'' setting.
+<code>
+begin act
+  int output_window_width 72
+end
+</code>
+For tools that use pretty-printing, this sets the output window width for a line break.
@@ Line 120: / Line 152: @@
 would use ''lvt'' for the ''in'' input to the pull-down network, but ''svt'' for the other devices needed.
+ACT also has support for generic two-terminal devices. The standard configuration option uses this to support capacitors.
+<code>
+begin act
+string_table prs_device "cap"
+end
+</code>
+This permits you to write:
+The first flavor in the list (''svt'' in the example) is the default value if the flavor is unspecified. This means that
+<code>
+prs {
+   cap (in,GND)
+   cap<5,2> (out,GND)
+}
+</code>
+These are capacitors, the first one being a unit capacitor while the second is 10 units (5 x 2) in size.
 ==== Specification directives ====
@@ Line 146: / Line 193: @@
 ===== Technology-specific configuration =====
-   * [[config:netlist|Netlist]] generation from production rules
+The bulk of the configuration options are technology-specific. These are used to convert a technology-independent ACT description into a technology-specific output (e.g. a SPICE netlist). The standard set of configuration files we expect are:
-   * [[config:layout|Layout]] generation from netlist
+   * ''prs2net.conf'': [[config:netlist|netlist]] generation configuration file, used to translate gate-level descriptions with abstract sizing into a transistor-level netlist.
+   * ''layout.conf'': [[config:layout|Layout]] generation from netlist.
+   * ''lint.conf'': [[config:lint|linting]] configuration for analyzing SPICE simulation traces.
+   * ''models.sp'': In the standard technology configuration directory, the file ''models.sp'' should exist if mixed-signal and analog modeling is to be used. This particular file should include the SPICE commands necessary to include all the device models needed for simulation. This is typically a single line of the form ''.lib "<path-to-models>" TT''