Testbench Fundamentals

1. Engineering intuition — a harness, not a circuit

Stop thinking "hardware" for a moment. A testbench's job is to put your design through its paces: feed it inputs, advance the clock, and confirm the outputs are what the specification demands. Nothing in a testbench needs to become gates — it only needs to run in the simulator — so it is free to behave like a small test program: wait for a time, apply a vector, check an answer, print a result. That freedom is the whole point. The testbench sits around the design under test, connected only to it, with no outside ports because in simulation the testbench is the entire world the DUT sees.

2. Formal explanation — the anatomy of a testbench

library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all;
 
entity tb_counter is                       -- NO PORTS: a testbench connects to nothing outside
end entity;
 
architecture sim of tb_counter is
  -- internal signals that wire to the DUT
  signal clk   : std_logic := '0';
  signal rst_n : std_logic := '0';
  signal q     : std_logic_vector(7 downto 0);
begin
  -- instantiate the DESIGN UNDER TEST (conventionally labelled uut/dut)
  uut : entity work.counter
    port map ( clk => clk, rst_n => rst_n, q => q );
 
  -- separate processes: clock, reset, stimulus/checking (next lessons detail each)
  clk_gen : process begin clk <= not clk; wait for 5 ns; end process;       -- 100 MHz
  stim    : process begin
    rst_n <= '0'; wait for 20 ns; rst_n <= '1';   -- release reset
    wait for 100 ns;
    assert q /= x"00" report "counter did not advance" severity error;       -- a check
    wait;                                          -- stop this process
  end process;
end architecture;

A testbench is a portless entity plus an architecture that: declares signals, instantiates the DUT (uut/dut), and runs processes for clock, reset, and stimulus/checking. Being non-synthesizable, it uses the full language — wait, assert/report, textio, access/protected — none of which is allowed in RTL.

3. Production usage — separation of concerns inside the harness

-- A well-structured testbench separates its jobs into distinct processes:
--   clk_gen   : free-running clock                    (14.3)
--   rst_gen   : reset assert/release sequence         (14.3)
--   stim_proc : apply stimulus / drive DUT inputs     (14.2)
--   check_proc: compare DUT outputs to expected       (14.4 self-checking)
-- Plus a way to END the simulation deterministically:
sim_end : process begin
  wait for 10 us;
  report "simulation complete" severity note;
  std.env.stop;            -- or 'finish' — stop the run cleanly (VHDL-2008)
end process;

What hardware does this become? None — and that is the defining property. The testbench is only a simulation construct; it generates no netlist. Its value is organizational: by splitting clock, reset, stimulus, and checking into separate processes (and ending the run deterministically), the harness stays readable and reusable as the DUT grows. Each subsequent lesson in this module fills in one of these processes; this lesson is the frame they hang on.

4. Structural interpretation — the harness around the DUT

5. Why this is structural, not timing

A testbench's fundamentals are about structure — a portless entity, a DUT instance, and the arrangement of clock/reset/stimulus/check processes — so the harness diagram above is the right picture, not a waveform. The testbench certainly produces waveforms (the stimulus and DUT response, the subject of later lessons), but its defining nature is organizational: how the harness is built and what role each process plays. That framing is a design-time property of the verification code, independent of any particular signal trace.

6. Debugging example — the testbench that would not elaborate (or synthesize)

Expected: a simulation that runs and never stops trying to be hardware. Observed: an elaboration error about unconnected/extra ports on the top, the simulation never ending, or a synthesis tool choking on the testbench. Root cause: the testbench entity was given ports (it must have none — it is the top), the run had no termination so it spun forever, or the testbench was mistakenly fed to synthesis (it uses non-synthesizable constructs by design). Fix: declare the testbench entity with no ports, end the run deterministically (std.env.stop/finish or by stopping all stimulus), and mark testbench files as simulation-only so they never enter synthesis. Engineering takeaway: a testbench is a portless, non-synthesizable top that must terminate — give it no ports, a clean stop, and keep it out of the synthesis flow.

-- BUG: a testbench with ports — it is the top, it connects to nothing.
-- entity tb is port ( clk : in std_logic ); end entity;   -- wrong
-- FIX: no ports.
entity tb is end entity;

7. Common mistakes & what to watch for

• Giving the testbench ports. The TB is the top and connects to nothing external; declare entity tb is end; with no ports.
• No deterministic end. Provide a stop (std.env.stop/finish, or cease all stimulus) so the run terminates.
• Feeding the testbench to synthesis. Testbenches use non-synthesizable constructs by design; keep them simulation-only.
• One giant process. Separate clock, reset, stimulus, and checking into distinct processes for clarity and reuse.
• Forgetting to initialize signals. Give TB-driven signals sane initial values (e.g. clk := '0') so the run starts from a known state.

8. Engineering insight & continuity

A testbench is the non-synthesizable harness around your design: a portless top that instantiates the DUT, wires it to internal signals, and runs separate clock, reset, stimulus, and check processes — free to use the full language because it only ever simulates. Establishing this frame is the foundation of all verification. With the skeleton in place, the next lessons fill in its processes, beginning with Stimulus Generation — how to drive the DUT's inputs with directed sequences, vectors, and patterns that exercise its behavior.