VHDL Processes & Concurrent Statements Interview Prep

Frequently asked questions

What is a VHDL process, and how does it relate to concurrent statements outside of one?

A process is a block of sequential (top-to-bottom, one-statement-after-another) code inside an inherently concurrent architecture -- every process in an architecture, and every concurrent signal assignment outside a process, executes concurrently with respect to every other one, the same way every always block and every continuous assign in Verilog runs concurrently. Inside a process, statements execute in the familiar sequential, imperative order; outside a process, a concurrent signal assignment (sig <= a and b;) is really syntactic sugar for an implicit single-statement process that is sensitive to every signal on its right-hand side. This is why VHDL is described as having exactly one true concurrency model -- concurrent statements at the architecture level -- with the process construct as the mechanism for writing sequential logic within that concurrent framework.

What is a sensitivity list, and what happens if you get it wrong?

A process's sensitivity list -- process (a, b, clk) -- declares which signals, when they change, cause the process to wake up and re-execute from the top. Get it wrong in the combinational direction (omit a signal the process actually reads) and simulation will show stale, incorrect combinational output whenever only the omitted signal changes, because the process simply does not re-run -- exactly the RTL-simulation-versus-synthesis-mismatch failure mode Verilog's always @(*) exists to prevent by inferring the sensitivity list automatically. VHDL has an equivalent automatic mechanism, process (all), standardized in VHDL-2008, which infers sensitivity to every signal read in the process body and is now the recommended default for combinational processes specifically to eliminate this class of bug. Get the sensitivity list wrong in a clocked process (adding a data signal alongside the clock) and you risk describing something that does not correctly model a real flip-flop.

Why is inferring a latch in a VHDL combinational process the same root cause as in Verilog, and how do you avoid it?

A combinational process infers a latch under exactly the same condition Verilog does: if some execution path through the process does not assign a value to an output signal, synthesis must generate a level-sensitive latch to hold the old value on that path, because a combinational output cannot simply have "no new value." The fix is identical in spirit to Verilog: give every output a default assignment at the top of the process before any conditional logic, and make every if have a matching else and every case statement exhaustive (VHDL requires an explicit others choice covering the remaining values, similar in spirit to Verilog's default). Candidates fluent in VHDL should be able to name this as the same underlying incomplete-assignment problem Verilog has, just triggered by if/case rather than always block syntax.

How does a clocked (sequential) process in VHDL compare structurally to a Verilog always @(posedge clk) block?

A clocked process typically has clk in its sensitivity list and an if rising_edge(clk) then ... end if; guard around the body -- the rising_edge function is the VHDL-standard way to detect a clock edge, preferred over the older clk'event and clk = '1' idiom because it is unambiguous about which transition it detects and handles unknown ('X') values more predictably during reset. Inside that guard, signal assignments describe register updates exactly like Verilog's non-blocking assignments inside always @(posedge clk): every assignment is scheduled, not immediate, and all of them conceptually apply together at the clock edge. The structural parallel is strong enough that an engineer fluent in one can usually read the other's clocked-process/always-block intent quickly -- the differences that matter are VHDL's scheduled-signal-assignment semantics (see /topics/vhdl-signals-and-variables) and its stricter typing, not the high-level shape of the construct.

What is the difference between a concurrent signal assignment and a process, and when should you use each?

A concurrent signal assignment written directly in an architecture body (sig <= a when sel = '1' else b;) is compact and appropriate for simple combinational logic that maps naturally to a single expression -- a mux, a simple boolean function, a direct wire-through. A process is appropriate once the logic needs sequential, imperative reasoning: multiple conditional branches that are easier to express as nested if/case rather than nested when/else, a chain of dependent intermediate computations best expressed with variables, or -- necessarily, since concurrent signal assignments have no equivalent -- any clocked/sequential logic, because a real register's "hold value until clock edge" behavior can only be expressed inside a process's clocked, sensitivity-list-gated structure. Neither is "more correct" in general; the choice follows from whether the logic is naturally a single expression or needs multi-step sequential reasoning.

How should I practice VHDL process fluency for an interview?

Write the same small combinational function -- a 4-to-1 mux with a 2-bit select -- three ways: as a single concurrent signal assignment using a selected signal assignment (with select ... when), as a combinational process using an explicit sensitivity list, and as a combinational process using process (all). Then write a clocked process for a simple register with synchronous reset, using rising_edge(clk) and an if rst = '1' then ... else ... end if; structure. Being able to produce all four fluently, and to explain why process (all) is now the safer default for combinational logic (it cannot omit a signal the way a hand-written sensitivity list can), demonstrates exactly the practical VHDL fluency interviewers are checking for.

Related topics