DEV Community: Semiwave Technologies

Verilog Overview: How to Write Verilog Code

Semiwave Technologies — Tue, 24 Jun 2025 07:02:33 +0000

How to Write Verilog Code: A Beginner’s Guide for RTL Design Engineers

Hey there! If you’re diving into the world of ASIC design or just brushing up on your hardware description language (HDL) skills, Verilog is likely your go-to tool. As an RTL design engineer, I’ve spent countless hours crafting Verilog code for everything from simple counters to complex state machines. In this post, I’ll walk you through the essentials of writing clean, functional Verilog code, with practical tips and snippets to get you started. Whether you’re a newbie or a seasoned verification engineer looking to understand the RTL side better, this guide’s got you covered!

Why Verilog?

Verilog is one of the most popular HDLs used in ASIC and FPGA design. It’s concise, widely supported, and strikes a balance between abstraction and control. Here’s why it’s a staple in VLSI:

Industry Standard: Used in countless EDA tools like Synopsys, Cadence, and Questa.
Simulation-Friendly: Perfect for both design and verification workflows.
Scalable: Works for simple modules or massive SoCs.

Let’s jump into the nuts and bolts of writing Verilog code.

Verilog Basics: Structure of a Module

Every Verilog design starts with a module, the building block of your hardware. Think of it as a function in software, but it describes physical hardware behavior. Here’s the basic syntax:

module module_name (
    input wire clk,    // Clock input
    input wire reset,  // Reset input
    output reg out     // Output
);
    // Your logic goes here
endmodule

Module Declaration: Defines the module name and its ports (inputs/outputs).
Port Types: Use wire for combinational signals and reg for sequential (clocked) outputs.
endmodule: Closes the module. No semicolons here!

Pro Tip: Always name your module descriptively (e.g., counter_4bit instead of mod1). It saves headaches during debugging!

Writing Your First Verilog Module: A 4-Bit Counter

Let’s create a simple 4-bit counter that increments on every clock cycle and resets to zero when reset is high. This is a classic example for RTL beginners.

module counter_4bit (
    input wire clk,    // Clock input
    input wire reset,  // Synchronous reset
    output reg [3:0] count  // 4-bit counter output
);
    always @(posedge clk) begin
        if (reset)
            count <= 4'b0000;  // Reset to 0
        else
            count <= count + 1;  // Increment count
    end
endmodule

Breaking It Down

Inputs/Outputs: clk and reset are inputs, count is a 4-bit output ([3:0] means 4 bits, from 0 to 15).
always @(posedge clk): This block triggers on the rising edge of the clock, making it synchronous.
Non-Blocking Assignments (<=): Used in sequential logic to ensure proper register updates.
Reset Logic: When reset is high, count is set to 0; otherwise, it increments.

Verification Note: If you’re a verification engineer, you’d write a testbench to simulate this. Want a testbench example? Let me know in the comments!

Best Practices for Clean Verilog Code

Writing Verilog is more than just getting it to work—it’s about making it readable, synthesizable, and maintainable. Here are my go-to tips:

Use Meaningful Names: clk over c, data_out over d.
Comment Liberally: Explain complex logic. Future you will thank you.

  // Increment counter only if enable is high
  if (enable) count <= count + 1;

Stick to Non-Blocking for Sequential Logic: Use <= in always @(posedge clk) blocks to avoid race conditions.
Avoid Latches: Ensure all paths in combinational always blocks assign every output to prevent unintended latches.

  always @(*) begin
      if (sel)
          out = in1;  // Assign for all cases
      else
          out = in2;
  end

Keep It Modular: Break complex designs into smaller modules for reusability and easier debugging.

Common Pitfalls to Avoid

Blocking vs. Non-Blocking: Using = instead of <= in sequential logic can cause simulation-synthesis mismatches.
Missing Sensitivity Lists: For combinational logic, use @(*) to automatically include all inputs.
Overcomplicating Logic: Simplify your design before coding. Sketch state machines or logic flows on paper first.

Testing Your Code

As an RTL designer, you’ll work closely with verification engineers. A basic testbench for our counter might look like this:

module tb_counter_4bit;
    reg clk, reset;
    wire [3:0] count;

    counter_4bit uut (
        .clk(clk),
        .reset(reset),
        .count(count)
    );

    initial begin
        clk = 0;
        reset = 1;
        #10 reset = 0;  // Release reset after 10ns
        #100 $finish;   // End simulation
    end

    always #5 clk = ~clk;  // 100MHz clock (10ns period)
endmodule

This testbench generates a clock, applies a reset, and lets the counter run. Run it in your favorite simulator (e.g., ModelSim) to see the counter increment!

Why This Matters for VLSI Enthusiasts

Writing clean Verilog code isn’t just about functionality—it’s about ensuring your design is synthesizable, testable, and scalable. As ASIC designs grow more complex, good coding practices save time in synthesis, place-and-route, and verification. Plus, they make you a hero in the eyes of your verification team!

What’s Next?

Try It Yourself: Code a 4-bit counter in your favorite EDA tool and simulate it.
Explore Further: Add an enable signal or make the counter up/down configurable.
Deep Dive: Check out my next post on “Writing Testbenches for Verilog” for verification tips!

Got questions or want to share your Verilog tips? Drop them in the comments below! Let’s keep the VLSI community buzzing.

Verilog Overview: HDL Abstraction Levels

Semiwave Technologies — Mon, 09 Jun 2025 05:59:38 +0000

Verilog is a Hardware Description Language (HDL) used to model digital systems at multiple levels of abstraction. The name Verilog combines "verification" and "logic", reflecting its origins as a tool for simulating and verifying digital designs before fabrication.

