ISIM signal assignment delay

Question

I expected signal 'delay' to be one clock cycle late wrt to the entities' port 'input', but ISIM shows no phase shift. I thought there is always is a delay between signal assignment and actual value (when the process suspends), but I don't seee it here.

Why is this?

Code:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity test is
Port ( clk:   in  std_logic;
          input: in  std_logic
        );
end test;

architecture Behavioral of test is
    signal delay: std_logic:= '0';

    begin   
    proc1: process(clk)
    begin
        if(rising_edge(clk)) then
            delay <= input;                -- ISIM shows no delay between them
        end if;             
    end process;

end Behavioral;

Testbench:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;


ENTITY tb_testbench_test IS
END tb_testbench_test;

ARCHITECTURE behavior OF tb_testbench_test IS 

-- Component Declaration for the Unit Under Test (UUT) 
COMPONENT test
PORT(
          clk:   in  std_logic;
          input: in  std_logic
    );
END COMPONENT;


--Inputs
signal clk: std_logic := '0';
signal input: std_logic := '0';

-- Clock period definitions
constant clk_period : time := 10 ns;

BEGIN

-- Instantiate the Unit Under Test (UUT)
uut: test PORT MAP (
      clk => clk,
      input => input
    );

-- Clock process definitions
clk_process :process
begin
    clk <= '0';
    wait for clk_period/2;
    clk <= '1';
    wait for clk_period/2;
end process;


-- Stimulus process
stim_proc: process
begin       
  wait for clk_period * 9.5;    

    input <= '1';
    wait for clk_period;
    input <= '0';

  wait;
end process;

end;

Answer 1

Your test bench describes clk and input going high at the same time. You then have a process in your entity that is looking for a rising_edge of clk . Therefore, when your process runs, and asks 'was there a rising edge of the clock?', if the answer to this is 'yes', ie the clock signal had just become '1' , then the state of the input must also be '1' , because the two signals changed at the same time. The delay signal then takes this new input , giving the result you see.

A more realistic scenario would be a change of the input being caused by a rising edge of clk . You can easily simulate this by modifying your stimulus process:

stim_proc: process
begin       
  wait for clk_period * 9.5;    
  wait until clk = '1';  -- Sit here until we have seen a rising edge of `clk`
  input <= '1'; -- This assignment now happens *after* the clock edge
  wait until clk = '1';
  input <= '0';

  wait;
end process;

Answer 2

The delay between a signal assignment and the appearance of its value is ... one delta cycle. And the time taken by one delta cycle is 0 fS.

What your testbench represents is a race condition whereby you present the input signal and the clock signal at exactly the same time - ie in the same delta cycle.

In real hardware, what would happen would be a coin-toss whether the input was seen by this clock edge or the next, or would be some intermediate value when the clock edge happened, raising the possibility of metastable operation. The simulation has accidentally alerted you to the possibility of such mis-operation.

If you delay the data signal by even one delta cycle (as is guaranteed to happen if it was the output from a previous clocked process) such as a concurrent signal assignment outside the process, you will eliminate the timing hazard and see the delay you expect.