Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Delay between state signal and output signal

Status
Not open for further replies.
A

am85

Member level 2
Joined
May 30, 2011
Messages
46
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,288
Location
Germany
Activity points
1,661
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:

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 ?!
 

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.
 

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.
Click to expand...
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.
 

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.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top