Test Bench - Verilog PDF
Document Details
Tags
Summary
A Verilog testbench is a simulation environment used for verifying the functionality and correctness of digital designs described in Verilog. It allows digital designers to simulate various design conditions and behaviors before physical hardware implementation.
Full Transcript
TEST BENCH WE SIM (Simulate) IT HERE UNTIL COOKED 001 What Is A TestBench A Verilog testbench is a simulation environment used to verify the functionality and correctness of a digital design described in the Verilog Hardware Description Language. The purpos...
TEST BENCH WE SIM (Simulate) IT HERE UNTIL COOKED 001 What Is A TestBench A Verilog testbench is a simulation environment used to verify the functionality and correctness of a digital design described in the Verilog Hardware Description Language. The purpose of a testbench is to provide a way to simulate the behaviour of the design under various conditions, inputs, and scenarios before actually fabricating the physical hardware. It allows designer to catch bugs, validate functional, and optimize design without the cost and time associated with physical prototyping. 002 Whoa! Too much… Have faith all of this will make sense… 003 Typical TestBench 01 Stimulus Design Under 02 Test (DUT) Output 03 Checker 004 02 Design Under Test (DTU) DUT or Design Under Test is the Verilog module or design that you want to test. It could be a simple component like adder or a more complex design like a microprocessor 005 Number Representation Syntax: ’ : Optional,Defines the number of Bits : The base of the number {b->Binary, o->Octal, d->Decimal, h->Hexadecimal} : The actual numeric value Examples: 4’b1010 //4 bit binary number 6’o34 //6 bit octal number 006 Value Levels Values Conditions in Hardware Circuits 0 Logical Zero, false condition 1 Logical One, true condition x Unknown value z High impedance, floating state 007 NETS ❏ NETS represent the interconnections between the hardware elements. ❏ They require a driver continuously. ❏ They are 1-Bit value by default unless declared as a vector. ❏ Default value of net is `Z`. ❏ NET is not a keyword, but represents a class of data types as wire, and other wire data types. ❏ Example: wire a; wire a,d=1’b0; 008 Registers ❏ REGISTERS represent data storage elements. ❏ A register in verilog is a variable that can hold value till another value is placed onto them. ❏ Unlike `NET` a `REGISTER` don’t need a driver. ❏ Declared using the keyword reg. ❏ Default Data type is x. ❏ Example: reg d; 009 VECTORS ❏ Both Nets and Regs can be declared as vectors ❏ [high # : low #] ❏ [low # : high #] ❏ The leftmost number in the square bracket is always the ❏ MSB (Most Significant Bit). ❏ Example: ❏ Wire[7:0]b —------> EQ to bus (down to 0) 0010 SYSTEM TASKS Verilog language has inbuilt routines to do certain tasks like displaying data, monitoring signals, starting and stopping simulations etc., these are called System Tasks. SYNTAX: $ Some commonly used systems. 0011 Initial & Always A set of Verilog statements are usually executed sequentially in a simulation. These statements are placed inside a procedural block. There are mainly two types of procedural blocks in Verilog. — initial and always 0012 initial An initial block is not synthesizable and hence cannot be converted into a hardware schematic with digital elements. Hence initial block do not serve much purpose than to be used in simulations. These blocks are primarily used to initialize variables and drive design ports with specific values. Explanation: module behave; Here, a will get value 2’b10 at This is an initial reg[1:0] a,b; time 0 ns. block which starts at time 0 ns. initial a=2’b10; endmodule 0013 always An always block is one of the procedural block in Verilog. Statements inside an always block are executed sequentially. The always block is executed at some particular event. The event is defined by a sensitivity list. Syntax: always @ (event) [statement] Always @ (event) begin [multiple statements] end 0014 Sensitivity list A sensitivity list is the expression that defines when the always block should be executed and is specified after the @ operator within parentheses. This list may contain either one or a group of signal whose value change will execute the always block. // Execute always block whenever value of “a” or “b” change always @ (a or b) begin [statements] end 0015 Block Statements There are ways to group a set of statements together that are syntactically equivalent to a single statement and are known as block statements. There are two kinds of block statements: sequential and parallel. Sequential: Statements are wrapped using begin and end keywords and will be executed sequentially in the given order, one after the other. Delay values are treated relative to the time of execution of the previous statement. After all the statements within the block are executed control may be passed elsewhere. 0016 Time Delay Delays may be inserted into always and initial blocks to cause the simulator to let “simulation time” advance. Syntax: – #n // delay of n time units Example: always @(...) begin a = 1’b0; #5; // 5-unit delay a = 1’b1; #3; // 3-unit delay a = (c|d)^(e|f); // a = 0 here end 0017 Concurrent Operations Think of verilog modules as operating on independent circuits (remember it describes hardware) always begin always begin a = (b&c) //1 f(gh); // 1 #5; // 5-Unit delay #7; //7-unit delay a = a; // 0 f = ~f; //0 end end 0018 $exit and $finish $finish The $finish task terminates the simulator and passes control back to the host operating system. This task is typically used when the simulation completes successfully or when an unrecoverable error occurs. You can provide an optional argument to print diagnostic messages related to the simulation termination. Example: module FinishExample; initial begin //... Some simulation code … $finish(2); // Terminate simulation and print message with level 2 end endmodule 0019 $exit The $exit task waits for all program blocks to complete, then implicitly calls $finish. This task is useful when you want to ensure that all simulation processes have finished before exiting the simulation. Example: module ExitExample; initial begin //... Some simulation code... $exit; // Wait for all program blocks to complete, then call $finish end endmodule 0020 Some more $(s) $display: print the immediate values § 21.2.1 The display and write tasks $strobe: print the values at the end of the current timestep § 21.2.2 Strobed monitoring $monitor: print the values at the end of the current timestep if any values changed. $monitor can only be called once; sequential call will override the previous. § 21.2.3 Continuous monitoring 0021 Code will run just fine without $finish and $exit And Gate (Test bench Code) // DESIGN BLOCK module andgate(c,a,b); output c; input a,b; assign #1 c=a&b; endmodule 0023 // TESTBENCH module andgate_tb; reg a,b; wire c; andgate a1(c,a,b); // Module Instantiation initial begin $display($time); // 0ns a=1'b0; b=1'b0; //0ns #10 $display($time," c=%b a=%b b=%b",c,a,b); //10ns a=1'b0; b=1'b1;// 10ns #20 $display($time,"c=%b a=%b b=%b",c,a,b); //20 ns a=1'b1; b=1'b0;// 20 ns 0024 #30 $display($time,"c=%b a=%b b=%b",c,a,b); //30 ns a=1'b1; b=1'b1; //30 ns #10 $display($time,"c=%b a=%b b=%b",c,a,b);//40 ns $ finish end endmodule 0025 Half Adder A B Carry Sum 0 0 0 0 0 1 0 1 1 0 0 1 1 1 1 0 Half Adder (Test bench Code) // DESIGN BLOCK module half_adder(input a,b, output sum, carry); assign sum = a^b; //XOR operation for sum assign carry = a&b; //AND operation for sum endmodule 0027 //TESTBENCH module half_adder_tb; reg a, b; wire sum, carry; half_adder ha1 (a, b, sum, carry); initial begin // Test case 1: 0 + 0 a = 0; b = 0; #10; // Wait for 10 time units // Test case 2: 0 + 1 a = 0; b = 1; 0028 #10; // Test case 3: 1 + 0 a = 1; b = 0; #10; // Test case 4: 1 + 1 a = 1; b = 1; #10; $finish; end // Monitor block to display results always @ (a, b, sum, carry) begin $display("a = %b, b = %b, sum = %b, carry = %b", a, b, sum, carry); end Endmodule 0029 Learning Verilog And Coding Playing quiz games and winning goodies