Timing constraints for asynchronous I/O input pin

Hello tmont3, my answer here is not related to timing constraint as your thread title requests, but it may still help. Apologies if you are already doing this. I am also unclear what is meant by "does not reveal the input signal," can you clarify this?

Since you are describing an input to your FPGA which I am assuming can transition asynchronously from your internal clock, are you double-registering this input signal to remove metastability? If not, it is possible that this could be your problem.

If you are not already doing this, one thing you can try is setting a false path timing constraint on the input, then double-registering the input signal and using the 2nd register stage in your internal logic. For example:

Assume the input pin/port is named "MYINPUT"

.sdc file:

set_false_path -from [get_ports {MYINPUT}]

.vhd file:

signal myinput_q : std_logic_vector (1 downto 0);
 
input_demet_P : process (CLK, RST_N) begin
  if (RST_N = '0') then
    myinput_q <= (others => '0');
  elsif (rising_edge(CLK)) then
    myinput_q <= myinput_q(0) & MYINPUT;
  end if;
end process input_demet_P;

...

do something with myinput_q(1) instead of MYINPUT

...

Hi Ccong1,

I appreciate very much your answer, i think that could help me a lot.

With "does not reveal the input signal" i would like to emphasize that, sometimes, while one of the 2 FPGAs w same project and same input signal is able to detect the state change of the input signal (i.e. from 0 to 3.3V) the other is not.

I've check in my design and the input signal goes to a channel select port of a 2in multiplexer. Could this cause the undetection of the signal state change?

During debug, I've seen that the output of the filtering instance is stuck @ 0V even if the input signal stay @ 3.3V for several minutes.

I hope I was more clear in the explanation, any further help will be so much appreciated.

thanks all

"I've check in my design and the input signal goes to a channel select port of a 2in multiplexer. Could this cause the undetection of the signal state change?"

It would depend on how the MUX is coded as well as what the output of the MUX goes to, I guess it is too hard to answer without seeing all of the code. Just a complete guess on my part but it is possible there is a latch, and the wrong value is getting latched and held?

Anyways, I suggest using the double-register of the input as recommended in the first reply. I'm assuming this input logic is registered/clocked at some point, even if the MUX is combinatorial perhaps the output goes to some clocked process. Use the same clock as the input logic runs on for the double-register of the asynchronous input signal. Try that, and let us know if it still does not fix the issue.

architecture test of A_filtering is
 
---------------------------------------------------------------
signal adderPulses :std_logic_vector (31 downto 0):= x"00000000";
signal outputSignal :std_logic;
-----------------------------------------------------------------------------
 
begin
		
		
A_filtering : process(inSignal, clock, resetb)
begin 
 
	
		if (resetb = '0') then
		
			adderPulses <= x"00000000";
			outputSignal  <='0';
			
		elsif (clock'event and clock='1') then
			
			if (inSignal ='0') then 
				if(adderPulses > x"00000000")then
						adderPulses <= adderPulses - '1';
				end if;
			elsif (inSignal ='1') then 			
				if(adderPulses < filter)then
						adderPulses <= adderPulses + '1';
				end if;
			end if;	
			
			if (adderPulses =filter)then
				outputSignal<='1';
			elsif (adderPulses =x"00000000")then	
				outputSignal<='0';
			end if;
				
		end if;	
end process A_filtering ;
 
outSignal <= outputSignal;
 
end test;

Hi Ccong1,

Thanks again for your support. Here is the code I was talking about. Do you think is robust to timing constraint?

I've not copied the entity but, both adderPulses and filter are 32-bit std_logic_vector.

Any council or recommendation would be welcome.

In the meantime i will try implementing a double registered input filtering routine.

talk soon.

Also try removing inSignal from the process sensitivity list, I don't think it belongs there:

A_filtering : process(clock, resetb)

begin