Differences

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

--- tools:actsim [2023/04/14 19:29] – [Mixed-signal simulation] rajit
+++ tools:actsim [2026/05/03 17:00] (current) – [Manipulating internal variables] rajit
@@ Line 80: / Line 80: @@
 ==== Timing ====
-<code>random [<min> <max>]</code>
+<code>random [-u] [<min> <max>]</code>
 Set the random timing mode and optionally specify the default random timing bounds for all nodes.
+If ''-u'' is used, then randomization is only applied to unspecified delays.
 <code>random_seed <seed></code>
@@ Line 90: / Line 91: @@
 <code>random_choice on|off</code>
-turn on/off random exclhi/lo firings
+Turn on/off random exclhi/lo firings. ACT uses ''mk_exclhi'' (''mk_excllo'') [[language:langs:spec#exclusive_directives|directives]] to force signals to be exclusive-high (exclusive low).
+This is typically used to model arbiters. If the ''mk_exclhi'' (''mk_excllo'') directive is used between a set of signals, and more than one signal is driven high (low) at the same simulation time, then turning on random choice randomizes the selection of the signal that is allowed to go high (low).
 ==== Running Simulation ====
@@ Line 169: / Line 169: @@
 (Work in progress; try running ''help'' on the command-line)
+==== Manipulating internal variables ====
+The internal state of a process cannot be accessed in ACT, unless it is explicitly exposed via the port list. Consider the following CHP fragment
+<code act>
+defproc funnyproc (chan?(int) X; chan!(int) Y)
+{
+   bool myvar;
+   ...
+   chp {
+       ...
+       [ myvar -> X!0 ];
+       ...
+   }
+}
+</code>
+If ''myvar'' is false when the selection statement is encountered, then this process is permanently deadlocked since
+the environment cannot access ''myvar.'' The simulator uses this observation to remove processes from the simulation
+if they are deadlocked. In that case, the following message will appear in the simulation log:
+<code>
+[          XXX]  <inst> Warning: all guards false; no probes/shared vars
+</code>
+where ''XXX'' is the time, and ''inst'' is the name of the instance that was deadlocked.
+During simulation, one can ''set'' or ''get'' internal variables from any process, violating this property.
+In particular, the variable ''myvar'' could be modified by using the ''set'' command. In this case, you can force the simulator to re-evaluate the deadlocked process and put it back into the simulator state.
+<code>
+actsim> gc-retry inst
+</code>
+This asks the simulator to re-evaluate the guards that led to the deadlock for the instance name ''inst''.
 ==== User-defined commands ====
@@ Line 268: / Line 298: @@
 {
     adder a;
-    sim::source_seq<32, // 32-bit data
+    sim::source_sequence<32, // 32-bit data
-                    false, // don't repeat the sequence of values
 , // three data values
-                    {3,5,2}  // the data values
+                    {3,5,2},  // the data values
+                    false, // don't repeat the sequence of values
+, // source ID is zero for logging
+                    false // don't log any information in the source
                     > s1(a.A);
-    sim::source_seq<32, false, 3, {7,9,3}> s2(a.B);
+    sim::source_sequence<32, 3, {7,9,3}, false, 1, false> s2(a.B);
-    sim::sink<true, // log output
+    sim::sink<32,  // 32-bit
-  // 32-bit
+, // sink ID for logging
+                     true // log values
               > sx(a.C);
  }
@@ Line 291: / Line 324: @@
 {
     adder a;
-    // The first parameter is the file ID (default name is _infile_.0).
+    // The first parameter is the bitwidth
-    // The second parameter is whether the file should be looped.
+    // The second parameter is the file ID (default name is _infile_.0).
-    // The third parameter is the bit-width.
+    // The third parameter is whether the file should be looped.
-    sim::file_source<0, false, 32> s1(a.A);
+    // The fourth parameter is the source ID for logging
+    // The fifth parameter specifies if the source should log its output
+    sim::source_file<32, 0, false, 0, false> s1(a.A);
     // This could also use a file source
-    sim::source_seq<32, false, 3, {7,9,3}> s2(a.B);
+    sim::source_sequence<32, 3, {7,9,3}, false, 1, false> s2(a.B);
-    sim::sink<true, // log output
+    sim::sink<32,  // 32-bit
-  // 32-bit
+, // sink ID for logging
+                     true // log values
               > sx(a.C);
  }
 </file>
+This example will also need a file ''_infile_.0'' that contains the [[sim:start|list of values]].
+===== Mixed level simulations =====
+''actsim'' includes support for simulations that combine CHP, HSE, and PRS. The level of detail for each process and/or instance can be selected via a  [[config:runtime#circuit_level_selection|configuration file]] if a process/instance has descriptions at multiple levels of detail. (The default simulation level is PRS.)
+For mixed level simulations to operate correctly, ''actsim'' must know how channel operations translate to signal level protocols. This information is provided in the channel data type in the ACT language; if this information is missing and the channel is used at the CHP/PRS boundary, the simulation will fail.
+When running CHP level simulations, all processes start their execution at the beginning of their  respective CHP program. However, when running simulations at the PRS level, all Boolean variables are initialized as unknown and a reset protocol is required to initialize the circuit into a valid initial state. To mix these levels of simulation, ''actsim'' must be able to hold the CHP program in reset while the PRS part of the circuit is initialized. Furthermore, any channels that communicate between CHP and PRS levels of abstraction must be properly initialized from both the CHP and PRS end.
+To support this functionality, the top-level ACT file can include an ''Initialize { ... }'' block. This block is used to describe the chip reset protocol, and consists of a sequence of ''actions { ... }''. A simple initialize block would be:
+<code act>
+Initialize {
+   actions { Reset+ };
+   actions { Reset- }
+}
+</code>
+When ''actsim'' starts up, it automatically executes this initialize block as follows:
+  * The circuit execution mode is set to ''reset'' mode.
+  * For channels that cross the CHP to HSE/PRS boundary, the appropriate reset block in the channel definition is scheduled for execution.
+  * The actions in the first ''actions { ... }'' block are executed, and the simulation runs until there are no further events. In this case, the ''Reset'' signal would be set to ''true''/''1''.
+  * Once there are no simulation events remaining, the second sequence of actions is executed. In this case, because the second sequence of actions is the //last// block, the ''actsim'' returns to the command-line prompt. At this point you can use the usual simulation commands to advance the simulation.
+There can be any number of ''actions { ... }'' blocks, and they will be executed sequentially. The simulation drops to the command-line prompt once the last block has been scheduled for execution.
 ===== Mixed-signal simulations =====
-Mixed analog-digital simulations can be done in ''actsim'', if it was built with Xyce (see [[https://github.com/rmanohar/actsim#building-with-xyce|building actsim with Xyce]]).
+Mixed analog-digital simulations can be done in ''actsim'', if it was built with Xyce (see [[https://github.com/rmanohar/actsim#building-with-xyce|building actsim with Xyce]]). This builds on the capability for mixed level simulation.
 There are two ways to specify an analog simulation:
    * Specify prs for a process and simulate it at the device level using spice models. This can be done by specifying the device level using an ACT [[config:runtime#circuit_level_selection|configuration file]] that is loaded at runtime into ''actsim''. The simulator will use the same approach as [[tools:netgen|prs2net]] to generate the SPICE netlist for the specified processes/instances.
@@ Line 312: / Line 373: @@
 The method to specify a blackbox process is described [[https://avlsi.csl.yale.edu/act/doku.php?id=config:runtime#external_black_box_support|here]]. An example with three inverters, one each with digital actsim simulation, analog simulation of prs and analog simulation of blackbox spice netlist can be found at [[https://github.com/ThomasJagielski/Analog-ACT-Example|this repository]].
+==== Resetting the circuit ====
+The reset phase of the analog part of the design needs special care, depending on how your circuit is supposed to operate. Here we describe a few scenarios:
+   * The normal operation of the digital circuit simulation initializes the analog part of the design. In this case, nothing special is required.
+   * The reset protocol for the digital circuit should also include the analog electronics. This happens, for example, if you are running analog simulations of some production rules with a digital environment. In this case, you may need to run the analog simulation for more than the default time to initialize the circuit.
+    * The digital circuit resets from input provided by the analog circuit.
+In the latter two cases, you may need to force the reset protocol to last a minimum duration that may be longer than the default. This can be accomplished by a //digital// delay as follows:
+<code act>
+import globals; // contains Reset
+defproc reset_delay(bool? i; bool! o)
+{
+   bool _i;
+   prs {
+      i => _i-
+      [after=5000] _i => o-   // explicit delay introduced
+   }
+}
+bool Rtmp;
+reset_delay r(Reset,Rtmp);  // create the delay line to extend the reset phase
+Initialize {
+  actions  { Reset+ };
+  actions { [Rtmp]; Reset- }
+}
+</code>
+This will delay the reset phase by a minimum amount of time determined by the ''after'' clause, forcing the analog simulation to also be executed for at least that period of time. This cannot be automated because an analog simulator may not have any mechanism to indicate that the circuit is idle; in general, the analog circuit  may never be in a state where no signals are changing!
 ===== Configuration file =====
 An ACT configuration file can be read into ''actsim'' to control its behavior. The following summarizes configuration options that affect the behavior of the simulator (beyond the default ACT configurations that affect all tools). The simulator loads in the default ''actsim.conf'' file, but any of those parameters can be augmented/over-ridden using the ''-cnf'' [[stdoptions:start|command-line option]].
+==== General options ====
+When ''actsim'' starts, any top-level initialization is executed. This includes the initialize body at the top level, as well as any reset protocols for channels  that cross between CHP and non-CHP components. To avoid infinite loops during this initialization phase, 100 rounds of simulation are executed by default. In some cases this amount of time may not be enough to finish the reset phase. The parameter ''reset_rounds'' can be adjusted to increase this period
+<code>
+begin sim
+   int reset_rounds 100
+end
+</code>
+''actsim'' also supports [[https://en.wikipedia.org/wiki/Standard_Delay_Format|SDF]] (Standard Delay Format) back-annotation for delays. This is usually enabled using the command-line option ''-S'', but can also be specified using the configuration file:
+<code>
+begin sim
+  string sdf_file "annotate.sdf"
+  int sdf_mangled_names 1
+end
+</code>
+The parameter ''sdf_manged_names'' is set to 1 if the instance names in the file correspond to ACT [[config:start#output_generation_and_name_mangling|mangled names]], and 0 if they correspond to standard ACT names.
 ==== CHP configuration options ====
@@ Line 349: / Line 454: @@
 If this is set to 1, then debugging messages are printed out showing the metrics that ''actsim'' was looking for in the configuration file, and what metrics were in fact found.
+Metrics for energy, delay, leakage power, and area can be specified in a configuration file. These metrics are specified for each process type. (A better version is in the works...)  The way this works is as follows:
+<code>
+begin sim
+  begin chp
+    begin mytype<>
+       begin varname
+          int D 42
+          int E 84
+        end
+        real leakage 1e-8
+        int area 23
+     end
+  end
+ end
+</code>
+This configuration file provides annotations for energy and delay for a ''mytype<>'' process. The ''varname'' is the name of the variable, and could be a channel or a variable that is assigned. ''D'' is the delay associated with a send/receive using that channel, or assignment to the variable (if it is an int/bool). ''E'' is the energy associated with the operation. Finally, there is a leakage power and area value for the process. These values override the defaults in a type-specific manner.
 ==== Mixed-signal simulation ====
+The mixed-signal simulation parameters are used to configure the interface to Xyce, and are contained in a sim.device block.
+<code>
+begin sim
+  begin device
+    # put mixed-signal parameters here
+  end
+end
+</code>
+The parameters are
+<code>
+real timescale 1e-12
+</code>
+This is used for the time resolution of the Xyce output trace files, if any.
+<code>
+real analog_window 0.05
+</code>
+This specifies when an analog signal output should be treated as a digital 0 or digital 1.  The value 0.05 means within 5% of the rail-to-rail voltage. So for a 1V power supply, this would be 0.95 for a digital 1 threshold, and 0.05 for a digital 0 threshold.
+<code>
+int case_for_sim 1
+</code>
+SPICE is case-insensitive, and the internals of the analog simulator usually have either a lowercase or uppercase name for all the signals. Set this to 1 (the default, and correct value for Xyce) if it is uppercase, 0 for lowercase.
+<code>
+real settling_time 1e-12
+</code>
+This is the settling time parameter for the built-in ADC device used to convert between the digital and analog signals.
+<code>
+int dump_all 1
+</code>
+If this is true, all voltage signals should be saved to the output trace file. Otherwise, only the interface signals are saved to the trace file.
+<code>
+string output_format "prn:lxt2:alint:vcd"
+</code>
+This specifies which output trace file formats should be generated from the underlying analog simulation engine. Any number of colon-separated formats are supported, but only one of the built-in formats (raw, prn, etc) can be used.
+<code>
+int waveform_steps 10
+real waveform_time 10e-12
+</code>
+The digital input is converted to a ramp before being fed to the analog simulation. This specifies the duration and number of steps used for the conversion.
+<code>
+string model_files "path.sp"
+</code>
+By default, the simulation will look for the file ''models.sp'' in the ACT configuration directory. This string can be used to override this default and pick a different SPICE file that includes all the needed models.
+<code>
+string outfile "xyce_out"
+</code>
+This is the name of the trace file output that is generated.
+<code>
+real stop_time 100e-12
+</code>
+This is the time at which the trace file output should stop.
+<code>
+string_table measure_statements ".measure ..." ".print i(X)..."
+</code>
+defines additional spice lines added to each generated spice file used for the device_level simulations, you can use it for eg. recording currents measuring avergage power and so on
 ==== Standard sim namespace helper functions ====