General

1
General

• Our objectives are
• Design a logic module.
• Verify the modules correctness.
• In this Presentation
• Achieving the goal description (Slide 2).
• Achieving the goal example (Slide 6).
• Manual Instructions (Slide 19).
• This presentation is not a substitute for
  learning the
• Verilog language or the Sugar syntax.
• For more information, refer to the Verilog
  handbook
• and the FoCs user manual.
• Advisory barrak_manos_at_yahoo.com

2
Achieving the goal

• Stage 1 - DUT (Design Under Test)
• Design an abstract module.
• Implement the module in Verilog.
• This module would typically have both input and
  output.

3
Achieving the goal (cont.)

• Stage 2 - Checker
• Define a set of rules (to be asserted over the
  DUT) in plain English.
• Phrase the set of rules in Sugar syntax.
• Generate a Checker from the Sugar set of rules,
  using FoCs.
• The Checker is also a Verilog module. This module
  has only input (no output).

4
Achieving the goal (cont.)

• Stage 3 - Test Bench
• The Test Bench is another Verilog module. This
  module should have no input or output.
• It includes an instance of the DUT and an
  instance of the Checker, and passes initial input
  to the DUT.
• It links between the DUT and the Checker by
  passing the same input, along with the DUTs
  output, as input to the Checker.
• It also passes the Checker a reset-bit and a
  clock-bit, by which the operation of the Checker
  is determined (discussed later).

5
The Big Picture
Initial input to the DUT
DUT
Checker
Reset bit
Clock bit
Checker generated messages
Test Bench Module
6
Example An Adder

• Design an abstract module of an adder that takes
  two 2-bit operands as input and returns their sum
  as a 3-bit output.

7
DUT- Abstract Design
Op 1, Bit 1
Op 2, Bit 1
o
Rem 3 Bits
Sum 3 Bits
Op 1, Bit 2
Op 2, Bit 2
Bit 1
Bit 2
Rem 3 Bits
Sum 3 Bits
Bit 3
o
o
Sum 3 Bits
8
DUT Implementation

• 2) Implement the module in Verilog
• module Sum3Bits(bit1,bit2,bit3,sum)
• input bit1,bit2,bit3
• output sum
• assign sum
• (( bit1 bit2 bit3 )
• (bit1 bit2 bit3 )
• (bit1 bit2 bit3 )
• ( bit1 bit2 bit3 ))
• endmodule

Sum 3 Bits
9
DUT Implementation (cont.)

• module Rem3Bits(bit1,bit2,bit3,rem)
• input bit1,bit2,bit3
• output rem
• assign rem
• (( bit1 bit2 )
• ( bit1 bit3 )
• ( bit2 bit3 ))
• endmodule

Rem 3 Bits
10
DUT Implementation (cont.)

• module Adder(Op1,Op2,Sum)
• input21 Op1,Op2
• wire21 Rem
• output31 Sum
• Sum3Bits Sum1(Op11,Op21,0,Sum1)
• Rem3Bits Rem1(Op11,Op21,0,Rem1)
• Sum3Bits Sum2(Op12,Op22,Rem1,Sum2)
• Rem3Bits Rem2(Op12,Op22,Rem1,Rem2)
• Sum3Bits Sum3(0,0,Rem2,Sum3)
• endmodule

11
Checker Set of Rules

• Define a set of rules (to be asserted over the
  DUT) in plain English
• Rule 1 (and only) The output is always greater
  than or equal to the input.
• Phrase the set of rules in Sugar syntax
• vunit Rule1
• assert "Output is greater than or equal to
  input"
• always OutgtIn1 OutgtIn2

12
Checker - Implementation

• 3) Generate a Checker from the Sugar set of
  rules, using FoCs
• FoCs Generates a relatively large Verilog module
  from the relatively small set of rules written in
  Sugar, thus saving us a lot of work.
• This module is too big to display here and
  doesnt really concern us anyway, as long as it
  works

13
Test Bench - Implementation

• Implement a module with no input or output.
• Declare an instance of the DUT and an instance of
  the Checker.
• The DUT should be passed registers with input
  values and wires to fill with its output
  values.
• The Checker should be passed two 1-bit registers
  that represent a reset bit and a clock bit, along
  with the DUTs input and output values (all of
  these as input).

14
Test Bench Implementation (cont.)

• 5) Initialize the DUTs input in an initial
  block and change them in an always block.
• 6) Initialize the reset bit and the clock bit in
  an initial block and change the clock bit in an
  always block.
• The Checkers performs checking operations every
• time the clock bit it receives from the Test
  Bench
• changes from 0 to 1. If the reset bit it receives
  from
