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: 
Adventurer
Adventurer
383 Views
Registered: ‎11-02-2014

Timing errors despite false paths

As you can see below, I explicity define these paths as false paths, and still they show up in the timing report? Is this a known issue?

Clipboard02.pngWhy?

Thanks for any help,

 

Brian

0 Kudos
12 Replies
Moderator
Moderator
366 Views
Registered: ‎01-16-2013

Re: Timing errors despite false paths

Hi @brianvg 

For clock to clock asynchronous domains the best way to write constraints is set_clock_groups -asynchronous. (Refer UG 903 and 949). Having said that false path constraints will also serve the purpose.

The issue looks like the parsing order issue to me. To confirm this please follow below steps and let me know the results.

Implement the design 

Open Implemented design

Source the false path constraints sing TCL console

Run report_timing 

If above steps help to constraints path properly then this is parsing order issue of XDC constraints.

Thanks,
Yash

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

Re: Timing errors despite false paths

@brianvg 

I can’t clearly see your screenshot.  However, if you are trying to set_false_path all the timing paths between two (say CLK1 and CLK2) clock domains then you need two set_false_path constraints:  one from CLK1 to CLK2 and another from CLK2 to CLK1.

Instead of two set_false_path constraints, you can use one set_clock_groups constraint (see UG903 for details).  

However, as Avrum often warns us, false-pathing every path between two clock domains is a dangerous thing to do.

Finally, be sure that all your clocks are defined properly with either a create_clock constraint or a create_generated_clock constraint - the latter being sometimes auto-generated (eg. when you use the Clocking Wizard).

Mark

0 Kudos
Scholar drjohnsmith
Scholar
348 Views
Registered: ‎07-09-2009

Re: Timing errors despite false paths

Once you have done Implimentation.

look at the report clock interaction tab

it shows a nice matrix of all th elcocks th etools knwo about, how thay interact and have you marked them as false paths or not.

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Adventurer
Adventurer
343 Views
Registered: ‎11-02-2014

Re: Timing errors despite false paths

Hi Yash,


Yes, I have tried what you mention, by running the clock group constraints in the tcl window and rerunning timing analysis. This will indeed get rid of the failing paths, but the strange part is that most of the paths are already properly constrained, and some random subset of the "rxoutclk_out*" clocks have failing paths. Without any of the false path constraints, they would all have failing paths. This means that part of the long list of clock constraints, from that file, are being applied, and others are being ignored/not parsed.

btw, I have already tried the following constraint:

set_false_path -from [get_clocks clk_20M] -to [get_clocks rxoutclk_out*]

Which should be a replacement for all 24 of those false paths, and this one has the same behavior. Some of the rxclocks are properly constrained, and others are not. 

I have also tried changing the order of the xdc files such that this file gets read last, first, or somewhere in the middle. This also does not have an effect.

I can try using an set_clock_groups -asynchronous constraint to see if that has better behavior.

Thanks for the responses,

Brian

0 Kudos
Moderator
Moderator
333 Views
Registered: ‎01-16-2013

Re: Timing errors despite false paths

Hi @brianvg 

After writing the clock level constraints it is expected to cover all paths comes under that CDC domain.

If you suspect some paths are constrained properly and some are not honoring the constraints then this need to be revisit and find out the root cause for that I would need the test case.

Also  @drjohnsmith  mentioned take a look at clock interaction report. If some paths are left out/ not constrained then those CDC interaction should be in orange color (i.e. partial false path).

Also mentioned in above post you need to be sure on whether all paths has to go under Asynchronous domain or not (this vary from design to design).

Thanks,
Yash

 

Thanks,
Yash

 

0 Kudos
Adventurer
Adventurer
302 Views
Registered: ‎11-02-2014

Re: Timing errors despite false paths

I just ran the implementation again with the following constraint:

set_clock_groups -asynchronous -group [get_clocks clk_20M] -group [get_clocks rxoutclk*]

As you can see in the image below, most of the rxoutclk* clocks are properly constrained:clock interaction.pngClock interaction report

 

failingroutes.pngExample failing routes

I can't really understand why the constraint is not being applied to the last four rxoutclocks, since it is being applied to the first twenty??

 

Best,

Brian

0 Kudos
Adventurer
Adventurer
301 Views
Registered: ‎11-02-2014

Re: Timing errors despite false paths

By the way, the images can be zoomed in on with the browser, though for some reason when you try the zoom reticle, they actually get smaller... Click the zoom reticle, then zoom in with the browser. They can then be seen clearly. 

0 Kudos
Adventurer
Adventurer
297 Views
Registered: ‎11-02-2014

Re: Timing errors despite false paths

Quick followup:

After rerunning the constraint

set_clock_groups -asynchronous -group [get_clocks clk_20M] -group [get_clocks rxoutclk*]

in the tcl window and regenerating a timing report, once again there are no failing paths!

Is it possible that some automatically generated xdc files are interfering with my constraints?

Best,


Brian

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

Re: Timing errors despite false paths

I don't know what problem you are having with the constraints, but I am going to ask a question...

It is clear that there are paths between the clk_20M and the rxoutclk* domains. Are you sure that it is correct to declare these paths false?

The set_false_path and create_clock_groups are simply telling the tool to ignore these paths (and not report any failures on them) - but what makes them "false"? Have you looked at them and determined that

  • Yes, these paths are real and supposed to be there
  • Yes, these paths are false - there is no way for a transition of the startpoint to corrupt the endpoint

In general, there are only a small number of cases where that second assertion is true...

I always find it valuable to say "Just because two clocks are unreleated does not inherently make paths between them false." In fact quite the contrary - if there are paths between unrelated clocks, then they need a clock domain crossing circuit (CDCC). The structure of the CDCC is determined by the speeds of the clocks and the types of data being brought between the domais. Ultimately it is the construction of the CDCCs determine what exception is needed on the path between domains - and it is usually not a set_false_path/create_clock_group.

Avrum

0 Kudos
Adventurer
Adventurer
184 Views
Registered: ‎11-02-2014

Re: Timing errors despite false paths

Hi @avrumw ,

Thanks for your help!

The design is not mine originally, but I had a look at the schematic for the failing paths.

The paths that are failing are associated with an asychronously asserted reset. They really are meant to be constrained as asynchronous. The reset signal enters a chain of ff on the clear pins, and the reset is taken back to ground after three ticks. I am fairly confident that the constraints are correct, or are at least a correct workaround for incorrectly identified failing paths.

The failing paths are all in the "Other Path Groups">>"**async_default**" path of the timing summary. I have still not found any documentation that makes it clear to me what this group of paths have in common. If these paths are "asynchronous by default", which is how I read that, why are they causing failing paths, and why do I need to apply asynchronous constraints?

Best Regards,

Brian

0 Kudos
Moderator
Moderator
171 Views
Registered: ‎01-16-2013

Re: Timing errors despite false paths

Hi Brian,
Please refer page#37 https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_1/ug906-vivado-design-analysis.pdf

Regarding why only few paths are not honored by the tool after clock level async constraints for that analysis I need test case.

Thanks,
Yash
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
135 Views
Registered: ‎07-16-2008

Re: Timing errors despite false paths

If you open implemented design and do "write_xdc -exclude_physical timing.xdc", do you see the false path constraints in the exported timing.xdc?

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos