Even from the early days of chip design the different tasks involved from architecture, logic design, layout and verification were accomplished in most part as individual efforts. The considerations of the “other disciplines” most of the time were not part of the equation in accomplishing ones task. “Once the logic design is done the back-end person can figure out how best to implement the layout”. When chip complexity and size were not so great we could get away with this kind of approach.
Today with large scale SOC designs and aggressive design targets, sophisticated nm technologies and schedules, this can no longer be the norm. More and more design tasks are being parallelized to compress design schedules. Design teams are much larger and can be located in different parts of the planet. The complex silicon technologies require deeper, more time consuming analysis of an increased list of parasitic effects such as cross-talk, inductive and capacitive coupling, junction leakage, etc. to achieve functional, performance and power design targets. In addition, sophisticated design tools produce volumes of analysis data over hundreds of modes and corners for each design flow step in the implementation process which allow engineers to evaluate if the design is converging toward budget targets.
So how can we manage this torrential flow of data in a way that keeps us on track and meet aggressive schedules? We need the ability to collect all this data from all project instances consistently from each design step, where ever it is produced, to a centralized location. The data needs to be organized in a way that allows review in a systematic approach from a project level to detailed issue presentation. The hundreds of analysis corners that may be generated for each flow step covering different process and operating conditions should be captured and organized for quick review. Important key metrics need to be displayed and highlighted making it possible to to make decisions where to focus first. As shown in Figure 1 below, the system should allow all aspects of the analysis data to be viewed in context (such as timing, layout, power, congestion, etc.) to see how different metrics could be contributing to specific issues. Historical data collected by such a system can then be compared by various analysis capabilities (tables, plots, metric aggregation, views) to assess metric trends and determine if the design is converging to expected targets. The system would enhance the ability to weed out non-issues from “project-critical” issues, allowing focus on key resolutions for the next pass of implementation. Finally, the system should help in constructing the current status and progress of the design and highlight problematic blocks that need further attention.
Figure 1
This integrated system would be useless without the ability to share the organized database with others to collaborate on issues, resolutions and trends as the design matures to completion. A centralized database where all team members can view the same picture of issues allows better decisions to be made and help with communication between disciplines (i.e. front-end and back-end).
With the ability to collect data from anywhere at any stage the flow, automatically keep track of design progress and analyze issues from an integrated view the prospect of meeting or bringing in schedules for these complex SOC design projects becomes more attainable.
Also, we’re going to be at the Design Automation Conference in San Francisco this year again. We will have a full presentation and demo agenda, a cocktail hour and prizes, join us!