Rescue Your Tape Out From False Path Timing Violations

Gate level simulation (GLS) can be a lengthy and tedious undertaking.  Tests can take hours or days in GLS with full timing values annotated.  With a debug loop measured in days, debugging a timing violation in GLS can have a huge detrimental impact to your tape out schedule.  But there are ways to reduce that impact and speed up the process.  Here’s one technique I developed for a recent project that made the difference in meeting our aggressive tape out schedule.

 

Scenario: Long Test, X-Propagation Near End

You’re running your GLS regression on the final post-layout netlist, and the longest test you have is expected to run for five days with SDF back annotation.  The test has been running for four days, making good progress,  and is still a day from completion. A timing violation has just occurred which propagates X’s and kills the test prematurely.  The cause is found to be a synchronizer flip flop or asynchronous false path which escaped earlier notice so it wasn’t included in the timing files that turn off X-propagation for such instances.  Your standard GLS flow would be to fix the timing file to add the newly found instances and remove the X-propagation, then rerun the test.

 

Problem: Tight Schedule

Any timing file change requires elaborating the DUT again and rerunning the simulation from time zero.  Tape out is two days away.  Restarting a five day test means slipping the schedule by at least three days, right?

 

Solution: Force The Notifier

Maybe not.  You did remember to save periodic checkpoints of the simulation state, didn’t you?  If not, you’re out of luck.  You’ll need to fix the timing file, elaborate the DUT, and rerun the simulation from time zero.  See you in five days!

Otherwise, create a Tcl simulation script with a restart from the latest saved time point before the timing violation. Immediately after the restart command, force the notifier signal of the flip flop with the timing violation to its current value.  Notifiers are located in the flip-flop cell model in the vendor standard cell library.  They are edge sensitive signals that tell the simulator that a timing violation has caused an X value to propagate to the instance output.  Forcing the notifier keeps the X-propagation from happening.  The timing violations will still occur and be reported in the log file, but the X-propagation from that instance will be disabled.  Make sure you get the correct notifier signal since some cell libraries use more than one.  Examine the library file for the cell type to get the correct notifier.

Chances are there are more than one instance you need to force.  In that case, you may need a list of instances and a loop in the Tcl script to apply the forces.  You may also wish to add dumping options so you can see that the fix worked properly, and/or add additional save points for the remainder of the test.

By using this method, you save four days of simulation time and get to immediately see if your fix is correct and sufficient.  If all goes well, your restarted simulation will finish in one more day without delaying tape out.  Don’t forget to update the timing files for the permanent fix!

 

Additional Topics

For more tips and tricks for conquering GLS methodology issues, please visit our website at www.CertusCG.com/Articles/.  We welcome your comments and suggestions for additional topics for future articles.  For this or for more information about Certus consultants and services, or to discuss your project needs, email us at info@CertusCG.com.