Uninitialized reg in simulation vs. synthesis

[hinxx]

Complete n00b in Verilog asking a question here, so bear with me please. I have no prior experience in FPGAs/Verilog/VHDL, I do in C, though.

I'm playing around with a FPGA board from Olimex, https://www.olimex.com/Products/FPGA/iCE40/, and have managed to put the blinking LEDs demo into the board ; and they blink .

I'm trying to understand the demo code as seen here https://github.com/OLIMEX/iCE40HX1K-EVB/blob/master/demo/ice40hx1k-evb/example.v.

For example, how the uninitialized reg:

Code: [Select]

reg [14:0] cntr;

is never assigned a value of 15'b0, yet it is incremented in the always block:

Code: [Select]

cntr <= cntr + 15'd1;

and appears to be starting from 0?! 

When I try to use iverilog and vvp to simulate the design the cntr is left at 15'bx, while on the hardware cntr clearly seems to take on a specific value at the start. I assume this value is 15'b0. Is this correct? Where does it come from? I assume this is done during the synthesis process, but fail to pin point down in which part.

Information I managed to get so far is that in synthesis "x is ignored", at least the assignment (with some exceptions); have not found the answer about the initial value though, if not initialized explicitly. Is there a better explanation to get from somewhere? I would also be interested in a list of differences between the simulation and synthesis of the Verilog models (i.e. what can and can not be done in one vs the other).

[tggzzz]

Since I don't know the toolset and hardware you are using, this is a generic answer.

Synthesis ought to create a netlist and components from the information in your design, no more no less.

Simulation ought to show values that are unknown, except when and where definite values can be computed from the design and execution. For example an 8-stage shift register with the serial input tied low should start out with all outputs unknown. After each clock one more output will be low, until after 8 clocks they will all be low.

Hardware will always power up in one state or another. The precise state will either be guaranteed in the datasheet, or random in the sense that you cannot rely on the state. Any given register will probably start in the same state every time - but you should not presume what that state will be.

For example, a 3 bit counter might start as 0 or 1 or 6 or 7 etc. After 8 clocks it will again be 0 or 1 or 6 or 7. Nonetheless, the simulator ought to show the count as unknown for all time.

[hinxx]

Since I don't know the toolset and hardware you are using, this is a generic answer.

It is yosys, arachne-pnr, icepack based toolchain and the chip is Lattice iCE40HX1K. For simulation I use iVerilog and vvp along with GTKwave.

Simulation ought to show values that are unknown, except when and where definite values can be computed from the design and execution. For example an 8-stage shift register with the serial input tied low should start out with all outputs unknown. After each clock one more output will be low, until after 8 clocks they will all be low.

I think I can understand that. And it makes sense; I'm seeing this in vvp outputs and waves in GTKwave as well. Where I fall short in understanding is how does the chip manage to get out of the unknown value. I was thinking that the toolchain would set up some 'sane' defaults for the hardware in synthesis process, whereas for simulation designer has to explicitly perform the task of initialization.

Hardware will always power up in one state or another. The precise state will either be guaranteed in the datasheet, or random in the sense that you cannot rely on the state. Any given register will probably start in the same state every time - but you should not presume what that state will be.

Does that mean that the iCE40HX1K chip once programmed will determine the startup (initial) values of the uninitialized regs.. in some startup sequence or similar?

For example, a 3 bit counter might start as 0 or 1 or 6 or 7 etc. After 8 clocks it will again be 0 or 1 or 6 or 7. Nonetheless, the simulator ought to show the count as unknown for all time.

Yes, I've been seeing unknown for the cntr in question, when running simulation, and as far simulation goes I'm fine with it.

[mfro]

... Where I fall short in understanding is how does the chip manage to get out of the unknown value...

The chip itself does know a value. It doesn't know anything else than 0 or 1 (so, depending on your toolchain and hardware, it might be *any* value or even 0 as intended).

Basically identical to using an unitialized variable in C. You won't do that there as well, don't you?

[tggzzz]

Since I don't know the toolset and hardware you are using, this is a generic answer.

It is yosys, arachne-pnr, icepack based toolchain and the chip is Lattice iCE40HX1K. For simulation I use iVerilog and vvp along with GTKwave.

Simulation ought to show values that are unknown, except when and where definite values can be computed from the design and execution. For example an 8-stage shift register with the serial input tied low should start out with all outputs unknown. After each clock one more output will be low, until after 8 clocks they will all be low.

I think I can understand that. And it makes sense; I'm seeing this in vvp outputs and waves in GTKwave as well. Where I fall short in understanding is how does the chip manage to get out of the unknown value.

