Signal vs Variable — Interview Deep Dive

1. Engineering intuition — same letters, different number of registers

The trap in this question is that signals and variables look interchangeable — both hold a value, both get assigned — so a weak answer treats the difference as cosmetic (<= vs :=). The strong answer sees that the choice changes the hardware. A variable's value is available immediately to the next line, so a chain of variable computations in one clocked pass collapses into a single cycle of combinational logic between two registers. A signal's value is deferred, so feeding one computation's signal output into the next means the second sees it only next cycle — a register stage appears. The interviewer is checking whether you can look at two similar processes and say how many registers each infers. That register-count consequence is the whole point.

2. Formal explanation — the rule and its hardware

-- RULE:
--   VARIABLE (:=) : updates IMMEDIATELY, in order; LOCAL to the process. Later lines see the new value.
--   SIGNAL   (<=) : SCHEDULES the update (applied after suspend, next delta); SHARED across the design.
--                   Later lines in the SAME pass see the OLD value.
 
-- HARDWARE in a clocked process:
process (clk)
    variable t : integer;
begin
    if rising_edge(clk) then
        t := a + b;        -- immediate
        q <= t * c;        -- uses NEW t THIS cycle -> add and multiply are ONE combinational stage -> 1 register (q)
    end if;
end process;
 
-- Same shape with a SIGNAL intermediate:
process (clk) begin
    if rising_edge(clk) then
        s <= a + b;        -- scheduled
        q <= s * c;        -- uses OLD s (previous cycle) -> add is registered, then multiply -> 2 register stages
    end if;
end process;

The variable version computes (a+b)*c in one cycle (one register, q); the signal version registers a+b into s first, so q uses last cycle's s — two register stages and an extra cycle of latency. Same arithmetic, different register count — that is the hardware consequence.

3. Production usage — read-after-write, swap, last-assignment

-- READ-AFTER-WRITE: variable sees the new value; signal sees the old value (same pass).
v := v + 1;  w := v;     -- w gets the INCREMENTED v
s <= s_next; r <= s;     -- r gets the OLD s this pass
 
-- SWAP in one edge works BECAUSE signals defer (each reads the other's pre-edge value):
if rising_edge(clk) then a <= b; b <= a; end if;   -- a and b exchange cleanly
 
-- LAST-ASSIGNMENT-WINS:
--   signal:   x <= '0'; x <= '1';   -> x becomes '1' (last scheduled value applies)
--   variable: y := 0;  y := 1;      -> y is 1 after both run (ordered, immediate)
 
-- PRACTICAL GUIDANCE:
--   variable -> immediate intra-cycle combine (collapse multi-step math into one cycle), scratch values.
--   signal   -> state held across cycles, interconnect between processes, intended register stages.

What hardware does this become? It depends entirely on the choice, which is why the question matters. The read-after-write and swap behaviors fall straight out of immediate-vs-deferred semantics; the swap idiom in particular only works because signals defer (both reads sample pre-edge values). The practical rule for the interview answer: use a variable when you want to combine several steps within one cycle (and for local scratch), and a signal for state held across cycles, for interconnect, and where you intend a register stage. Stating this — and why — is what separates a strong answer from "one uses :=."

4. Structural interpretation — variable path (1 cycle) vs signal path (2 cycles)

5. Simulation interpretation — immediate combine vs one-cycle lag

6. Debugging example — the unexpected extra pipeline stage

Expected: a combinational result registered once. Observed: the output is one cycle late (or the pipeline is one stage deeper than intended), throwing off downstream timing or a self-checking testbench's expected cycle. Root cause: a signal was used for an intermediate value that was meant to combine within the same cycle; because the signal defers, it inserted an unintended register stage, so the dependent computation used last cycle's value. Fix: use a variable for an intermediate that must be consumed immediately in the same clocked pass (collapsing the steps into one cycle); reserve signals for values that should be registered/state. Engineering takeaway: in a clocked process, a signal intermediate adds a register stage while a variable intermediate does not — choose by whether you want the value this cycle (variable) or next cycle as state (signal); the wrong choice silently changes latency and register count.

-- BUG: signal intermediate defers -> q is one cycle later than intended (extra stage).
-- s <= a + b;  q <= s * c;   -- q uses OLD s
-- FIX: variable intermediate combines in one cycle.
-- t := a + b;  q <= t * c;   -- q = (a+b)*c this cycle

7. Common mistakes & what to watch for

• Calling it cosmetic. <= vs := changes the hardware: signals defer (can add a register stage), variables combine immediately — say the register-count consequence.
• Signal intermediate where you meant a combine. A deferred signal adds an unintended pipeline stage; use a variable for same-cycle intermediates.
• Variable where you meant state. A variable is local and immediate; cross-process state and intended registers need signals.
• Forgetting read-after-write. Variable reads see the new value; signal reads in the same pass see the old — and the swap idiom relies on that deferral.
• Stopping at the rule. Finish the answer with the hardware (register count/latency) and a failure mode — that is what interviewers grade.

8. Engineering insight & continuity

Signal vs variable is the interview classic because the rule (immediate/local variable vs deferred/shared signal) has a concrete hardware consequence: in a clocked process a variable intermediate combines steps into one cycle, while a signal intermediate defers and adds a register stage — so near-identical code yields a different register count and latency. Answer it as rule → hardware → failure and you stand out. The next most-tested topic is when a process accidentally creates storage you didn't ask for — the next lesson, Latch Inference — Interview Deep Dive, worked through in the same structure.