I'm just getting into FPGAs, and if I understand correctly, you are connecting logic gates together using code. So if I design a CPU in Verilog, it should connect some logic gates together and work, but how do I know how fast my DIY CPU can run? What does it depend on?

  • 12
    \$\begingroup\$ @KingDuken I am curious about the alternative to Verilog for designing something like CPU you have in mind (not VHDL I presume :) )? \$\endgroup\$
    – Eugene Sh.
    Commented Jul 15, 2019 at 18:16
  • 1
    \$\begingroup\$ @KingDuken That's not the problem I'm having, I already made my CPU and it's architecture on breadboard and want to port it to an FPGA. My question is, how can I calculate what the maximum frequency clock for my CPU would be, what limits it? \$\endgroup\$
    – user138530
    Commented Jul 15, 2019 at 18:17
  • 4
    \$\begingroup\$ You might want to google "static timing analysis" \$\endgroup\$
    – The Photon
    Commented Jul 15, 2019 at 18:36
  • 14
    \$\begingroup\$ @KingDuken As someone who has designed two CPUs, it is not really that time consuming. You can have a working processor in 1-2 months, if you know what you are doing. \$\endgroup\$
    – user110971
    Commented Jul 15, 2019 at 22:03
  • 2
    \$\begingroup\$ @KingDuken Fun fact: Sun/Oracle has released the Verilog source code to their UltraSPARC T1 and T2 processors. I happen to have seen several in person, and they all worked. FYI, they even went to win SPECint_rate2006! :D That clearly shows how impossible it is to design CPUs in Verilog or other HDLs. I've done so myself a couple times as a hobby, and it really isn't anything impossible (once you grok it, as always) \$\endgroup\$ Commented Jul 15, 2019 at 23:09

3 Answers 3


The speed of a design is limited by several things. The biggest will most likely be the propagation delay through the combinatorial logic in your design, called the critical path. If you use a fast FPGA and write your HDL very carefully, you could probably hit 700 MHz on something like a Virtex UltraScale+. On a lower end FPGA, for example a Spartan 6, a reasonable figure is probably more like 250 MHz. This requires pipelining everywhere so you have the absolute minimum amount of combinatorial logic between stateful components (minimize levels of logic), low fan-outs (minimize loading on logic elements), and no congested rats-nests (efficient routing paths).

The fabric logic of different FPGAs will have different timing parameters. Faster, more expensive FPGAs will have smaller delays and as a result can achieve higher clock frequencies with the same design, or run a more complex design or design with less pipelining at the same frequency. Performance within a particular process can be similar - for example, Kintex UltraScale and Virtex UltraScale are made on the same process and have similar cell and routing delays. It is impossible to say how fast a given design will be without running it through the tool chain and looking at the timing reports from the static timing analysis.

When doing toolchain runs to determine maximum clock speed, bear in mind that the tools are timing-driven: they will try to meet the specified timing constraints. If no timing constraints are specified, the result can be very poor as the tools will not try to optimize the design for speed. Generally, the tools will have to be run several times with different clock period constraints to find the max achievable clock frequency.

If you can optimize your design so that the critical path is not the limit, then you'll run in to limitations in the clock generation and distribution (PLLs, DCMs, clock buffers, and global clock nets). These limits can be found in part datasheets, but getting near them with a non-trivial design is difficult. I have run stuff on a Virtex UltraScale at 500 MHz, but this was only a handful of counters to provide triggering signals to other components.


You synthesize your design in the target technology (a particular FPGA) and let the static timing analysis tools tell you what the minimum clock period is.

Or, you add constraints to the design in the first place, and then the tools will let you know whether they're met or not.

  • \$\begingroup\$ What would cause the constraints to not be met? What limits the clock period? Is it dependent on the FPGA I use or is it the same for the entire family of FPGA's?(Or maybe for every FPGA in existence?) \$\endgroup\$
    – user138530
    Commented Jul 15, 2019 at 18:18
  • 3
    \$\begingroup\$ It depends on the speed of the FPGA, and how much combinatorial logic you put between FFs in your design. \$\endgroup\$
    – Dave Tweed
    Commented Jul 15, 2019 at 18:25
  • 9
    \$\begingroup\$ @appmaker1358, have you tried to read the datasheet for an FPGA? Speed rating is one of the most important parameters called out in the datasheet. \$\endgroup\$
    – The Photon
    Commented Jul 15, 2019 at 18:37
  • 2
    \$\begingroup\$ The speed will be limited by the longest timing path, which will be the longest propagation delay through the logic and routing between two stateful elements (flip flops, RAMs, etc). Different FPGAs will have different timing parameters and hence a design will achieve different speeds on different FPGAs. There are some parts of the FPGA that are frequency limited though - clock distribution components and PLLs usually have limits, but it's difficult to write HDL that gets near those for non-trivial designs. \$\endgroup\$ Commented Jul 15, 2019 at 18:40
  • 3
    \$\begingroup\$ Also, you always need to add timing constraints. The placement and routing take the constraints into consideration and work to try to meet them. If you don't add any constraints, the tools won't try very hard and you won't get a very optimistic number. \$\endgroup\$ Commented Jul 15, 2019 at 18:58

The speed that your CPU will run will be based on your longest flop-to-flop delay in your synthesized design. The flop-to-flop delay will include clock-to-Q, routing, logic/LUT, and flop setup time. These added together form the critical path of your timing, which you can inspect in the timing report output by the place-and-route tool.

There are entire design disciplines devoted to making architectures that minimize this delay to get the most out of a given process - pipelining, parallel execution, speculative execution, and so forth. It's a fascinating, involving task, wringing that last ounce of performance out of an FPGA (or for that matter, an ASIC.)

That said, FPGA vendors will give different speed grades for their parts, which correspond to a max MHz rate. For example a -2 Xilinx Artix is a '250 MHz' part roughly speaking although it's capable of higher clock rates for highly-pipelined designs.

When you interact with the FPGA synthesis and place-and-route tools, you will need to give constraints for your design. These tell the tool flow the target flop-to-flop delay you're trying to achieve. In Quartus (Altera) and Vivado (Xilinx) these constraints use a syntax called SDC, which stands for Synopsys Design Constraints. SDC came initially from the ASIC world and has been adopted by the FPGA industry as well. Get to know SDC - it will help you get the results you want.

Altera and Xilinx have online communities for help with how to use SDC syntax and many other topics.

That all said, if you care about speed you should consider an FPGA that has a CPU hard macro in it, such as Zynq.


Your Answer

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