Capturing pulse - generated pulse can’t be received

[EDA_hg81]

capturing pulse in clock domain crossing

In my design, I have used two state machines.

First state machine is running under 4MHZ, which generate a 500us pulse.

Second state machine is running under 16MHZ, which receive this 500us pulse.

My code for checking the pulse is as follow:

process ( refclk ) 
	begin
	if (rising_edge(refclk)) then
	    fstart_reg1  <= cformat;
	    fstart_reg2  <= fstart_reg1;
	    if(  fstart_reg1  = ‘1’ and    fstart_reg2 = ‘0’ ) then
                      …………………………….
                end if;
        end if;   
end process;

But why that generated pulse can’t be received?

Thanks.

Added after 1 hours 5 minutes:

I am really sick of Altera FPGA.

The initial state machine is not constant.

 

[pev]

Re: Capturing Pulse

Fist of all metastability could be your problem. The recive filpflops could be getting stuck in a meta stable state. However if this is your problem then it should work sometimes just not all the time.

To remove metastability problems (well reduce them down to somthing like 0.000001% of happening) doulbe register your logic before you use it like below

process ( refclk )
   variable temp  : std_logic_vector(1 downto 0);
   begin
   if (rising_edge(refclk)) then
       fstart_reg1  <= temp(0);
       fstart_reg2  <= fstart_reg1;
       if(  fstart_reg1  = ‘1’ and    fstart_reg2 = ‘0’ ) then
                      …………………………….
                end if;
        temp(temp'high downto 1) :=  cformat & temp(temp'high-1 downto 0);
        end if;   
end process;

Ignorming metasability what you have written here should work.

I sugest using the same clock for both as a stame machines just as a sanity check.


Chipscopeor equivalent should be great for this.

 

[EDA_hg81]

Re: Capturing Pulse

Please explain how this is going to work?

my input is processed with two stages flip-flop already...:|

 

[FvM]

Re: Capturing Pulse

I am really sick of @ltera FPGA.

A german saying goes "The bad craftsman is complaining first about his tool"

Actually, I don't see anything with your problem related to A.ltera or any other vendor's FPGA. Furthermore, the shown code is just O.K., there's no significant likelihood of metastable events in this case. Thus, I rather expect some trivial design problem in the code, that's not shown in the post.

 

[EDA_hg81]

Re: Capturing Pulse

Yes. You are right.

What I want is to use signal inside 4MHZ domain to trigger a module inside 16MHZ domain.

I use Altera signal tap to check signals, nothing happened.

If I used hand shake like this:

    getformat         <= '1';
		               if ( ackformat     = '1' ) then
                                                   getformat     <= '0';
                                                  format_state  <= idle; 
                                               end if;

getformat is the trigger signal.
ackformat is the acknowledge signal inside module.
I have to keep getformat high until get ackformat high.

by this way everything can work.

But I would like to check the incoming pulse as:

process ( refclk ) 
   begin 
   if (rising_edge(refclk)) then 
       fstart_reg1  <= cformat; 
       fstart_reg2  <= fstart_reg1; 
       if(  fstart_reg1  = ‘1’ and    fstart_reg2 = ‘0’ ) then 
                      ……………………………. 
                end if; 
        end if;    
end process;

4MHZ clock and 16MHZ clock generated from the same 27MHZ clock source

 

[FvM]

Capturing Pulse

I use @ltera signal tap to check signals, nothing happened.

It's not understandable from your post, what should happen but doesn't. You may want to show a minimal example design to make this understandable.

Also some details should be clarified. Assuming, you are using a Cyclone II FPGA, it doesn't provide a 4 MHz PLL output frequency-

 

[EDA_hg81]

Re: Capturing Pulse

I know where the problem is:

When the acknowledge signal (ackformat) inside 16MHZ domain try to trigger module inside 4MHZ, the pulse of acknowledge signal (ackformat) is too narrow and can't be captured by 4MHZ domain.

Thank you anyway.

 

[pev]

Re: Capturing Pulse

If there is no phase relationship between the clock domains then metastability is always a problem that needs to be dealt with. Or else your code will all of sudden mysterious stop working until you reprogram it.

One way to deal with metastability is to make sure that all signals are double flip folped before you use them. As in code the signal crossing the clock domain is used after it went though only one filpflop (this is not recormended).

I've attahced some code I created a long time ago. It's good for getting slow changing parralell data (with respect to both clocks) from one clock domain to another and guarantee that it got there. Might be worth a look if your going to do more stuff like this.

What the code does is:
- users metastable registers.
- Look for the rising edge to determine when the data is valid
- Passes back an acknolge signal to the receive side (usefull to know when you can send the next one).
It's very simple and very slow.

Applogise for some reason I was required to add .pdf onto the end (just delete .pdf)

If the data is moving quickly just use an async fifo.

Just trying to be helpful let me know if you dissagree with anything here or can do in a better way.

 

[FvM]

Re: Capturing Pulse

I know where the problem is:

When the acknowledge signal (ackformat) inside 16MHZ domain try to trigger module inside 4MHZ, the pulse of acknowledge signal (ackformat) is too narrow and can't be captured by 4MHZ domain.

My post wasn't related to the handshaking solution. Generally, a handshaking can be designed in a way, that it doesn't depend on particular clock periods. So I don't see an issue, that can't be solved.

I simply mentioned, that I don't understand, why the "one-way" communication based on synchronous edge detection shouldn't work. In my opinion, the shown code should reliably detect any asynchronous input pulse with a pulse duration (and respective idle time) of at least one clock period. Although there's a finite likelihood of metastable events, it's rather unlikely that ever see it.

 

[EDA_hg81]

Re: Capturing Pulse

I have fixed my errors.

Sorry for misleading you, I thought it was metastability problem but at last I found out it was hand-shake problem.

Thank you again and have a good weekend.