Timing constraints for asynchronous I/O input pin

[tmont3]

What is the right way to constraint an FPGA input pin coming from a analog stage whose last stage is a Schmidt trigger, thus converting the signal to "digital domain"?

I'm asking this because some times happens that, having two FPGAs with same project and same input source, one of the two does not reveal the input signal. (that is not due to high state of the input signal too low)

Thanks all

[CCong1]

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

...

[tmont3]

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

[CCong1]

"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.

[tmont3]

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.

[CCong1]

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

A_filtering : process(clock, resetb)

begin