Design, simulation and synthesis flow in Verilog

The design flow separates the circuit description from the experiments used to check it. A simulator elaborates module instances and executes events. Synthesis transforms a supported RTL subset into an implementation; implementation tools then place and connect physical resources. A simulation result alone does not prove timing closure or hardware feasibility.

Worked example

The module below is RTL; the separate testbench drives it. With Icarus, compile using iverilog -g2005 -s tb -o example.vvp example.v, then run vvp example.vvp. Simulation checks the adder's value. A synthesis report is needed to inspect the inferred arithmetic.

module add4(input [3:0] a,b, output [4:0] sum);
  assign sum = {1'b0,a} + {1'b0,b};
endmodule
module tb;
  reg [3:0] a,b; wire [4:0] sum;
  add4 dut(.a(a),.b(b),.sum(sum));
  initial begin
    a=15; b=1; #1;
    $display("sum=%d",sum); // 16
    $finish;
  end
endmodule

What to watch for

A #delay in a testbench is a simulation timing instruction, not a request to insert a precise physical delay cell into ordinary RTL.

Try it yourself

Can a correct RTL simulation guarantee that a design meets its target clock frequency?

Answer: No. Static timing analysis with the target library, constraints and implementation is needed; simulation and timing analysis answer different questions.

How to study this topic

Save the example in a .v file and identify its top module before compiling. Separate stimulus and observation from synthesizable RTL. Change one input, width or boundary condition at a time, predict the result, and compare that prediction with simulation. A syntax check does not establish synthesis support or timing closure.