cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
joe306
Scholar
Scholar
231 Views
Registered: ‎12-07-2018

Understanding False Paths Constraint

Jump to solution

Hello, quick question for the forum members. Would one set LED indicator signals or test outputs signals as False Paths? Is that generally done? Signals that you don't care about timing.

 

Thank you

Joe

0 Kudos
Reply
1 Solution

Accepted Solutions
avrumw
Guide
Guide
214 Views
Registered: ‎01-23-2009

To add to markg@prosensing.com 's response, what he is suggesting is completely correct from the static timing point of view. If an output port has no set_output_delay, then it is not part of a path - a path can only end at a clocked object; in the case of an output port, the "clocked object" is the one "created" by the set_output_delay - it "creates" a clocked object clocked by the clock specified in the -clock option and with a delay specified by the value in the command. So without a set_output_delay, the cells and nets between the final flip-flop (technically the clock pin of that flip-flop) and the output port are not part of a path, and hence will not result in a timing report.

However, the tools have a specific check for unconstrained output ports - the "check_timing" command (which is done as part of the normal flow) will flag these "unconstrained output ports" (which are either a warning or a critical warning - I don't remember which). If these are asynchronous outputs like LEDs, then you can ignore the warning. But many designed are uncomfortable ignoring warnings, so they want to fix them.

To do this, you do two things:

  • Put a set_output_delay on the port
    • You can use any legal clock and any delay value for the command
    • set_output_delay -clock <any_legal_clock> <any_value> [get_ports <name_of_output_port>]
  • Set the path (and it is now a path since it is constrained) as false
    • set_false_path -to [get_ports <name_of_output_port>]

This, then satisfies the check_timing command and tells the tool that there are no timing requirements on the path.

Avrum

View solution in original post

4 Replies
221 Views
Registered: ‎01-22-2015

Hi Joe,

The set_false_path timing exception is placed on a signal path.

So, for an LED, there will be a signal in the FPGA (lets called it LED1_CTRL) that travels the following path:

  1. leaves a flipflop, LED1_CTRL_reg
  2. travels through an IO pin/port (lets called it LED1)
  3. and ends up at the LED.  

Unless you have placed an a set_output_delay constraint on the port, LED1, then the path described above is automatically not analyzed by timing analysis - and there is no need to use a set_false_path constraint.

Other test outputs can be handled like the LED example I have shown.  That is, if you have not placed a set_output_delay constraint on the IO port then you don't need to use a set_false_path constraint.

However, make sure that your test outputs travel from a flipflop to the IO port - and not from a LUT to the IO port.  This is called "registering outputs" of the FPGA and is needed to prevent sending signal glitches out of the FPGA.

Cheers,
Mark

avrumw
Guide
Guide
215 Views
Registered: ‎01-23-2009

To add to markg@prosensing.com 's response, what he is suggesting is completely correct from the static timing point of view. If an output port has no set_output_delay, then it is not part of a path - a path can only end at a clocked object; in the case of an output port, the "clocked object" is the one "created" by the set_output_delay - it "creates" a clocked object clocked by the clock specified in the -clock option and with a delay specified by the value in the command. So without a set_output_delay, the cells and nets between the final flip-flop (technically the clock pin of that flip-flop) and the output port are not part of a path, and hence will not result in a timing report.

However, the tools have a specific check for unconstrained output ports - the "check_timing" command (which is done as part of the normal flow) will flag these "unconstrained output ports" (which are either a warning or a critical warning - I don't remember which). If these are asynchronous outputs like LEDs, then you can ignore the warning. But many designed are uncomfortable ignoring warnings, so they want to fix them.

To do this, you do two things:

  • Put a set_output_delay on the port
    • You can use any legal clock and any delay value for the command
    • set_output_delay -clock <any_legal_clock> <any_value> [get_ports <name_of_output_port>]
  • Set the path (and it is now a path since it is constrained) as false
    • set_false_path -to [get_ports <name_of_output_port>]

This, then satisfies the check_timing command and tells the tool that there are no timing requirements on the path.

Avrum

View solution in original post

joe306
Scholar
Scholar
205 Views
Registered: ‎12-07-2018

Thanks Mark!

0 Kudos
Reply
joe306
Scholar
Scholar
204 Views
Registered: ‎12-07-2018

Avrum,

 

Hello, thank you for your detailed response. I sure have a lot to learn. 

Joe

0 Kudos
Reply