# Mixing reset and non reset registers

If you must mix synchronous reset and non reset flops in a single always block, would this be the correct way...

always @ (posedge clk)
if ( reset )
begin
resettable_flops    <= 0;   // Resettable to 0.
nonresettable_flops <= 'dx; // No reset function. Is this OK?
end
else
begin
// Functionality goes here.
end


EDIT: If I do not write the x assignment, ISE infers logic to not change the flop when reset is asserted i.e., !reset ends up driving the clock enable which I want to avoid since reset is high fanout and may affect timing. However, assigning 1'dx works and ISE does not use the reset in the timing path of nonresettable_flops.

• What technology are you synthesizing to? ASIC, FPGA, or CPLD? – The Photon May 28 '17 at 0:02
• @ThePhoton I am targetting FPGA. – Revanth Kamaraj May 28 '17 at 2:08

When FPGA/CPLD is being configured, every FF is set to defined state of 0 (however it may happen that this behavior can be tweaked).

I think that having digital signal or register in X (undefined) state is not what you want, and actually incorrect in real life, thus this X will not synthesize, however may work for simulation.

Furthermore, in your sample code you have synchronous reset, triggered by clk. If you do not want to change FF's state on posedge of clk when reset is high, just do not write assignment clause there.

Actually this Verilog code synthesizes into electronic circuit; it is not a program, and subject to different execution terms than usual computer program.

• You should bold the part about "if you do not want to change FF's state ..., just do not write assignment clause." – The Photon May 28 '17 at 0:29

In real life, there is no "X" as it has no meaning except in simulation where a signal is "unknown" either due to being uninitialized or multiple drivers. It is possible to get HDL/syn simulation mismatches, but likely ok, if X not causing issues in HDL sim.

• I think it is good practice to initialize all FFs. It shows intent and that it was explicitly considered as part of the design... even if it is 0
• I use asynchronous resets on IO, synchronous resets internally, with few exceptions and exceptions only with good reason. Asynch reset IO is good practice to keep from damaging IO, driving external parts, etc. Internal synchronous resets help achieve timing closure.

this is a good paper that maybe isn't exactly applicable to your question but maybe applies in some regard: Asynchronous & Synchronous Reset Design Techniques - Part Deux