Timing violation in PrimeTime

I did timing verification with PrimeTime. After the report_constraint, there are some violations as below

****************************************
report_constraint -all_violators -verbose
Pin: U18129/Y
max_capacitance 0.33
- Capacitance 1.01
------------------------------
Slack -0.69 (VIOLATED)

Pin: U53740/D

max_transition 2.23
- Transition Time 7.51
------------------------------
Slack -5.28 (VIOLATED)
****************************************
But in the report timing file: there are no violations.
****************************************
Report : timing
-path_type full
-delay_type max
-slack_lesser_than 0.00
-max_paths 20
-group CLK
-transition_time
-capacitance
No paths with slack less than 0.00.
****************************************
Anyone help me explain why ? And how to fix the above violation ?
Thank you.

There are two kinds of violations in DC/PT.
1): Timing violation, which can be reported by report_timing
2): design rule violation. Such as your example: max_transition / max_capacitance violation. If you are doing PT just after synthesis, you can ignore these violations. If you are doing sign off PT check, you need fix these violatins. And it supposed design rule violation will be fixed by place&route tools.

Thank you, yx.yang,
As your mention, in my case, there are timing violation due to design rule. This is a result after running IC Compiler. In case that slack values are less than 0, we can use fix_eco_timing and write_changes to generate ICC TCL to fix, but in report timing file there are no timing violation results. In this case of design rule timing violation, do you have any suggestion to fix it ?
Regards,

Sorry, I don't know how to fix it. I'm just front-end enginer, not back-end (runing Place & route) engineer.

Hi Idhung,

You can fix this violation by splitting the load on the cell "U18129" which can result in reducing max_capacitance and max_transition violations.
If the output of cell "U18129" is a long running net try to split the net using a buffer.

~vamsi

before fixing the cap&trans violation you could check how much margin you have path which goes through this pin.
I means if the setup & hold margin is very huge, you will not have any real issue.
Also check for what this signal should be use, only in test mode and you are able to control extenally some timing (delay)?

1-Before to fix it check the place and route trans&cap reports to see the tool already seens this violation.
2-In primetime, there are some eco fix command which will indicate how to fix it, and how, increase drive, add cell?, and tehn change in PnR tool.