HDLRuby 3.0.0 → 3.1.0

data/tuto/tutorial_sw.md

@@ -273,30 +273,30 @@ If everything was OK, a file named `my_circuit.v` should have appeared in the `w
 ```verilog
 `timescale 1ps/1ps
 
-module _v0_1( _v1_clk, _v2_rst, _v3_addr, _v4_data_in, _v5_data_out );
-   input _v1_clk;
-   input _v2_rst;
-   input [15:0] _v3_addr;
-   input _v4_ce;
-   input [7:0] _v5_data_in;
-   output [7:0] _v6_data_out;
+module _v0_1( clk, rst, addr, data_in, data_out );
+   input clk;
+   input rst;
+   input [15:0] addr;
+   input ce;
+   input [7:0] data_in;
+   output [7:0] data_out;
 
 
 endmodule
 ```
 
-The syntax looks indeed a little bit different from HDLRuby, but you should be able to recognize the description of the circuit. The name of the ports is different though, this is because HDLRuby supports any Unicode character for names and to avoid compatibility problems, it recreates the names when generating Verilog. Still, an effort is made to keep the original name, e.g., `clk` became `_v1_clk`. But, just for the fun, please replace `:addr` in the HDLRuby file with `:☺` and regenerate Verilog HDL from it... It works! And the result is:
+The syntax looks indeed a little bit different from HDLRuby, but you should be able to recognize the description of the circuit. The name of the module is different though, this is because HDLRuby supports any Unicode character for names and to avoid compatibility problems, it recreates the names when generating Verilog. But, just for the fun, please replace `:addr` in the HDLRuby file with `:☺` and regenerate Verilog HDL from it... It works! And the result is:
 
 ```verilog
 `timescale 1ps/1ps
 
-module _v0_1( _v1_clk, _v2_rst, _v3_, _v4_data_in, _v5_data_out );
-   input _v1_clk;
-   input _v2_rst;
-   input [15:0] _v3_;
-   input _v4_ce;
-   input [7:0] _v5_data_in;
-   output [7:0] _v6_data_out;
+module _v0_1( clk, rst, _v1_, data_in, data_out );
+   input clk;
+   input rst;
+   input [15:0] _v1_;
+   input ce;
+   input [7:0] data_in;
+   output [7:0] data_out;
 
 
 endmodule
@@ -357,17 +357,17 @@ Three new files should have appeared in the `work` directory: `_v10_5.v`, `_v8_4
 ```verilog
 `timescale 1ps/1ps
 
-module _v0_3( _v1_clk, _v2_rst, _v3_addr, _v4_ce0, _v5_ce1, _v6_data_in, _v7_data_out );
-   input _v1_clk;
-   input _v2_rst;
-   input [15:0] _v3_addr;
-   input _v4_ce0;
-   input _v5_ce1;
-   input [7:0] _v6_data_in;
-   output [7:0] _v7_data_out;
+module _v0_3( clk, rst, addr, ce0, ce1, data_in, data_out );
+   input clk;
+   input rst;
+   input [15:0] addr;
+   input ce0;
+   input ce1;
+   input [7:0] data_in;
+   output [7:0] data_out;
 
-   _v8_4 _v9_my_circuit0();
-   _v10_5 _v11_my_circuit1();
+   _v8_4 my_circuit0();
+   _v10_5 my_circuit1();
 
 endmodule
 ```
@@ -497,14 +497,14 @@ When the compile succeeds (no error message), two new files appear in `work`, na
 ```verilog
 `timescale 1ps/1ps
 
-module _v0_3( _v1_clk, _v2_rst, _v3_addr, _v4_ce0, _v5_ce1, _v6_data_in, _v7_data_out );
+module _v0_3( clk, rst, addr, ce0, ce1, data_in, data_out );
    input _v1_clk;
    input _v2_rst;
-   input [15:0] _v3_addr;
-   input _v4_ce0;
-   input _v5_ce1;
-   input [7:0] _v6_data_in;
-   output [7:0] _v7_data_out;
+   input [15:0] addr;
+   input ce0;
+   input ce1;
+   input [7:0] data_in;
+   output [7:0] data_out;
    wire _v8_0;
    wire _v9_1;
    wire [15:0] _v10_2;