Why Verilog Coding Styles Matter

Verilog’s flexibility lets you describe hardware at different abstraction levels, from low-level gates to high-level algorithms. Each coding style offers a unique way to model your design, impacting readability, synthesis, and verification. Here’s a quick overview before we dive into the details:

Structural: Describes hardware by connecting components (like a schematic).
Gate-Level: Models logic using primitive gates (AND, OR, etc.).
Dataflow: Uses continuous assignments to describe signal flow.
Behavioral: High-level, algorithmic description of functionality.

1. Structural Coding Style

The structural style is like drawing a schematic: you define and connect modules explicitly, specifying the hierarchy and interconnections. It’s low-level and closely mirrors the physical hardware.

Example: 2-to-1 MUX (Structural)

Submodule: AND gate equivalent

module and_gate (
    input wire a, b,
    output wire y
);
    assign y = a & b;
endmodule

Submodule: OR gate equivalent

module or_gate (
    input wire a, b,
    output wire y
);
    assign y = a | b;
endmodule

Submodule: NOT gate equivalent

module not_gate (
    input wire a,
    output wire y
);
    assign y = ~a;
endmodule

Top-level 2-to-1 MUX

module mux_2to1_structural (
    input wire a, b, sel,
    output wire y
);
    wire sel_n, a_and_sel, b_and_sel_n;

    not_gate u1 (.a(sel), .y(sel_n));               // Invert sel
    and_gate u2 (.a(a), .b(sel), .y(a_and_sel));    // a * sel
    and_gate u3 (.a(b), .b(sel_n), .y(b_and_sel_n)); // b * ~sel
    or_gate  u4 (.a(a_and_sel), .b(b_and_sel_n), .y(y)); // Combine

endmodule

Key Features

Hierarchy: Uses instantiated modules (and_gate, or_gate, etc.).
Explicit Connections: Signals are wired using .port(signal) syntax.
Use Case: Ideal for low-level designs or when you need to map directly to specific hardware components.

Pros:

Precise control over the design hierarchy.
Closely matches physical implementation.

Cons:

Verbose and time-consuming for complex designs.
Hard to modify or scale.

2. Gate-Level Coding Style

The gate-level style is a subset of structural, using Verilog’s built-in gate primitives (e.g., and, or, not). It’s often used for netlist-level descriptions post-synthesis or for low-level optimization.

Example: 2-to-1 MUX (Gate-Level)

module mux_2to1_gatelevel (
    input wire a, b, sel,
    output wire y
);
    wire sel_n, a_and_sel, b_and_sel_n;

    not (sel_n, sel);                   // Invert sel
    and (a_and_sel, a, sel);            // a * sel
    and (b_and_sel_n, b, sel_n);        // b * ~sel
    or  (y, a_and_sel, b_and_sel_n);    // Combine

endmodule

Key Features

Primitives: Uses Verilog’s built-in gates (and, or, not, etc.).
Netlist-Like: Mimics the output of synthesis tools.
Use Case: Post-synthesis netlists or low-level gate modeling.

Pros:

Direct mapping to standard cell libraries.
Useful for gate-level simulation or timing analysis.

Cons:

Even more verbose than structural.
Not practical for high-level design.

3. Data Flow Coding Style

Example: 2-to-1 MUX (Dataflow)

module mux_2to1_dataflow (
    input wire a, b, sel,
    output wire y
);
    assign y = sel ? a : b;  // Conditional operator for MUX
endmodule

Key Features

Continuous Assignments: Uses assign for combinational logic.
Concise: Expresses logic equations directly.
Use Case: Ideal for combinational logic like adders, MUXes, or decoders.

Pros:

Short and readable.
Naturally synthesizable for combinational logic.

Cons:

Limited to combinational logic (no sequential behavior).
Can get messy for complex expressions.

Tip: Use dataflow for simple combinational blocks or when you want to express logic as equations. Avoid overcomplicating assign statements.

4. Behavioral Coding Style

The behavioral style is the most abstract, using always blocks to describe functionality algorithmically. It’s like writing software but still synthesizable if done right.

Example: 2-to-1 MUX (Behavioral)

module mux_2to1_behavioral (
    input wire a, b, sel,
    output reg y
);
    always @(*) begin
        if (sel)
            y = a;
        else
            y = b;
    end
endmodule

Key Features

Always Blocks: Uses always @(*) for combinational or always @(posedge clk) for sequential logic.
Algorithmic: Focuses on what the hardware does, not how it’s built.
Use Case: High-level designs, state machines, or complex sequential logic.

Pros:

Easy to write and modify.
Great for rapid prototyping or complex logic.

Cons:

Risk of unsynthesizable code if not careful (e.g., using delays or unsynthesizable constructs).
May lead to inefficient synthesis if overly abstract.

Comparing the Styles: 2-to-1 MUX Summary

Style	Lines of Code	Abstraction	Use Case	Synthesizable?
Structural	20+	Low	Hierarchical designs, IPs	Yes
Gate-Level	10-15	Very Low	Netlists, gate simulation	Yes
Dataflow	5-7	Medium	Combinational logic	Yes
Behavioral	7-10	High	Complex logic, state machines	Yes (if proper)

When to Use Each Style

Structural: When integrating modules or modeling specific hardware (e.g., connecting IP blocks).
Gate-Level: For post-synthesis netlists or low-level gate optimization.
Dataflow: For simple combinational logic (e.g., arithmetic, MUXes, decoders).
Behavioral: For complex sequential logic, state machines, or quick prototyping.