WP_Term Object
(
    [term_id] => 34
    [name] => Ansys, Inc.
    [slug] => ansys-inc
    [term_group] => 0
    [term_taxonomy_id] => 34
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 261
    [filter] => raw
    [cat_ID] => 34
    [category_count] => 261
    [category_description] => 
    [cat_name] => Ansys, Inc.
    [category_nicename] => ansys-inc
    [category_parent] => 157
)
            
3dic banner 800x100
WP_Term Object
(
    [term_id] => 34
    [name] => Ansys, Inc.
    [slug] => ansys-inc
    [term_group] => 0
    [term_taxonomy_id] => 34
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 261
    [filter] => raw
    [cat_ID] => 34
    [category_count] => 261
    [category_description] => 
    [cat_name] => Ansys, Inc.
    [category_nicename] => ansys-inc
    [category_parent] => 157
)

Peering Over the Timing Edge

Peering Over the Timing Edge
by Bernard Murphy on 05-03-2018 at 7:00 am

I wrote recently about a yield problem which mobile vendors have been finding for devices built in advanced technologies. This was a performance issue (the devices worked fine at lower clock speeds), pointing to a discrepancy in some devices between predicted and observed timing. These were experienced design teams, using state of the art timing flows and libraries and yet performance yield was 10% lower than expected. This should raise a concern – are we approaching a point where current approximations for timing are becoming insufficient for signoff?

21591-variation-aware-analysis-min.jpg

When we started analyzing timing, back in the days of really small circuits, we used SPICE. Designs grew, SPICE was no longer practical for full-circuit analysis, so we switched to cell-based design, with cells characterized for timing (ultimately in the Liberty format), with which we could do static timing analysis (STA) and drive timing-based synthesis and physical design. Those timing models have evolved through multiple versions as processes have shrunk and manufacturing variabilities have become more important, but we’ve still managed to retain the concept of cell-based timing models in some form, albeit more complex and requiring more corners to fully capture process variations. Factors which cannot be captured at the cell-level, such as power noise, have been managed by setting global margins and ensuring that IR-drop (in the power-noise case) does not stray outside those margins.

But the non-cell-based factors are becoming more troublesome at advanced processes where nominal voltages are much closer to threshold. Now noise, both in power and ground, can squeeze actual potential differences below threshold, pushing delays and slew rates well outside the nominal characterization range. Compensating by further increasing global margins becomes prohibitively expensive in power routing, decaps and ultimately total die cost. Which means we now must deal with instance-based and use-case-sensitive modeling; cell-based timing models, complemented by margins, are not sufficiently accurate for cost-effective design.

I doubt this is a cliff-edge in timing. The Liberty style of modeling (with many corners) still works well for huge designs on the most advanced processes. But we’re starting to see evidence, as I mentioned in that earlier blog, that accuracy is deteriorating noticeably (10% performance yield hit) at the fringes. Over time hopefully the library solution will improve further but that’s not a near-term fix. Monte-Carlo SPICE (MC-SPICE) can be used today but even in massive parallelism will be bounded to hundreds of paths, not very compelling on the mega-designs of today with potentially tens of thousands of paths near-critical.

21591-variation-aware-analysis-min.jpg

Of course, there is another solution, one I’ve written about before – the FX platform from ANSYS. FX doesn’t look at Liberty models or faked waveforms. It does transistor-level modeling of the circuit with analog waveforms, Miller capacitances and the like. It’s not SPICE but it’s close – within 2% accuracy when compared with SPICE on one 7nm example operation at 435mV (sub-threshold). And it runs much faster than MC-SPICE, able to analyze up to 10K paths per hour.

Better yet, FX can model both voltage and ground noise accurately with real use-case waveforms. It’s integrated with the RedHawk product family – RedHawk and RedHawk-SC – for detailed IR-drop analysis and DvD-aware clock-jitter analysis. It can also do aging analysis, looking at per-transistor degradation (increase in Vt) as a result of use-case-dependent electrical stress.

Clearly even at this performance, FX doesn’t replace STA for bulk timing on SoCs. But when it comes to signoff for paths close to critical, higher accuracy will be necessary, with higher throughput than you can get with MC-SPICE. Why not just stick to Spicing a few hundred paths? If STA+Liberty was sufficiently accurate you could, if you knew for certain that no other paths were near-critical. But as outlined above, the standard flow isn’t sufficiently accurate near-critical. So you need check a larger selection of paths. Remember that what should be checked can’t be judged solely by how close STA says the path is; you also must consider use-cases which may promote big IR-drops and ground bounces. ANSYS mentions a customer example: a path thought to be just fine, which proved to be a real problem in a realistic use-case.

Over the long-term, where might this go? No doubt the STA/library model approach will continue to improve but there has to be some upper bound to acceptable model complexity given bounded return in accuracy for those models. That said, there is too big an investment in cell-based design and STA-based signoff methods to abandon this methodology. Perhaps there will be a shift over time to using Liberty-style models and STA for the bulk of the timing heavy-lifting, complemented by SPICE or FX-like methods for signoff near the margins.

You can watch a detailed webinar on the FX platform HERE.

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.