ruby-vpi 20.0.0 → 21.0.0

data/examples/pipelined_alu/Hw5UnitModel.rb

@@ -1,114 +0,0 @@
-# Behavioral model of the hw5_unit Verilog module.
-class Hw5UnitModel
-
-  # Represents an ALU operation.
-  class Operation
-    attr_accessor :type, :tag, :arg1, :arg2, :stage, :result
-
-    def initialize(type, tag, arg1 = 0, arg2 = 0)
-      raise ArgumentError unless OPERATIONS.include? type
-
-      @type = type
-      @tag = tag
-      @arg1 = arg1
-      @arg2 = arg2
-
-      @stage = 0
-    end
-
-    # Computes the result of this operation.
-    def compute
-      case @type
-        when :add
-          @arg1 + @arg2
-
-        when :sub
-          @arg1 - @arg2
-
-        when :mul
-          @arg1 * @arg2
-
-        when :nop
-          nil
-
-        else
-          raise
-      end
-    end
-
-    def compute!
-      @result = compute
-    end
-  end
-
-
-  # Supported types of ALU operations.
-  OPERATIONS = [ :add, :sub, :mul, :nop ]
-
-  # Number of cycles each operation uses.
-  OPERATION_LATENCIES = {
-    :add => 1,
-    :sub => 2,
-    :mul => 3,
-    :nop => 1,
-  }
-
-  # The famous no-operation.
-  NOP = Hw5UnitModel::Operation.new(:nop, nil)
-
-
-  def reset
-    @aluQueues = {}
-    @outputQueue = []
-
-    # create a separate pipeline for each operation
-    OPERATIONS.each do |op|
-      @aluQueues[op] = []
-    end
-  end
-
-  alias_method :initialize, :reset
-
-
-  # Starts the given operation during the present cycle.
-  def startOperation(op)
-    @aluQueues[op.type] << op
-
-    p "started operation:", op  if $DEBUG
-  end
-
-  # Performs the behavior for the present cycle.
-  def cycle
-    # perform ALU operations
-    @aluQueues.each_pair do |alu, pipeline|
-      finished = []
-
-      pipeline.each do |op|
-        # when the operation has finished all pipeline stages, compute the result and output it
-        if op.stage >= OPERATION_LATENCIES[op.type]
-          op.compute!
-          finished << op
-          @outputQueue << op
-        end
-
-
-        # perform the next stage of the operation
-        op.stage += 1
-      end
-
-
-      # remove finished operations from pipeline
-      @aluQueues[alu] = pipeline - finished
-    end
-  end
-
-  # Returns the output for the present cycle.
-  def output
-    unless @outputQueue.empty?
-      @outputQueue.shift
-    else
-      NOP
-    end
-  end
-
-end

data/examples/pipelined_alu/README

