0
\$\begingroup\$

Timing closure in FPGAs is a challenging subject. There are many guidelines, one of them: pipelining, is to introduce new registers in the data path so that the overall combinational logic gets distributed in a way that the critical path delay through the gates will be lesser than the clock period minus setup time.

Posting a snapshot of this video: Intel FPGA guidelines for timing closure

In this example a DFF is inserted at a desired position in the data path. My question is that, If I'm using a single 32-bit comparator or similar functionality, it usually gets implemented as a cascading chain of similar combinational logic cells in the post-fit netlist. I convey the desired comparator behavior using == or >= or <= or != or > or < etc. operators along with corresponding signals as a single line of code. How do I put a DFF somewhere between that operator? Or do I have to construct a gate level comparator and then manually put DFF at desired places?

What are the guidelines if I use a Boolean expression with multiple signals and multiple Boolean or arithmetic operators?

\$\endgroup\$
7
  • 1
    \$\begingroup\$ In addition to what Mikef said in his answer, you usually don't start going down this route until you do a place & route of your design at which time you have an idea of what your limiting path is, or what path(s) fail your timing constraints. \$\endgroup\$
    – SteveSh
    Mar 7 at 2:27
  • \$\begingroup\$ The current implementation violates the timing at some other point on the same datapath, not exactly at the point of combinational expression. What I am assuming is that if I am able to reduce the delay here, the PnR tool might get some exploratory freedom to route logic in a way that solves the issue occuring somewhere else in the same datapath. \$\endgroup\$
    – lousycoder
    Mar 7 at 7:05
  • 1
    \$\begingroup\$ I would not count on that. P&R and routing resources & the tools are pretty good with today's parts. So I would not expect that that freeing up resources in one place of the design would help with the timing in another place. You need to address the path that is failing your timing constraint. \$\endgroup\$
    – SteveSh
    Mar 7 at 12:56
  • \$\begingroup\$ When I see neg slack, I see that path delay is 25% of the value and clock skew contributes around 75% of the value, should I consider that skew here is the cause of timing violation? \$\endgroup\$
    – lousycoder
    Mar 7 at 15:27
  • 1
    \$\begingroup\$ Probably. But that tells me you have a poor clock distribution scheme. Most of today's FPGAs have dedicated, low skew clock distribution networks built into the FPGA fabric. Are you taking advantage of that, or are you treating a clock as just another signal? \$\endgroup\$
    – SteveSh
    Mar 7 at 16:08

1 Answer 1

3
\$\begingroup\$

Don't have go all the way to gate level. Break up a 32 bit compare into two behavioral 16 bit compares separated by a pipeline stage, and gated together as a fan in of 2 after the pipe.

Check out this tutorial video By Greg Stitt which discusses your issue. His solution is to work to reduce the size/width of the compare. Timing Optimization Tutorial

\$\endgroup\$
1
  • 2
    \$\begingroup\$ Many years ago (40+) we used this technique to improve the performance of a 16-bit adder, using 'als/s283s'. We built two 8-bit adders (lower 8 bits, upper 8 bits) with some pipeline registers between them in order to reduce the carry propagate time. \$\endgroup\$
    – SteveSh
    Mar 6 at 23:02

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.