Verifying multi-cyclicity of multi-cycle paths

[PO Laprise]

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 --

 

[Brian Philofsky]

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:

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...