Vivado Behavioural Simulation vs Post-Implementation Timing Simulation

[Luke Abela]

Good day,

I would like to enquire regarding the Vivado 2018.3 simulation tools. I typically use the behavioural simulation in order to verify my logic, however, I recently attempted using the post-implementation timing simulation and was met with significantly different results. Could someone kindly breakdown what may lead to such an outcome?

Thank you and regards,

Luke Abela

 

[JColvin]

Hi @Luke Abela,

I'm not a simulation expert so I'm not able directly answer this, though this forum thread may be of interest to you: https://forum.digilentinc.com/topic/16679-thoughts-on-simulation/.

Thanks,
JColvin

[zygot]

5 hours ago, Luke Abela said:

I recently attempted using the post-implementation timing simulation and was met with significantly different results.

In short the post-implementation, or timing simulation takes into account the delays associated with the actual synthesis and logic placement. It is a more accurate picture of how robust your design is. While the behavioral simulation has to account for clocked delays like registers it is naive about routing delays. Generally, behavioral simulation is good for checking logic. Of course it's only as good as your testbench. If you are doing serious work then formal methods are better for catching events or conditions that you might not have thought about.  

For designs using a high percentage of resources timing simulation is more important and worth the extra step. Sometimes you don't have access to the innards of IP and a timing simulation is the only route to fixing problems. 

[Luke Abela]

17 hours ago, zygot said:

In short the post-implementation, or timing simulation takes into account the delays associated with the actual synthesis and logic placement. It is a more accurate picture of how robust your design is. While the behavioral simulation has to account for clocked delays like registers it is naive about routing delays. Generally, behavioral simulation is good for checking logic. Of course it's only as good as your testbench. If you are doing serious work then formal methods are better for catching events or conditions that you might not have thought about.  

For designs using a high percentage of resources timing simulation is more important and worth the extra step. Sometimes you don't have access to the innards of IP and a timing simulation is the only route to fixing problems. 

The design I`m working involved high speed digital signals to the tune of 400 MHz, so what you are suggesting that routing delays may be an issue definitely sounds likely. My question now is how should I alter my design in order to accommodate such issues? Is it a matter of using the constraints wizard, or rather, will I have to manually configure which CLBs are used and which aren`t?

[zygot]

45 minutes ago, Luke Abela said:

Is it a matter of using the constraints wizard, or rather, will I have to manually configure which CLBs are used and which aren`t?

You're probably expecting this; the answer is " it depends". I've posted project designs for the Genesys2 with some logic clocked at 600 MHz without having to intervene with synthesis constraints. I did have to tweak the synthesis and implementation settings though. What this depends on are things like:

• how much of your design is clocked at a frequency near the device maximum
• the speed grade of your device
• routing to resources like block memory and DSP slices that are in fixed locations in the device. The more resources  you use and how you use them make a difference.
• HDL design and coding style.

I've done designs requiring manual logic placement constraints and have seen quite a few more. Fortunately, the synthesis and implementation tools are pretty good at this for the majority of designs. Diddling with the synthesis and implementation settings, in my experience, is generally of minimal benefit. If you are having problems maintaining a reasonable timing margin in a design then restructuring the design or choosing a different approach is often the quickest way to fixing it. Timing constraints are tricky because they are more of a "wish list" than a constraint. It's been a long time since I've run into a vendor tool that quits because it is unable to meet a timing constraint; it just does the best that it can and reports failing paths. At least you have a list of nets to focus your attention on.

Read the datasheet for you device, paying attention to the AC switching specifications for the resources that you are using. In general generic FPGA platforms don't use the fastest speed grade devices. Cheaper devices families are generally harder to use for high performance designs than more expensive device families.

 

[xc6lx45]

Just to mention the basic rule of synchronous logic design: Static timing analysis guarantees your signals being stable within the setup-/hold period around the clock edge but it says nothing whatsoever about the time in-between. For example, it's a fairly common and nasty surprise when e.g. driving the (edge-sensitive!) clock input of an external 74595 shift register or the like.

I'd spend time with constraints first, and be prepared for a somewhat steep learning curve (e.g. learning by trial-and error is not straightforward).

Depending where you are, there may be unexpected payoffs e.g. you realize that the worst timing challenges in your design that cause 3x P&R time were caused by a LED and / or a switch that can be easily taken care of with false_path... I find it strange that there is so much online material about HDL language coding and so little about timing constraints unless I visit e.g. the Xilinx forum.

[xc6lx45]

PS there are a few "pragmas" that can be used to overcome the above problem, e.g. DONT_TOUCH  to prevent a register from being shifted in retiming to enforce outputs being free of combinational logic that could cause hazards (alternatively, instantiate an output cell) and ASYNC_REG for metastability-hardened placement of synchronizer registers.

[Luke Abela]

At the crux of it all, we`re talking about simulations with varying levels of details in regards to their considerations.

I have attempted an alternate design which does not require timing constraints from the wizard in order to meet its timing requirements, however, I am still reaching the same issue regarding a mismatch in my simulation results. I have also spent time with the previous iteration fiddling with constraint parameters and was met with little reward. I don`t suppose there any obvious of generic approaches to fixing this issue. I have struggled to find comprehensive literature or guidance regarding such discrepancies... perhaps I`m not looking correctly?

[zygot]

36 minutes ago, Luke Abela said:

I have struggled to find comprehensive literature or guidance regarding such discrepancies... perhaps I`m not looking correctly?

Unfortunately, FPGA vendors aren't too keen on educating customers about how to effectively develop applications for their products. I suppose an analogy is all of the books and third parties helping Microsoft customers use its products. It's a big problem for everyone, except the vendors who generally ignore this aspect of the design process.

My experience is that in industry people learn from co-workers and accumulated corporate experience. I suppose that there are sources available on the internet but I don't have anything currently available to point to. Reading through FPGA vendor Application Notes and, when available, studying example designs sometimes provide clues for advanced timing closure.

Perhaps if you post the exact discrepancies that you are having trouble with someone reading the post will have helpful suggestions for addressing and maybe resolving them. Currently, what you've said isn't very detailed.

[zygot]

In my experience post-routed timing simulations treat the design as somewhat like a black box in that a lot of the source code signal names have disappeared. So you are driving inputs and looking at outputs. You can do timing simulations on individual pieces but the results aren't the same when everything is combined into a whole design.