VHDL Interview Questions: Simulation Semantics and Code Review

This VHDL interview question tests two things: whether you understand the simulation semantics of VHDL (delta cycles, and signals updating only after every active process has suspended), and whether you can read small architectures and judge if they are legal, behave like a reference design, are synthesisable and follow good practice. The reference design registers a OR b and then registers its inverse, so z equals NOT (a OR b) two clock cycles later. Three of the five variants match it, one is illegal, and one is legal but behaves differently.

Key takeaways

• A signal assigned inside a clocked process keeps its old value until the process suspends, so two assignments in one process still form two register stages.
• Moving an inverter before or after a register does not change cycle-level behaviour; it only changes where the combinational logic sits.
• An if-generate condition must be static (known at elaboration), so it cannot test port values.
• A process with two wait until rising_edge(clk) statements is legal VHDL, but it samples on every second edge and is poor practice for synthesis.

The questions

1. What are the two key concepts in the simulation semantics of VHDL, and how does each concept help VHDL simulation produce waveforms that match the behaviour that we expect?
2. What is the advantage of RTL simulation in comparison to simulation as defined by the VHDL standard?
3. What is the disadvantage of RTL simulation in comparison to simulation as defined by the VHDL standard?
4. For each of the architectures muruku_1 to muruku_4 (and muruku_X), answer the following questions.
   • Is the code legal VHDL?
   • If the code is legal VHDL:
     • Answer whether the signal z has the same behaviour as in the main architecture of sumit.
     • Answer whether the code is synthesisable.
     • If the code is synthesisable, answer whether it adheres to good coding practices.

If the code is not legal, not synthesisable, or does not follow good coding practices, explain why.

Difficulty: Medium

The reference design

The original listing omitted the library clause; it is added here so the entity compiles, because std_logic and rising_edge come from the IEEE std_logic_1164 package.

library ieee;
use ieee.std_logic_1164.all;

entity sumit is
  port (
    a, b, clk : in  std_logic;
    z         : out std_logic
  );
end sumit;

architecture main of sumit is
  signal m : std_logic;
begin
  process (clk)
  begin
    if rising_edge(clk) then
      m <= a or b;
    end if;
  end process;

  process (clk)
  begin
    if rising_edge(clk) then
      z <= not m;
    end if;
  end process;
end main;

Behaviour: on each rising edge, m captures a OR b, and z captures NOT of the previous m. So z at cycle n equals NOT (a OR b) sampled at cycle n−2. Two flip-flops, one OR gate and one inverter between them.

The architectures

Muruku_1

architecture muruku_1 of sumit is
  signal m : std_logic;
begin
  process (clk)
  begin
    if rising_edge(clk) then
      m <= a or b;
      z <= not m;
    end if;
  end process;
end muruku_1;

Muruku_X

architecture muruku_X of sumit is
  signal m, p : std_logic;
begin
  process (clk)
  begin
    if rising_edge(clk) then
      m <= a or b;
    end if;
  end process;

  process (clk)
  begin
    if rising_edge(clk) then
      z <= p;
    end if;
  end process;

  p <= not m;
end muruku_X;

Muruku_2

architecture muruku_2 of sumit is
  signal m, p : std_logic;
begin
  if (a or b) = '1' generate
    m <= '1';
  end generate;
  if (a or b) = '0' generate
    m <= '0';
  end generate;

  process (clk)
  begin
    if rising_edge(clk) then
      p <= m;
    end if;
  end process;

  process (clk)
  begin
    if rising_edge(clk) then
      z <= not p;
    end if;
  end process;
end muruku_2;

Muruku_3

architecture muruku_3 of sumit is
begin
  process
  begin
    wait until rising_edge(clk);
    wait until rising_edge(clk);
    z <= not (a or b);
  end process;
end muruku_3;

Muruku_4

architecture muruku_4 of sumit is
  signal m, p : std_logic;
begin
  process (clk)
  begin
    if rising_edge(clk) then
      m <= a or b;
    end if;
  end process;

  process (clk)
  begin
    if rising_edge(clk) then
      p <= m;
    end if;
  end process;

  z <= not p;
