I'M puzzled. why simulation wave is incorrect!

[Altera_Forum]

Hi. 

My design is a D FF. Its codes is as followed. When I simulate in the Quartus II 6.0 , the result of out1 is wrong and the result of out2 is correct.    I am confused. I want to get the correct result and what shall I do.   module reg_two_chanel(clk,rst_n,in1,in2,out1,out2);   input clk,rst_n;  input[7:0] in1,in2;  output[7:0] out1,out2;   reg[7:0] out1,out2;    always@(posedge clk or negedge rst_n)  if(rst_n==1'b0)  begin  out1<=8'h00;  out2<=8'h00;  end  else  begin  out1<=in1;  out2<=in2;  end   endmodule

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

Hello,Frank! 

  You suggestion have help me a lot.    Thank you again.