1 FUTURE HOMENET MEETS IEEE DRAFT 6 Jouni Korhonen, Philippe Klein July 2014.
System-on-Chip Design Flow - edu.cs.tut.fiedu.cs.tut.fi/soc-sme/TombergELKOM.pdf · 26.03.2003...
Transcript of System-on-Chip Design Flow - edu.cs.tut.fiedu.cs.tut.fi/soc-sme/TombergELKOM.pdf · 26.03.2003...
Jouni Tomberg / TUTJouni Tomberg / TUT 1126.03.200326.03.2003
SystemSystem--onon--Chip Design FlowChip Design Flow
Prof. Jouni TombergProf. Jouni TombergTampere University of TechnologyTampere University of Technology
Institute of Digital and Computer SystemsInstitute of Digital and Computer Systems
[email protected]@tut.fi
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 22
SoC SoC -- How and with whom?How and with whom?•• SoC PlayersSoC Players•• MarketsMarkets•• FlowsFlows•• BottlenecksBottlenecks•• IP and platform metricsIP and platform metrics
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 33
DefinitionsDefinitions•• Frontend designFrontend design
–– Design from system level to cell library level netlistDesign from system level to cell library level netlist
•• Backend designBackend design–– Design from netlist level to Placed & Routed production Design from netlist level to Placed & Routed production
ready databaseready database
•• ASIC flowASIC flow–– Netlist handoff to ASIC vendor (takes care of the backend)Netlist handoff to ASIC vendor (takes care of the backend)
•• COT (Customer Owned Tooling) flowCOT (Customer Owned Tooling) flow–– P&R database handoff to foundry (takes care of the P&R database handoff to foundry (takes care of the
production)production)
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 44
SoC PlayersSoC Players
Customer(end user)
IP provider
DesignServiceprovider
ASIC vendoror
Foundry
Standardfunctionblocks
Requirement specification
Physicalbackannotation
Netlist orP&R databaseIC's
Productionrequirements
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 55
Need for System Level DesignNeed for System Level Design
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 77
Design Productivity GapDesign Productivity Gap
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 88
Typical Design Flow TasksTypical Design Flow Tasks
Implement
Verify
Models/IP
Syst
em/
Alg
orith
m
Beh
avio
ral
RTL
Gat
e-le
vel
Tran
sist
or/
Phys
ical
Define SystemCreate/select
AlgorithmsFilter designProtocol
Development
Verify systemfunction
Verify Algorithmperformance
System SimulationHW/SW Coverification
System model components
System environmentsReference Kits
Create behavioraldescription
Code generationWordlength optimizatiuonArchitectural TradeoffsPartitioning
Verify behavioraldescription (functionand performance)
SimulationTestbench GenerationHW/SW Coverifiication
Behavioral modelsRAM ModelsPart modelsBus ModelsCores
Create RTLdescription
Behavioral SynthesisCode generationDesign Planning
Verify RTLdescription(function andperformance)
SimulationPower AnalysisRTL quality analysisEmulation
RTL modelsRAM modelsPart modelsBus ModelsCores (functional &
timing Models)
Create NetlistOptimize NetlistLogic SynthesisDatapath SynthesisTest SynthesisPower OptimizationRetiming
Verify Netlist(function andperformance)
SimulationEquivalence CheckingStatic Timing AnalysisPower AnalysisTest Analysis/ATPG
Gate modelsBus ModelsSynthesis/simulation
libraries
Create physicalrepresentation
Place & RouteClock-tree synthesisPower RoutingTransistor Optimization
Verify physicaldesign
DRC, LVSPower analysisRail analysisStatic Timing analysisParasitic Extraction
Physical/transistormodels
Std Cell librariesGate Array libraries
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 99
Design FlowsDesign FlowsSource: T. Moxon / EEDesign, 2.1.2002
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 1010
ASIC design flow interfacesASIC design flow interfacesDESIGN TEAM CUSTOMER ASIC VENDOR
Requirement spec
Technical info for quotation
ASIC quotation
Library & tools
Data sheet for acceptance
Verification for acceptance (modeler/testbench/simul.results)
Netlist, test vectors, arch.plan
Backannotation from P&R
Acceptance for prototype production (sign off)
Prototype ASICs (/risk production)
Prototype acceptance
Mass production ASICs
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 1111
Importance of SpecificationImportance of Specification
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 1212
Design BottlenecksDesign Bottlenecks * Source EETIMES EDA 2000 Survey
32%
32%
26%
17%
17%
Design Creation
Place & Route
Post Layout Optimization
Parasitic ExtractionSystem or System-on-Chip
Simulation/Design Verification 51%
Layout Versus Schematic(LVS)Design Rule Check (DRC) 17%
Static Timing Analysis 16%
Synthesis 15%
Base = 545Delay Calculation 13%
0% 10% 20% 30% 40% 50% 60%
50 -70 % of project effort devoted to design verification!
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 1313
Verification ImportanceVerification Importance
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 1414
Project SchedulingProject Scheduling•• External constraintsExternal constraints
–– Targeted market entryTargeted market entry–– ASIC vendorASIC vendor
•• Layout generation (P&R)Layout generation (P&R)•• Mask producingMask producing•• Prototype processingPrototype processing•• Prototype acceptancePrototype acceptance•• Volume production starting delayVolume production starting delay
•• Design constraintsDesign constraints–– Design team experience Design team experience –– Design tools / flows, vendor libraries, IP provider qualityDesign tools / flows, vendor libraries, IP provider quality–– System specification iterationsSystem specification iterations–– Design complexityDesign complexity–– Verification complexityVerification complexity–– Production test complexityProduction test complexity
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 1515
Differencies between SoC and SoPC Differencies between SoC and SoPC design flowsdesign flows•• SoPC is a FPGA technology based user programmable SoPC is a FPGA technology based user programmable
solutionsolution–– P&R and programming done by the user (vs. backend flow in P&R and programming done by the user (vs. backend flow in
SoC)SoC)•• No delay on prototype productionNo delay on prototype production•• No delay on mass production startNo delay on mass production start•• No NRE (production start) costsNo NRE (production start) costs
–– Production tests done by the IC vendorProduction tests done by the IC vendor•• Design resource and time savings in the design flowDesign resource and time savings in the design flow
–– Quick and cheap modificationsQuick and cheap modifications
•• On the other hand certain limitations on performance, On the other hand certain limitations on performance, integration capacity and mass production costs exists integration capacity and mass production costs exists compared to SoC compared to SoC
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 1616
Platform Based DesignPlatform Based Design•• A platform should consist of a basic set of A platform should consist of a basic set of
integrated technologies that defines how the integrated technologies that defines how the system should function.system should function.
•• Design platform / Verification platformDesign platform / Verification platform•• Generic platformGeneric platform
–– CPU, memory and standard peripheral fucntionsCPU, memory and standard peripheral fucntions•• Application specific platformApplication specific platform
–– Generic platform plus preGeneric platform plus pre--integrated IP blocks for integrated IP blocks for the given applicationthe given application
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 1717
Platform driversPlatform drivers
Source: B. Altizer, L. Cooke, and G. Martin / EEDesign 7.11.2002
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 1818
Platform AdvantagesPlatform Advantages•• Reduce integration risk by insuring that all IP works Reduce integration risk by insuring that all IP works
togethertogether•• Reduce licensing and contractual negotiation time Reduce licensing and contractual negotiation time
per projectper project•• Reduce cost by allowing efficient reuse in multiple Reduce cost by allowing efficient reuse in multiple
designsdesigns•• It is estimated that in the near future each SoC It is estimated that in the near future each SoC
design will consist of 10 to 15 different IP blocks design will consist of 10 to 15 different IP blocks from 6 to 8 IP vendorsfrom 6 to 8 IP vendors–– Suppose 6 to 8 weeks per IP vendor for evaluation, Suppose 6 to 8 weeks per IP vendor for evaluation,
negotiation and integration of IP into the systemnegotiation and integration of IP into the system=> with 8 different IP vendors this means 64 weeks of => with 8 different IP vendors this means 64 weeks of ”hidden” cost”hidden” cost
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 1919
IP Market DynamicsIP Market Dynamics•• Design dynamics (Dataquest 2002)Design dynamics (Dataquest 2002)
–– 30% of a designs are composed of reused circuitry30% of a designs are composed of reused circuitry–– 12% of reused circuit is from outside sources12% of reused circuit is from outside sources
=> 3.6% of circuitry is from third parties=> 3.6% of circuitry is from third parties•• Contractual and legal issuesContractual and legal issues
–– Legal issues remain a huge bottleneck in the IP purchase processLegal issues remain a huge bottleneck in the IP purchase process•• rights, responsibility, guarantee, business modelrights, responsibility, guarantee, business model
–– VCX trying to address this bottleneck (with standard Ts &Cs)VCX trying to address this bottleneck (with standard Ts &Cs)•• Evaluation of IPEvaluation of IP
–– Deciding if a core is viable is biggest technical challenge in IDeciding if a core is viable is biggest technical challenge in IP acquisition P acquisition process.process.
–– Opportunities in IP evaluation servicesOpportunities in IP evaluation services•• Perceived instability of vendors.. Perceived instability of vendors..
–– Most IP vendors are small and vulnerableMost IP vendors are small and vulnerable–– Partnerships and alliance can help to resolve perceived volatiliPartnerships and alliance can help to resolve perceived volatilityty
•• Software replacing hardwareSoftware replacing hardware–– Proliferation of processors in ICsProliferation of processors in ICs–– Resulting in more functions being implemented in softwareResulting in more functions being implemented in software–– SW/HW coSW/HW co--design!design!
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 2020
IP Market MetricsIP Market Metrics
46%CAGR46%CAGR
75% License Revenue 25% Royalty Revenue75% License Revenue 25% Royalty Revenue
26.03.200326.03.2003 Jouni Tomberg / TUTJouni Tomberg / TUT 2121
ConclusionsConclusions•• The main players in the SoC design flow are Design The main players in the SoC design flow are Design
team, IP provider, IC vendor (or Backend team + team, IP provider, IC vendor (or Backend team + Foundry)Foundry)
•• Efficient SoC design flow is based on IP reuse and Efficient SoC design flow is based on IP reuse and platform based designplatform based design
•• The major bottlenecks are in the test and verification The major bottlenecks are in the test and verification areaarea
•• The system level (specification, HW/SW coThe system level (specification, HW/SW co--design) design) and layout level links to RTL design play also an and layout level links to RTL design play also an important role in a fluent design flowimportant role in a fluent design flow