Timing errors despite false paths

[brianvg]

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?

Why?

Thanks for any help,

Brian

[yashp]

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

[markg@prosensing.com]

@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

[drjohnsmith]

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.

[brianvg]

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

[yashp]

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

[brianvg]

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 report

Example 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

[brianvg]

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. 

[brianvg]

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

[avrumw]

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

[brianvg]

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

[yashp]

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

[graces]

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?