Is post-place and route simulation useful?

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

Reply to
GaLaKtIkUsâ„¢
Loading thread data ...

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.

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

Reply to
KJ

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?

Reply to
GaLaKtIkUs™

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

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

Reply to
Kim Enkovaara

Not so much for synchronous designs on FPGAs.

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.

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

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

-- Mike Treseler

Reply to
Mike Treseler

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

Reply to
Andy

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.

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.

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

Good point!

Hans

formatting link

Reply to
HT-Lab

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.