Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Modelsim gives an unexpected simulating result,why?

Status
Not open for further replies.

skycanny

Junior Member level 3
Junior Member level 3
Joined
Dec 23, 2004
Messages
30
Helped
2
Reputation
4
Reaction score
2
Trophy points
1,288
Activity points
363
Verilog HDl and modelsim have been exposed to me for only one week. Today , I describe a Counter with 4 width using verilog HDL and simulate it by modelsim. However ,an unexpected simulating result occers.The following is my source verilog HDL counter:

module counter(clk,clr,dir,ce,data_out);

input clk,clr,dir,ce;
output [3:0] data_out;
reg [3:0] data_out;

integer direction;

always@ (posedge clk)
begin
if(dir == 1'b1)
direction = 1;
else
direction = -1;
if(clr == 1'b0)
data_out = {4{1'b0}};
else if (ce == 1'b0)
data_out = data_out + direction;
end
endmodule

Could you explain this phenomina to me or would you please find the buggs in the source file? Thanks a lot!!! The attachment is the simulating wave.
 

In general, you should use non-blocking "<=" assignments to synchronous signals. Maybe like this:
Code:
module counter(clk, clr, dir, ce, data_out);
  input clk, clr, dir, ce;
  output reg [3:0] data_out;

  always @ (posedge clk)
    data_out <= clr ? 0 : !ce ? data_out : dir ? data_out+1 : data_out-1;
endmodule
 

Thanks for your reply ,but modelsim can not give an expexted simulating result using your sorce code ! Even thoiugh i modified my code very simple form as fllowws, modelsim can not give a proper result as well .Why? Could you show me a right counter described by verilog HDL? Thank you very much?

module counter(clk,data_out);
input clk;
output [3:0] data_out;
reg [3:0] data_out;
always@ (posedge clk)
begin
data_out <= data_out + 1;
end
endmodule

Added after 49 minutes:

I found out that the counter described by you can work properly after being cleared. If it dose not be cleared ,it will not be count correctly? If so, is this rule suitbale for any kind of counters? Thanks
 

Hi skykanny,

echo47 code is works fine. Synchronous logic is supposed to be cleared/preset before its state is allowed to change.

BTW, this is the same problem with you second code.Think about this: "what is data_out state at time zero"?

You are assuming data_out is initialized to zero so the counting can start but actally its initial state is UNKNOWN.

Take care.
 

Yes, my example module requires a synchronous clear to initialize the counter to a known state. Notice how my simulation drives the clr signal for one clock.

If your FPGA provides global register initialization capability (such as Xilinx Spartan/Virtex), here is another way to initialize the counter (this may be Verilog 2001 syntax):
output reg [3:0] data_out = 0;
 

Thanks for your helps and replies. Now I have a better understanding about digital circuits.All of digital circuits from counter to microprocessor, if wanted to be work properly, must be reset before working . Is this right?
 

Hi skycanny,

echo47 is using conditional expression to get data_out output signal. You can use if else condition and get the same result.

module counter (clk, clr, dir, ce, data_out);
input clk, clr, dir, ce;
output [3:0] data_out;
reg [3:0] data_out;
integer direction;

always @ (posedge clk)
begin
if (dir == 1'b1)
direction <= 1;
else
direction <= -1;

if (clr == 1'b1)
data_out <= {4{1'b0}};
else if (ce == 1'b1)
data_out <= data_out + direction;
else
data_out <= data_out;
end

endmodule

echo47 is right, you should use non-blocking "<=" assignments to synchronous signals. For digital design, use of nonblocking assignments instead of blocking assignments is highly recommended in places where concurrent data transfers take place after a common event. In such cases, blocking assignments can potentially cause race conditios because the final result depends on the order in which the assignments are evaluated.
On the downside, nonblocking assignments can potentially cause a degradation in the simulator performance and increase in memory usage.

Hope that would help.

cheers
 

I am very happy because the simulating result is right. The first code written by me using ifelse is also right . It can be chosed to work in count down or count up mode by manipulating dir input. I express many thanks to those who have been helping me!
Regards!!!
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top