Timing Simulation Problem

[b01010101]

My design is implemented on MAX7256AE.
I use QuartusII to systhesis and fit the design. The Classic Timing Analythesis reports that the fmax of the clk can get 84.03MHz, and no error or warnings are
reported.
I take timing simulation in Modelsim-SE6.2b and encounter with this error:

// Error Message //
# ** Error: D:/Modeltech_6.2b/win32/../altera/verilog/src/max_atoms.v(2070): $setup( datain:379100 ps, posedge clk &&& reset:381200 ps, 2900 ps );
# Time: 381200 ps Iteration: 0 Instance: /testcase/inst_harness/u_FCT/\r_addr[4]\/preg
# ** Error: D:/Modeltech_6.2b/win32/../altera/verilog/src/max_atoms.v(2070): $setup( datain:379100 ps, posedge clk &&& reset:381200 ps, 2900 ps );
# Time: 381200 ps Iteration: 0 Instance: /testcase/inst_harness/u_FCT/\r_addr[5]\/preg
.
.
All the errors occur in 381200 ps, the waveform is attatched below (ft_lck is the clock):


Q1: I don't understand why this error occurs. It's only a simple asynchronous reset when 'pc_rst_n' is low. Why it can't meet the setup time?
I find that this error will not happen if I move the pc_rst_n some ns earlier or later. But why the error happens in some situation?
Why the Classic Timing Analysis didn't report this problem?

The code is just so common. Part of the source code is shown below:
// Source Code //
always @(negedge ft_lck or negedge pc_rst_n) begin
if(~pc_rst_n) begin
......
r_addr<=19'h0;
......
end
else begin
......
r_addr<=......;
......
end
end

By the way, I have 2 more questions:
Q2: What do "~dataout" and "~pexpout" mean in the waveform respectively?
Q3: Why "sram_addr~743_dataout" is before "sram_addr", but "ft_lck~dataout" is after "ft_lck"?

 

[j_andr]

/.../I take timing simulation in Modelsim-SE6.2b and encounter with this error/.../

the problem with async. reset is well known, [although I must
remark I do not see it clearly on the waveforms attached]
when the reset is removed [deactivated] close to an active
slope of the clock a flip-flop - saying figuratively -
'can not decide' if it's still under reset or should
react on the clock;
what's more due to slightly different traveling time
of the clock and reset to different flip-flops a set
of them can 'see' the reset being active when the others
already write data with the clock;
the observation:

this error will not happen if I move the pc_rst_n some ns earlier or later

confirms the explanation;

What do "~dataout" and "~pexpout" mean in the waveform

wires created by quartus synthesis;
open: tools -> netlist viewers -> technology map viewer
to see the signals;

Why "sram_addr~743_dataout" is before "sram_addr", but
"ft_lck~dataout" is after "ft_lck"

the ***~dataout are internal signals, so they change their
levels after changes at the inputs and of course the outputs
follow switching of the internal states;
---

 

[b01010101]

So, the same problem also exist when the asynchronous reset is activated when close to the active slope of the clock?

So, it's not my design's problem. Is there anything I can do to avoid its happening?

Does this problem matters? Does that means any design with asynchronous reset is unreliable? When reset, the design may get into a unkown state.

Thank you so much!

 

[j_andr]

So, the same problem also exist/.../activated
when close to the active slope of the clock?

no, in such case just some F-F's are reseted slightly faster
then others;

So, it's not my design's problem

actually it is, the design uses an asynchronous reset;

Is there anything I can do to avoid its happening?

if the reset is really async. to clock you have to synchronize
it to the clock;
pretty often the reset signal is fired by an external device/logic
working with the same system clock so in fact reset is synchronized;

Does this problem matters?/.../

design dependent, but usually yes, you need a reset signal
when you have to put the logic to a defined starting state,
if you do don't care what the starting state is, you do not
need the reset;
---

 

[b01010101]

So, the same problem also exist/.../activated
when close to the active slope of the clock?

no, in such case just some F-F's are reseted slightly faster
then others;

But in the simulation, errors occur at 381200ps(near rst_n 1->0) and 885200ps(near rst_n 0->1). The error messages all say "$setup(....,.....,....)".

Why there is also such error message when reset is activated?

Thank you very much for your help!

 

[j_andr]

But in the simulation, errors occur at 381200ps(near rst_n 1->0)/.../

right, for the simulation software some clock to reset timing relations are
violated so the warning/error is generated; but in hardware it's meaningless
that some registers store incorrect value few hundreds ps before reset;
---