10-10-2019 02:49 AM
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
10-10-2019 03:29 AM
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
10-10-2019 03:32 AM
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
10-10-2019 03:53 AM
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.
10-10-2019 03:59 AM
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
10-10-2019 04:08 AM
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
10-10-2019 07:12 AM
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
10-10-2019 07:14 AM - edited 10-10-2019 07:15 AM
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.
10-10-2019 07:20 AM
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
10-10-2019 07:30 AM
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
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
10-14-2019 01:02 AM
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
10-14-2019 02:09 AM
10-15-2019 02:11 AM
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?