modelsim problem regarding input initialization

You know what they say about computers; Garbage in, garbage out. :)

I would say on a general basis it sounds like a very good idea to initalize all your inputs.

Uninitialized signals in modelsim are set to U (which means uninitialized, obviously).

If you want to understand better what happens with uninitializes signals in your circuit, I suggest you look at the ieee/std_logic_1164 library file in Modelsim.

For instance for the logical and funciton, the and_table in that file is used to determine the output based on different input signal levels, and you'll notice that if one input is U, then unless the other input is zero the output will always be U as well. Similar for logical or in the or_table. resolution_table is used to determine the signal level when there are several drivers for one signal. You'll notice U dominates here.

So if you have an uninitialized input (U) in your design, I think it can easily propagate through your design and cause many signals to be U. Maybe a state machine uses that input in some combinational logic to calculate its next state, then suddenly the state variable might become U.

For signals you've declared in your design, you can specify initialization values when declaring them with the := operator (for simulation only of course, most likely ignored by the synthesis tool!). But the inputs to your top level entity, your DUT, you obviously can't set from inside that entity, so you need to initialize the signals you connect to those inputs in your test bench.

But lets say you didn't do that, and you have a state machine in your design, and the state machine state variable/signal, or some other critical variable/signal (such as a counter), is only being reset when your active low reset goes low. The state variable might be stuck at 'U' until you pull the reset low (if you didn't make a default / when others state), or might be stuck in some undesired state because some other important signal has an uninitialized value.

A lot of digital ICs have a Power On Reset (POR) reset function, which kicks in when the power supply has settled at an acceptable value and resets the circuit, so that the circuit is known to operate in a known state. You'd probably want to design your circuit with a POR, and your logic in such a way that a reset is expected to initialize state machines etc. to their desired states. Then it makes a lot of sense to pulse the reset at the beginning of your simulation.

To voidptr. Your post only applies to vhdl. The op might be using verilog where uninitialized signals default to X. Also I think most of what you pirated doesn't really ally to the ops problem.

To the OP. Post your code. Your problem sounds like a code error.

A simple reason is that the register that you declared did not experience a proper reset and as such it would drive X during the start of your simulation.

Since you implement register with active low reset, the negedge condition of the rstn is not met when you tied it to 1'b1 (set it high at the start of simulation). As such, the register will drive out X until the D pin input is stable. Negedge condition require a transition of low to high in order to take effect.

--- Quote Start ---

To voidptr. Your post only applies to vhdl. The op might be using verilog where uninitialized signals default to X. Also I think most of what you pirated doesn't really ally to the ops problem.

To the OP. Post your code. Your problem sounds like a code error.

--- Quote End ---

Tricky,

I agree that I wrote purely from a vhdl perspective. I am not as experienced with verilog, but I think the concepts should be similar?

The OP's second question was a fairly general question about whether it is a good idea to initialize all inputs. I argued that it is, and I tried to come up with some examples from the top off my head to support my point of view. If you disagree or don't like my answer, that's fine, but please don't be so quick at accusing me of pirating. I write my own answers, and if I quote someone else I always try to specify the source.

Thank you all for your replies.

with regards to the POR, i think it makes sense as upon power up one would want the circuit to initialize to some known state, however in a simulation software this should not be a problem.

I will upload the vhdl source files and the simulation macro in a few hours because currently i am at school.