See below. The hardware is always in a valid state. Exceptions: metastability and input signal integrity failures.

I was thinking that the toolchain would set up some 'sane' defaults for the hardware in synthesis process, whereas for simulation designer has to explicitly perform the task of initialization.

No.

Only the designer can define what a "sane" value might be.

Hardware will always power up in one state or another. The precise state will either be guaranteed in the datasheet, or random in the sense that you cannot rely on the state. Any given register will probably start in the same state every time - but you should not presume what that state will be.

Does that mean that the iCE40HX1K chip once programmed will determine the startup (initial) values of the uninitialized regs.. in some startup sequence or similar?

RTFDS If it doesn't say anything, you can't assume anything.

Part of the art is reading what a data sheet does say. The other part is reading what it does not say.

In general it is good practice to explicitly force a device into a known state. That "reset" can be done whenever convenient and/or necessary.

For example, a 3 bit counter might start as 0 or 1 or 6 or 7 etc. After 8 clocks it will again be 0 or 1 or 6 or 7. Nonetheless, the simulator ought to show the count as unknown for all time.

Yes, I've been seeing unknown for the cntr in question, when running simulation, and as far simulation goes I'm fine with it.

That sounds as if the simulator presumes something about the hardware initialisation state. Is there any reason to believe that the hardware's behaviour will always match the presumption? Personally I would distrust a simulation where the outputs don't start as "unknown" - until after the device has been reset.

In a professional context, that would not pass a design review. Predictability and repeatability are very important.

[asmi]

Some FPGAs do not support register initialization from bitstream, so unless you know for sure that your target device does support it, it's wise to include a startup reset code which will place your design in known initial state.

[hinxx]

Thank you all!

In short my cntr initial value could be anything at start. It would eventually wrap at 15'd24414. I guess the only side effect, in this case, might be reaching the wrapping point sooner in the first iteration, whereas for subsequent iterations it counts from 0 to 15'd24414.

Takeaways:
* do not assume what uninitialized bit value is - can be 0 or 1 depending on the toolchain output and/or hardware
* implement init of the regs at reset time
* try to extract the default state (if any) from datasheet

 

If I would like to see if my toolchain does it, does anyone know, how to look it up? In which phase could I see that?

.. off to read some hardware datasheets ..

[fourfathom]

With the Lattice FPGAs, the registers are physically initialized at startup,  From this document (http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/EH/HDLSynthesisCodingGuidelinesforLatticeFPGAs.ashx?document_id=4815):

For all Lattice Semiconductor FPGA devices, the Global Set/Reset (GSR) is pulsed at power-up, regardless of the function defined in the design source code.

The synthesis tools I've used for Lattice take this into account.  I wouldn't depend on this if your design doesn't self-correct for a random state at startup. 

[tggzzz]

Takeaways:
* do not assume what uninitialized bit value is - can be 0 or 1 depending on the toolchain output and/or hardware
* implement init of the regs at reset time
* try to extract the default state (if any) from datasheet

Good to see a student that thinks, asks, listens

If you do rely on the default state, then document that very carefully. That will help someone else, or help you in a year's time, or help when moving the device to a different toolset.

As an example of why only the designer can specify a sane initial value, consider an FSM implemented using the "one hot" design pattern. That's particularly relevnt for FPGAs, and each state is encoded as a different flip-flop output being active. Clearly not having any outputs active (or more than one active) is an invalid violation of the design pattern.

[Bassman59]

This is the reason why all digital logic designs require a logic reset -- to get all of the registers into a known state.

Some FPGAs, like Xilinx and Lattice, support an internal global reset (GSR) that is asserted after configuration. You determine the states to which the flip-flops are set or reset at that time by writing initializers in your code.

In VHDL that's simply:

    signal foo := std_logic_vector(7 downto 0) := "10100110";

where the := "10100110" is the initializer.

Sorry, I forget how to do this in Verilog.

Other FPGA families, like MicroSemi ProASIC-3, require an explicit reset to come from somewhere. In this case, you can use one of those little reset supervisor chips which hold their output asserted for some time after power supplies are stable. You connect that to an input on your FPGA and you use it as a global asynchronous reset, and you then write your Verilog appropriately. In your @always block you add the reset signal on the sensitivity list and code the reset condition to set all signals to the desired reset state.

