Lesson 07: Modeling Digital Circuits in Verilog

The gates have one scalar output and multiple scalar inputs. The first terminal in the list of gate terminals is an output, and the other terminals are inputs.

The basic syntax for each type of gate with zero delays is as follows:

and | nand | or | nor | xor | xnor [instance name] (out, in1, …, inN); // [] is optional and | is selection

Gate	Description	Syntax
or	N-input OR gate	or GateName(out, in1, in2, in3, ...);
and	N-input AND gate	and GateName(out, in1, in2, in3, ...);
xor	N-input XOR gate	or GateName(out, in1, in2, in3, ...);
nor	N-input NOR gate	nor GateName(out, in1, in2, in3, ...);
nand	N-input NAND gate	nand GateName(out, in1, in2, in3, ...);
xnor	N-input XNOR gate	xnor GateName(out, in1, in2, in3, ...);

The basic syntax for each type of gate with zero delays is as follows:

buf | not [instance name] (out1, out2, …, out2, input);

Gate	Description	Syntax
buf	N-output buffer	buf GateName(out1, out2, ..., in);
not	N-output NOT gate	not GateName(out1, out2, ..., in);

The basic syntax for each type of gate with zero delays is as follows:

bufif0 | bufif1 | notif0 | notif1 [instance name] (outputA, inputB, controlC);

Gate	Description	Syntax
bufif0	Tri-state buffer with active-low control	bufif0 GateName(out, in, ctrl);
bufif1	Tri-state buffer with active-high control	bufif1 GateName(out, in, ctrl);
notif0	Tri-state NOT gate with active-low control	notif0 GateName(out, in, ctrl);
notif1	Tri-state NOT gate with active-high control	notif1 GateName(out, in, ctrl);

The basic syntax for each type of gate with zero delays is as follows:

pullup | pulldown [instance name] (output A);

Using gate-level modeling, write a Verilog description of the 2-to-4 decoder as shown below.

module mux_4to1(in0, in1, in2, in3, s0, s1, out);
    input  in0, in1, in2, in3, s0, s1
    output out;

    wire ns0, ns1;
    wire a0, a1, a2, a3;

    not N0 (ns0, s0);
    not N1 (ns1, s1);
    and G0 (a0, ns0, ns1, in0);
    and G1 (a1, ns0,  s1, in1);
    and G2 (a2,  s0, ns1, in2);
    and G3 (a3,  s0,  s1, in3);
    or  G4 (out, a0, a1, a2, a3);

endmodule

An "initial" statement is executed only once in the simulation.

The syntax for the initial block is as follows:

initial [timing_control] procedural_statement;

initial [timing_control] begin
multiple_procedural_statements;
end

The initial statement is non-synthesizable and is normally used in test benches to generate inputs at the desired time to test the module.

Each "always" statement repeats continuously throughout the simulation run and circuit execution.

The syntax for the always block is as follows:

always @ (<sensitive List>) procedural_statement;

always @ (<sensitive List>) begin
multiple_procedural_statements;
end

The always statement is synthesizable, and the resulting circuit can be combinational or sequential.

Procedural assignments are used in Verilog's always and initial blocks to describe the behavior of a digital system. They allow you to model complex logic and control structures. Procedural assignments can be classified into blocking and non-blocking assignments, each serving a different purpose and having distinct characteristics.

Types of Procedural Assignments:

• Blocking Assignments (=)
• Non-Blocking Assignments (<=)

always @ (sensitivity list) begin
    reg_variable = expression;
    // Other sequential statements
end

module blocking_example ( a, b, y);
    input  a, b;
    output y;

    reg y;

    always @(*) begin
        y = a & b;  // Blocking assignment
    end

endmodule

always @ (posedge clk or posedge rst) begin
    if (rst)
        reg_variable <= reset_value;
    else
        reg_variable <= expression;
    // Other sequential statements
end

module nonblocking_example ( clk, rst, d, q);
    input  clk, rst, d;
    output q;

    reg q;
    always @(posedge clk or posedge rst) begin
        if (rst)
            q <= 1'b0;  // Non-blocking assignment
        else
        q <= d;
    end