• the Test Bench is 1, it resets all its internal
• registers. Otherwise, it performs checking
• operations over the other input (the DUTs input
• and output, passed by the Test Bench).

15
Test Bench Implementation (cont.)

• include "Adder.txt" //Include the DUT file
• include "Checker.txt" //Include the Checker
  file
• module Test //A module with no input or output
• reg reset,clock //1-bit registers (reset and
  clock)
• reg21 A,B //Input of the DUT
• wire31 C //Output of the DUT
• Adder Device(A,B,C) //DUT instance
• Checker Monitor(reset,clock,C,A,B) //Checker
  instance

16
Test Bench Implementation (cont.)

• Initial
• begin Reset //The Checker will receive
• reset1 //reset1 until clock changes
• _at_(posedge clock) //from 0 to 1 for the first
  time,
• reset0 //and then reset0 forever
• end
• initial
• begin InitClock
• clock0
• end

17
Test Bench Implementation (cont.)

• Initial //Initialize the DUTs input and display
• begin InitTest //the DUTs input and output
• A0
• B0
• display(" Time Reg A Reg B Reg C")
• monitor("d d d d",time,A,B,C)
• end
• Always //Flip the clocks value at every cycle
• begin RunClock
• 1
• clock!clock
• end

18
Test Bench Implementation (cont.)

• always
• begin RunTest
• _at_(posedge clock) //Wait until clock changes
• AA1 //from 0 to 1 before changing
• if (A0) BB1 //the DUTs input
• end
• Initial
• begin StopTest
• 16 //Terminate operation
• stop //after 16 cycles
• end
• endmodule

19
Manual Instructions

• Implementing a module in Verilog
• Use a simple editor (i.e. NotePad) to write a
  module. If more modules are required, you can
  write them in the same file, or in separate files
  (if module A uses module B than in file A.txt
  write include "B.txt).
• In order to compile the file A.txt into a
  viable module in the file A. and ensure that
  there are no parse errors, run the command line
  iverilog -o A. A.txt

20
Manual Instructions (cont.)

• Generating a Checker with FoCs
• 1) FoCs runs on Linux OS, so if you dont have
  one at home, connect to the Linux server (you
  need to install CygWin)
• Double-click CygWin.
• In the CygWin terminal write startx.
• Write ssh X your_username_at_ginger.haifa.ac.il.
• Enter your password.

21
Manual Instructions (cont.)

• Generating a Checker with FoCs (cont.)
• 2) In order to create the rules file, use one of
  Linux editors. If you dont know any, the
  following provides a (very) brief tutorial for
  the VI Editor
• Edit a file vi file_name
• Switch to writing-mode i
• Switch back to command-mode Esc
• Save and quit (only from command-mode) wq
• Quit without save q (if you made changes,
  q!)

22
Manual Instructions (cont.)

• Generating a Checker with FoCs (cont.)
• 3) Generate the Checker from the rules file
  youve created, using FoCs
• Run FoCs. In Ginger, FoCs is located at
  /opt/focs/focs2 (as well as /opt/focs/focs1), so
  if running the command line focs doesnt work
  then run the command line /opt/focs/focs2/focs.
• Double-click Settings. Double-click Main.
• In the Rule File text box enter the name of the
  rules file youve created in the previous step.
• Double-click Clock / Reset. Choose names for
  the clock and reset registers (the Checker module
  will have two 1-bit registers with these names).

23
Manual Instructions (cont.)

• Generating a Checker with FoCs (cont.)
• 5) Double-click Close in order to close the
  Settings menu.
• Double-click Refresh.
• Choose a rule from the left part of the viewer.
• Double-click Generate. If your rules file is
  error-free then FoCs will now generate a file of
  the same name ending with .v. It is a text file
  of the Checker module (written in Verilog
  syntax). Its contents should not concern you
  youre only required to include it in the Test
  Bench module (see step 3).

24
Manual Instructions (cont.)

• Generating a Checker with FoCs (cont.)
• If your Verilog compiler (i.e. Icarus) runs on
  Windows OS, you will need to transfer the files
  youve created with FoCs from Linux to Windows.
  One way to do it is with FTP
• Run the command line ftp ginger.haifa.ac.il.
• Enter your username and password.
• Run the command line get file_name.
• The file should be transferred to the path
• from which you invoked the FTP.

25
Manual Instructions (cont.)

• Building the Test Bench
• As with the DUT, use a simple editor (i.e.
  NotePad) to write the Test Bench. Remember to
  include the DUT and the Checker files at the
  beginning.
• Compile the Test Bench file in the same way as
  with the DUT file (see step 1).
• In order to run it, run the command line vvp
  file_name (where file_name is the name of the
  compilation output file).