how to solve the setup path WNS problem in xilinx vivado

hello guys,
i have done a bd design in xilinx vivado 2015.4, it has generated the bit stream and i have tested the functionality of the design in my fpga, but it has WNS = -1, and TNS = -55, how to solve the timing error problem, it is saying the path source and destination ,one way is i want to add delays in between them, but in bd u cannot add "register or delay" in the bd design, can anyone suggest me the solution?

decrease the frequency is the trivial solution

you can also check the timing report and try to understand where the violations are coming from. it is likely to be systematic in some way.

can anyone suggest me the solution?

Click to expand...

As mentioned above, I would also say please analyze where the violations are coming from (where is the exact register).
There are ways to solve this but the method to solve it really depends on where the violation is occurring.

i have selected all the nets and set the paths as false paths it worked for the design, but i really dont understand why it worked? if the intra clk path error is between some clk and register D then we should choose it as multi cycle path, if the intra clk path error is between some register and register we should add max delay and sysnthesize , is it in that way ?

hahaha sure. This solution is great.

Seriously, you need to understand what set_false_path does and why you just killed your design. Your design is not timed anymore. Oh boy.

Post the a verbose full timing report of one of the violating paths.

Unless you know why you set_false_path and what it is exactly doing in your design then I agree with ThisIsNotSam, that you just killed your design.

The issue is that you have no idea if you have broken anything. In one design I worked on there was an incorrect timing constraint on a clock. It worked fine in the lab until summer.

Basically, if you have set_false_path you are turning off analysis and optimization for these paths. This means any successful results do not indicate the design can work on another device or under other operating conditions.

ThisIsNotSam said:

hahaha sure. This solution is great.

Seriously, you need to understand what set_false_path does and why you just killed your design. Your design is not timed anymore. Oh boy.

Click to expand...

are you serious? i just selected the wrongly timed path and set as false paths it worked.

set false path tells the compiler that you do not care about this path, so it is free to set the delay to 10 seconds if it wants. Is that what you really want?

beginner_0029 said:

are you serious? i just selected the wrongly timed path and set as false paths it worked.

Click to expand...

I have several issues with this statement based on similar statements I've heard from others in the past. Specifically, this is not an insult to you -- I suspect everyone has had a moment similar to this.

This is a very short statement that suggests that you want to be seen as successful in your efforts while bringing ridicule to anyone who would say otherwise. Both are traps. If you hear other people say a similar statement, be wary. Again, this is based on my experiences on both sides of this statements.

1.) "are you serious?" -- this suggests that you are actively hostile towards any information that doesn't make you appear good. (to random people you don't really know on the internet.)
2.) "it worked" -- This is the most terrifying part. There is a concept of "survivor bias" and "test coverage" that come into play here. Logic -- especially if you don't have internal visibility -- can be very complex. As an example, there are cases where you could simply connect an input to '0' instead of the correct output signal and the design would pass simulation and even work in the field.
3.) "the wrongly timed path" -- this doesn't sound like you understand the issue. I would be suspicious that you can correctly identify false paths, multi-cycle paths, or other exceptions.
4.) "and set as false paths" -- false path is almost never the correct choice.


From my perspective, your comments suggest that you attempted a build. The results gave a -1ns slack. In response you disabled optimizations for such nets -- allowing much worse than -1ns -- then you tested something that might not have any coverage of the signal on a single prototype. Both issues would make your tests invalid, unless you only need the prototype, never do anything outside of what you have tested, and also don't change the voltage/temperature on the device.

beginner_0029 said:

are you serious? i just selected the wrongly timed path and set as false paths it worked.

Click to expand...

"you need to understand what set_false_path does and why you just killed your design"