@@ -518,29 +518,29 @@ module _v0_3( _v1_clk, _v2_rst, _v3_addr, _v4_ce0, _v5_ce1, _v6_data_in, _v7_dat
    wire [7:0] _v18_10;
    wire [7:0] _v19_11;
 
-      _v20_4 _v21_my_circuit0(._v1_clk(_v8_0),._v2_rst(_v9_1),._v3_addr(_v10_2),._v22_ce(_v11_3),._v6_data_in(_v12_4),._v7_data_out(_v18_10));
-   _v23_5 _v24_my_circuit1(._v1_clk(_v13_5),._v2_rst(_v14_6),._v3_addr(_v15_7),._v22_ce(_v16_8),._v6_data_in(_v17_9),._v7_data_out(_v19_11));
-   assign _v8_0 = _v1_clk;
+      _v20_4 my_circuit0(.clk(_v8_0),.rst(_v9_1),.addr(_v10_2),.ce(_v11_3),.data_in(_v12_4),.data_out(_v18_10));
+   _v23_5 my_circuit1(.clk(_v13_5),.rst(_v14_6),.addr(_v15_7),.ce(_v16_8),.data_in(_v17_9),.data_out(_v19_11));
+   assign _v8_0 = clk;
 
-   assign _v9_1 = _v2_rst;
+   assign _v9_1 = rst;
 
-   assign _v10_2 = _v3_addr;
+   assign _v10_2 = addr;
 
-   assign _v11_3 = _v4_ce0;
+   assign _v11_3 = ce0;
 
-   assign _v12_4 = _v6_data_in;
+   assign _v12_4 = data_in;
 
-   assign _v13_5 = _v1_clk;
+   assign _v13_5 = clk;
 
-   assign _v14_6 = _v2_rst;
+   assign _v14_6 = rst;
 
-   assign _v15_7 = _v3_addr;
+   assign _v15_7 = addr;
 
-   assign _v16_8 = _v5_ce1;
+   assign _v16_8 = ce1;
 
-   assign _v17_9 = _v6_data_in;
+   assign _v17_9 = data_in;
 
-   assign _v7_data_out = (_v18_10 + _v19_11);
+   assign data_out = (_v18_10 + _v19_11);
 
 
 endmodule
@@ -599,7 +599,7 @@ With HDL like Verilog HDL, there is a real distinction between wires and storage
 
 __Note__: one may ask what about the `variable` construct in VHDL: those are syntactic intermediates used for simplifying the descriptions. HDLRuby also supports such a `variable` construct, but those are simply the variables of the Ruby language. Therefore, these variables can hold not only values but any Ruby or HDLRuby constructs.
 
-In HDLRuby, there are three kinds of signals: the input ports, the output ports, the inout ports, and the inner signals. The first three kinds of signals have already been described in the section about declaring a [circuit](#circuit-declare). At that time they were called ports because it is what such constructs are called in common HDL. However, in HDLRuby there is no distinction at all between ports and signals, hence from now on, we will use the term `signal` in general, and the term `port` when we only want to refer to the interface of a circuit. The inner signals can be used inside a circuit and are usually used as an intermediate for internal computations. They are declared like the ports, but using `inner` instead of `input`, `output`, or `inout`. For example, the following code declares a module named `a_circuit` with two 1-bit inputs, one 8-bit output, and one 4-bit inner signal.
+In HDLRuby, there are four kinds of signals: the input ports, the output ports, the inout ports, and the inner signals. The first three kinds of signals have already been described in the section about declaring a [circuit](#circuit-declare). At that time they were called ports because it is what such constructs are called in common HDL. However, in HDLRuby there is no distinction at all between ports and signals, hence from now on, we will use the term `signal` in general, and the term `port` when we only want to refer to the interface of a circuit. The inner signals can be used inside a circuit and are usually used as an intermediate for internal computations. They are declared like the ports, but using `inner` instead of `input`, `output`, or `inout`. For example, the following code declares a module named `a_circuit` with two 1-bit inputs, one 8-bit output, and one 4-bit inner signal.
 
 ```ruby
 system(:a_circuit) do
@@ -737,9 +737,11 @@ This section will explain the following about sequencers:
 
  * [How to write a structured programming algorithm in a sequencer.](#322-how-to-write-a-structured-programming-algorithm-in-a-sequencer)
 
- * [How to use enumerators in a sequencer.](#323-how-to-use-enumerators-in-a-sequencer)
+ * [How to write and use a sequencer function.](#323-how-to-write-and-use-a-sequencer-function)
+
+ * [How to use enumerators in a sequencer.](#324-how-to-use-enumerators-in-a-sequencer)
 
- * [What happens when there are several sequencers?](#324-what-happens-when-there-are-several-sequencers)
+ * [What happens when there are several sequencers?](#325-what-happens-when-there-are-several-sequencers)
 
 
 #### 3.2.1 How to declare and control a sequencer
@@ -952,7 +954,7 @@ In detail here is a list of the control statements you can use within a sequence
 
  * `sif(<condition>) <block>`: executes `block` if `condition` is true (i.e., different from 0).
 
- - `selsif(<condition>) <block>`: executes `block` if the previous `sif` and `selsif` conditions are false and if the current `condition` is true.
+ * `selsif(<condition>) <block>`: executes `block` if the previous `sif` and `selsif` conditions are false and if the current `condition` is true.
 
  * `selse <block>`: executes `block` if the conditions of the previous `sif` and `selsif` are false (i.e., equals 0). It is also used for giving the default block for the `scase` statements (see below).
 
@@ -970,6 +972,8 @@ In detail here is a list of the control statements you can use within a sequence
 
  * `scontinue`: ends the current iteration.
 
+ * `steps(<num>)`: performs `num` times `step` (`num` can be any expression). Useful for waiting a certain number of cycles.
+
 > __IMPORTANT__: each control statement requires one clock cycle for each branch they perform, independently of what their block contains. For example, in the following code, the value of `y` will be set one cycle after `x` is set to 0, and one cycle before `z` is set to 1.
 
 ```ruby
@@ -1096,7 +1100,7 @@ clk <= 1
 ```
 
 > __IMPORTANT__: as said when presenting HDLRuby, this language is implemented on top of the Ruby language, and is fully compatible with it. For instance, you can write any Ruby code within HDLRuby constructs (e.g., `def`), and you can write HDLRuby code within Ruby constructs. However, there is an important difference: Ruby code is executed at compile time (i.e., when hdrcc runs) and does not produce any hardware, whereas HDLRuby code is the description of the hardware that will be produced and will be then executed either through simulation or after production physically.
-  Then, what calling `clk!` do is paste the HDLRuby code in place. Here it is used to shorten the code: instead of setting each time the clock to 0, advancing time, then setting it to 1, writing `clk!` is enough to obtain the same result.  
+  Then, what calling `clk!` do is paste the HDLRuby code in place. Here it is used to shorten the code: instead of each time setting the clock to 0, advancing time, then setting it to 1 again, writing `clk!` is enough to obtain the same result.  
   It is from this capability to mix Ruby and HDLRuby that comes the *meta programmability* of HDLRuby.
 
 Finally, when you simulate with the following command:
@@ -1110,6 +1114,38 @@ You should obtain the following kind of resulting VCD file:
   ![hruby_simulator.vcd](fact_vcd.png)
 
 
+#### But in structured programming, it is better to use local variables!
+
+Indeed, in the factorial program, signals `val` and `res` are only used within the sequencer, so why declare them outside it? The code would be more clear if they were declared more locally, i.e., *inside* it, and even better, inside its main loop. So let us modify it as follows:
+
+```ruby
+system :fact do
+   input :clk, :start, :req
+   [5].input :data_in
+   output :ack
+   [32].output :data_out
+
+   sequencer(clk,start) do
+      sloop do
+         [4].inner :val
+         [24].inner :res
+
+         ack <= 0
+         swhile(req != 1)
+         val <= data_in
+         res <= 1
+         swhile(val>1) do
+             res <= res*val
+             val <= val - 1
+         end
+         data_out <= res
+         ack <= 1
+      end
+   end
+end
+```
+
+You can simulate it again, and you should obtain exactly the same result. However, if you try to access `res` or `val` outside the main loop, then an error will be raised.
 
 
 #### Now about `sfor`
@@ -1208,16 +1244,128 @@ You should obtain the following time chart:
 
 
 
+#### 3.2.3. How to write and use a sequencer function.
+
+Why not necessarily associated with algorithmic, it is common in software to define functions for code reuse and implementation of recursive algorithms. HDLRuby also provided such kinds of functions, with all the software features, including recursion, using the construct `sdef`. Such a function is defined as follows:
+
+```ruby
+sdef :<name> do |<arguments>|
+   <body>
+end
+```
+
+In the code above, `name` is the name of the function, `arguments` is a list of arguments and `body` is the code of the function that can be any kind of HDLRuby sequencer code. For returning a value from a function, the `sreturn(<value>)` command is used. For example, the following describes a function computing the factorial of its argument `n`:
+
+```ruby
+sdef :fact do |n|
+   sif(n>1) { sreturn(n*fact(n-1) }
+   selse    { sreturn(1) }
+end
+```
+
+There is a lot to unpack from this small example:
+
+ 1. Such a function can be defined outside or inside a module, but can only be called within a sequencer.
+
+ 2. The arguments of a function, here `n`, do not have any defined type: their type, and consequently the final implementation of the function, is determined by the data type of the actual arguments when the function is called. For example, in the following code, the data type of the actual argument `val` is 16-bit unsigned, hence that will be the data type of `n`.
+
+    ```ruby
+    [16].inner :val, :res
+
+    sequencer do
+       val <= 5
+       res <= fact(val)
+    end
+    ```
+
+ 3. When a function is recursive, a stack is created to store the arguments and the sequencer states for returning at each recursion. The size of this stack is by default set to the bit width of the largest argument, e.g., for `fact` it is set for supporting 16 recursions. In case of stack overflow, i.e., there were too many recursive calls, the recursion is stopped, and the execution of the sequencer proceeds from just after the last call.
+
+ 4. The behavior of the stack can be controlled in two ways when defining a function as follows:
+
+    ```ruby
+    sdef(:<name>,<size>, proc <error_handler>) do |<arguments>|
+       <body>
+    end
+    ```
+
+    In the code above, `size` is the forced size of the stack, and `error_handler` is a block of code that will be executed when a stack overflow occurs. Both arguments are optional, but if the error handler is provided, then the size must also be provided. For example, the code of the factorial can be rewritten as follows for forcing the stack to support 64 recursions:
+
+    ```ruby
+    sdef(:fact,64) do |n|
+       sif(n>1) { sreturn(n*fact(n-1) }
+       selse    { sreturn(1) }
+    end
+    ```
+
+    It can also be defined as follows to support only 8 recursions but to set a signal named `stack_overflow` to 1 when a stack overflow happens:
+
+    ```ruby
+    sdef(:fact, 8, proc { stack_overflow <= 1 }) do |n|
+       sif(n>1) { sreturn(n*fact(n-1) }
+       selse    { sreturn(1) }
+    end
+    ```
+
+Here is a full example using the factorial:
+
+```ruby
+sdef(:fact,8,proc { stack_overflow_error <= 1 }) do |n|
+    sif(n > 1) { sreturn(n*fact(n-1)) }
+    selse      { sreturn(1) }
+end
+
+
+# Checking the fact function.
+system :module_with_fact do
+
+    inner :clk,:rst
+
+    [16].inner :val
+    [16].inner :res
+    inner stack_overflow_error: 0
+
+    sequencer(clk.posedge,rst) do
+        5.stimes do |i|
+            val <= i
+            res <= fact(val)
+        end
+        hprint("stack_overflow_error=",stack_overflow_error,"\n")
+    end
+
+    timed do
+        clk <= 0
+        rst <= 0
+        !10.ns
+        clk <= 1
+        !10.ns
+        clk <= 0
+        rst <= 1
+        !10.ns
+        clk <= 1
+        !10.ns
+        clk <= 0
+        rst <= 0
+        !10.ns
+        clk <= 1
+        repeat(500) do
+            !10.ns
+            clk <= ~clk
+        end
+    end
+end
+```
+
+
 ---
 
 So now, you know:
  
- * How to describe fully fledged algorithms with sequencers.
+ * How to describe fully-fledged algorithms with sequencers using conditional and control statements as well as functions, including recursive ones.
 
 Also, if you are not familiar with languages like Ruby or Python, the `sfor` may look great compared to what C can provide. But this is just the beginning, HDLRuby can do better than that.
 
 
-#### 3.2.3. How to use enumerators in a sequencer
+#### 3.2.4. How to use enumerators in a sequencer
 
 If sometimes you program with Ruby, you may know about enumerators: they are objects used for processing iteratively several elements of objects. The HDLRuby's sequencer provides the same concept: it is possible to build hardware enumerators for any enumerable objects and they will run like Ruby's.
 
@@ -1284,12 +1432,12 @@ That's all that we will explain here, the remaining is exactly like Ruby. Moreov
     
     sequencer(clk,start) do
        16.stimes {|i| ar[i] <= sin }
-       ar.ssort
-       16.stimes {|i| sout <= ar[i] }
+       res = ar.ssort
+       16.stimes {|i| sout <= res[i] }
     end
     ```
    
-   In this example, `16.stimes` generates an enumerator over the `0..7` range, and is a way to build an enumerator from an integer value.
+   In this example, `16.stimes` generates an enumerator over the `0..7` range, and is a way to build an enumerator from an integer value. In addition, please notice the use of the Ruby variable `res` for accessign the signal containing the sort result.
 
   * Apply a 4-point FIR filter over an array obtained from input signal `sin` with 0-padding at the beginning and output the result to `sout`
 
@@ -1309,7 +1457,29 @@ That's all that we will explain here, the remaining is exactly like Ruby. Moreov
     end
     ```
    
-    In this example, `[_h00]*3` builds an array of three 8-bit zeros for the padding, `seach` creates the iterators over this padding. This iterator is added to one over `ar` which creates a global iterator over them all. `seach_slice` and `sreduce` work the same way their Ruby equivalent `each_slice` and `reduce` do.
+    In this example, `[_h00]*3` builds an array of three 8-bit zeros for the padding, `seach` creates the iterators over this padding. This iterator is added to one over `ar` which creates a global iterator over them all. `seach_slice` and `sreduce` work the same way their Ruby equivalent `each_slice` and `reduce` do. Here, since the result is a single byte, it is directly assigned to the output `sout`, but the following could also have been possible:
+
+    ```ruby
+    input :clk,:start
+    [8].input :sin
+    [8].output :sout
+    
+    bit[8][-4].inner coefs: [_h01,_h05,_h0A,_hFE]
+    bit[8][-16].inner : ar
+   
+    res = nil
+
+    sequencer(clk,start) do
+       16.stime {|i| ar[i] <= sin }
+       res = ([_h00]*3).seach + ar.seach).seach_slice(4).sreduce(_h00) do |a,b,c,d|
+          a*coefs[0] + b * coefs[1] + c * coefs[2] + d * coefs[3]
+       end
+    end
+
+    sout <= res
+    ```
+
+    Please notice that since the Ruby variable `res` is used outside the sequencer, it must also be declared outside (`res = nil`).
 
 
 
@@ -1354,7 +1524,7 @@ But this is not all: contrary to software, hardware is inherently parallel, a pr
 
 
 
-#### 3.2.4. What happens when there are several sequencers?
+#### 3.2.5. What happens when there are several sequencers?
 
 
 #### General considerations
@@ -1698,7 +1868,7 @@ In software, when you want to do parallelism you usually need specific libraries
 
  * [A sequencer is not a program](#41-a-sequencer-is-not-a-program)
 
- * [Adding parallelism is genuine](#42-parallel-control-statements-and-enumerators)
+ * [Adding parallelism is genuine](#42-parallel-control-statements-functions-and-enumerators)
 
 ### 4.1. A sequencer is not a program
 
@@ -1736,7 +1906,7 @@ sequencer(clk,start) do
 > __WARNING__: in hardware design with HDLRuby (and with all similar languages like Verilog VHDL or VHDL,) it is assumed that a clock is slow enough for the relevant combinatorial circuits to complete computation before the next cycle. If this is not the case, the resulting circuits will not function properly. Fortunately, the synthesis frameworks usually provide tools for verifying these timings.
 
 
-### 4.2. Parallel control statements and enumerators
+### 4.2. Parallel control statements, functions, and enumerators
 
 Sequencers provide many constructs for easy control and enumeration. However, those constructs are sequential by construction. What if you would like to do the same in parallel? This is possible, but there is an important restriction:
 
@@ -1840,14 +2010,46 @@ Yes, this is becoming confusing because it is hard to know what Ruby does when e
  * `zip`
 
 
+#### 4.2.3. Can functions be parallel too?
+
+As explained before, the body of a `sdef` function can contain any kind of sequencer code, hence parallel code is also possible. Yet, calling and returning from such a function are themselves sequential procedures that require several cycles to be performed. Hence, there exists a parallel version of `sdef` whose call and return as well as its body execution is fully combinatorial. It is declared as follows:
+
+```ruby
+hdef :<name> do |<arguments>|
+   <body>
+end
+```
+
+As you can see, the declaration is identical to the `sdef` one. However the behavior is different, and this new kind of function has the following limitations:
+
+ 1. It cannot contain any sequential code, i.e., constructs like `step`, `sif` or `sloop`.
+
+ 2. It does not support the `sreturn` constructs either, instead, it is the last value computed by the function that is returned.
+
+ 3. It cannot be recursive.
+
+Here is an example of a parallel-compatible function counting the number of ones in the input argument:
+
+```ruby
+hdef :popcount do |n|
+   n.each.reduce(_b0.as(n.type),&:+)
+end
+```
+
+In the code above, it can be seen that no return is provided but instead, it will be the result of the parallel sum result that will be returned since it is the last computation of the function. Also, the data type of the sum is obtained from the argument `n` (`as(n.type)`).
+
 ---
 
 Now you know:
 
- * How to use Ruby code for concisely describing parallel HDLRuby code.
+ * How to introduce parallelism within a sequencer.
 
+ * How to define a parallel-compatible function using `hdef`
 
-#### 4.2.3. Parallel is faster, so why do sequential computations?
+But, by the way, why bother with sequential code if parallel one is faster?
+
+
+#### 4.2.4. Parallel is faster, so why do sequential computations?
 
 Why parallel dataflow computations are indeed faster than sequential ones, in theory, they also have some drawbacks.
 
@@ -1898,7 +2100,11 @@ First, we must make things clear:
 
 > Processes in hardware has very little (nothing?) to do with any kind of software process.
 
-In hardware, a process is a list of data flow statements that are activated (we would say *executed* if they were software instructions) on a common condition. Depending on the activation condition, there are three kinds of processes:
+In hardware, a process is a list of data flow statements that are activated (we would say *executed* if they were software instructions) on a common condition. 
+
+> By data flow statements, we mean all the assignment statements, the `hif`, `helse`, `hcase` and `hwhen` statements, and the calls to `hdef` functions.
+
+Depending on the activation condition, there are three kinds of processes:
 
  * The connection processes (in HDLRuby they are considered to be processes)
 

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: HDLRuby
 version: !ruby/object:Gem::Version
-  version: 3.0.0
+  version: 3.1.0
 platform: ruby
 authors:
 - Lovic Gauthier
 autorequire:
 bindir: exe
 cert_chain: []
-date: 2023-04-10 00:00:00.000000000 Z
+date: 2023-07-08 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: bundler
@@ -195,11 +195,12 @@ files:
 - lib/HDLRuby/hdr_samples/with_reconf.rb
 - lib/HDLRuby/hdr_samples/with_reduce.rb
 - lib/HDLRuby/hdr_samples/with_ref_array.rb
-- lib/HDLRuby/hdr_samples/with_register_stack.rb
+- lib/HDLRuby/hdr_samples/with_ref_expr.rb
 - lib/HDLRuby/hdr_samples/with_sequencer.rb
 - lib/HDLRuby/hdr_samples/with_sequencer_deep.rb
 - lib/HDLRuby/hdr_samples/with_sequencer_enumerable.rb
 - lib/HDLRuby/hdr_samples/with_sequencer_enumerator.rb
+- lib/HDLRuby/hdr_samples/with_sequencer_func.rb
 - lib/HDLRuby/hdr_samples/with_sequencer_sync.rb
 - lib/HDLRuby/hdr_samples/with_str2value.rb
 - lib/HDLRuby/hdr_samples/with_subsums.rb
@@ -370,6 +371,7 @@ files:
 - lib/HDLRuby/std/pipeline.rb
 - lib/HDLRuby/std/reconf.rb
 - lib/HDLRuby/std/sequencer.rb
+- lib/HDLRuby/std/sequencer_func.rb
 - lib/HDLRuby/std/sequencer_sync.rb
 - lib/HDLRuby/std/std.rb
 - lib/HDLRuby/std/task.rb

data/lib/HDLRuby/hdr_samples/with_register_stack.rb

@@ -1,150 +0,0 @@
-require 'soft/stacks.rb'
-
-include HDLRuby::High::Soft
-
-
-# A system testing the bram-based stack.
-system :register_stack_test do
-
-    widthA = 3
-    size   = 2**widthA
-    widthD = 8
-
-
-    input :clk,:rst,:ce
-    [2].inner :cmd
-    [widthD].inner  :din,:dout
-    inner :empty, :full
-    douts = size.times.map { |i| [widthD].inner :"dout#{i}" }
-
-    register_stack(widthA,widthD,size).(:stackI).(clk,rst,ce,cmd,din,dout,empty,full,*douts)
-
-    [widthD].inner :count # Additional counter for the test.
-
-    timed do
-        clk <= 0
-        ce  <= 0
-        rst <= 0
-        cmd <= READ
-        din <= 0
-        !10.ns
-        clk <= 1
-        !10.ns
-        clk <= 0
-        rst <= 1
-        !10.ns
-        clk <= 1
-        !10.ns
-        clk <= 0
-        rst <= 0
-        ce  <= 1
-        din <= 1
-        !10.ns
-        clk <= 1
-        repeat(9) do
-            !10.ns
-            clk <= 0
-            cmd <= PUSH
-            din <= din + 1
-            !10.ns
-            clk <= 1
-        end
-        !10.ns
-        clk <= 0
-        !10.ns
-        clk <= 1
-        din <= -1
-        repeat(8) do
-            !10.ns
-            clk <= 0
-            cmd <= READ
-            din <= din + 1
-            !10.ns
-            clk <= 1
-        end
-        !10.ns
-        clk <= 0
-        !10.ns
-        clk <= 1
-        count <= 0
-        repeat(4) do
-            !10.ns
-            clk <= 0
-            din <= 1
-            cmd <= POP
-            !10.ns
-            clk <= 1
-            !10.ns
-            clk <= 0
-            count <= count + 1
-            din <= count
-            cmd <= PUSH
-            !10.ns
-            clk <= 1
-        end
-        !10.ns
-        clk <= 0
-        !10.ns
-        clk <= 1
-        repeat(9) do
-            !10.ns
-            clk <= 0
-            din <= 1
-            cmd <= POP
-            !10.ns
-            clk <= 1
-        end
-        !10.ns
-        clk <= 0
-        din <= _b8hAA
-        cmd <= PUSH
-        !10.ns
-        clk <= 1
-        !10.ns
-        clk <= 0
-        din <= 7
-        cmd <= WRITE
-        !10.ns
-        clk <= 1
-        din <= -1
-        repeat(8) do
-            !10.ns
-            clk <= 0
-            cmd <= WRITE
-            din <= din + 1
-            !10.ns
-            clk <= 1
-        end
-        !10.ns
-        clk <= 0
-        din <= size-1
-        cmd <= READ
-        !10.ns
-        clk <= 1
-        !10.ns
-        clk <= 0
-        din <= -3
-        cmd <= POP
-        !10.ns
-        clk <= 1
-        !10.ns
-        clk <= 0
-        din <= 31
-        cmd <= PUSH
-        !10.ns
-        clk <= 1
-        !10.ns
-        clk <= 0
-        din <= 3
-        cmd <= POP
-        !10.ns
-        clk <= 1
-        !10.ns
-        clk <= 0
-        din <= size-1
-        cmd <= READ
-        !10.ns
-        clk <= 1
-    end
-
-end