UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
5,842 Views
Registered: ‎01-22-2015

set_input_delay clarification

Jump to solution

In a previous post here, Avrum said,

 

"..since the [async signal is] coming from an input pin, you can technically skip the set_false_path, as long as you

don't use a set_input_delay on the port. Without a set_input_delay, the path will not be timed. The only

disadvantage of this is that this will show up as a warning in the check_timing report, since it sees an

unconstrained path (so, to avoid this, use a set_input_delay with a meaningless value and a set_false_path)."

 

The image below shows an async input to the FPGA called BITEST1.  I define PATH1 to be the path from the BITEST1

port to the FF called meta_2ff_reg.  Are the following comments correct?

 

1) If BITEST1 is asynchronous with all clocks used in the FPGA, then synchronizer SYNC1_2FF is needed to mitigate

metastability.


2) The set_input_delay command could be used to characterize paths that are external to the FPGA and are connected

to BITEST1.


3) If the set_input_delay command is not used then timing analysis will not be done on PATH1.


4) If timing analysis is not done on PATH1 then implementation is free to make PATH1 any length.


5) If the set_input_delay command is used together with  set_false_path -from [get_ports BITEST1]  then timing analysis will not

be done on PATH1.     

async_port2.jpg

0 Kudos
1 Solution

Accepted Solutions
10,715 Views
Registered: ‎01-22-2015

Re: set_input_delay clarification

Jump to solution

Mark:

Let’s first review some concepts. Xilinx document UG906 says, “…timing paths are formed by a pair of sequential elements [also called cells] controlled by the same clock, or by two different clocks”.  In apparent contradiction to this timing path definition, we would properly elaborate your defined timing path, PATH1, as follows:

 

–from [get_ports BITEST1] –to [get_cells tgn/ems1_tst_s/meta_2ff_reg]

 

Despite the explicit use of [get_ports BITEST1], the BITEST1 port is technically not the start of PATH1.  Instead, PATH1 starts external to the FPGA at a cell whose relation to BITEST1 is described by the set_input_delay command.  In other words, the PATH1 elaboration will make sense to the timing analysis engine only if it is accompanied by a set_input_delay command for BITEST1.

 

I think that the above discussion has answered your questions 2) and 3). In regards to 4) and 5), if you omit the set_input_delay command for BITEST1 or you use the set_false_path timing exception on PATH1 then timing analysis will not be done on PATH1 and implementation is free to make PATH1 any length.  If BITEST1 is a 1-bit asynchronous input to the FPGA, then “any length” for PATH1 is probably OK.   However, if BITEST1 is part of a multi-bit asynchronous input to the FPGA, then allowing “any length” for PATH1 may cause problems.  These problems are similar to those that occur for a multi-bit clock-domain-crossing (see message 4 of this post for details). 

 

Finally, the answer to your question 1) is yes - a synchronizer is needed for asynchronous inputs to the FPGA.  However, the type of synchronizer needed will depend upon whether the inputs are isolated 1-bit signals or are grouped as multi-bit signals.  For isolated 1-bit signals, the conventional two-flip-flop synchronizer (your ems1_tst_s is an example) is probably sufficient.  For multi-bit signals you will need a different type of synchronizer (again, see this post).

1 Reply
10,716 Views
Registered: ‎01-22-2015

Re: set_input_delay clarification

Jump to solution

Mark:

Let’s first review some concepts. Xilinx document UG906 says, “…timing paths are formed by a pair of sequential elements [also called cells] controlled by the same clock, or by two different clocks”.  In apparent contradiction to this timing path definition, we would properly elaborate your defined timing path, PATH1, as follows:

 

–from [get_ports BITEST1] –to [get_cells tgn/ems1_tst_s/meta_2ff_reg]

 

Despite the explicit use of [get_ports BITEST1], the BITEST1 port is technically not the start of PATH1.  Instead, PATH1 starts external to the FPGA at a cell whose relation to BITEST1 is described by the set_input_delay command.  In other words, the PATH1 elaboration will make sense to the timing analysis engine only if it is accompanied by a set_input_delay command for BITEST1.

 

I think that the above discussion has answered your questions 2) and 3). In regards to 4) and 5), if you omit the set_input_delay command for BITEST1 or you use the set_false_path timing exception on PATH1 then timing analysis will not be done on PATH1 and implementation is free to make PATH1 any length.  If BITEST1 is a 1-bit asynchronous input to the FPGA, then “any length” for PATH1 is probably OK.   However, if BITEST1 is part of a multi-bit asynchronous input to the FPGA, then allowing “any length” for PATH1 may cause problems.  These problems are similar to those that occur for a multi-bit clock-domain-crossing (see message 4 of this post for details). 

 

Finally, the answer to your question 1) is yes - a synchronizer is needed for asynchronous inputs to the FPGA.  However, the type of synchronizer needed will depend upon whether the inputs are isolated 1-bit signals or are grouped as multi-bit signals.  For isolated 1-bit signals, the conventional two-flip-flop synchronizer (your ems1_tst_s is an example) is probably sufficient.  For multi-bit signals you will need a different type of synchronizer (again, see this post).