Your sdf file comes from a post-layout parasitic extraction?
It isn't too strange to find some violation in final post-layout simulation: the only possible tip is to make more robust as possible your sinthesys process!
Use ever timing constraints worst than needed: so your desing will be more robust!
In your pre-simulation, if you annotate the SDF file, the result don't meet your RTL simulation. Your can check your script file for synthesis. Maybe your design can't meet your cycle requirement.
i agree with lailiya, sometimes the problem is from the asynchronous reset. if the timing problem happen at the very beginning of the simulation, change the reset timing, probably it will work.
Before you finished your design, you need to pass the gate level simulation with the post layout sdf. Of course, PT might help you speed up the timing verification.
You might not have time for re-synthesis all your design again. You should try the in-place optimization, eco, buffer sizing, buffer insertion, ... first.
What do you mean "the result is incorrect"
Where your sdf come from??
If your sdf come from pre-sim(run DC)
then the sdf is so what you want
you need got a post-layout sdf
if it's post-layout sdf and
what you mean is Simulation Pattern check error
Just Trace the waveform
(gate level trace, recommand use Debussy)
you should be able to find timeing violations in waveform
Usually, the inputs (netlist & sdf file) of post-simulation is from backend layout result.
In backend layout, clock tree and scan logic will be inserted. The sdf from layout result is accurate.
If just use output from dc, as 1st synthsys is estimated (take wireload for example), many information is not correct. In this situation, even you compare dc's timing report & PT's timing report, they are also not completely match.