end muruku_4;

Answers

1. The two key concepts of VHDL simulation semantics

Delta cycles. A signal assignment without an explicit delay is scheduled one delta cycle later, an infinitesimal step that does not advance simulated time. Chains of zero-delay logic settle through a series of deltas at the same time point. This makes the result independent of the order in which the simulator happens to run processes, which is what real parallel hardware needs.

Signals update only after all active processes suspend. In each delta cycle, every process triggered by an event runs until it suspends, reading the current signal values; only then are the new values applied, possibly triggering further processes. This is why, inside a clocked process, reading a signal assigned earlier in the same process still gives the old value, so two assignments behave like two flip-flops in series, as real registers do.

2. Advantage of RTL (cycle-based) simulation

Speed. An RTL or cycle-based simulator evaluates each signal once per clock cycle in a fixed order, instead of tracking every event and delta cycle. For synchronous designs that is much faster and uses less memory.

3. Disadvantage of RTL simulation

It only works for a restricted subset: synchronous designs without combinational loops, explicit delays, asynchronous behaviour or code whose result depends on delta ordering. It does not show glitches or intra-cycle timing, and code outside the subset may simulate differently from a standard VHDL simulator, or not at all.

4. The architectures

Architecture	Legal VHDL?	Same z as main?	Synthesisable?	Good practice?
muruku_1	Yes	Yes	Yes	Yes
muruku_X	Yes	Yes	Yes	Yes
muruku_2	No	Not applicable	Not applicable	Not applicable
muruku_3	Yes	No	Tool dependent, often rejected	No
muruku_4	Yes	Yes, at cycle level	Yes	Acceptable, with a caveat

muruku_1: both assignments are in one clocked process. Because m does not change until the process suspends, z gets NOT of the old m, exactly as in main. Two registers, same behaviour. Legal, synthesisable and good practice; some teams even prefer one process per pipeline.

muruku_X: the inverter is moved to a concurrent assignment between the two registers. Logically z = NOT m delayed by one register, which is identical to main. Legal, synthesisable, good practice.

muruku_2: illegal, for two reasons. The condition of an if-generate must be a static expression evaluated at elaboration, but a and b are ports whose values change during simulation. Also, generate statements must have a label (for example g1 : if ... generate). The intent, m following a OR b combinationally, is what a plain concurrent assignment m <= a or b; would express.

muruku_3: legal VHDL. The process waits for two rising edges, then assigns z from a and b sampled at that second edge, and loops. So z updates only on every second edge and has no two-cycle pipeline delay: if a or b changes between those edges, the change may be missed entirely. That is different from main. For synthesis, a process with several wait statements describes an implicit state machine; many tools reject it, and those that accept it require all waits to use the same clock edge. It also has no reset for its hidden state. Poor practice either way.

muruku_4: two registers, with the inverter after the second register. At the clock-cycle level z is NOT (a OR b) two cycles earlier, same as main. Legal and synthesisable. The caveat: z is now driven by combinational logic rather than directly by a flip-flop, so the output timing includes the inverter delay and the output is not glitch-protected by a register. Many coding guidelines prefer registered outputs at block boundaries, which main, muruku_1 and muruku_X provide.

How interviewers probe this question

• They ask you to draw the schematic for each architecture: count the flip-flops and place the gates.
• For muruku_1 they check whether you expect one register or two; the answer depends on knowing signal semantics versus variables.
• They may ask how muruku_1 changes if m is a variable instead of a signal. Then z gets NOT of the new value, one register disappears, and the behaviour no longer matches main.
• For muruku_2 they want the exact rule (static condition, and the missing labels), not just "it looks wrong".

FAQ

Is a delta cycle a real time step?

No. Simulated time does not advance during delta cycles; they only order events at the same time point.

Why does the order of processes not matter in VHDL?

Because all processes in a delta cycle read the same old signal values and their assignments are applied together afterwards.

Would muruku_1 behave the same in Verilog?

Yes, if non-blocking assignments (<=) are used. With blocking assignments (=) the second statement would read the new value, like a VHDL variable.