endmodule

Common Pitfalls and Best Practices:

• Use Non-Blocking Assignments for Sequential Logic: Always use non-blocking assignments (<=) for registers in sequential logic to avoid race conditions and ensure proper timing.
• Use Blocking Assignments for Combinational Logic: Use blocking assignments (=) for combinational logic to ensure correct evaluation order within the always block.
• Avoid Mixing Assignments: Do not mix blocking and non-blocking assignments for the same variable within the same always block. This can lead to unpredictable behavior.
• Complete Sensitivity Lists: Ensure that the sensitivity list in combinational always blocks includes all relevant signals to avoid simulation mismatches.
• Test Thoroughly: Use test benches to simulate and verify your design's behavior. This helps catch procedural assignment issues early in the design process.

Define the Module:

module d_flip_flop ( clk, rst, d, q);
    input  clk, rst, d;
    output q;

    reg q;

    // Always block for sequential logic
    always @(posedge clk or posedge rst) begin
        if (rst)
            q <= 1'b0; // Reset condition
        else
            q <= d; // On clock edge, q takes the value of d
    end

endmodule

Explanation

• Module Definition: The d_flip_flop module has inputs clk, rst, and d, and an output q.
• Register Declaration: q is declared as reg because it stores the value.
• Always Block: Triggered on the rising edge of clk or the rising edge of rst.
• Procedural Statements: if-else statement checks the reset condition. If rst is high, q is set to 0. Otherwise, q is assigned the value of d on the clock edge.

Define the Module:

module counter ( clk, nrst, en, count);
    input  clk, rst, en;
    output [3:0] count;

    reg [3:0] count

    // Always block for sequential logic
    always @(posedge clk or negedge rst) begin
        if (!rst)
            count <= 4'b0000;  // Reset count to 0
        else if (en)
            count <= count + 1;  // Increment count if enabled
    end

endmodule

Explanation

• Module Definition: The counter module has inputs clk, nrst, and en, and an output count.
• Register Declaration: count is a 4-bit register.
• Always Block: Triggered on the rising edge of clk or the falling edge of nrst.
• Procedural Statements: if-else statement checks the reset condition and enables the signal. If nrst is low, the count is reset. If en is high, count is incremented.

Define the Module

module comparator ( a, b, eq);
    input  [7:0] a;
    input  [7:0] b;
    output       eq;

    reg eq;
    // Always block for combinational logic
    always @(*) begin
        if (a == b)
            eq = 1'b1;
        else
            eq = 1'b0;
    end

endmodule

Explanation:

• Module Definition: The comparator module has inputs a and b, and an output eq.
• Register Declaration: eq is declared as reg because it is assigned within an always block.
• Always Block: Triggered whenever there is a change in a or b (combinational logic).
• Procedural Statements: if-else statement checks if a is equal to b and sets eq accordingly.

Define the Module:

module traffic_light_controller ( clk, nrst, lights);
  input        clk, nrst;
  output [1:0] lights;

    reg [1:0] lights;

    // State encoding
    typedef enum reg [1:0] {S_RED, S_GREEN, S_YELLOW} state_t;
    state_t curr_state, next_state;

    // State transition logic
    always @(posedge clk or negedge rst) begin
        if (!rst)
            curr_state<= RED;
        else
            curr_state<= next_state;
    end

    // Next state logic
    always @(*) begin
        case (state)
            S_RED:
                next_state = GREEN;
            S_GREEN:
                next_state = YELLOW;
            S_YELLOW:
                next_state = RED;
            default:
                next_state = RED;
        endcase
    end

    // Output logic
    always @(*) begin
        case (curr_state)
            S_RED:
                lights = 2'b00;
            S_GREEN:
                lights = 2'b01;
            S_YELLOW:
                lights = 2'b10;
            default:
                lights = 2'b00;
    endcase
  end

endmodule

Example Testbench for the Traffic Light Controller:

