Scaling Methodology Scaling Methodology Dan Smith Director HW - PDF document

EDP- -2002 2002 EDP Scaling Methodology Scaling Methodology Dan Smith Director HW Engineering dsmith@nvidia.com Introduction NVIDIA NVIDIA’s growth Methodology Group NVIDIA’s methodology beginnings How the methodology has changed Philosophy Practicality Examples What’s the future like EDP-2002 1

NVIDIA Characteristics NVIDIA is the global leader in advanced graphics processing technology for mainstream platforms GPU’s, Platform Chipsets, XBOX chipset Frequent design refreshes Large, complex designs Verilog RTL and C++ behavioral COT back-end Design team primarily in Santa Clara, but reasonable number of people in other areas EDP-2002 NVIDIA Growth NVIDIA has grown significantly in many dimensions over the last 5 or so years Revenue 1600 1400 1200 1000 Millions 800 600 400 200 0 1996 1997 1998 1999 2000 2001 2002 EDP-2002 2

Design Growth Many simultaneous design projects Design complexity is growing Size in Millions of Transistors 70 60 50 40 30 20 10 0 RIVA 128 RIVA TNT RIVA TNT2 NV1 NV2 GeForce2 GeForce3 XGPU GeForce 256 EDP-2002 Compute Server Growth NexGen2 Tape-out 2000 NexGen1 Tape-out 1800 1600 XGP Tape-out 1400 IGP/MCP Tape-out 1200 GeForce3 Tape-out Number of 1000 CPUs GeForce2/MX Tape-out 800 GeForce2/GTS Tape-out 600 GeForce256 Tape-out RivaTNT Tape-out 400 Riva128Zx Tape-out RivaTNT2 Tape-out 200 0 Aug-97 Jan-98 Feb-98 June-98 Aug-98 Nov-98 Feb-99 May-99 Aug-99 Oct-99 Nov-99 Feb-00 Aug-00 Sept-00 Oct-00 Nov-00 Feb-01 June-97 July-97 Sep-97 Oct-97 Nov-97 Dec-97 Mar-98 Apr-98 May-98 July-98 Sep-98 Oct-98 Dec-98 Jan-99 Mar-99 Apr-99 June-99 July-99 Sep-99 Dec-99 Jan-00 Mar-00 Apr-00 May-00 June-00 July-00 Dec-00 Jan-01 Mar-01 Apr-01 May-01 June-01 July-01 Aug-01 Sept-01 Jan 02 Sparc/Solaris-based machines x86/NT X86/Linux EDP-2002 3

Methodology Group Central group responsible for standardizing, enhancement, and automation of NVIDIA’s methodology Common methodology for platform and GPU products Practical approach Manage globally used EDA vendor tools EDP-2002 Methodology Beginnings Several generations of GPU’s done by same team One designer per unit No specialization Little turn-over Design code base and tools code base copied from project to project Consistent high level methodology Lots of variability at the implementation level Many “standard” methodologies in use simultaneously on the same chip Custom tools crafted for a specific chip or unit EDP-2002 4

Forces Driving Methodology Change Volume Time to Market New Markets Hitting all market segments Lowering Cost Competition Engineering staff growth Increased design complexity EDP-2002 How to scale design methodology Continually find better ways to do design Standardization Reduces the learning curve Provides for better reuse Helps ensure consistent quality Combines the best practices from all engineers Allows global upgrades/enhancements Documentation and training Automation Communication Continue to hire great engineers Specialize EDP-2002 5

What to Standardize Anything that takes engineering time is a candidate for standardization Verification environments Synthesis/Timing/Layout flows Emulation Manufacturing test methodology Formal verification Custom scripts, process flows, and software tools should be written only once Selection and use of commercial EDA tools All design rule checks EDP-2002 Drawbacks to Standardization Can slow adoption of new techniques if they have to work globally before being used at all Requires dedicated staff to support Different chips may be best designed with different techniques Difficult for chip designers to customize tools quickly to get chip’s out. EDP-2002 6

