What is the difference between throughput and operating frequency of a digital system?

Question

I am designing a digital system with 2 pipeline stages. While synthesizing the design in Xilinx ISE, I find that the latency of the critical path is 19ns. The clock period estimate for my design is showing to be 7.329ns (frequency: 136.449MHz). My confusion is isn't the clock period of my system supposed to be greater than the critical path delay (19ns)? Also I understand that throughput is 1/max latency. What is the difference between operating frequency and throughput?

EDIT: So what basically I am designing is a multiply-accumulate circuit. The multiplier is a pure combinatorial block with delay of 19ns, has two inputs from 2 registers, say A and B. The output of the multiplier goes to the product register, say P, which is connected to the adder(pure combinatorial, delay of 18ns). The multiply-accumulate module has been designed using state machines. I expected the clock period estimate to be greater than 19ns, but timing report suggests otherwise (7ns).

Answer 1

Far too little information in the question, but...

if that 19ns path is a pure combinational critical path, then yes the clock period must be greater than 19ns.

Another way of looking at it : an overall circuit latency of 19ns and a clock period of 7 ns implies 2 pipeline registers in that 19ns path. (delay between 2 and 3 clock cycles).

Note there are pitfalls synthesising pipelined circuits... here's one, which is my best guess given the scant information...

Clock constraints only cover paths between source registers and destination registers. It looks as if - in your example - the longest path between one register and another is 7 ns, allowing that as your clock period.

It does NOT cover paths from:

• an input port to a register
• a register to an output port
• an input directly to an output bypassing all registers.

These CAN be addressed by a more complex set of constraints, but if you are working on a module internal to the FPGA (part of a hierarchical design or a reusable component) there's a simpler way:

create a wrapper entity to instantiate the block under test. In the wrapper, register every input to the block, and every output from it - and clock these registers from the same clock as your pipeline.

This way, every I/O path into or out of the block is covered by the clock constraint and you will likely find your 19ns path is either

• optimised better to meet the fast clock constraint
• reported as a timing violation because it can't meet that clock constraint
• imposes a lower clock frequency at which this long path will meet timings

or possibly some combination of the above.

Now it is up to you to re-pipeline until you meet your goals.

---

There is a related problem for actual I/O pins to the FPGA device. These have their own delays, which can be mitigated with registers in the IOBs themselves. (Then you find relatively long routing delays from the more remote pins to the actual logic : in extreme cases you may need an additional pipeline stage to hide that delay from your pipelined logic).

---

Re: Edited question:

I don't know where your A and B registers are in the design, or how you manage to make a multiplier as slow as 19 ns, or why you aren't using an FPGA with DSP blocks purpose built for this task (and 10-20x faster). But if A,B and P are internal to your MAC and clocked off the same clock, yes you should see a clock period that covers the multiply.

How do you know the mult is really 19 ns? Have you examined the slowest path covered by the 7ns clock? Does that path actually run through the multiplier?

Is it possible you measured 19ns from IOB through mult to IOB in isolation (with no registers)? (There are synthesis options to allow testing blocks in isolation, without inserting IOBs.)

In that case it may be that eliminating the IOBs (and their delays!) and inserting the mult between A,B and P registers allowed a more optimal synthesis and placement, and actually meets a more reasonable 7 ns. But that again is speculation.

You'll have to learn to read the timing reports. and track the longest path from source register to destination register through the combinational logic in between.

Answer 2

Frequency in this context means clock frequency, and it is the frequency of master clock that synchronizes all of the logic in the system.

Throughput is how many output values are produced per second.

Latency is the delay from when a given input value is provided until the corresponding output value appears. In synchronous sequential systems the latency will usually be some integer number of clock periods.

Your computer might have a system clock frequency of over a gigahertz. The audio output typically has a throughput of something like \$44.1\,\text{ksps}\$ (kilosamples per second). It might take many clock cycles for your processor to compute what the next audio output will be. Suppose you are compressing some raw audio to an mp3. The latency of your compressor is the amount of time from when you supply the raw audio until the compressed result is available.

Answer 3

Yes, the clock period (times the multicycle factor, if any) is supposed to be greater than the path delay plus setup time between two registers that are connected and that use the same clock.

That is the simplest form of a timing constraint: switching a register causes the following combinatorial elements to cascade into a new state, which needs to be stable for the setup time of the next register to be taken over reliably.

Pipelining inserts register stages in the middle between combinatorial elements to shorten the register-register paths, so you have shorter latency between two stages of a pipeline, but each stage requires the signal to be stable for the setup time, so overall latency of the pipeline (= the latency of the steps, added) is longer.

Throughput is defined by frequency, because you can insert more data into the beginning of the pipeline with every cycle, and each stage will hand over its intermediate result to the next one at the same time.

One caveat: there is an option to build multicycle paths, where the enable signals to the registers are turned off for several cycles, allowing the combinatorics more time to settle. This will still use the full clock rate, but throughput is divided by the multicycle factor -- sending data to a disabled register causes the data to be lost.

Answer 4

I agree with Elliot Anderson in that throughput is the number of output values per second. So in that case throughput is context or usage/function dependent.

Take an FPGA design that's running with a clock of 100 Mhz. Now assume that the FPGA is determining parameters that need 10 operations (add, multiply, table look up) to calculate. You could fully pipeline the design, with one pipelined stage (reg->logic->reg) being used for each operation. In this case, once the pipeline has been filled, you get one value every clock, or 1 value every 10 ns, so throughput would be ~100 Mhz.

Another approach would be an ALU type design, where all the intermediate values are kept in the ALU until the final value is computed. In this case, it would take the FPGA 10 clock cycles to compute and output a single value. Throughput in this case would be 1 value every 100 ns (10 clock cycles), or 10 MHz.

Same functionality, same clock rates, but two different throughputs.