In digital design, the output signals may have source in register or perhaps some combinatorial logic which is directly connected to an output port. This raises these questions:

  1. How important is it to always register outputs, even when they are generated from purely combinatorial process?
  2. How important is it to register input signals before they are used inside an entity/module?

The design may appear to work correctly even if input/output signals are not registered. However, adding registers ultimately adds latency but can also lead to higher fmax or help the fitter/floorplan stage. So in this way, there is a trade-off. Because of this, the correct answer to this question is not clear.

EDIT: Please note that I am referring to entity/module created in hierarchical designs. This is not specific to top level entity/module in a design.

  • 5
    \$\begingroup\$ Anywhere between hardly important at all and vital. The devil's in the detail and not really in the generics. \$\endgroup\$
    – Andy aka
    Dec 2, 2021 at 15:37
  • \$\begingroup\$ There is no reason to register purely combinatorial circuits. fmax is meaningless in that context. Registers make sense when your circuit is pipe-lined/sequential (clocked). \$\endgroup\$
    – Eugene Sh.
    Dec 2, 2021 at 15:44
  • \$\begingroup\$ No I mean that the final output may come from a purely combinatorial process, which will then go into another entity/module to be processed. \$\endgroup\$
    – gyuunyuu
    Dec 2, 2021 at 15:45
  • 1
    \$\begingroup\$ Depends how you expect to consume it. Think of a basic AND gate. Can you think at which cases you would add a register on it's output and in which you wouldn't? \$\endgroup\$
    – Eugene Sh.
    Dec 2, 2021 at 15:46
  • \$\begingroup\$ Inputs? Absolutely Vital for asynchronous external control or handshake inputs (i.e. from pins). Outputs? Meh. Registers in IOBs give much cleaner timings (closer to the clock edge) which can help the external design. But for low speed externals, may not be necessary. Internal blocks in a fully synch design? Whatever is needed. Hierarchical blocks can be much easier to optimise with the clean timings that output registers give them. \$\endgroup\$
    – user16324
    Dec 2, 2021 at 18:49

2 Answers 2


For internal blocks, I focus on having one register in the path. Typically at the output, but I try to stay flexible when there is a small amount of combinational logic following a flipflop.

As a general rule, this will help prevent the new designer mistake of creating infinitely long combinational logic paths through the design.

For a large chip, with flip-flops at or near subblock outputs, you can synthesize the subblocks early to get timing information about that subblock. If the subblock makes timing plus margin for routing delay and flip-flop propagation delays, then it is more likely that when the chip is assembled you will meet timing.

OTOH, if your chip is small, and you are always synthesizing the whole thing together and timing is not a large concern, then you can get by with a less structured approach.

WRT flip-flops on the input as well as output, if your block to block routing delays are large relative to your clock frequency, then you may find you need these. It will be a function of your clock frequency and your target device.

For IO of the design, I register all inputs where possible and likewise for outputs. This simplifies characterization of the design. I have had designs where we had to have simulations that triggered the 6 slowest and 1 fastest path to each IO. If there is a register in the path, there is only one path.

Registers with load enables that only update when necessary on outputs can reduce the power of your chip.

  • \$\begingroup\$ Registers with load enables, such as a DFFE (DFF with Enable), seem to get misunderstood. The Enable isn't an optional extra lying around unused by the compiler, waiting for a designer to decide to use it for power etc. They're synthesised routinely. A VHDL 'if' clause in a clocked process that conditionally assigns to an output synths to decision LUT(s) driving the Enable of the output DFFEs. The DFFEs don't load unless the decision is met. They're not going spare. They're a naturally-used part of synchronous logic design - that's why the FPGA/CPLD manufacturers use registers with Enables. \$\endgroup\$
    – TonyM
    Dec 8, 2021 at 21:32
  • \$\begingroup\$ @TonyM Not sure what your point is. I don't just have extra if clauses lying around in my clock processes. I consciously choose to either have or not have load enables. The point being that on outputs, choosing to load outputs only when the output needs to be updated can save you power vs. let them update even when the interface is inactive and will not impact correct functionality. \$\endgroup\$
    – Jim Lewis
    Dec 9, 2021 at 17:06
  • \$\begingroup\$ Well, my point looks very clear. Don't get the 'if' bit except you've missed the point. But try looking at the actual RTL that VHDL designs produce (not just yours, let's widen it). You'll find it's not as you're describing. \$\endgroup\$
    – TonyM
    Dec 9, 2021 at 17:20
  • \$\begingroup\$ The load enables that my designs have and that my colleagues have are the ones that were intentionally placed there - because we envisioned the hardware and coded to that plan. They are not just there by happen stance as you seem to imply. That is non-sense. And I have spent close to 30 years coding VHDL and reviewing code. It would be nice if you discard your sneering, condescending attitude. \$\endgroup\$
    – Jim Lewis
    Dec 9, 2021 at 19:28
  • \$\begingroup\$ Sorry you went for anger and personal attack in an electronics discussion. It's certainly at odds with the site guidelines. I'm looking at an RTL view of a large circuit right now, which does what I described all over the place. It's not my opinion and you can find it, too. And not by 'happenstance' - register enables were designed in by the chipmakers for the purposes I described. The alternative (synthesis not routinely using enables) is DFFs continually clocked, needing value-preserving feedback logic, which mows through FPGA/CPLD resources. Not my view of it, s'what Quartus/Vivado/etc do. \$\endgroup\$
    – TonyM
    Dec 9, 2021 at 20:57

The correct answer is not clear because there is no single correct answer.

There are guidelines and techniques for good digital logic design. There are known pitfalls and problems that produce bad digital logic design. These apply to a whole digital logic circuit.

Your question's tagged VHDL and FPGA. So you're talking about use of VHDL entities ('modules') and their ports. Those VHDL structures allow a single digital circuit to be divided up into smaller parts, to assist development, testing and reuse.

(If by 'ports', you mean only top level ports for pins, that's something different. But I'll stick with all entity ports.)

How that dividing up is done is totally up to the VHDL designer(s). There's nothing in VHDL that enforces how it's done. So where the entity boundaries are within the single final logic circuit being designed is also up to the designer(s).

Adding unnecessary registers between entities causes unnecessary delays, wastes registers and makes some circuit designs impossible. That may be inconsequential for some designs and damaging for others but it's not a good design target.

Leaving off registers for clock-multiple signals to/from I/O pins can cause glitching outputs and metastable inputs. Again, that may be inconsequential for some designs and damaging for others but is not a good design target.

Some designers have entity I/O techniques they work by, some companies have standards governing them. But there is not a single definitive answer for VHDL partitioning.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.