1

I've a stupid problem and I don' figure out how I can solve it. In my design I'm using a rising edge detector. The problem is that ActiveHDL doesn't simulate it in the way that I expect. The VHDL code is : 

process (clk_i, rst_i)
begin
    if ( rst_i = '1' ) then
        wb_IO_cyc_i_d <= '0';
        wb_IO_cyc_i_edged <= '0';  
    elsif (rising_edge(clk_i) ) then           
        wb_IO_cyc_i_d <= wb_IO_cyc_i;       
        wb_IO_cyc_i_edged <= ( not  wb_IO_cyc_i_d ) and wb_IO_cyc_i;            
    end if;
end process;

The problem is that the simulation is the following enter image description here

The signal wb_IO_cyc_i_d should be delayed of 1 clock cycle but it doesn't. Someone can tell me why?

haster8558
  • 221
  • 3
  • 8
  • 2
    How are you driving `wb_IO_cyc_i` in the simulation? If it's going high just before the clock edge, that's what the simulation would look like. If it's an asynchronous input, you should put it through a 2-stage synchronizer before feeding it to your edge detector. – Dave Tweed Apr 03 '15 at 11:08
  • @DaveTweed the signal `wb_IO_cyc_i` is synchronous. The signals in simulation are the inputs of the entity where there is that process so I don't understand that result. The `wb_IO_cyc_i_d` has to be delayed. Am I wrong ? – haster8558 Apr 03 '15 at 12:22

1 Answers1

2

Like @DaveTweed suggested, it is likely a race condition between clock and data. One thing that will cause this is a delta cycle delay on clock within your chip - such as would occur if you did any assignments to the clock signal in the RTL code. Hence, make sure you did not do anything like the following:

clk_i <= clk ;  -- causes delta cycle delay/skew

If wb_IO_cyc_i comes from the testbench, you may wish to use the pattern:

wait until clk_i = '1' ; 
wb_IO_cyc_i <= '1' after tprop_delay ;  -- where tprop_delay = 20% of your clock cycle.

Start tprop_delay with an estimate of 20% of your clock cycle, then later update it with the actual numbers.

Jim Lewis
  • 894
  • 4
  • 10