Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
tools:actsim [2023/04/14 19:22] – [Configuration file] rajittools:actsim [2025/08/17 13:13] (current) – [Resetting the circuit] rajit
Line 80: Line 80:
 ==== Timing ==== ==== 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. 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> <code>random_seed <seed></code>
Line 90: Line 91:
  
 <code>random_choice on|off</code> <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 ==== ==== Running Simulation ====
Line 268: Line 268:
 { {
     adder a;     adder a;
-    sim::source_seq<32, // 32-bit data +    sim::source_sequence<32, // 32-bit data
-                    false, // don't repeat the sequence of values+
                     3, // three data values                     3, // three data values
-                    {3,5,2}  // the data values+                    {3,5,2},  // the data values 
 +                    false, // don't repeat the sequence of values 
 +                    0, // source ID is zero for logging 
 +                    false // don't log any information in the source
                     > s1(a.A);                     > 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  // 32-bit+                     0, // sink ID for logging 
 +                     true // log values
               > sx(a.C);               > sx(a.C);
  }  }
Line 291: Line 294:
 { {
     adder a;     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     // 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  // 32-bit+                     0, // sink ID for logging 
 +                     true // log values
               > sx(a.C);               > sx(a.C);
  }  }
 </file> </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-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:  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.    * 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 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]]. 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 ===== ===== 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 ==== ==== CHP configuration options ====
  
-The standard simulation library (in the sim namespace) uses a few configuration file settings to pick the names +<code> 
-of the files for I/O. +begin sim 
 +  begin chp 
 +    int inf_loop_opt 0 
 +  end 
 +end 
 +</code> 
 +''actsim'' can detect an infinite loop where no state changes occur, and delete the process from the simulation environment if this flag is turned on (by being set to 1).
  
 <code> <code>
-string sim.file.prefix "_infile_"+begin sim 
 +  begin chp 
 +    int default_delay 0 
 +    real default_leakage 0 
 +    int default_area 0 
 +  end 
 +end
 </code> </code>
-Change this parameter to modify the default file names used by the file I/O library used by the standard simulation namespace.+These set default simulation parameters for CHP processes. The default delay sets the value for each non-skip basic statement (send, receive, assignment) in a CHP program. The default leakage per process can be secified (in nW), as can the default area (in square microns).
  
-Alternatively, a file name table can be specified whose entries are the names of the files to be used for each file ID (0 = first entry, 1 = second entry, etc.) 
 <code> <code>
-string_table sim.file.name_table "file1.in" "file2.in"+begin sim 
 +  begin chp 
 +    int debug_metrics 0 
 +  end 
 +end
 </code> </code>
-If this parameter is specified, then the prefix parameter is ignored.+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.
  
-Other simulation parameters are:+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> <code>
-int sim.chp.inf_loop_opt 0+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> </code>
-''actsim'' can detect an infinite loop where no state changes occur, and delete the process from the simulation environment if this flag is turned on (by being set to 1).+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> <code>
-int sim.chp.default_delay 10+begin sim 
 +  begin device 
 +    # put mixed-signal parameters here   
 +  end 
 +end
 </code> </code>
-This is the default delay for each non-skip basic statement (send, receive, assignment) in a CHP program.+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> <code>
-int sim.chp.default_leakage 0+real analog_window 0.05
 </code> </code>
-This is the default leakage associated with a process (in nW)+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> <code>
-int sim.chp.default_area 0+int case_for_sim 1
 </code> </code>
-This is the default area associated with a CHP process (square microns).+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> <code>
-int sim.chp.debug_metrics 0+real settling_time 1e-12
 </code> </code>
-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.+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 ==== 
 + 
 +The standard simulation library (in the sim namespace) uses a few configuration file settings to pick the names 
 +of the files for I/O.  
 + 
 +<code> 
 +begin sim 
 +  begin file 
 +    string prefix "_infile_" 
 +  end 
 +end 
 +</code> 
 +Change this parameter to modify the default file names used by the file I/O library used by the standard simulation namespace. 
 + 
 +Alternatively, a file name table can be specified whose entries are the names of the files to be used for each file ID (0 = first entry, 1 = second entry, etc.) 
 +<code> 
 +begin sim 
 +  begin file 
 +    string_table name_table "file1.in" "file2.in" 
 +  end 
 +end 
 +</code> 
 +If this parameter is specified, then the prefix parameter is ignored. 
 + 
tools/actsim.1681500165.txt.gz · Last modified: by rajit
Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3


  • Show page
  • Old revisions
  • Backlinks
  • Recent Changes
  • Media Manager
  • Sitemap