12-27-2012 02:52 AM
i would like to know different approaches for fixing hold violations. There's lots of information about resolving setup violations but for hold violation I couldn't find enough . Most of the posts say change your design to increase delay in path ,
add delay in path but in many of the post simply adding buffers or using two inverters or similar practices are discouraged by seniors.
So please throw a little light on fixing hold violations
1) between two internal registers of a design which has hold violations due to insufficient combinational delay between the two registers (no skew )
2) Hold violation at input and output pads
12-27-2012 05:57 AM
The tools will automatically fix "reasonable" hold time violations - you shouldn't need to worry about them.
Lets look at the two cases.
Between FFs, hold violations are caused by different arrival times of the clocks at the source and destination FF. If the two FFs are on the same clock network, then the skew will be small, and the tool will be able to fix them.
Even if the two FFs are on different, but related (and properly constructed), clocks, then the skew between them should still be small, and the tool will fix them.
However, if you have a bad clock design - say one clock coming through one BUFG, and another coming through two BUFGs, then the skew will be large (several nanseconds), then the tool will likely not be able to fix them. This is not a tool bug, but an error in design - you need to design clocking systems that use the resources of the FPGA properly.
As for the second case - hold time violations on inputs generally need to be fixed using proper interface design. You either need to use an MMCM/DCM to adjust the phase of the capture clock so that the clock is centered in the data eye, or use IDELAY cells to move the data over the clock. Again, it is really up to the user to design the capture mechanism, using the dedicated clock and IOB resources in the FPGA. The OFFSET IN in these cases merely acts as a mechanism to ensure that you have the system designed properly. You should never rely on the tool to fix hold time violations in interfaces by adding buffers/routing delay...
(There is no way of having a hold check done on an output - the OFFSET OUT format doesn't have a mechanism for specifying a minimum clock to out).
01-21-2013 09:22 AM
If the Hold Time Violation is associated with an OFFSET IN constraint, the data path is faster than the clock path. Either increase the delay associated with the data path or decrease the delay associated with the clock path.
To decrease the clock path delay, verify that the design is using the global clocking resources. You can also run PAR with a -k option, which tries to perform limited rip up and rerouting to solve problems.
If the Hold Time Violation is associated with a PERIOD constraint, the data path is faster than the clock skew. The resolution is similar to a Hold Time Violation in an OFFSET IN constraint, but decrease the clock skew instead of just the clock path delay.
To decrease the clock path skew, verify that the design is using the global clocking resources. You can also run PAR with a -k option, which tries to perform limited rip up and rerouting to solve problems.
02-01-2013 07:10 PM
Does Vivado support the -k option? If so where and how do you specify it?
06-08-2017 06:24 PM
I also encounter the warning "Design has a large number of hold violations. This is likely a design or constraint issue. This may increase router runtime".
Because of this the route cost a long time to finish.I think this may be caused by some gated clock in my design and I need to fix that to reduce the runtime.
My question is can Vivado report the position of the hold violation paths where it is fixing the violation? Or any other method can I get the fixing paths?
06-08-2017 11:58 PM
If you have the timing report for routed design, you can try to find the paths with hold time violation.
If the route_design fails, you can open the placed.dcp and report_timing_summary to check the paths hold violation.
In many situations, the warning message you see is caused by unreasonable clock structure. Such hold violation is hard to be resolved by Tools automatically.
06-09-2017 07:28 PM
As mentioned by others, if the hold time problem is really caused by a bad clocking structure, it is unlikely the tool will be able to fix it. So while it will chew on it for a long time, it probably won't get them all. If the place and route completes, then just open the routed design and look at the remaining hold failures - that should be enough to call attention to the underlying problem.
However, this isn't necessary. Hold times are fixed by the route_design stage, but the clock structure problem that created the hold time problem have been around since the design was synthesized. Vivado uses the same timing engine to perform timing analysis at all stages, so you can simply open the synthesized (or even placed) design and look at the hold time failures there. This can be done if either
- route design can't complete or hasn't yet completed or
- (the unusual case) the tools complain about the large hold times to fix, but succeeds in actually fixing them (and hence there are no remaining hold time violations after route_design) or
- any time you want
But, be a bit careful with this. Since hold times are only fixed by route_design, it is normal to see some small hold time violations in a synthesized or placed (but not routed) design. As long as the magnitude of these violations are small (like 100ps or so), then you can ignore them - the tools will fix this in route_design.