VHDL integers initialization and FPGAs

[Altera_Forum]

I've started coding in VHDL just less than a year ago - unexperienced student warning! 

 My question is about integer initalization. I own an Altera DE1 board and I've also got some experience with Xilinx Spartan 3. With both deviced I've noticed a strange thing about integers. I must initialize an integer to some value at declaration level (i.e. signal int : integer range bla to blabla := 0; ), because otherwise my program may freeze or some other voodoo might appear. Usually I use integer signals for counters (UART interface for instance).  Have you ever encountered this before ?  I guess I'm configuring/doing something wrong as I know that initialization at declaration level doesn't (or shouldn't?) affect the program after synthesis.

[Altera_Forum]

I dont understand what the problem is? is it your misunderstanding of initialisation in VHDL? 

 Any signal that is left uninitialised is given the left most value as an initial value. This is why std_logic starts as 'U'.  Similarly for unconstrained integers, if you didnt initialise them to 0 the left most value is -2^31. When constrained, like this:  signal int : integer range -10 to 10;  It would initialise to -10 in VHDL, but when you synthesise it, it will convert it to 5 bits, and then may initialise it to something else.

[Altera_Forum]

--- Quote Start ---  Any signal that is left uninitialised is given the left most value as an initial value. This is why std_logic starts as 'U'.  Similarly for unconstrained integers, if you didnt initialise them to 0 the left most value is -2^31. When constrained, like this:  signal int : integer range -10 to 10;  It would initialise to -10 in VHDL, but when you synthesise it, it will convert it to 5 bits, and then may initialise it to something else.  --- Quote End ---   The rule definitely doesn't apply to synthesized VHDL. Unless "init don't care" is specified, all VHDL registered signals are initialized to zero. Because integer is represented by unsigned or signed, it will be also initialized to zero by default.  The behaviour is however different in functional simulation, so you would want to use explicite initializers for registered signals, if congruence behaviour of simulation and synthesized code is intended.  P.S.: I have to correct my statement. The rule applies also to synthesized integer in Quartus. Sorry for the confusion.

[Altera_Forum]

So how come my design (say a really simple UART receiver) freezes at some point, but when I initialize those integers at definition level it works fine without any glitches?  

Please note that I had problems with other designs where I used integers in this manner (for counting). Maybe the problem is with this "init don't care" mentioned above?   Anyhow, I attached the code, in case something's not right with it.

[Altera_Forum]

have you tried simulating it? are you sure you're not missing the state change conditions somehow and allowing the counter to freewheel? 

 When these integers get converted for synthesis their range will be greater than you specified to fit the number of bits, and if you overflow it will have to wait longer before hitting the final conditions.  Do you have a testbench for this code?

[Altera_Forum]

Have you simulated this code with a testbench? are you sure you arnt missing the state change parameters somehow and letting the counters freewheel?  

The counters will have a larger range in real hardware because they have to be converted to bits. Have you any idea in which state the problem occurs?  Do you have the testbench code?

[Altera_Forum]

I see, that the integer signals are also reset asynchronously, after that, their state won't depend on an initializer anyway. 

 A strange point is defining reversed integer ranges with downto. Apparently, it's not forbidden by the VHDL standard. But I wonder, if it may confuse the compiler. And I don't understand the purpose.

[Altera_Forum]

FvM, I'm just used to use downto. No special purpose. I'll try it with 'to'. 

 Tricky, I have no idea how to capture the exact moment when it freezes. I have monitored a signal (using SignalTap) which shows when the receiver has a new byte and I saw that after it freezes, that signal never goes up as it should and no new data appears on the data bus.  I have no idea how to capture the exact moment of the glitch. Maybe you have an idea how to do it using a testbench and/or SignalTap?  By the way thanks for the help and fast replies, guys!

[Altera_Forum]

how about writing a testbench and simulating the design?

[Altera_Forum]

I simulated using ActiveHDL, so there's no testbench code since I didn't need it. I could write one if you'd like. 

Maybe you'd rather like to see simulation results?  Edit: ha, this is interesting. I just tested it again using 'to' instead of 'downto' in the declaration (without the := 0 initialization), and it also worked fine. So I guess it's a compiler related issue?

[Altera_Forum]

An other point to take care of : I suppose RX is asynchronous to the clock. You should/must not take this asynchronous signal as an input to your state machine. This can cause the described freeze.

[Altera_Forum]

How did you test it without a testbench? did you use a waveform file?

[Altera_Forum]

hjs (http://www.alteraforum.com/forum/member.php?u=4216), oh I didn't know that, thanks! So passing it through DFFs is the way to go, I guess? 

 tricky (http://www.alteraforum.com/forum/member.php?u=7270), yep, in ActiveHDL you have the option to manipulate signals and set them to any (possible) value you want in any given period of time. Usually I find that easier to work with than with a testbench...

[Altera_Forum]

--- Quote Start ---  You should/must not take this asynchronous signal as an input to your state machine. This can cause the described freeze.  --- Quote End ---   Yes, it's the most likely explanation. In case, state would show an illegal bit combination, it can be easily detected in simulation or with signal tap.  The probability of dropping into an illegal state with asynchronous inputs also depends on arbitrary design timing details, it may change with design modifications without a clear relation.

[Altera_Forum]

--- Quote Start ---  Yes, it's the most likely explanation. In case, state would show an illegal bit combination, it can be easily detected in simulation or with signal tap.  The probability of dropping into an illegal state with asynchronous inputs also depends on arbitrary design timing details, it may change with design modifications without a clear relation.  --- Quote End ---    I see, so what is the best way to prevent this from happening? Synchronize the async. inputs feeded into the FSM ?

[Altera_Forum]

--- Quote Start ---  what is the best way to prevent this from happening? Synchronize the async. inputs feeded into the FSM ?  --- Quote End ---   Yes, that's the required method, as already mentioned. In those cases, where a safe timing can't be guaranteed, e.g because the clock input may have glitches, the safe state machine option prevents freezing. See the Quartus software handbook for details.  I was just aware, that my previous statement about default initialization of integers has been incorrect. As Tricky said, integers are initialized to the leftmost value of the range, also in Quartus synthesis. Thus to or downto definition makes an important difference.

[Altera_Forum]

OK, thanks a lot for clearing this up :D  

I will definitely check out that safe state machine option.  Now I'll try to capture that glitch in SignalTap somehow... I'm not really familiar with state-based trigger flow so I might as well educate myself about it too.