@@ -1,152 +0,0 @@
-PIPELINED ALU
-
-  This example is my solution to a homework assignment for an Advanced Logic
-  Design class I had taken during the Winter of 2006 at University of
-  California, Santa Cruz. Relevant portions of the problem have been revised and
-  reproduced here with permission from the instructor: professor Jose Renau.
-
-
-
-PROBLEM
-
-  Implement the functionality for hw5 unit, a pipelined ALU:
-
-  `define  WIDTH      32
-  `define  DATABITS   7
-  `define  OP_NOP     0
-  `define  OP_ADD     1
-  `define  OP_SUB     2
-  `define  OP_MULT    3
-
-  module hw5_unit(
-      input                           clk
-      ,input                          reset
-
-      // inputs
-      ,input     [`DATABITS-1:0]      in_databits
-      ,input     [`WIDTH-1:0]         a
-      ,input     [`WIDTH-1:0]         b
-      ,input     [1:0]                in_op
-
-      // outputs
-      ,output reg [`WIDTH-1:0]        res
-      ,output reg [`DATABITS-1:0]     out_databits
-      ,output reg [1:0]               out_op
-  );
-
-
-  MAJOR POINTS
-
-  1. in_op selects the operation to perform (OP_NOP means no operation).
-
-  2. A new operation may be started every cycle.
-
-  3. OP_ADD must have 1 cycle latency.
-
-  4. OP_SUB must have 2 cycles latency.
-
-  5. OP_MULT must have 3 cycles latency.
-
-  6. There is only one result (res). Since three operations can finish every
-  cycle, you need to buffer the other two. Note that since at most one operation
-  starts per cycle, a 3-entry buffer should be enough.
-
-  7. Each operation has an associated tag (in_databits) which you must pass back
-  with the result (out_databits). For example, if a OP_MULT operation is started
-  with parameters a=2, b=4, in_databits=3; then after the multiplication
-  finishes three cycles later, the outputs should be res=8, out_databits=3,
-  out_op=OP_MULT.
-
-  8. The testbench used to verify this module must:
-
-    a. Test random combinations of positive, zero, one, prime numbers,
-    power-of-two values from powers 1 to 32, and random numbers.
-
-    b. Execute random combinations of add, subtract, and multiply operations.
-
-    c. Perform tests for 4000 ALU operations.
-
-
-
-DESIGN
-
-  From the start, my approach was to use a single queue to solve the resource
-  conflict (only one ALU can give an output per cycle). After drawing some
-  sketches and understanding the problem, I wrote the following algorithm to
-  solve the resource conflict:
-
-    def queue_results(a, b, c)
-      output a
-      enqueue b, c
-    end
-
-
-  We cannot perform all the operations in the queue_results method using only
-  one cycle. However, if the queue_results method is not implemented as shown,
-  then the design will not work---it will be chaotic and produce incoherent
-  results.
-
-  The trick is to satisfy the post-conditions of the queue_results method (one result is outputted and the other two have been queued) using multiple clock cycles:
-
-    1. enqueue b
-    (remember a and c)
-
-    2. enqueue c
-    (remember a)
-
-    3. output a
-
-    or
-
-    1. enqueue b
-    (remember a and c)
-
-    2. enqueue c; output a
-    (nothing to remember)
-
-  Note that we cannot output the 'a' result during the first cycle because that
-  would violate the post-conditions.
-
-
-  After gaining this understanding, I realized that a separate queue was wholly
-  unnecessary. Instead, I could simply use pipeline registers to remember values
-  until they were needed (i.e. the 'a' result is output only in the last cycle).
-
-  This approach uses exactly the same number of pipeline registers (three in
-  this case) as the size of the queue suggested by the Professor. Also, this
-  approach uses less storage than the three-queues (one for each ALU output;
-  therefore 9 registers) approach suggested by the Professor.
-
-
-  Finally, I wrote a behavioral model (see MODEL section) of the RTL using Ruby
-  and verified both my initial approach (magical single-cycle queueing of
-  multiple items) and its later improvement (the pipeline-register approach).
-
-
-
-MODEL
-
-  $ cd tests
-  $ ruby -w TestHw5UnitModel.rb		# use the "-d" option for details
-
-
-  The model is written in Ruby and comes with a unit test which is similar to
-  the Ruby-VPI test bench I wrote for the RTL implementation.
-
-
-
-TEST BENCH
-
-  $ ulimit -s unlimited
-  $ make VERILOG=$VCS_HOME VCS_FLAGS="-cc gcc32 -ld gcc32" vcs
-
-  ... lots of output here ...
-
-  hw5_unit_tb.rb passed successfully!
-  CPU time: .120 seconds to compile + .268 seconds to link +
-  30.042 seconds in simulation
-
-
-
-  The test bench structure was ported from my unit test for the behavioral model
-  of hw5_unit.

data/examples/pipelined_alu/Rakefile

@@ -1 +0,0 @@
-require 'ruby-vpi/runner_proxy'

data/examples/pipelined_alu/TestHw5UnitModel.rb

@@ -1,72 +0,0 @@
-require 'int_gen'
-require 'Hw5UnitModel'
-require 'test/unit'
-
-class TestHw5UnitModel < Test::Unit::TestCase
-  NUM_VECTORS = 4000
-
-  def setup
-    @model = Hw5UnitModel.new
-    @ingen = IntegerGenerator.new 32
-  end
-
-  def test_reset
-    @model.reset
-    assert_same Hw5UnitModel::NOP, @model.output
-  end
-
-  def testModel
-    # generate input for module
-    inputQueue = []
-
-    NUM_VECTORS.times do |i|
-      inputQueue << Hw5UnitModel::Operation.new(
-        Hw5UnitModel::OPERATIONS[rand(Hw5UnitModel::OPERATIONS.size)],
-        i,
-        @ingen.random.abs,
-        @ingen.random.abs
-      )
-    end
-
-
-    # test the module
-    outputQueue = []
-    cycle = 0
-
-    until inputQueue.length == outputQueue.length
-      if $DEBUG
-        print "\n" * 3
-        p ">> cycle #{cycle}"
-      end
-
-
-      # start a new operation
-      if cycle < inputQueue.length
-        @model.startOperation inputQueue[cycle]
-        cycle += 1
-      end
-
-
-      # simulate a clock cycle
-      @model.cycle
-
-
-      # verify the output
-      output = @model.output
-      p "output:", output if $DEBUG
-
-      unless output == Hw5UnitModel::NOP
-        assert_not_nil inputQueue.find {|op| op.tag == output.tag }, "unknown tag on result: #{output.tag}"
-        assert_equal output.compute, output.result, "incorrect result"
-
-        outputQueue << output
-      end
-
-
-      if $DEBUG
-        puts
-        pp @model
-      end
-    end
-  end
-end

data/examples/pipelined_alu/hw5_unit.v

@@ -1,128 +0,0 @@
-module hw5_unit
-#(parameter                 WIDTH    = 32,
-  parameter                 DATABITS = 7,
-  parameter                 OP_NOP   = 0,
-  parameter                 OP_ADD   = 1,
-  parameter                 OP_SUB   = 2,
-  parameter                 OP_MULT  = 3)
-( input                     clk,
-  input                     reset,
-
-  input      [DATABITS-1:0] in_databits,
-  input      [WIDTH-1:0]    a,
-  input      [WIDTH-1:0]    b,
-  input      [1:0]          in_op,
-
-  output reg [WIDTH-1:0]    res,
-  output reg [DATABITS-1:0] out_databits,
-  output reg [1:0]          out_op
-);
-
-
-  /* PHASE 0: perform the ALU operations */
-
-  // operation ID
-    reg [DATABITS-1:0]     in_databits_phase0;
-    reg [1:0]              in_op_phase0;
-
-    always @(*) begin
-      in_databits_phase0 = in_databits;
-      in_op_phase0       = in_op;
-    end
-
-  // addition
-    reg [WIDTH-1:0] add_result_phase0;
-
-    always @(*) begin
-      add_result_phase0 = a + b;
-    end
-
-  // subtraction
-    reg [WIDTH-1:0] sub_result_phase0;
-
-    always @(*) begin
-      sub_result_phase0 = a - b;
-    end
-
-  // multiplication
-    reg [WIDTH-1:0] mul_result_phase0;
-
-    always @(*) begin
-      mul_result_phase0 = a * b;
-    end
-
-
-  /* PHASE 1: delay the ALU results */
-
-    reg  [DATABITS-1:0]  in_databits_phase1;
-    reg  [1:0]           in_op_phase1;
-
-    reg  [WIDTH-1:0]     add_result_phase1;
-    reg  [WIDTH-1:0]     sub_result_phase1;
-    reg  [WIDTH-1:0]     mul_result_phase1;
-
-    always @(posedge clk) begin
-      in_databits_phase1 <= in_databits_phase0;
-      in_op_phase1       <= in_op_phase0;
-
-      add_result_phase1  <= add_result_phase0;
-      sub_result_phase1  <= sub_result_phase0;
-      mul_result_phase1  <= mul_result_phase0;
-    end
-
-
-  /* PHASE 2: delay the ALU results */
-
-    reg [DATABITS-1:0] in_databits_phase2;
-    reg [1:0]          in_op_phase2;
-
-    reg [WIDTH-1:0]    add_result_phase2;
-    reg [WIDTH-1:0]    sub_result_phase2;
-    reg [WIDTH-1:0]    mul_result_phase2;
-
-    always @(posedge clk) begin
-      in_databits_phase2 <= in_databits_phase1;
-      in_op_phase2       <= in_op_phase1;
-
-      add_result_phase2  <= add_result_phase1;
-      sub_result_phase2  <= sub_result_phase1;
-      mul_result_phase2  <= mul_result_phase1;
-    end
-
-
-  /* PHASE 3: produce the outputs */
-
-    reg [DATABITS-1:0] out_databits_next;
-    reg [1:0]          out_op_next;
-    reg [WIDTH-1:0]    res_next;
-
-    always @(*) begin
-      if (reset)
-        out_op_next = OP_NOP;
-      else
-        out_op_next = in_op_phase2;
-
-      out_databits_next = in_databits_phase2;
-
-      case (in_op_phase2)
-        OP_NOP:
-          res_next = 0;
-
-        OP_ADD:
-          res_next = add_result_phase2;
-
-        OP_SUB:
-          res_next = sub_result_phase2;
-
-        OP_MULT:
-          res_next = mul_result_phase2;
-      endcase
-    end
-
-    always @(posedge clk) begin
-      res          <= res_next;
-      out_op       <= out_op_next;
-      out_databits <= out_databits_next;
-    end
-
-endmodule