Differences

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

Link to this comparison view

Next revision 		Previous revision
scratch:tutorial_1_-_a_simple_inverter [2020/11/02 05:25]
ole created 		scratch:tutorial_1_-_a_simple_inverter [2020/12/02 01:00] (current)
Line 2: Line 2:
  
 In this first example we will build and simulate an inverter and touch the basic language elements and tools needed for this (production rules, prs block, defproc incl. in/out, instantiation, aflat and prsim) In this first example we will build and simulate an inverter and touch the basic language elements and tools needed for this (production rules, prs block, defproc incl. in/out, instantiation, aflat and prsim)
 +
 +make sure you installed act and added it to your path please follow [[:install]]
  
 ACT is used to describe a hierarchical collection of processes that together implement a circuit. Each process is an independent entity, and operates concurrently with all the other processes in the system. Circuits are also processes, and the physical implementation of two circuits operate concurrently. ACT is used to describe a hierarchical collection of processes that together implement a circuit. Each process is an independent entity, and operates concurrently with all the other processes in the system. Circuits are also processes, and the physical implementation of two circuits operate concurrently.
Line 10: Line 12:
 | 1 (TRUE) ^ 0 (FALSE) | | 1 (TRUE) ^ 0 (FALSE) |
 | 0 (FALSE) ^ 1 (TRUE) | | 0 (FALSE) ^ 1 (TRUE) |
- 
- 
  
 <code> <code>
Line 22: Line 22:
 }  } 
 </code> </code>
 +
 +=== production rules ===
  
 Let's start with the statements Let's start with the statements
Line 29: Line 31:
 </code> </code>
  
-These statements are two //production rules.// ([[language:langs:prs|prs documentation]]). If you have designed asynchronous circuits, then this terminology should be familiar. A production rule behaves in the following way:+These statements are two //production rules.// ([[language:langs:prs|prs documentation]]). They are embedded into the ACT hirachy, therefor the file type is act. If you have designed asynchronous circuits, then this terminology should be familiar. A production rule behaves in the following way:
    * The left hand side is a Boolean expression    * The left hand side is a Boolean expression
    * The right hand side is a signal transition    * The right hand side is a signal transition
Line 56: Line 58:
  
 as a quick recap you have ''->'' (simple rule), ''=>'' (complementary rule / combinational logic) and ''#>'' (c-element rule, not important at the moment) as a quick recap you have ''->'' (simple rule), ''=>'' (complementary rule / combinational logic) and ''#>'' (c-element rule, not important at the moment)
 +
 +=== processes ===
  
 The ''prs { ... }'' specifies the production rule body for the process. There are other bodies that can also be included, and they use different keywords instead of ''prs'' but the same basic structure. The ''prs { ... }'' specifies the production rule body for the process. There are other bodies that can also be included, and they use different keywords instead of ''prs'' but the same basic structure.
Line 82: Line 86:
 </file> </file>
  
-the prsim simulator can only read pure production rule files, and not the hierarchical act files we use so to simulate we need to convert our definition.+the prsim simulator can only read pure production rule files, and not the hierarchical act files with embedded production rules we wrote before. So to simulate we need to convert our definition to plain and flat production rules.
 If the file above is called ''test_inv.act'', a production rule file can be created from the ACT file by: If the file above is called ''test_inv.act'', a production rule file can be created from the ACT file by:
  
Line 106: Line 110:
  
 (Prsim) initialize  (Prsim) initialize 
 +</code>
 +''(Prsim)'' shows you that you need to enter a command, the output of the tool is displayed without it.
 +after you entered initialize the sim is set up, but we still want to see what happens so we need to add some ''watch <signal>''
 +<code>
 (Prsim) watch inv.i (Prsim) watch inv.i
 (Prsim) watch inv.o (Prsim) watch inv.o
 +</code>
 +we can also use prsim to show us all signals that are 1 or X with ''status [0|1|X|...]''
 +<code>
 +(Prsim) status 1
 +</code>
 +no output but for
 +<code>
 (Prsim) status X (Prsim) status X
 +---------------------------------------
 +inv.o inv.i
 +</code>
 +it shows us that our signals are not set. so lets do this with ''set <signal> [0|1|...]''
 +<code>
 (Prsim) set inv.i 0 (Prsim) set inv.i 0
 +</code>
 +to see what will change in the circuit we now have to let the simulation run a cycle with
 +<code>
 (Prsim) cycle (Prsim) cycle
 +---------------------------------------
 +          0 inv.i : 0
 +         10 inv.o : 1  [by inv.i:=0]
 +</code>
 +
 +so the first line ''0 inv.i : 0'' shows that out set 0 command (''inv.i : 0'') from above was applied at step 0 (''0 in...''), 
 +the second line ''10 inv.o : 1  [by inv.i:=0]'' shows us that the inverter inverted the input: from left to right at timesept ''10'' the output ''inv.o'' switched to 1 '': 1'', this swich was initated/caused by the input beeing set to 0 ''[by inv.i:=0]''
 +
 +the standard gate delay in prsim (from input to output of the inverter) is on default 10 steps thats why the steps advance by 10.
 +
 +lets also test the other direction:
 +
 +<code>
 (Prsim) set inv.i 1 (Prsim) set inv.i 1
 (Prsim) cycle (Prsim) cycle
 +---------------------------------------
 +          10 inv.i : 1
 +          20 inv.o : 0  [by inv.i:=1]
 </code> </code>
  
-''prsim'' 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 ''prsim'' command to see the range of commands supported by ''prsim.''+ 
 +so again the first line ''10 inv.i : 1'' reads at timesept ''10'' the input ''inv.i'' switched to 1 '': 1'' 
 +and the second line ''20 inv.o : 0  [by inv.i:=1]'' reads at timesept ''20'' the input ''inv.i'' switched to 0 '': 0'' , this switch was initated/caused by the input set to 1 ''[by inv.i:=1]'' 
 + 
 + 
 + 
 +as a summery ''prsim'' 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 ''prsim'' command to see the range of commands supported by ''prsim.''
  
 One of the useful features of ''prsim'' is that it can automatically randomize the delays of production rule firings. To do this, use One of the useful features of ''prsim'' is that it can automatically randomize the delays of production rule firings. To do this, use
scratch/tutorial_1_-_a_simple_inverter.1604312747.txt.gz · Last modified: 2020/12/02 01:00 (external edit)
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