-1
\$\begingroup\$

I have written a combinational block which makes some math operations. What's the best way to calculate the time elapsed in that block?

Thanks in advance!

\$\endgroup\$

closed as too broad by Chris Stratton, Warren Hill, Finbarr, Dave Tweed May 17 at 21:31

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    \$\begingroup\$ Are you talking about propagation time? There is timing analysis available in most of synthesis tools. \$\endgroup\$ – Eugene Sh. Jan 16 '18 at 22:13
  • \$\begingroup\$ I think so. I just want to know how much time takes that combinational block in doing all the math operations and get the result \$\endgroup\$ – Jose de arimatea Jan 16 '18 at 22:16
  • 7
    \$\begingroup\$ Think about this: There's no time without hardware. Different FPGAs have different speeds. Different synthesis strategies will lead to different implementations, and so on. so, there simply can't be a general answer to your question other than: Tell your toolchain to make a timing analysis (but you probably already knew that). \$\endgroup\$ – Marcus Müller Jan 16 '18 at 22:17
  • 1
    \$\begingroup\$ Depends on 1) Optimisation goal 2) Chosen FPGA and speed grade 3) Synthesis and routing specifics chosen 4) RTL Coding . Timing analysis of design gives you the delays involved. \$\endgroup\$ – Mitu Raj Jan 17 '18 at 15:42
  • \$\begingroup\$ if/when you change the design you have to do the analysis again as all parts of the design can affect the overall routing and synthesis for a particular chip including this one block. Change something unrelated to your math block and it can affect how the math block is implemented for that build which affects timing/performance. Hopefully you get the idea that there is no answer to this, other than the execution time varies from build to build. \$\endgroup\$ – old_timer Jan 19 '18 at 3:24
0
\$\begingroup\$

You can't really. As mentioned there are different FPGA's, strategies etc. But even if you stick to one FPGA, the biggest time factor is the utilization. If you get 60%-70% it gets worse. Above 80% your timing can suddenly jump.

I have seen plenty of code which tested in isolation works fine but put it together with the other required 'stuff' (and of course all that 'stuff' is also timing critical) and it falls apart.

\$\endgroup\$
0
\$\begingroup\$

There's no real good magic bullet solution for this. Probably the best you'll be able to do is stick flip-flops on both the inputs and outputs and place and route the design for a candidate FPGA. Repeat this a few times with different timing constraints on the test flip flop clock to see how fast you can get it to go. Since place and route is timing-driven, the performance you get will heavily depend on the clock timing constraints. You'll also probably have to add some additional 'dummy logic' to prevent the synthesizer from optimizing things you don't want it to.

\$\endgroup\$

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