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;
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.
'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 :
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With