Is post-place and route simulation useful?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,
Is the post place&route simulation so important?
IMHO doing post synthesis (or post translate) simulation for verifying
behavior than doing a post place and route static timing analysis is
sufficient and less resource consuming than doing a timing simulation.
Moreover if errors are found during timing simulations (by errors I
mean X or false results) they are almost always (for my cases)
difficultly traceable.

Mehdi


Re: Is post-place and route simulation useful?
Quoted text here. Click to load it
Once one is sufficiently skilled I would agree....at least for FPGA
designs.  For ASICs where the cost for fixing an error is much, much
higher one might have a different opinion.

Quoted text here. Click to load it
Which sounds like you're maybe not quite there on the 'sufficiently
skilled' front since you still get 'X' or false results.  Definitely a
pain in the rear to trace back to the root cause through the post-
route sim I agree.

KJ


Re: Is post-place and route simulation useful?
Quoted text here. Click to load it
What I meant is that if I see X or errors in post place and route
simulation than fixing them is almost impossible in reasonable time
(for me). But if I do timing analysis and fix all errors than do
timing simulation than the timing is true.
So to reformulate clearly:
Is it sufficient yo do post-synthesis simulation (of course after
having validated the design by behavioral simulation) + static timing
simulation to guarantee working design? in other words is it possible
to skip timing simulation this way?


Re: Is post-place and route simulation useful?
Quoted text here. Click to load it

I'd say that both simulations are usually not necessary with FPGAs. RTL
simulations and STA analysis should be enough almost all the time.
Netlist simulations verify the synthesizer and timing constraints.
Formal equivalence checking might be faster way to verify RTL->netlist
synthesis results. And usually for FPGA the timing constraints are
not as complicated as with ASIC (no need for the process variation
analysis etc.)

Quoted text here. Click to load it

That is the problem with netlists. I have spent weeks wondering what
happens inside ASIC netlists, where the X propagates and how
to fix them. NRE for ASIC is so high that netlist simulations
are important, but just for timing constraint verification, and
to catch stupid errors that are related to IO and test structures
that are inserted in by automatic tools.


--Kim

Re: Is post-place and route simulation useful?
Kim makes an excellent point: timing constraints are the biggest
reason for an experienced designer to run (or not run) post-route
timing simulations.  While most clock and IO constraints are pretty
straight forward and seldom cause a problem, false-path and multi-
cycle constraints are easily specified erroneously, and lacking
specialized formal tools to check/generate them, the only way to
verify them is with post-route timing simulations.

For that reason, If I don't need a multicycle or false path
constraint, I don't use it. I will put in a significant level of extra
work in the implementation to avoid them if necessary, and thus avoid
the need for post-route simulations.

That said, novice designers should run post-synthesis or post-route
simulations just to make sure they're not doing something stupid in
their synthesizable code.

By focusing on much faster RTL simulations (especially if you use
integers, variables, and only clocked processes wherever possible),
more "corner cases" can be covered in less time.

This should be obvious, but Static Timing Analysis is mandatory,
regardless of whether you run a full timing simulation.

Also, this holds for FPGA development where the cost of failure is
usually rather low, compared to ASICs. That said, there are some
rather expensive OTP FPGAs that would fall more under the ASIC
verification model, where full timing simulations are justified by the
NRE to fix a problem during hardware test/integration.

You have to ask yourself what kind of problems you are trying to
detect/prevent: design specification problems, verification problems,
tool problems (simulation, synthesis, P&R, STA, etc.), and what are
their relative probabilities as well as cost of detection vs cost of
repair?

Andy


Re: Is post-place and route simulation useful?

Quoted text here. Click to load it

Focus from Fishtail will find most MCP and FP's in your design and generate
a bunch of PSL/SVA assertions to verify them. Assertions are great for
validating MCP/FP's. If you are a burn and go kind of engineer than you can
use Temento's Dialite to convert your MCP/FP assertions into hardware
monitors and check that during hardware testing none of them triggers.

Quoted text here. Click to load it

I would also add that gatelevel (structural) can be useful if your design is
not working on "the board" (STA is all happy) since the whole chain from RTL
to bitstream is not flawless and bad logic can be introduced during any of
the intermediate stages. I know that gatelevel simulation is dead slow
especially if you are using Vital but sometimes you need to run a gatelevel
simulation to answer the above question.

Quoted text here. Click to load it

That reminds me of my first Radition Tolerant 1020 from Actel, at 1000 a
pop (10 years ago) ...... those were the days of real FPGA's :-)

Quoted text here. Click to load it

Good point!

Hans
www.ht-lab.com


Quoted text here. Click to load it



Re: Is post-place and route simulation useful?

Quoted text here. Click to load it

Not so much for synchronous designs on FPGAs.

Quoted text here. Click to load it

A gate level sim tells me nothing
about behavior that I didn't learn from my code sim.
It may be a valid check-off item at release time
for the reasons that Kim mentioned.

..  then doing a post place and route static timing analysis

This is essential.

Quoted text here. Click to load it

and STA finds all timing problems, where
a timing sim is lucky to find any.

Quoted text here. Click to load it

Yes, and the root cause is almost always
the testbench or a vendor sim model,

 -- Mike Treseler

Site Timeline