Verifying multi-cyclicity of multi-cycle paths

Ok, here's a small variation on a previous post. My design is giving the wrong results in post-PAR simulation (no SDF errors or warnings, no timing violations in PAR), and I want to verify whether my multi-cycle paths are to blame. I would prefer to check this using behavioural code rather than the post-PAR model, because the latter takes days to run my complete testbench. How would you go about this? Post-PAR suggestions are also welcome, as are any other ideas as to the possible causes of such a discrepancy. Thanks in advance...

--
Pierre-Olivier

-- to email me directly, remove all _N0SP4M_ from my address --
Reply to
PO Laprise
Loading thread data ...

Have you thought about performing a timing simulation on just the part of the design in question? If the multi-cycle paths in question are contained within a single hierarchy (good design practice) or a few levels of hierarchy in the design, then that portion of the design can be separated from the rest of the design for a timing simulation if you retain that hierarchy of the design during implementation. To do this, you need to define the portions of hierarchy you wish to keep for verification by telling your synthesis tool to maintain the hierarchy for that instance (how this is done is different for each synthesis tool) and then you need to put a KEEP_HIERARCHY=TRUE attribute on that hierarchy as well in order to tell the P&R tools to maintain those boundaries as well. If you do this, when you generate a post-PAR simulation model, you can use the -mhf switch (Generate Multiple Hierarchical Netlist Files for the GUI) and generate separate smaller gate-level netlists and SDF files for each level of hierarchy you asked to maintain. This methodology can be a very useful in your situation and can cut your simulation times to a fraction of the time you spent simulating the entire design however you must have good hierarchy to begin with (not have timing paths that span many levels of hierarchy) and you must implement the design using this methodology. You do not need to specify to KEEP_HIERRACHY on every hierarchical block in your design and many times you do not want to but you should do so on blocks that can assist in verification. There are several references to this in the Xilinx docs and web site. Search for KEEP_HIERACHY and you should be able to find out more information on this if you are interested.

-- Brian

PO Laprise wrote:

Reply to
Brian Philofsky

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.