How to Standardize Programmers develop robust tools and flows, scalable across projects Tool experts working with chip designers and programmers Hire great chip designers, encourage them to innovate, and leverage the work they do across other projects Plan ahead, develop and acquire technology, and be opportunistic is deployment EDP-2002 Standardization Hurtles Picking the right methodology and getting everyone to agree on the selection Disruption to projects during transition period Projects sometimes diverge from common flows as they get close to tape-out Common flows/tools usually more complex than those written to work on a particular project “Owner” of flows/tools doesn’t usually have the same sense of urgency as those on a project EDP-2002 7

Structured Tool & Flow Development Unlike EDA companies, it does make sense for chip companies to develop custom code for particular chips or design types. All tools and flows should use common set of libraries for accessing information Clear designation between chip specific and chip independent code. Subclass chip independent classes to extend or specialize functionality Tool independent configuration files for all chip specific information Consistent set of tools and libraries “frozen” for each design EDP-2002 Synthesis - Legacy Originally >20 different ways to go about automating synthesis Synthesis responsibility with designer of unit Some were attempts to standardize and used by many modules within a unit Impossible to change things globally, like cycle time Many copies of design quality scripts Chip designers had problems moving from block to block as they had to relearn these relatively complex environments No documentation meant that new engineers had a steep learning curve EDP-2002 8

Synthesis - Common Merged good characteristics from all environments into one automated and documented flow, used across all projects Automatic dependency generation Standard script structure Centralized default constraints Centralized library definitions Automatic invocation of design quality scripts Common code base, freezable and tweak-able for individual projects if necessary Simple setup but completely customizable without breaking automation Automatic checking of failure conditions EDP-2002 Resources NVIDIA has always had a shared pool of resources Compute servers: linux and solaris Network and file servers EDA tool licenses Sharing requires additional priority schemes as the number of projects grows Simple scaling of resources breaks all sorts of things Need to get more sophisticated about our use of resources EDP-2002 9

Manufacturing Test - Traditional 100% scan ATPG patterns for all stuck-at faults At-speed Functional patterns for detecting all speed faults and doing speed characterization Test cost expensive per chip Large chips with huge patterns sets No characterization or optimization of shift speed Functional patterns require tight timing tollerances Minimal FA EDP-2002 Manufacturing Test - Today Automatic structural tests for transition faults Automatic tests for chip delay characterization Better process for isolating faults based on structural tests – both transition and static faults Techniques for compressing vectors New techniques for improving coverage Logic optimized to run structural tests fast Characterization of various pattern sets to optimize test programs Requires much larger investment in time, engineers, and capital EDP-2002 10

Manufacturing Test - Future Continual drive towards lower cost test Timing critical testing moved on-chip Critical timing relationships for functional testing Analog interfaces PLL Structural vector compression Higher quality vectors Bridging fault models Higher transition fault coverage Better fault isolation techniques EDP-2002 Tracking the Design Process Design process is a complex and involved process taking many people many months to accomplish Problems: Engineers and managers need to understand the flows and where their chip is in the flow. Need to better manage revisions of design files to ensure that the proper set was used for building the chip, as well as for all verifications steps along the way. EDP-2002 11

Design File Revisions - Traditionally Files are kept in a source code control system Latest revision number of a file is considered the revision to be used. Individual engineers “sync” to a set of files and perform some activities which might span many days, and then check in the resulting files. Leads to confusion on what tools were run with what revision of the files. Relies on very careful engineers with an in-depth knowledge of the process to manage successfully Big waste of time and hit to schedules EDP-2002 Design File Revisions - Future Mechanism for formally specifying a process Database for tracking: execution of process activities revisions of design files involved in the process flow executions checkins to source code system EDP-2002 12

Tracking Tools Tools will read tracking database and process description files. These can be used to: Verify before running a process that all the input files are available and up to date. Automatically launch process flows when input files have been updated Ensure all verification steps have been run on the file revisions used to tape out a chip EDP-2002 Conclusion Nothing is a substitute for intelligent, diligent engineers working well together Well thought out, standard, automated processes will enable growth without compromising quality or efficiency EDP-2002 13