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: 
Explorer
Explorer
753 Views
Registered: ‎04-01-2016

Unconstrained paths

Jump to solution

Hi all,

I have a question related with clocking networks and constraints. I get the following unconstrained paths:

2018-12-20_17h54_01_c1.png

Looking inside one of them I get the following information:

2018-12-20_17h56_46_c2.png

The schematic looks like follows:

2018-12-20_17h57_48_c3.png

 

This is what I expect. I programmed a counter which divides the clock by 16 and use this as enable signal, but not as clock. The clock which drives the signal itself is fosc_clock (left side). The fosc_div16 is then just used at LUTs for enabling some FF later on and this is in this case used for 216 inputs.

Could someone give me a hint why Vivado thinks this path is unconstrained? If I know why this path is unconstrained I hope that I can solve all other paths as well.

Kind regards and thanks in advance!

Sebastian

0 Kudos
1 Solution

Accepted Solutions
664 Views
Registered: ‎01-22-2015

Re: Unconstrained paths

Jump to solution

Sebastian,

I suspect that some of your “fosc_clk to_NONE” unconstrained paths can simply be ignored.

Before explaining why, recall that timing paths which start in the FPGA and go through a port (FPGA pin) to an outside device are not complete paths until you place a set_output_delay constraint on the port. This constraint tells Vivado that there is a register located outside the FPGA that is receiving the data. It also tells Vivado which of your FPGA clocks is clocking the outside register. If you have not written the set_output_delay constraint, then Vivado does not know which FPGA clock is clocking the outside register. Thus, you get the unconstrained path with “NONE” representing the unknown clock for the outside register.

Does this mean you should write set_output_delay constraints for all your output ports?  Well, you can if you want - since this will prevent the unconstrained path message – but often it makes no sense to write these constraints. For example, your timing summary report shows a path that starts at register, counter_LED_reg[7], goes through port, LED, and ends outside the FPGA (at an LED, I assume). Vivado knows the clock, fosc_clk, for the source register, counter_LED_reg[7], but does not know the clock for the LED outside the FPGA. Hence, you get the unconstrained path from fosc_clk to NONE. Of course, “clocking an LED” makes no sense. So, writing the set_output_delay constraint in this case makes no sense.  -and you can simply ignore the unconstrained path message.

Here is an example of a path in my project where register, MOSFT3_reg, provides control for a MOSFET located outside the FPGA. I get an unconstrained path message, “clk_out1 to NONE”, because I have not written a set_output_delay constraint for port, MOSFT3.
clk_out1_to_NONE.jpg

On a related topic, your original post shows a register, fosc_div16_counter_reg[3], that drives through a bunch of combinational logic to “somewhere”.  Be sure that “somewhere” is not a port of the FPGA – because you will be sending glitch pulses out of the FPGA.  To prevent the glitches, add another register after the combinational logic and ensure this other register drives directly through OBUF to the FPGA port (ie. not through combinational logic).

Mark

Tags (1)
5 Replies
Highlighted
689 Views
Registered: ‎01-22-2015

Re: Unconstrained paths

Jump to solution

Sebastian,

An unconstrained path is one where clocks associated with the path have not been properly defined (with a create_clock or create_generated_clock constraint).   In your case, it appears that Vivado thinks fosc_div16 is a clock?

I am unfamiliar with the “Unconstrained” report you have shown. How did you generate this report?

Anyway, please try the following after opening the implemented design: 

  1. In the Tcl Console, type report_clocks and tell us what it says about fosc_div16 and fosc_clk.

  2. Run “Report Timing Summary” and tell us what it says under “Unconstrained Paths” for fosc_div16 and fosc_clk.unconstrained.jpg

  3. Run “Report Methodology”. In the resulting report, tell us what warnings (eg. TIMING-17) you see that refer to fosc_div16 and fosc_clk.  FYI - these warnings (and how to resolve them) are described in Appendix-A of UG906.

  4. Send us a snippet of your code showing how you have used fosc_div16 to “enabling some FF later on”.

Cheers,
Mark

0 Kudos
Explorer
Explorer
677 Views
Registered: ‎04-01-2016

Re: Unconstrained paths

