ModelSim undefined initial value

[Altera_Forum]

Hello, I am trying to do some simple simulation using modelsim-altera and am seeing undefined value for output "result" and it stays like that until 10ns or so into the simulation. Here is the example: 

 counter.v  module counter (clk, reset, result); input clk; input reset; output reg result; initial# 0 result = 0; always @(posedge clk or posedge reset) begin if (reset) result <= 0; else result <= result + 1'b1; end endmodule  counter_tb   `timescale 1ns/1ps module counter_tb (); reg clk; reg reset; wire result; counter u_count (clk, reset, result); initial begin # 0 clk = 0; # 0 reset = 1; # 100 reset = 0; end always# 2.5 clk = ~clk; endmodule  The waveform is shown in the attached jpeg. This happens when I select Gate Level Simulation. Any ideas why "result" is undefined?  Thank you

[Altera_Forum]

Your starting the simulation with a running clock. The counter value must be expected to change before you see the initial value at the outputs. Actually, reset is in effect during this period, so the temporary output state is more like a meaningless artefact, I think.

[Altera_Forum]

Thank you FvM! Does the initial block mean anything to ModelSim? Does it ignore it?

[Altera_Forum]

Thank you FvM! Does the initial block mean anything to ModelSim? Does it ignore it? 

--- Quote Start ---    --- Quote End ---   I think ModelSim is using it. Delay the clock and reset signal in your TB to check.

[Altera_Forum]

Ok, I will try that and see what happens.

[Altera_Forum]

Probably you see undetermined results due to propagation delay of the signal in your logic (you need some time before the reset propagates to the output). 

 However the way you define your testbench is awkward.  Better use a process for the clock:  always begin clk=1'b0;# 10; clk=1'b1;# 10; end  This will be repeated forever  then the initial block, that is processed only once at the beginning of the simulation:  initial begin reset=1'b1;# 105; reset=1'b0;# 1000; $stop; end  Try this (if I didn't make too many mistakes in the code)

[Altera_Forum]

Something still does not look right with this. Here is what I get with your suggestion.

[Altera_Forum]

I see that in your design you put an "initial " statement.  

Try to remove it. It cannot be synthesized.

[Altera_Forum]

I tried removing that and tried delaying the clock and reset as FvM suggested. The best I could do was reduce the undefined 'count' value to the first 5ns. Basically, what I am seeing is that for any register in the test bench module, the values are defined starting at t=0. For any instantiated entity, its output does not become valid until a few nanoseconds later. I am not sure if 5ns is due to propagation delay in this case, since that sounds like too long. If that is normal, then I will probably just move on since the simulation looks correct past the first few nanoseconds. 

 nplttr: I thought the initial block is synthisized. I usually have a auto reset scheme based on a count that makes sure everything is what it is supposed to be at startup. Is that a sound way of doing it or do you recomment a better way - in that absense of an external reset that is.

[Altera_Forum]

1) I think it's propagation delay. And you can move on wirth your design. 

 2) You should never design without a reset value and never simulate without applying a reset for a sufficnet long period of time.  3) The initial value, to the best of my knowledge, is not sythesized and only creates discrepancies between RTL and gate level simulations.  4) Never assume that somthing has a given value 'at startup'. It's your reset that fix the design to a known state

[Altera_Forum]

Thanks nplttr. That kind of makes it hard to make sure that a design with no external reset function properly. I will dig into this a little bit and see what I can find. A couple of the boards I am working on do not have an external reset.

[Altera_Forum]

I found this post (http://www.alteraforum.com/forum/showthread.php?t=6602) which helps clarify my last issue.

[Altera_Forum]

1) Initial block are sythesized by Quartus. Of course not every construct in an initial block can be sythesized, but assigning power-up values to registers is valid. Many people however, don't like to use power-up values, they use reset instead. 

 2) An external reset is not mandatory, most designs can use an internal one.  3) Just forget about gate level simulation. Use static timing analysis and RTL level simulation.

[Altera_Forum]

--- Quote Start ---  That kind of makes it hard to make sure that a design with no external reset function properly.  --- Quote End ---    As I mentioned in my initial post, your testcode is inappropriate to check the function of the power on reset. You're doing effectívely all at once: Starting the clock and asserting the external reset. In this situation, you can't see the initial power-on state at all.  A clock that is already present during power-on may cause timing violations in comibination with the asynchronous release of the internal reset. In this case, an initial counter or state machine state can become unpredictable.

[Altera_Forum]

I did try to delay the clock and the reset signal. I played with combinations of both but could never get the count to settle before the 5ns mark. I will change counter.v a little bit next.

[Altera_Forum]

I think you are complicating yourself too much. Once again, forget about gate-level/timing simulation. 

 The output should not be undefined. It is probably an artifact of non-accurate gate-level simulation, combined with non-recommended testbench practices. In particular, avoid using a zero delay, just don't use any delay at all in that case, and use non-blocking assignments.  But yet once again, I'd avoid gate-level simulation altogether.