Differences

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

--- tools:actsim [2025/08/16 11:33] – [Mixed-signal simulations] rajit
+++ tools:actsim [2025/08/17 13:13] (current) – [Resetting the circuit] rajit
@@ Line 315: / Line 315: @@
 ''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 327: / Line 343: @@
 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 =====