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
intro_example:inverter [2020/04/30 17:42] – [A simple inverter] rajitintro_example:inverter [2025/05/01 13:32] (current) – [Simulating with prsim] rajit
Line 4: Line 4:
  
 An inverter is a very simple process that has a one-bit digital input and one bit digital output. The following specifies a process that corresponds to one inverter. An inverter is a very simple process that has a one-bit digital input and one bit digital output. The following specifies a process that corresponds to one inverter.
-<code>+<code act>
 defproc inverter (bool? i; bool! o) defproc inverter (bool? i; bool! o)
  
Line 15: Line 15:
  
 Let's start with the statements Let's start with the statements
-<code>+<code act>
  i -> o-  i -> o-
 ~i -> o+ ~i -> o+
Line 33: Line 33:
 This is a combinational gate, which means either the pull-up or pull-down network is always conducting (alternatively, the OR of the Boolean expressions for the pull-up and pull-down is always true). In this case, the pull-up and pull-down networks are complements of each other, so you only need specify one. The ''=>'' arrow can be used so that one rule can be used to specify both the pull-up and pull-down network as follows: This is a combinational gate, which means either the pull-up or pull-down network is always conducting (alternatively, the OR of the Boolean expressions for the pull-up and pull-down is always true). In this case, the pull-up and pull-down networks are complements of each other, so you only need specify one. The ''=>'' arrow can be used so that one rule can be used to specify both the pull-up and pull-down network as follows:
  
-<code>+<code act>
 defproc inverter (bool? i; bool! o) defproc inverter (bool? i; bool! o)
  
Line 47: Line 47:
  
 This fragment of ACT simply defines a process named ''inverter''. To actually create an inverter, we have to instantiate the process. The ''defproc'' can be viewed as defining the inverter type. We can use ''inverter'' just like we used ''bool'', and create an inverter called ''inv'' using the following: This fragment of ACT simply defines a process named ''inverter''. To actually create an inverter, we have to instantiate the process. The ''defproc'' can be viewed as defining the inverter type. We can use ''inverter'' just like we used ''bool'', and create an inverter called ''inv'' using the following:
-<code>+<code act>
 inverter inv; inverter inv;
 </code> </code>
Line 57: Line 57:
 The complete example is: The complete example is:
  
-<code>+<code act>
 defproc inverter (bool? i; bool! o) defproc inverter (bool? i; bool! o)
  
Line 108: Line 108:
  
 After this command, all delays are randomized. This is a useful test to see if your production rules are stable and non-interfering. If ''prsim'' finds that a production rule is unstable, it sets its output to ''X'' (for undefined). These ''X''s can propagate through the circuit. After this command, all delays are randomized. This is a useful test to see if your production rules are stable and non-interfering. If ''prsim'' finds that a production rule is unstable, it sets its output to ''X'' (for undefined). These ''X''s can propagate through the circuit.
 +
 +===== Simulating with actsim =====
 +
 +ACTSIM is setup to simulate processes by default. We recommend having a top-level process that is used for testing purposes. In this setup, the complete example is:
 +
 +<code act>
 +defproc inverter (bool? i; bool! o)
 +
 +  prs {
 +    i => o-
 +  }
 +
 +
 +defproc test()
 +{
 +  inverter inv;
 +}
 +</code>
 +
 +If the file above is called ''test_inv.act'', we can start the simulation using:
 +
 +<code>
 +% actsim -p test  test_inv.act
 +</code>
 +
 +Note that we don't need to generate the flattened production rule file, which could be quite large. We can simulate this as follows:
 +
 +<code>
 +actsim> watch inv.i
 +actsim> watch inv.o
 +actsim> status X
 +inv { o }
 +actsim> set inv.i 0
 +[                   0] <[env]> inv.i := 0
 +actsim> cycle
 +[                  10] <inv>  inv.o := 1
 +actsim> set inv.i 1
 +[                  10] <[env]> inv.i := 1
 +actsim> cycle
 +[                  20] <inv>  inv.o := 0
 +</code>
 +
 +''actsim'' will check if the production rules being run are stable (i.e. hazard/glitch-free) and non-interfering (i.e. that pull-up and pull-down networks are not on simultaneously). It doesn't check all possible delay configurations, but just reports errors if it observes unstable or interfering production rules while the simulation is running. Try ''help'' as a ''actsim'' command to see the range of commands supported by ''actsim''.
 +
 +One of the useful features of ''actsim'' is that it can automatically randomize the delays of production rule firings. To do this, use
 +
 +<code>
 +actsim> random
 +</code>
 +
 +After this command, all delays are randomized. This is a useful test to see if your production rules are stable and non-interfering. If ''actsim'' finds that a production rule is unstable, it sets its output to ''X'' (for undefined). These ''X''s can propagate through the circuit.