I have started to wonder what is the significance of the timing simulation for FPGAs nowadays. I can easily justify what is the idea behind that by quoting some Xilinx materials:

Performing a thorough timing simulation ensures that the finished design is free of defects that can easily be missed, such as the following:

  1. Post-synthesis and implementation functionality changes caused by the following: Synthesis attributes or constraints that can cause simulation/implementation mismatches, such as translate_off/translate_on or full_case/parallel case. UNISIM attributes applied in the UCF file or using synthesis attributes Differences between synthesis interpretation of language in different simulators

  2. Dual-port RAM collisions

  3. Missing or improperly applied timing constraints

  4. Operation of asynchronous paths

Howevery, I do not know any engineers or companies in my area that would perform timing simulations for FPGAs. They just assume that if the timing constraints are correct and there are no timing violations after the place and route, then everything is fine.

I can understand this approach as timing simulation can take a lot of time for complex designs and, to be honest, I have never heard or read any story that timing simulation for FPGA has helped in fixing some bug that wouldn't be a bug on the functional level of the design.

Can we just say that nowadays timing verification of the FPGA designs has been reduced to trusting outputs of the vendors tool chains?

  • \$\begingroup\$ I think it is exceedingly difficult to say that "the timing constraints are correct" with certainty, and that they cover all possible timing issues. This is really an opinion-based question, so I VTC. \$\endgroup\$ Jan 3, 2019 at 18:24
  • 1
    \$\begingroup\$ The assumption that everything is fine must be based on something. Like low clock frequency and good design. But the truth is sometimes idiots get to code FPGA. I once saw a code that was running with 1MHz clock, and still didn't fit timing. It took like ten compilations to get the code working somehow :) i left that company quickly \$\endgroup\$
    – user76844
    Jan 3, 2019 at 18:25
  • 3
    \$\begingroup\$ I'm with you. I've done dozens of successful FPGA designs, relying entirely on functional simulation and static timing analysis. Validating the results of a timing simulation takes A LOT of work -- especially to verify coverage -- you really need to know what you're doing, and it's rarely worth the extra effort. Without it, your design might end up being a little more conservative than strictly necessary, and only if you need to push the performance beyond that point would you do it. \$\endgroup\$
    – Dave Tweed
    Jan 3, 2019 at 19:00
  • 1
    \$\begingroup\$ Timing simulations might be needed for external interfaces. Timing simulations for FPGA internal parts has no advantages except for warming up your room. For item 2: The simulation model of Xilinx memories does not match the behavior of the real FPGA, that's why the PoC Library implements it's own simulation model according to the real behavior. \$\endgroup\$
    – Paebbels
    Jan 3, 2019 at 20:06

1 Answer 1


IO timing is of more concern than internal timing, because as you say, the tools are "good at it". Having said that, the tools are only as good as your constraints; you can reliably count on getting back the same errors you specified, just as you can reliably count on getting back, post-synthesis/PAR the same logic bugs that you didn't discover in rtl verification. According to Wilson Research survey that Mentor Graphics commissioned, timing errors are second only to logic errors as the cause of re-spins... ASIC or FPGA, no matter, you just spend less money and time re-spinning an FPGA. It is important to remember that the timing constraints are applied on the front-end of PAR as an input, and checked on the back-end against the PAR netlist results. That only guarantees that you got back what you specified.... miss a specification, or wrongly specify it otherwise, and you will likely have issues in hardware (#3 above). Minimizing clock domains and utilizing sequential design techniques are the best ways to avoid errors. Avoid transparent latches at all costs (sometimes you can't), and be diligent on clock domain crossings... you can "IGNORE" clock domain crossings in your constraint file if you have guaranteed, through design review and/or CDC tools, proper crossing techniques (i.e. Satisfy Nyquist... both of these are addressed in #4 above)

If you have built agents (UVM terminology... think "BFM" if not familiar with UVM) properly with timing, normally configured "OFF" for functional sim, and turned "ON" for the post-PAR netlist sim with back-annotation, you can find IO timing errors. Having said that, you are at the behest of the board designer to have provided the proper IO constraints... the agent to which you interface (a DSP, CPU, whatever) will have specifications for how the signals are delivered/received (min and max skews/timing), the trace will have some amount of delay (hopefully, "negligible", but easily accommodated in the top-level TB) and your ASIC/FPGA IO will have to accommodate the numbers the board designer gave you. If you are "in spec" and the agent timing is implemented properly, and you are having failures at the IO (maybe your verification person wrote assertions to capture these errors), you and the board designer are going to need to review his timing analysis. Point is, you/me prefer to do this in a back-annotated simulation where you have the visibility you need, not in the lab where you have to use scopes, etc.

I would suggest, unless you are responsible for integration too, that your goal is to stay out of the lab, and you do that by having a robust verification environment that allows you to find logic bugs and, maybe, timing errors.

Having said all of that, I don't think most people do back-annotated simulations until they have a HW issue and suspect timing.... it is nice though if the TB is already created to simulate with constrained-random timing based on the specifications.


Your Answer

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

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