CODEWITHSUNDEEP
simulationfpgasynthesisasic
user2609910
user2609910

Reputation: 157

how to track errors in FPGA/ASIC development using post place'n' route and/or post synthesis simulation?

I am a bit confused on the usefulness of post PnR and/or post synthesis simulations for FPGA/ASIC development. If the synthesis or PnR process complete successfully in the design flow, is there any chance that the respective 'post' simulation will reveal errors in the design? Could someone give an example?

Upvotes: 4

Views: 276

Answers (4)

CapnJJ
CapnJJ

Reputation: 151

Mostly stable process in terms of translating the logic from mapped to PAR. But, of course, if pedantic, you could use a LEC for both syn->map and map-> PAR.

Post PAR Sims could be useful though if you have issues in the lab, maybe because you didn't fully constrain your design for timing, and need to simulate with the back-annotated SDF, as someone else mentioned above. This, of course, does not help you though, wrt to IO,h if you haven't created models with timing in your TB and/or constrained your IO properly as provided to you by the Board designer.

I think it is best-practice to run regression suite at least once against the PAR netlist with back-annotated SDF. It costs you nothing, and provides one more confidence data point.

Upvotes: 0

Shankhadeep Mukerji
Shankhadeep Mukerji

Reputation: 668

Post PnR simulations are what is called as Gate Level Simulation in industry. This is of two types timing and non timing. This kind of simulation is used to detect

  1. Timing paths, not checked by STA or timing closure.
  2. Bugs in power and reset operation as HFNS (High Fanout Net synthesis) and CTS (Clock tree synthesis) may have caused irregularities in the reset of some resettable flops causing them to deliver x to the next logic in the path causing an x-propagation.
  3. Bugs in DFT logic which was not checked during RTL simulation and might have been removed during PnR.
  4. x on logic path due to relaibility issues for clock domain cross paths skipped by STA

Upvotes: 1

FritzDC
FritzDC

Reputation: 507

In typical design flow post Synthesis and/or post PnR simulations are not useful and the aim should be to avoid them.

Post synthesis simulation can only unearth bugs in the, well, synthesis tool which are extremely rare in established FPGA tools. Checking these should not be an integral part of any design flow.

Albeit there are some very rare cases where the PnR tools might make e.g. technology mapping error or fail to give a warning from design rule violation, at minimum 99% of the cases that reveal problems in Post PnR simulation are due to design error, most typically clock domain crossing, memory access race conditions a good, but already very rare, second.

Therefore, the emphasis should be in adhering to the design rules and having rigorous design methodology to avoid the problems rather than trying to catch them in the post PnR simulation.

To your question - if there is no negative slack and the design rule check is ok, there should not be anything more that either of the post simulations can reveal.

One practical use for post PnR simulation is when you have complex design that is failing occasionally due to timing variation of an external component or mistake in I/O constraints, but you don't have a clue about the error mechanism. Combination of integrated logic analyzer and post PnR simulation can help the trickiest of situations to find out the root cause.

Upvotes: 1

user3885596
user3885596

Reputation:

Post-PnR simulations don't only verify the functionality, but also the timing. The timing information of the circuit can be dumped to the simulation in several formats, however the most popular one is Standard Delay Format (SDF), which is published as IEEE 1497.

What kind of errors can we catch then?

  • It is hard to catch some unwanted glitches in RTL simulations. If some outputs are generated by a combinational logic, post-PnR simulations are more important than ever.

  • There may be some mistakes in the synthesis and/or PnR constraints. It is always better to double check everything.

  • Synthesis/PnR tools may have bugs. Logic Equivalence Checking (LEC) can also catch bugs, but it performs for functionality only.

Upvotes: 1

Related Questions