0
\$\begingroup\$

I'm a software guy by trade and I have been dabbling in digital design on FPGA using the open source toolchain. I have made a few designs and generally understand how the handle verilog and VHDL.

One of the things I'm wondering is not really a black and white question but rather I'm wondering whether there is a "best practice".

I generally divide the designs I make into modules. For example I have a uart that I can include in a design. Now the transmit part of the uart has a feedback mechanism that indicates whether it is ready to receive another 8 bit word to transmit.

Now I could choose to make either the input or the output registered essentially forcing a pipeline. However this would have some impact on users of the design. If I register the input or the output the feedback is always delayed by 1 clock cycle. This is not so bad and might even be what you want. But If both input and output are registered the feedback is delayed by 2 clock cycles which might be confusing for users.

Is there some kind of best-practice to follow here. As in most of the time register your input or your output?

Any help is appreciated!

\$\endgroup\$
2
  • \$\begingroup\$ I don't see how it might be "confusing". Whatever you choose, it will be reflected in the interface specification (documentation) for your module. Users will have to abide by that specification, whatever it is. \$\endgroup\$
    – Dave Tweed
    Jul 24, 2021 at 1:01
  • \$\begingroup\$ You decide. Just document the pipeline depth of each module; math modules may have much larger pipeline depths to achieve high throughput. \$\endgroup\$ Jul 24, 2021 at 12:24

1 Answer 1

1
\$\begingroup\$

UART might not be the best example to drive this question, since the external activities associated with a UART are generally so slow relative to the other activities internal to the FPGA that an extra clock or two in a handshake hardly makes any difference at all.

However, in the high-speed video signal processing pipelines that I build (the bulk of my work these days, it seems), I generally register the outputs of each module. Then any modules receiving these signals can use combinatorial logic on them without worrying about excessive input delays, glitches, etc.

Inputs get registered only if they are known to be coming from a different clock domain or a completely asynchronous source, in which case, I have a library of CDC (clock domain crossing) modules that I use.

\$\endgroup\$
2
  • \$\begingroup\$ Why the choose the output though? Wouldn't the same delay happen but at the input? \$\endgroup\$
    – John Smith
    Jul 24, 2021 at 2:31
  • \$\begingroup\$ Because it's easier to register the source of a signal, rather than doing it at all the places it might go. But it's just the convention that I have chosen -- you could choose a diffferent one. Either way, in the end, the design must meet all timing constraints anyway. \$\endgroup\$
    – Dave Tweed
    Jul 24, 2021 at 4:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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