I'M puzzled. why simulation wave is incorrect!

Hello,

don't think that simulation results are wrong, they show what could happen in real live when you ignore setup and hold timing.

Regards,

Frank

Hi!

Thanks for your replay! Frank

But my timing analyzer report don't indicate any timing violation.

Timing Analyzer Sumary:

slack Required time Actual time From To

Worst-case tsu : 1.327ns 2.0ns 0.673ns in2[7] out2[7]~reg0

Worst-case tco : 3.047ns 9.0ns 5.593ns out2[7]~reg[0] out2[7]

Worst-case th : 0.485ns 1.0ns 0.515ns out1[0]~reg0

If I change the code as follow all the output results in the timming simmulation are correct. I just add two input and two output and set the same timing assingments which have been set in the front code.

module reg_four_chanel(clk,rst_n,in1,in2,in3,in4,out1,out2,out3,out4);

input clk,rst_n;

input[7:0] in1,in2,in3,in4;

output[7:0] out1,out2,out3,out4;

reg[7:0] out1,out2,out3,out4;

always@(posedge clk or negedge rst_n)

if(rst_n==1'b0)

begin

out1<=8'h00;

out2<=8'h00;

out3<=8'h00;

out4<=8'h00;

end

else

begin

out1<=in1;

out2<=in2;

out3<=in3;

out4<=in4;

end

endmodule

The same structure of code and same timming assingment, but the simmulation is different. I also think the timing constrain should be assingment but which particular

timing constrain should be assingment.

Hello,

the different results between the 2 byte and the 4 byte design are probably due to small timing differences from place and route. Quartus simulates an individual routed design unless you specify functional simulation.

Regarding timing analysis: What did you specify for input to clock relation? Probably nothing. The timing analysator won't expect that you intend to change input state exactly simultaneous with active clock transition. But the simulator should have reported the timing violation. You could simply switch the clock phase in *.vwf to remove the violation.

However, this consideration is somewhat unrealistic. In real life, I see two basic szenarios:

1. Input signals are synchronous to clock, cause they have a source somewhere in the same clock domain. Then their transition could be expected short behind active clock transition. And the timing analysator could watch them.

2. Input signals are asynchronous to clock and must be expected to change at any time. Then you are unable to get reliable results for input without either a handshake with signal source or a special coding of signals, e. g. gray code in case of a counter value.

Regards,

Frank

Hello,Frank!

You suggestion have help me a lot.

Thank you again.