`timescale 1ns/1ps
module traffic_light_controller_tb;
    reg clk;
    reg nrst;
    wire [1:0] lights;

    // Instantiate the traffic_light_controller
    traffic_light_controller UUT (
        .clk(clk),
        .nrst(nrst),
        .lights(lights)
    );

    // Clock generation
    initial begin
        clk = 0;
        forever #5 clk = ~clk;  // 10 time units clock period
    end

    // Test sequence
    initial begin
        // Initialize signals
        nrst = 0;
        #10 nrst = 1;  // Release reset after 10 time units

        // Observe the output
        #100;  // Run simulation for 100 time units
        $finish;
    end

    // Monitor output
    initial begin
        $monitor("Time: %0d, lights: %b", $time, lights);
    end

endmodule

Explanation:

• Module Definition: The traffic_light_controller module has inputs clk and nrst, and an output lights.
• State Encoding: Uses an enumerated type state_t for state encoding.
• Registers: state and next_state are declared as reg.
• Always Block (State Transition): Triggered on the rising edge of clk or the falling edge of nrst. It updates the current state based on the next state.
• Always Block (Next State Logic): Determines the next state based on the current state.
• Always Block (Output Logic): Determines the output lights based on the current state.

Gate-Level Modeling

Characteristics:

• Lowest Level of Abstraction: Describes the circuit using basic logic gates (AND, OR, NOT, etc.) and their interconnections.
• Explicit Gate Instantiation: Uses predefined primitives or user-defined gate modules.
• Close to Hardware: Provides a detailed representation of the actual hardware implementation.
• Use Case: Detailed hardware optimization.

Advantages:

• Accuracy: Provides a precise representation of the hardware.
• Control: Offers fine-grained control over the design, which is useful for optimization.

Disadvantages:

• Complexity: It can become very complex and difficult to manage for large designs.
• Low Productivity: Time-consuming and error-prone, as it requires detailed specifications of every gate and connection.

Example:

module and_gate_example (a. b. y);
    input  a, b;,
    output y;

  and U1 (y, a, b); // Gate-level instantiation of an AND gate

endmodule

Dataflow Modeling

Characteristics:

• Higher Level of Abstraction: Describes the circuit regarding data flow using continuous assignments.
• Expression-Based: Uses expressions and operators to describe how data is transformed and flows through the circuit.
• Concurrent Execution: Statements are evaluated concurrently, as in hardware.
• Use Case: Medium-sized combinational logic circuits.

Advantages:

• Readability: Easier to understand and write than gate-level modeling.
• Efficiency: Suitable for describing combinational logic succinctly and clearly.

Disadvantages:

• Limited Control: Less detailed control over the implementation compared to gate-level modeling.
• Simulation vs. Synthesis: Some dataflow constructs may behave differently in simulation and synthesis.

Example:

module adder_4bit (a, b, sum, carry_out);
    input  [3:0] a;
    input  [3:0] b;
    output [3:0] sum;
    output carry_out;

    assign {carry_out, sum} = a + b; // Dataflow modeling of a 4-bit adder

endmodule

Behavioral Modeling

Characteristics:

• Highest Level of Abstraction: Describes the circuit behavior algorithmically using procedural statements.
• Use of always Blocks: Utilizes always blocks to describe sequential and combinational logic.
• Close to Algorithmic Descriptions: Complex behavior can be easily described in high-level programming languages.
• Use Case: Complex control structures, state machines.

Advantages:

• Productivity: Fast and easy to write, especially for complex logic and control structures.
• Flexibility: Allows high-level constructs like loops, conditionals, and case statements.

Disadvantages:

• Synthesis Challenges: Some constructs may not be directly synthesizable or result in inefficient hardware.
• Less Hardware Insight: Provides less insight into the actual hardware implementation, potentially leading to suboptimal designs.

Example:

module counter (clk, rst, count);
    input  clk, rst;
    output [3:0] count;

    reg[3:0] count;

    always @(posedge clk or posedge rst) begin
        if (rst)
            count <= 4'b0000;
        else
            count <= count + 1;
    end

endmodule