(There are good arguments to be made about synchronizing an external reset, but let's leave that alone for now.)

Anyway, reset is very important. The thing with the GSR initializer is that people forget that it's actually a reset.

[BrianHG]

In verilog:

reg      [14:0]   cntr = 15'd0 ; // 15'd0 initializes the power-up default to decimal 0.


reg      [14:0]   cntr = 15'bxxxxxxxxxxxxxxx ; // 15'bx initializes the power-up default value to an undetermined state.

This is useful in simulation because in the output waveform, you can track when that register was first assigned a value via actual code.  So, if somewhere in the beginning of your functioning code, if you have a reset pulse somewhere in you simulation setting the reg to 0, but not at powerup, or if you forgot to assign a value of 0 to this variable during the reset itself, you can now see the mistake in your simulation.

[hinxx]

Again, I really appreciate the responses here. Thank you all!

With the Lattice FPGAs, the registers are physically initialized at startup,  From this document

GSR would explain it. I have not seen the linked doc before as it did not appear in the list of docs under the iCE40HX1K part  . The HX1 family doc mentions GSR as well, but I could not grasp the concept due to being flooded with this new terminology about the FPGAs .

.. I wouldn't depend on this if your design doesn't self-correct for a random state at startup. 

I do not quite understand the above statement. Are you saying that I should defer the initialization to a dedicated reset procedure (presumably handcrafted) just to be sure that it happens and does the right thing(r)?

From what I've been hearing here, and reading some of the Lattice docs, I think one can drive perform the GSR from the HDL code. How is that done? In the suggested code

    signal foo := std_logic_vector(7 downto 0) := "10100110";

where the := "10100110" is the initializer.

I fail to understand what signal/wire/register foo is actually driving. I'm not asking about the VHDL vs. Verilog syntax differences here, but how does the "10100110" actually perform GSR, if at all? Is "10100110"  some kind of a magic value perhaps? OTOH, docs are also saying that several external pins can perform the GSR for my part.

[tggzzz]

Are you saying that I should defer the initialization to a dedicated reset procedure (presumably handcrafted) just to be sure that it happens and does the right thing(r)?

That is good practice.

You remove all sorts of assumptions and misunderstandings.

You can invoke it at any time in an operational system, e.g. if a watchdog times out or an FSM enters an invalid state.

[NorthGuy]

Are you saying that I should defer the initialization to a dedicated reset procedure (presumably handcrafted) just to be sure that it happens and does the right thing(r)?

Reset and initialization are two different things. Initialization assigns the value when you design start. Reset is a signal (or many signals in a complex design) which assigns known values to registers when it is asserted. Initialization is free - these are just configuration bits which either can be 0 or 1 in your bitstream. Reset requires resources - at the very least the reset signal must be distributed through the fabric.

Therefore, if you don't need reset, then use initalization - initialize everything as you want, don't do the reset. In simulation, you will see everything already initialized from the start.

If you do need a reset, it is better to keep only one copy of everything. Otherwise, there may be differences in how your design behaves when it comes from reset compared to the behaviour after the start. Therefore, don't use initialization. Instead, start in reset, then release the reset when needed. This guarantees that your design always go through reset. Do not reset everything, only what you need - often most of the logic is "do not care" and there's no need to assign it at reset - this is just waste of resources. In simulation, if you spot something undefined, which you need initialized, add the corresponding assignment to reset.

[tggzzz]

Are you saying that I should defer the initialization to a dedicated reset procedure (presumably handcrafted) just to be sure that it happens and does the right thing(r)?

Reset and initialization are two different things. Initialization assign the value when you design start. Reset is a signal (or many signals in a comnplex design) which assign known values to registers when it is asserted. Initialization is free - these are just configuration bits which either can be 0 or 1 in your bitstream. Reset requires resources - at the very least the reset signal must be distributed through the fabric.

Therefore, if you don't need reset, then use initalization - initialize everything as you want, don't do the reset. In simulation, you will see everything already initialized from the start.

If you do need a reset, it is better to keep only one copy of everything. Otherwise, there may be differences how your design behaves ehen it comes from reset compared to the behaviour after the start. Therefore, don't use initialization. Instead, start in reset then release the reset when needed. This guarantees that your design always start in reset. Do not reset everything, only what you need - often most of the logic is "do not care" and there's no need to assign it at reset - this is just waste of resources. In simulation, if you spot something undefined, which you need initialized, add the corresponding assignment to reset.

It is worth noting that a reset doesn't have to affect all registers.

Consider a pipelined design with 10 stages. It is sufficient if the reset only changes the first stage register, provided that you specify last state register isn't used/examined until after 10 clocks have occurred.

[SiliconWizard]

Long story short: as you clearly identified it, this is an uninitialized register. As such, any decent simulator will see it as "X" (unknown state).

But synthesized on a given FPGA - it depends! Many FPGAs just reset all flip-flops right after configuration, so if not explicitely initialized, they are likely to start with a value of zero. When this is not the case, obviously on real hardware, any register WILL have a value, even if it's not zero, so the design per se can't be stuck (whereas in simulation, if a register is X, then incrementing it will have no visible effect (will keep being X until explicitely assigned a value.)

Some FPGAs/vendor tools allow explicitely initializing registers/signals within the HDL code (as suggested above). This approach will work both in simulation and on many (but not all) FPGAs.

Otherwise, the proper way of dealing with initialization would be to implement a reset state in your code.

Then whether you *really* need to initialize a given register/signal depends on your design. It's not necessarily the case. At least not necessarily at a common "reset" event. You don't need to initialize a signal early if it's going to be used many clock periods after a "reset" for instance. You can assign it an initial value in some kind of FSM instead for instance. Or, in some cases you actually don't care about the initial value. Say you're using a counter to flash a LED or something - initializing the counter may not matter as you may not care about the very first "flash" period.

But as I said first, if you don't initialize a given signal, you may still have simulation issues - so all in all, the common approach to this is - either you initialize it upon a "reset" state (asynchronous or synchronous), or initialize it at the declaration level - then it's likely to work on many FPGAs, and even if it doesn't (and as long as it doesn't matter), it will at least make the simulation work.

[fourfathom]

.. I wouldn't depend on this if your design doesn't self-correct for a random state at startup. 

I do not quite understand the above statement. Are you saying that I should defer the initialization to a dedicated reset procedure (presumably handcrafted) just to be sure that it happens and does the right thing(r)?

There are some good explanations above.  Here are some additional thoughts on the subject:
* You may want to simulate with a different toolchain, or target a different device, and the physical or simulated global reset or other initializer may be different.  In this case having an explicit reset or initialization in your design will ensure predictable states.

* If your design uses logic that would become stuck in in an improper state by, say, a cosmic ray hit or other Random Act of God, then even an initial reset will not protect you.  You need to decode all illegal states and restore proper operation.  I've seen this in design reviews where there are two counters that are initially synched and offset in a particular state and rely on this forever.  The only way to correct a random error was to reset the entire system --not good.  I made the engineer redesign it.  I'm sure you can think of other designs that might be sensitive to this (one-hot circulating shift registers, etc.)  Of course this issue is valid regardless of whatever form of initialization or reset you have.

[radar_macgyver]

Xilinx recommends that you avoid the use of an async reset if possible, and try instead to use the GSR mechanism to ensure the registers are at a known value. This is because an async global reset net is by definition a high-fanout net, and will be difficult for the tools to meet timing. That said, I try to use an explicit async reset in all my designs, maybe because I'm oldschool?

https://www.xilinx.com/support/documentation/white_papers/wp272.pdf

[tggzzz]

Xilinx recommends that you avoid the use of an async reset if possible, and try instead to use the GSR mechanism to ensure the registers are at a known value. This is because an async global reset net is by definition a high-fanout net, and will be difficult for the tools to meet timing. That said, I try to use an explicit async reset in all my designs, maybe because I'm oldschool?

https://www.xilinx.com/support/documentation/white_papers/wp272.pdf

The other reason is that an async reset is, um, asynchronous. Hence there is the possibility that the releasing the reset won't meet a register's setup and hold times, which might lead to behaviour that depends on the device/temperature/phase of moon.

There is a place for asynchronous logic, but those with a solid base in theory will know that it is extraordinarily difficult to get correct - and even then "correctness" presumes that only one input changes at any one time (which is unrealistic except in synchronous logic!).

So, keep async signals to an absolute minimum (i.e. inputs and clock-domain crossing logic), and use metastable-resistant design where they have to be used.

[SiliconWizard]

Xilinx recommends that you avoid the use of an async reset if possible, and try instead to use the GSR mechanism to ensure the registers are at a known value. This is because an async global reset net is by definition a high-fanout net, and will be difficult for the tools to meet timing. That said, I try to use an explicit async reset in all my designs, maybe because I'm oldschool?

https://www.xilinx.com/support/documentation/white_papers/wp272.pdf

The other reason is that an async reset is, um, asynchronous. Hence there is the possibility that the releasing the reset won't meet a register's setup and hold times, which might lead to behaviour that depends on the device/temperature/phase of moon.

There is a place for asynchronous logic, but those with a solid base in theory will know that it is extraordinarily difficult to get correct - and even then "correctness" presumes that only one input changes at any one time (which is unrealistic except in synchronous logic!).

So, keep async signals to an absolute minimum (i.e. inputs and clock-domain crossing logic), and use metastable-resistant design where they have to be used.

There's room for some debate here - and this has already been discussed a few times here, and a lot of times everywhere. But you're essentially right.

There's at least one case for which an async reset can't be avoided - to ensure a definite state in the absence of a clock. There are designs in which some clock may not be running at all times. If there's at least one clock that is continuously running, then you can work around this by using this one clock to reset whatever state needs to be reset in another clock domain (making sure you handled domain-crossing properly), but there are cases for which there is just one clock that may not be running at all times, and you may thus need an async reset at some point to get the system in a definite state. I've had the case a few times.

[NorthGuy]

This is because an async global reset net is by definition a high-fanout net, and will be difficult for the tools to meet timing.

I've never needed global reset, never used it. If I need to start over, I can always re-configure.

I only use resets in different local modules, such as FSM may need a reset etc.

[filssavi]

While this might make the code a little less portable, I tend to avoid resets where possible and rely on GSR mechanisms (Xilinx’s one namely) as the reset network can start to cause issues when pushing for 200+ MHz, as the fanout is extremely large and a large portion of the design will be affected by it

[tggzzz]

Xilinx recommends that you avoid the use of an async reset if possible, and try instead to use the GSR mechanism to ensure the registers are at a known value. This is because an async global reset net is by definition a high-fanout net, and will be difficult for the tools to meet timing. That said, I try to use an explicit async reset in all my designs, maybe because I'm oldschool?

https://www.xilinx.com/support/documentation/white_papers/wp272.pdf

The other reason is that an async reset is, um, asynchronous. Hence there is the possibility that the releasing the reset won't meet a register's setup and hold times, which might lead to behaviour that depends on the device/temperature/phase of moon.

There is a place for asynchronous logic, but those with a solid base in theory will know that it is extraordinarily difficult to get correct - and even then "correctness" presumes that only one input changes at any one time (which is unrealistic except in synchronous logic!).

So, keep async signals to an absolute minimum (i.e. inputs and clock-domain crossing logic), and use metastable-resistant design where they have to be used.

There's room for some debate here - and this has already been discussed a few times here, and a lot of times everywhere. But you're essentially right.

There's at least one case for which an async reset can't be avoided - to ensure a definite state in the absence of a clock. There are designs in which some clock may not be running at all times. If there's at least one clock that is continuously running, then you can work around this by using this one clock to reset whatever state needs to be reset in another clock domain (making sure you handled domain-crossing properly), but there are cases for which there is just one clock that may not be running at all times, and you may thus need an async reset at some point to get the system in a definite state. I've had the case a few times.

Accepted, although I haven't personally come across that situation.

There is one other reason for forcing a reset, even in a system like the OP's where there is a free-running counter and the hardware/system doesn't care its initial phase.

ATE test vectors do require such a counter starts in a defined phase, so that it can pass/fail the counter at predetermined clock cycles.

[mfro]

The other reason is that an async reset is, um, asynchronous. Hence there is the possibility that the releasing the reset won't meet a register's setup and hold times, which might lead to behaviour that depends on the device/temperature/phase of moon.

There is a place for asynchronous logic, but those with a solid base in theory will know that it is extraordinarily difficult to get correct - and even then "correctness" presumes that only one input changes at any one time (which is unrealistic except in synchronous logic!).

Altera/Intel FPGA FFs do have an asynchronous CLR that will be used as reset input. If you really need a reset, it is usually advisable to use that one (as synchronous resets eat up extra resources).

They provide an application note with a safe sample implementation (search for AN545).

And the problem is not the async reset itself, but the need to get out of it in a synchronous way...

[Berni]

This sync vs async reset thing comes up a lot because Xilinx(never use async) and Altera(use async) have conflicting recommendations for it.

The reasoning behind Altera recommending async reset is because they have a dedicated async reset input on the logic blocks that goes directly to the flipflop. So adding a reset does not introduce any extra logic and so does not reduce performance. It does consume some wiring resources to wire them up tho, but can be routed using global clock routing line if needed to act like a GSR line.

As for "But its async! What about hold time violations?!", well being async doesn't mean you just run that reset line directly out to a pin. There is often a synchronize that syncs the edge up to a clock, this makes things a lot more predictable. The compiler can make multiple instances of this synchronizer next to the logic to improve timings. You can also put multiple synhronizers in yourself to be able to match them into various clock domains. The point to it being async is that it is not part of the LABs synchronous timing path.

Usually large blocks of logic coming out of reset on two different clock cycles is not an issue, but if they are required to come out of reset precisely together, then you baked this interdependancy into the very functionality of your logic. In that case you forced the compiler to meet timing closure across the multiple large blocks just by the way you designed it.