I'm designing an adder in VHDL, and I've come across several VHDL designs (not necessarily adders) that include a reset port. My adder has input and output registers. Should all designs include a reset signal? What is the use of this reset?

Edit:

Resetting the carry_out makes sense to me, because some systems would handle that as an exception. What about the input registers and the sum output?

• If they have state, they should have a Reset signal. Does your adder have state? – user_1818839 Sep 2 '16 at 23:14
• The adder has input and output registers – gilianzz Sep 3 '16 at 11:38

Pretty much every design that has a register or a latch should have a reset. Now whether or not that reset is anything more than the power-on-reset of the FPGA is another question.

The following is a not-complete list of places which should always have a specific reset (either power on or design specific such as push button), and places where it probably doesn't matter so much.

Reset a must:

• Control Signals - any signal which controls the flow of data through a system should have a reset signal to ensure that they are in a known state. For example, if you have a register which when high ends the world, you probably want to know that it won't be high when you turn it on.

• Data Valid Signals - any signal which indicates that data on a bus is valid. If you reset the circuit, you want to know that no data bus is marked valid unexpectedly (e.g. data loading into FIFO).

• Counters - things that count should probably have a reset so that you know what value it started counting at. For example if you have a counter for a clock divider, you probably want it to always start at the same point after reset to ensure deterministic behaviour.

• State Machines - most have an IDLE state which is entered after power on or reset to wait for some event to occur. These should therefore have a reset

Reset is optional:

• Some Data Buses - I say some. Any which are qualified by a valid signal (see above) don't really need reset signals, and not adding them can save routing pressures and timing issues with reset signals, expecially on large data buses. The reason they aren't required is because the valid signal should have a reset. Whenever the valid signal indicates the bus is invalid, any downstream logic should be designed to not rely on the value of the data - the data is effectively don't care. It is assumed that you will change the value of the register anyway before you assert valid.

• Pure Combinational Circuits - Any stateless combinational circuit. There is no point having a reset because the output of the circuit depends only on the inputs - there is no way of having an invalid/unknown value after power on.

• Non-Critical Registers - For lack of a better term. Basically anything where you have verified in your design that it works fine regardless of what value in on the register - i.e. you don't care what the value is. For example if you want to test an adder circuit as in your case and are simply buffering and output input signals, then a reset is not really necessary.

There are probably more for each list, but that is a good starting point. If there are any key places I've missed, let me know in the comments.

• While having a reset signal on every state element is certainly a design paradigm you can follow (which works very cleanly), it is also very possible to simply write the proper data in at the first cycle; ignoring the initially random states. I don't think it's fair to say it is necessary. – jbord39 Sep 2 '16 at 23:33
• @jbord39: How exactly do you identify the "first cycle"? – Dave Tweed Sep 3 '16 at 0:12
• @DaveTweed: Well there are numerous ways to do this. An RC network could always be used. Or you could have a reset on some of the states but not all of them. One example could be a skewed memory node which always starts up at one state, but can be toggled upon completion of the first (or any subsequent) cycle. Another example could be a counter which is does have a reset @ powerup. But that does not mean every single state needs a reset. I also mentioned it is the most clean way I know of. But it is not necessary. Boxing yourself in like that will only stifle creative design. – jbord39 Sep 3 '16 at 0:19
• @jbord39: Ah, so you're talking about the same kind of "bootstrapping" that Simon Richter describes. Your comment, taken at face value, seemed to be implying that you could do away with reset altogether. – Dave Tweed Sep 3 '16 at 0:28
• I'll accept the answer if you could answer the following question: My adder has input (a and b) and output (sum and carry out) registers. Should they have a reset? I can see why the carry out should deserve a reset: some systems execute an exception handler if there is a carry_out (overflow), but what about the other ports? – gilianzz Sep 3 '16 at 22:53

I recently had a discussion with Altera about the exact same subject. Interestingly, they say you do not actually need a reset signal on FPGAs, as long you as set a default state for your registers. This is because the FPGA can guarantee its internal state when power is applied.

In a sense, you are using the FPGA POR circuitry as your reset. You can just cycle power to reset the FPGA. On the other hand, having a reset is always good practice. Especially if you are planning to migrate to ASICs or different FPGA manufacturers.

• This is device-specific, not true of FPGAs in general. Also, it is not so much the "power-on" default you are using, but rather the state left at the end of configuration. – Chris Stratton Sep 3 '16 at 14:58
• Yeah, that is what I meant. But all FPGAs are guaranteed to be configured as specified, aren't they? You set a register with a default state of 1, and that will be the case after configuration. – user110971 Sep 3 '16 at 15:02
• You are assuming that is a feature that they all support in some way. I seem to recall some that did not, but not the specifics. Related, there are quite a few FPGAs (including from Altera) where some of the internal RAMs cannot be initialized from the configuration. – Chris Stratton Sep 3 '16 at 15:34

Edit: clarify that it's not individual state machines' state that is invalid, but the whole system's.

Reset signals are needed for systems containing state machines when there are invalid system states. Possible examples would be

• protocol engines that count bits: sender and receiver need to agree where bit 0 is.
• a computer is reset: now its interrupt handlers are no longer able to service interrupt requests, so no further requests should be generated.

Invalid states are entered either because the registers are set to random values during powerup, or because of bugs or external influence (e.g cosmic rays flipping bits).

The reset logic only needs to change those registers that have an actual influence on the external behaviour, so there is usually no need to define reset states for every register (although several modern FPGA architectures have a dedicated reset distribution network so no additional resources are consumed here).

For example, a processor design would guarantee only that the program counter would be set to the reset vector, and the execution mode set to supervisor mode. The user registers do not need to be reset, because boot code is expected to overwrite them anyway.

Whether your adder needs a reset signal depends on the way it is designed. A purely combinatorial adder doesn't have any state, so there is nothing to reset.

If the output is registered, you could add a reset that clears it to zero, but I'd normally clear it to 'U' to cause an error in simulation if that value is propagated to an output port.

If your adder has additional state (for example, there are adder designs that only have a single input port, and add the value there to their accumulator), then you'd need a reset to clear the accumulator. Whether that reset is connected to a chip-wide reset, or generated by the next enclosing entity depends on the design.

• I disagree somewhat with your first paragraph. A state machine definitely needs a reset to get it into the correct initial state, but as far as getting out of invalid states, that should be implicit in the state machines's design -- e.g., if you're using an HDL case statement, there should always be a default: or a when others => clause to catch invalid states and do something appropriate. – Dave Tweed Sep 3 '16 at 0:04
• @DaveTweed, yes, I can see how that wording is suboptimal -- it's the entire system that's in an invalid state (e.g. interrupt source turned on, but no handler installed, or DMA engine on but no memory reserved) -- for individual components of the system, there may not even be an invalid state, but we still need a reset signal to get it consistent with other modules. – Simon Richter Sep 3 '16 at 0:54