- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 endmoduleLink Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,Frank!
You suggestion have help me a lot. Thank you again.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page