+ Post New Thread
Results 1 to 6 of 6
  1. #1
    Member level 2
    Points: 1,076, Level: 7

    Join Date
    May 2011
    Location
    Germany
    Posts
    46
    Helped
    1 / 1
    Points
    1,076
    Level
    7

    Delay between state signal and output signal

    Hi,

    I have a design with several states implemented using case statements. In one of the states I assign 2 signals, the state signal and an output signal. After one clock cycle, the output signal(counter) is changed while the state signal requires one more clock cycle to change, so the same state is accessed again instead of the new state. What could be causing this delay?

    A part of the code is as follows:

    Code:
    case state is 
    
    when setup => 
    
    if data_ready = '1' then
       state <= start;
       counter <= "001";
    end if;
    
    
    when start =>


    Thanks.
    Last edited by am85; 24th October 2012 at 09:49.

    •   AltAdvertisement

        
       

  2. #2
    Advanced Member level 5
    Points: 37,734, Level: 47
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,842
    Helped
    2011 / 2011
    Points
    37,734
    Level
    47

    Re: Delay between state signal and output signal

    please post more code.



    •   AltAdvertisement

        
       

  3. #3
    Member level 2
    Points: 1,076, Level: 7

    Join Date
    May 2011
    Location
    Germany
    Posts
    46
    Helped
    1 / 1
    Points
    1,076
    Level
    7

    Re: Delay between state signal and output signal

    I solved the problem. The data_ready signal in the if condition is coming from a faster clock domain, so I put it first into a register before the if condition then it worked fine. But I am not sure why this was happening because this signal is just a flag set to high til the slow clock domain reads it and set it back to low. So why would it affect only the state signal and not the output signal ?!



    •   AltAdvertisement

        
       

  4. #4
    Advanced Member level 5
    Points: 37,734, Level: 47
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,842
    Helped
    2011 / 2011
    Points
    37,734
    Level
    47

    Re: Delay between state signal and output signal

    reading a signal in an unrelated clock domain will always be dangerous. you risk getting metastable values. you should always at least double register the crossing.

    but again, without code, its difficult to see what you're talking about.



  5. #5
    Super Moderator
    Points: 259,210, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    45,256
    Helped
    13766 / 13766
    Points
    259,210
    Level
    100

    Re: Delay between state signal and output signal

    reading a signal in an unrelated clock domain will always be dangerous. you risk getting metastable values. you should always at least double register the crossing.
    Besides causing metastable states, there's a more likely case, that the input event is just sampled at different clock edges by different register, caused by routing delay skew. To quantify the probability, we can assume up to ns delay skew and ps (or sub ps) range metastability windows.

    As a special point, each bit of counter will be sampled separately, so combinations of the previous state and "001" can occur as well.



    •   AltAdvertisement

        
       

  6. #6
    Member level 2
    Points: 1,076, Level: 7

    Join Date
    May 2011
    Location
    Germany
    Posts
    46
    Helped
    1 / 1
    Points
    1,076
    Level
    7

    Re: Delay between state signal and output signal

    Yes it is causing me lots of problems. The fast clock domain(100MHz) is performing fast calculations on ADC data. Then it sends the results to the SPI module(slow clock domain 1MHz) to be sent to a µC.

    The faster module detects the rising edge of the flag (results are ready) and then sets data_ready to SPI high. When the SPI reads the data, it sends back to the faster module SPI_done signal to set data_ready to low again. This ensures that SPI has detected the flag and read the data.
    Code:
    		if BUSY = '1' and delayed_BUSY = '0' then
      			data_ready <= '1';                                        
      		end if;                                                            
      		                                                                   
      		if SPI_done = '1' then                      
      			data_ready <= '0';                                        
      		end if;
    The SPI sends the 3-byte data, one byte at a time as follows:

    Code:
    	
    case state is 
    
    when setup => 
    
             if data_ready = '1' and start_counter = "000" then	
    		data_out<= x"41";
    		bit_counter <= 7;
    		state  <= WRITE ;
    		return_state=SETUP;
    		start_counter <= "001";		
    		SPI_done <='1';
    	end if;
    
    	if start_counter = "001" then	
    		data_out<= data_max_filter(7 downto 0);
    		bit_counter <= 7;
    		state  <= WRITE ;
    		return_state<= SETUP;
    		start_counter <= "010";	
    		SPI_done <='0';
    	end if;
    
    	if start_counter = "010" then 
    		data_out<= data_max_filter(15 downto 8);
    		state  <= WRITE ;
    		return_state<= INIT;
    		start_counter <= "000";
    	end if;
    
    when WRITE =>
    		if (bit_counter = 0) then
    			state <= return_state;
    		else
    			bit_counter <= bit_counter - 1;
    			data_out <= data_out(6 downto 0) & '1';
    		end if;
    So what happened is instead of going after the first if condition to state WRITE, it stayed in state SETUP for one more clock cycle and accessed the second if condition because counter is now "001" then it went to state WRITE. So sometimes the first byte was missing in the µC.



--[[ ]]--