How to debug a mismatch in a scan pattern?

i did chip simulation with post-layout netlist and got one mismatch (exp 0, got 1) in a scan pattern (totally about 1000 scan patterns).
how to debug this fail? or this can be masked in vectors? thanks.

I think you have not timing violations during the simulation?
To debug, you need to find which FF fail, analyze the cone of logic...
If you used the WGL you could mask it, but it is a manual operation, not very clean. And normaly the patterns must pass the simulation.

Thanks for your reply.
Actually it is the 2nd rev of chip, there are warnings of timing violation during simulation, but only one mismatch.
we ignored the warnings because when we did 1st rev, there were also many warnings of timing violation but no mismatch, and it got pass on ATE test).

now, i have got the scan cell (FF), and ploted its waveform during unloading. it looks ok (no x state, and having enough margin).
i also ploted the waveform during "caputure"... but the combinational logic circuits connecting with that FF is so deep and complex, i don't know whether and how to trace them...
i also tried to reduce the scan clock down to one tenth, but still failed at the same scan cell and pattern.
is there any method for that, please?

I don't like timing warning, these warning occurs only on memories/macros for example, or/and at time 0, never on std cell?

did you try to change when the output comparaison is done?

these warnings are setup & hold timing violations on std cell.

what did you mean change, please?
i tried GSV and watched the failed cell at that pattern. the D and Q of that DFF are both 111, while the ck is 000 (why no pulse?) and se is x00. (i assume they stand for the period of PI-force/PO-measure).
is it possible that the tool produced a wrong pattern?

and you don't think the setup & hold violations need to be fix? You arn't concern by these violations?
The violation occurs at the FF which make the pattern issues?

i fixed timing violations occured during functional gate-simulation; but we didn't care about the timing violations occured during scan gate-simulation unless it led to an mismatch error.

for this case, there are timing violations around the mismatch cycle, but not at that cycle. so i didn't fix them.
as mentioned, i tried to reduce the scan clk down to 1/10, but the mismatch still existing. so i guess it should not be a timing issue, right?

Is it a multi clock capture phase?

no, single clock.

by multiple clock, I mean during the phase capture, multiple clock pulses are generated on the scan clock.
you confirm that's?

no, only one scan clock pulse during the phase capture.

The mismatch error still exists during the gate-level simulation.
i will directly mask this vector. i hope it won't reduce the test coverage too much...
Thanks.