Jump to solution

Hi markg@prosensing.com

thank you very much for your recipe. Here is the output from the timing summary, both the setup and the hold report:

2018-12-21_18h13_43_setup.png

2018-12-21_18h14_20_hold.png

 

The only information I find when I run report_methodology is the following:

2018-12-21_18h22_10_met.png

Thank you very much for helping! I will have a closer look to UG906.

Kind regards

Sebastian

0 Kudos
665 Views
Registered: ‎01-22-2015

Re: Unconstrained paths

Jump to solution

Sebastian,

I suspect that some of your “fosc_clk to_NONE” unconstrained paths can simply be ignored.

Before explaining why, recall that timing paths which start in the FPGA and go through a port (FPGA pin) to an outside device are not complete paths until you place a set_output_delay constraint on the port. This constraint tells Vivado that there is a register located outside the FPGA that is receiving the data. It also tells Vivado which of your FPGA clocks is clocking the outside register. If you have not written the set_output_delay constraint, then Vivado does not know which FPGA clock is clocking the outside register. Thus, you get the unconstrained path with “NONE” representing the unknown clock for the outside register.

Does this mean you should write set_output_delay constraints for all your output ports?  Well, you can if you want - since this will prevent the unconstrained path message – but often it makes no sense to write these constraints. For example, your timing summary report shows a path that starts at register, counter_LED_reg[7], goes through port, LED, and ends outside the FPGA (at an LED, I assume). Vivado knows the clock, fosc_clk, for the source register, counter_LED_reg[7], but does not know the clock for the LED outside the FPGA. Hence, you get the unconstrained path from fosc_clk to NONE. Of course, “clocking an LED” makes no sense. So, writing the set_output_delay constraint in this case makes no sense.  -and you can simply ignore the unconstrained path message.

Here is an example of a path in my project where register, MOSFT3_reg, provides control for a MOSFET located outside the FPGA. I get an unconstrained path message, “clk_out1 to NONE”, because I have not written a set_output_delay constraint for port, MOSFT3.
clk_out1_to_NONE.jpg

On a related topic, your original post shows a register, fosc_div16_counter_reg[3], that drives through a bunch of combinational logic to “somewhere”.  Be sure that “somewhere” is not a port of the FPGA – because you will be sending glitch pulses out of the FPGA.  To prevent the glitches, add another register after the combinational logic and ensure this other register drives directly through OBUF to the FPGA port (ie. not through combinational logic).

Mark

Tags (1)
Explorer
Explorer
657 Views
Registered: ‎04-01-2016

Re: Unconstrained paths

Jump to solution

Hi markg@prosensing.com,

cool, thank you very much for your explanation. Now I will have a look at the other paths and check if they do have a similar structure.

Kind regards

Sebastian

0 Kudos
Historian
Historian
644 Views
Registered: ‎01-23-2009

Re: Unconstrained paths

Jump to solution

A path from an internal flip-flop to an output port is unconstrained unless you have a set_output_delay on the port.

In the case of an asynchronous output (like a LED), there is no need to have a set_output_delay on the port from a timing perspective, but not having one will have it show up in a variety of places as a warning - both here and in the "check_design" tests (DRC warnings).

The way to deal with ports like this is to have a set_output_delay on the port and also have a set_false_path on the port

set_output_delay -clock <some_clock> <some_value> [get_ports LED]
set_false_path -to [get_ports LED]

The set_output_delay command can use pretty much and value for <some_delay> and can use pretty much any clock for <some_clock>. This command will remove the path from the "unconstrained path report" as well as from the DRC checks. The set_false_path will then remove the timing requirement on the path.

For a LED, you can drive it anyway you want. But for the SPI signals, the signal should be properly constrained and, as markg@prosensing.com suggested, the output should come directly from a flip-flop (with no combinatorial logic).

However, your original report might be showing something different - it is hard to tell from the report you showed, but it looks like the fosc_div_16 may be driving the clock pin of other flip-flops. If this is the case, then these flops are truly unconstrained (and that is a problem) - while it is possible to constrain fabric derived clocks like this, it is highly discouraged to use structures like this.

Avrum

0 Kudos