Tools or Users - UCSD VLSI CAD Laboratory - UC San Diego
Tools or Users - UCSD VLSI CAD Laboratory - UC San Diego
Tools or Users - UCSD VLSI CAD Laboratory - UC San Diego
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Tools</strong> <strong>or</strong> <strong>Users</strong>:Which is the Bigger Bottleneck?John Szetela, AMDHilton Kirk, PhilipsPatrick Groeneveld, MagmaLavi Lev, CadencePaul Rodman, ReShapeRon Collett, NumetricsModerat<strong>or</strong>: Andrew B. Kahng, <strong>UC</strong> <strong>San</strong> <strong>Diego</strong>DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>1
The Productivity GapDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>2
Semiconduct<strong>or</strong> Quality/Cost = Job #1• “Cost of design is the greatest threat tocontinuation of the semiconduct<strong>or</strong> roadmap”– International Technology Roadmap f<strong>or</strong> Semiconduct<strong>or</strong>s, December 2001• Semiconduct<strong>or</strong> productivity fuels wealth creation• Productivity gap– “ASIC vs. custom” quality gap– Schedule risk, #respins, design TAT, design NRE à cost gap• W<strong>or</strong>karounds are not pretty– Programmable silicon implementation platf<strong>or</strong>ms?– Software?• We (tools/users/semi) are in this together !DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>3
ITRS 2001 Design Technology Crises• 2-3X m<strong>or</strong>e verification engineers than designers• Software = 80% of system development cost• Analog and mixed-signal design hasn’t scaled andisn’t reusable• Cost of Design > 10’s of $M• TAT of Design = years• Without DFT, test cost per transist<strong>or</strong> growsexponentially relative to mfg costDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>4
ITRS Design Needs (Back-End)• Analog layout synthesis and reuse• Layout-BIST synergies f<strong>or</strong> UDSM fault models• New paradigms f<strong>or</strong> global signaling, synchronizationand system-level interconnect• Modeling and simulation (interference, reliability, …)• Management of increased process variability and nonrecurringcosts in mask and foundry flows• Multi-(V dd , V t , t ox , biasing) perf<strong>or</strong>mance optimization• = reliable front-end signoff + SOC productivity + mfg i/fDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>5
Four Questions• <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>: Who’s to Blame?• What are specific problems and their costs?(Supp<strong>or</strong>t with metrics, data.)• Why do design teams still succeed despitethese problems?• Shopping / wish list: What would solve theproblems you’ve cited?• Structure: Panelist presentations, moderat<strong>or</strong>questions, audience questions• Goal: Illumination, and some progress !DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>6
<strong>Tools</strong> <strong>or</strong> <strong>Users</strong>:Which is the Bigger Bottleneck?John J. SzetelaManager, <strong>CAD</strong> <strong>Tools</strong> & SystemsAMDDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>7
<strong>Tools</strong> <strong>or</strong> <strong>Users</strong>: Who is to Blame?• <strong>Tools</strong> are the Bottleneck, of course !!!• The <strong>CAD</strong> Tool problem areas have shifted…….– “Min<strong>or</strong>” issues are MAJOR, in “new” denser fab process technologies– Simple fixes incur significant time f<strong>or</strong> designs with large data sets– Infinite sized files are impractical as a “Standard” tool interface– <strong>Tools</strong> unable to shield users wrestling with design complexity• Cannot expect users to become vastly m<strong>or</strong>e proficient at tool usage !– <strong>Tools</strong> assume internal “design” experts on 3 rd party IP• The experts are elsewhere but the tools are “local”• “Brownie Points” f<strong>or</strong> <strong>Tools</strong>:– New Point tools address some of the identified problem areas– <strong>Tools</strong> partially “manage” data size and design complexity problemsDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>8
Specific Tool Problem Areas• Design Closure is THE issue !!!– Complete design validation is an oxym<strong>or</strong>on !– Late changes in the design cycle are inevitable– The automated flow from “design” to “silicon” is too S-L-O-W• A TWO week repair cycle f<strong>or</strong> a “final” timing fix is NOT effective• Timing Analysis ECO Placement Routing Analysis• Custom fixes with a half dozen metal layers are near ineffective• New technology, old “closure” problems….– The BIG FOUR problems:• IR Drop, Electromigration, Antenna, Signal Integrity• Previous rules of thumb do NOT play well in “deep” submicron• Much easier to design in reliability than to “repair” it at tape-out– Point <strong>Tools</strong>’ fixes f<strong>or</strong> BIG FOUR, conflict with Timing ClosureDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>9
Why Design Teams Still Succeed ?• Because, we eat our very own dog food !!– Faster Compute Platf<strong>or</strong>ms• Process<strong>or</strong>s are now 3 – 10x faster than bef<strong>or</strong>e• 2- Way Multi-Process<strong>or</strong> are common• Even faster with distributed computing• “Server Farms have replaced Cherry <strong>or</strong>chards in Silicon Valley”– Netw<strong>or</strong>k perf<strong>or</strong>mance is 10X what it used to be– Disk St<strong>or</strong>age is “free” and “centralized”• The tools are getting much better– Handling “large” designs– “Fixing” most problem areas, BUT they create new problems• IP has been a saving grace, though it often seems like a curse !– Has anyone used this “IP stuff” without finding problems?DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>10
My Shopping / Wish List• Integrated tool set that understands all the design closure issues– “Fix” design convergence issues between point tools– “I do NOT really place much hope f<strong>or</strong> this integration !”• Standard tool interfaces that use m<strong>or</strong>e than files– The two <strong>CAD</strong> database eff<strong>or</strong>ts here are w<strong>or</strong>th watching– “Of course, we users usually write our own, don’t we?”• Verification tools that allow clean “final” netlists to the back end– “See, I can’t even avoid saying netlist, even if it is RTL” !• IF the above wish-list is “asking f<strong>or</strong> the moon”, THEN….– AT LEAST an ECO system that w<strong>or</strong>ks with good point tools !• Did some one say Wish List?– STOP saying “2½D Extraction”, means UNKNOWN accuracy– DO NOT say “hierarchical flow”, when you mean TWO levels– How about NOT saying “It’s fixed in our next release”, FIRST JDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>11
<strong>Tools</strong> <strong>or</strong> <strong>Users</strong>:Which is the Bigger Bottleneck?Hilton Kirk (f<strong>or</strong> Lambert van den Hoven)Design Technology GroupPhilips Semiconduct<strong>or</strong>sDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>12
<strong>Tools</strong> <strong>or</strong> <strong>Users</strong>: Who's to Blame?• Mainly the <strong>Tools</strong> (= Vend<strong>or</strong>s)• Focus on point solutions not flows– perf<strong>or</strong>mance of tool– testing of tool– quality of result of tool• Delivery of flows = additional revenue stream• Slow introduction of new methods (also slowtakeup by users)– eg. higher levels of abstractionDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>13
Specific Problems and Costs• Err<strong>or</strong>s & time lost in tool interoperability– >30 beltstop faults in debugging new flow– multiple view f<strong>or</strong>mats• cost of update f<strong>or</strong> libraries• data semantics lost/misinterpreted between tools• Verification (>50% err<strong>or</strong>s in Spec)– F<strong>or</strong>mal verification rarely used– Functional verification expensive (time & $)• Physical implementation– time to achieve area, power, timing closureDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>14
Why Design Teams Still Succeed• Emulation/Prototyping of the IC– FPGA’s & Rapid Silicon prototyping• (Over)Guardbanding, ‘don’t touch’ hard blocks• Re-Use– experts in the various domains• application system, synthesis, layout, test…– larger blocks of IP: platf<strong>or</strong>m derivatives• Cookbooks & w<strong>or</strong>karounds– high cost to produce & maintain– users reluctant to read!DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>15
My Shopping / Wish List• Fast and efficient RTL to layout flow– tunable f<strong>or</strong> power, area, perf<strong>or</strong>mance– Value proven on specific design!• Stable flow– controlled introduction of proven improvements• Inituitive flows and UI’s• An easy to use f<strong>or</strong>mal design & verificationmethodology• Common database - open access to facilitateimproved flows & minimizing f<strong>or</strong>mat changeDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>16
<strong>Tools</strong> <strong>or</strong> <strong>Users</strong>:Which is the Bigger Bottleneck?Patrick GroeneveldMagma Design AutomationDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>17
<strong>Tools</strong> <strong>or</strong> <strong>Users</strong>: Who's to Blame?• It’s the tool flow that is to blame• Ruthless automation is required to keepup with Mo<strong>or</strong>e’s law and• to keep ASIC’s financially andtechnically viable.DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>18
Specific Problems and CostsIt must deal with many Zero tolerance‘nitty gritty’ detailsf<strong>or</strong> sloppynessAlg<strong>or</strong>ithms do only one thing well(and cannot handle multiple objectives)Alg<strong>or</strong>ithms use inaccurate models ofthe layout reality.Layout/logic Synthesis alg<strong>or</strong>ithms are unreliableDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>The IC layout RTL to GDSIIflow is a long chain ofdifferent alg<strong>or</strong>ithms.Alg<strong>or</strong>ithmic steps dothings that could causeproblems at later stepsWe often need tostart over iterate t<strong>or</strong>ecover such err<strong>or</strong>s19
Why Design Teams Still Succeed• .. Because of sweat and tears:painstaking manual w<strong>or</strong>k andc<strong>or</strong>rection.• Succeed due to ‘super designers’ whoknow the ins and outs– they are rare.• Not all do succeed!DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>20
My Shopping / Wish List• A strong generic datamodel– (not to be confused with a database)• Common sense ABC approach thatattempts to avoid issues.DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>21
Let the tool flow around the data!RTLRoutingMask layoutPlacementCDFGDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>Net list of Super Cells22
The ABC of an IC design flowA: AvoidDetect specific serious problem patterns early and fix them.- Fast- Many are not a problem, resource expensiveB: BuildSynthesize using a simple model and alg<strong>or</strong>ithm- Capture 1st <strong>or</strong>der effect of problem as objectiveHope f<strong>or</strong> the best- … Hope f<strong>or</strong> the bestDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>C: C<strong>or</strong>rectPerf<strong>or</strong>m accurate analysis, detect remaining problems andFix problems the hard way (ECO).- This is typically slow and it- might not w<strong>or</strong>k.- If its real bad, iterate back to step A <strong>or</strong> B23
<strong>Tools</strong> <strong>or</strong> <strong>Users</strong>:Which is the Bigger Bottleneck?Lavi LevExecutive Vice President &GMCadence Design Systems, Inc.DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>24
<strong>Tools</strong> <strong>or</strong> <strong>Users</strong>: Who's to Blame?• Nothing really failed, it just hurts a lot– EDA failed to understand, and users failed tocommunicate, all the headaches• Key ingredients to design team success– <strong>Tools</strong>’ perf<strong>or</strong>mance (we got that)– <strong>Tools</strong>’ interoperability (didn’t get that)– Design team size and project complexity (didn’t getthat either)DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>25
Specific Problems and Costs• The specifics– EDA guys decide f<strong>or</strong> Chip guys what their problems are– EDA guys considering vict<strong>or</strong>y when their competitionfails, not when their customer wins• The cost– Customers invests heavily in EDA infrastructure– EDA guys invest heavily on things that can be common– SOC creation market can’t growDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>26
Why Design Teams Still Succeed• Teams succeed, the market does not– There is a w<strong>or</strong>karound to almost everythingCurrent state of affairs f<strong>or</strong> most designers!Flow1XFlow2Tool‘n’db‘n’XXFlow ‘n’DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>27
My Shopping / Wish List• Mature EDA– Agree on standards first and then compete• OpenAccess is offered: We hope the industry adopts it– Standards around SOC creation are still missing• Knowledgeable EDA– Add chip designers to your management team• You might even solve real problem….OpenAccess DatabaseFlow1Tool‘n’DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>CommonDatabaseFlow2Flow ‘n’28
<strong>Tools</strong> <strong>or</strong> <strong>Users</strong>:Which is the Bigger Bottleneck?Paul RodmanCTOReShape, Inc.DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>29
<strong>Tools</strong> <strong>or</strong> <strong>Users</strong>: Who's to Blame?• <strong>Users</strong>!– The Captain is Responsible f<strong>or</strong> theShip• <strong>Tools</strong> Vend<strong>or</strong>s Follow the Money– Stimulus-Response– If you don’t like it, don’t buy itDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>30
Specific Problems and Costs• Technical Issues Cause < 40% SlipsSubcontract<strong>or</strong> issues6%Unrealistic targets6%Po<strong>or</strong> management5%Late changes tothe product requirement13%Other15%Resource sh<strong>or</strong>tfall16%Unanticipatedtechnical difficulty39%Source: Pittiglio Rabin Todd & McGrathSemiconduct<strong>or</strong> design benchmark study, 2002Complexity is Not Being Managed– The “second computer” problemDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>31
Why Design Teams Still Succeed• “Nothing is a substitute f<strong>or</strong> intelligent, diligentengineers w<strong>or</strong>king well together.”-- Dan Smith, NVIDIA, EDP 2002• Concurrent Design– Discover RTL coding issues early• Good Project Management– A bad plan is better than no planDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>32
My Shopping / Wish List• Interoperability solved– Each Vend<strong>or</strong> provide open sourceparser used f<strong>or</strong> each f<strong>or</strong>mat• Make tools easier to automate flows– Err<strong>or</strong>/Warning/Exit status– License handling– Batch mode trap do<strong>or</strong>s• Hire people with track rec<strong>or</strong>ds ofcompleting complex ICsDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>33
<strong>Tools</strong> <strong>or</strong> <strong>Users</strong>:Which is the Bigger Bottleneck?Ronald CollettPresident & CEONumetrics Management Systems, Inc.DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>34
<strong>Tools</strong> <strong>or</strong> <strong>Users</strong>: Who's to Blame?• Events invariably occur that cause “bottlenecks”• Sometimes it’s users, sometimes it’s tools,sometimes it’s both, sometimes it’s neither,but…DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>35
It’s the Usual Suspects that CauseBottlenecks!• Changing specification• Inadequate engineering resources• EDA tool/flow problems• Mfg. process/library instability• Lack of management commitment• “Unexpected” design bugs• Etc.DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>36
Why Teams Succeed: Better Planning• Chip Complexity = ƒ(ckt. types, timing, reuse, power . . .)• Design Productivity =ComplexityEff<strong>or</strong>t– Eff<strong>or</strong>t = ƒ(Eng. & mgmt. skills, EDA tools, specstability, mfg. process stability, etc.)• Rate of Eff<strong>or</strong>t Consumption = ƒ(best practices)• Quality of Design Process – e.g. spin count probabilitydensity function• Key Milestones -- e.g. ƒ(eff<strong>or</strong>t consumed, bug rate)DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>37
Silicon Spin Count can be ModeledSilicon Spins, High Complexity Communications ICs*Probability30%20%31.03% 31.03 %17.24 %High AnalogContent10%10.34%10.34 %First-timeSilicon Success1 2 3 4 5 Or M<strong>or</strong>eDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>Spin Count*High Complexity = >1 Million Complexity Units38
Shopping List: Project Plan SynthesisIndividualProductivityEDA <strong>Tools</strong>& FlowsManagementInfluenceCustomerInfluenceTeam ProductivitySynthesis InputsProjectConstraintsSynthesis OutputPeakRampStaffing LimitsKey PeopleAvailabilityCriticalMilestonesTapeoutsPhysical DesignFunctionalityReuse LevelsModel CalibrationUses EmpiricalProject DataTeam SizeA/MSLogic DesignVerification/Validation.PeakStaffTargetTechnologyProject Duration(Time -to-Market)Chip ComplexityDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>39
DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>40
The Value of Interoperability• All:– Define what it means f<strong>or</strong> a tool X to be“interoperable”.• <strong>Users</strong>:– How many m<strong>or</strong>e licenses, at how much higher aprice per license, would you buy of a new“interoperable” version of tool X, if it wereavailable?• <strong>Tools</strong>:– Estimate the costs of providing “interoperability”acc<strong>or</strong>ding to the definitions given.• All:– So, what f<strong>or</strong>m of “interoperable” is even possible?DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>41
DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>42
On Openness• <strong>Tools</strong>– In the spirit of openness, will you allow your toolsto be benchmarked, and the results freelyrep<strong>or</strong>ted? (If not, why not?)• <strong>Users</strong>– If open benchmarking is permitted, what resourcesand design IP would your <strong>or</strong>ganization/companycommit to whatever entity fulfills such a need?• All– (Or, is there any need to benchmark EDA …?)DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>43
Who Should Define the Methodology?• All– Should tools define the methodology?– Who should (<strong>or</strong>, can) define new and improvedmethodologies: tool vend<strong>or</strong>s <strong>or</strong> design teams?DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>44
DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>45
So What’s Really Different Today?• All– [Who remembers SPINE99 J ? (Do tools and/<strong>or</strong>users simply “get religion” every few years?)]– Is this a panel that we’ll have every 5 DAC’s f<strong>or</strong> thenext 20 years, <strong>or</strong> is something fundamentallydifferent and m<strong>or</strong>e urgent today?DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>46
DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>47
Technology Lag• All– Do tools have an inherent “technology lag” ?– What do you see as lower / upper bounds on thislag ?• <strong>Users</strong>– Given that one technology node now arrives everytwo years, is this lag bearable?• <strong>Tools</strong>– Is the lag in any way attributable to how users w<strong>or</strong>kwith available tools?– What measures (internal to EDA, <strong>or</strong> joint betweensemi+EDA companies) would enable systematicreduction of the “technology lag”?DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>48
“Mother Nature” vs. “Integration/Flow”• All: Why haven’t we be talking about these specificissues?– Easy?– Less imp<strong>or</strong>tant?• Analog layout synthesis and reuse• Layout-BIST synergies f<strong>or</strong> UDSM fault models• New paradigms f<strong>or</strong> global signaling, synchronization and system-levelinterconnect• Modeling and simulation (interference, reliability, …)• Management of increased process variability and non-recurring costs inmask and foundry flows• Multi-(V dd, V t, t ox, biasing) perf<strong>or</strong>mance optimization• = reliable front-end signoff + SOC productivity + mfg i/fDAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>49
DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>50
So…• All– Who is to blame f<strong>or</strong> the productivity (value / cost)gap – tools <strong>or</strong> users?– What’s the solution?DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>51
DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>52
Other Questions• Do vend<strong>or</strong>s understand the design problem?• Is it impossible f<strong>or</strong> tools to be both easy to use andhave reliably high quality of result?DAC02 Panel: <strong>Tools</strong> <strong>or</strong> <strong>Users</strong>53