SOCEncounter is not fixing hold violation

When you examine the vicinity of the hold violation in the layout, do you see a landing area nearby that seems like it would accodomate a delay cell?

Also, you might want to try re-running hold fixing with "setOptMode -verbose true" if you're not already.  The messaging might be more specific in that mode.

 Yes, bob I do see a landing area nearby for placing a delay cell.

The messages I sent were reported by turning on this option only "setOptMode -verbose true"

 Did you use cell padding on your flops to save this room for delay cells during hold fixing? If so, make sure you remove the cell padding (deleteAllCellPad) before trying to fix holds. Just a thought!

- Kari 

 I'm not using any cellpadding for the flops.

What I observe is the tool is trying to fix the hold looking at the start point only.At start point there is very little margin.

Though it has lot of margin at the end point it is not trying to fix at the endpoint. 

I used  this option  "setOptMode -fixHoldAtSinkOnly true" also

Another thing to try - if your design is very tight you may have exceeded the max utilization.

Even if there is room available near the component with the violation, if you have exceeded

the max utilization, it will not fix the violation.

 The default -maxDenisty setting is 0.95. Try setting it to 0.99. (setOptMode -maxDensity 0.99).

 At this point, I would use a script like the following:

deleteAllCellPad
setOptMode -noRPlace

set endpoints { \
"top/REG746/D" \
"top/REG712/D" \
}

foreach endpoint $endpoints {
  ecoAddRepeater -term $endpoint -relativeDistToSink 0.1 -cell BUFX2
}

refinePlace -preserveRouting

 Then follow up with an ECO route and a new extraction and timing run.

You can also script getting the endpoints with various options and the output of report_timing -machine_readable.

Hope that helps,

- Kari