difference between using reset logic vs initial values on signals

Question

Let's say I have a signal, I can either assign a initial value of zero OR I can set it to zero upon RESET. I've seen my co-workers using the two method interchangeably. I just want to see others opinion on this.

Example (using initial value):

architecture arch of xxx is

    signal flag : STD_LOGIC   := 0;

begin
    process (clk) begin
        if rising_edge(clk) then
            -- do something
        end if;
    end process;
end arch;

Example (using reset value):

architecture arch of xxx is

    signal flag : STD_LOGIC;

begin
    process (clk,rst) begin
        if (rst = '1') then
            flag <= '0';
        elsif rising_edge(clk) then
            -- do something
        end if;
    end process;
end arch;

Answer 1

If possible, use a dedicated reset signal, for several reasons:

• Designs using complex clock generation may require that a module is held idle (reset) until the clock is stable. Using initial values with an unstable but running clock may change the initial value from the expected.

• A module that interfaces to other or external modules may get protocol violations on an interface during startup, and to avoid wrong operation or hangup due to protocol violations, it may be required to hold the module in reset until the protocol operation is well defined in the interface.

• Restart of the entire system, or part of the system, is possible by asserting reset, instead of having to reload the entire FPGA, which takes much longer time, and may be more complicated if it requires CPU interaction.

• Some FPGA technologies, for example Altera partial reconfiguration, does not support initial values for the modules used in partial reconfiguration. Reuse of modules is therefore easier if only reset is used.

• Simulation of different start/restart conditions is easier when it is possible to apply reset, and continue the same simulation sequence. If initial value is used, then the entire simulation must be restarted.

Apply reset to as few flip-flops as possible, for the resource reasons that Russell points out. Also, applying it to only the required flip-flop, makes it easier to catch bugs and oversights in the design during simulation, since unknown X values may then appear. The reset should be asynchronous, since most FPGA and ASIC technologies have flip-flops with dedicated reset input, and the reset will then not slow down the timing of the synchronous design part, by insertion of logic to apply a reset value. The slow down can be seen in for example Altera Cyclone V, where logic is inserted in the data path due to the synchronous reset through a MLABCELL, as shown in the data path timing report here:

A flip-flop using asynchronous reset does not have this extra delay in the data path, as can be seen in figure through this link.

The process for flip-flops with reset should be written with the reset part as:

process (clk, rst) begin
  if rising_edge(clk) then
    -- Flip-flops updated at clock
  end if;
  if (rst = '1') then
    -- Flip-flops reset
  end if;
end process;

This coding style makes it possible to apply reset to only some of the flip-flops updated at the rising clock, while the remaining flip-flops are implemented without reset.

The combined if-then-elsif-end if in question code, actually specified that the state is held during reset for flip-flops that are not reset, since the rising_edge(clk) part of the if does then not take effect. This is probably not the intended implementation.

For proper timing, the reset signal (rst) should be synchronized to the clock (clk), at least for deassertion (1 to 0), so recovery and removal time are not violated.

Answer 2

'Value after FPGA configuration' vs 'Value after reset'

The initial value will be the value the signal will get after the FPGA configuration.

The value affected in case of a reset will be... the value the signal will get in case the reset signal is asserted :-)

About the signal value after FPGA configuration

From Xilinx "Large FPGA Methodology Guide" page 31 :

FPGA devices have dedicated global set/reset signals (GSR). At the end of device configuration, the GSR is automatically asserted to initialize all registers to the initial state specified in the HDL code.

Every register is at a known state at the end of configuration. You do not need to code a global reset for the sole purpose of initializing the device.

Of course, you need to trust the FPGA you use about this initial value. People often prefer to have a reset on control signals to ensure this out of configuration initial value, even if this is normaly not required...

To reset or not to reset

Maybe you need a reset for specific other reasons :

• coding rules that enforce this
• the necessity to set this signal back to a known value without having to reconfigure the FPGA

If you need this reset, it will probably be asserted when the FPGA go out of configuration, and the initial value will then be useless, so it is probably better to not use it.

Hope this helps.

Answer 3

I'm of the opinion that you should not reset any signals that do not need it. Only things like state machines or counters should be reset. Adding resets to everything means that the tools will have to add routing resources to hook up all of these resets. So for example I almost never reset any signal that just holds data, or some enable signal that will only be active for one clock cycle anyway.

Regarding initialization, I initialize every register that I infer. This can be easily checked by looking at a modelsim waveform. Red = Bad. This takes no additional resources to achieve, but it ensures that the FPGA starts up in a known-condition.