SoC Design Flow & Tools: Introduction

Transcription

1 SoC Design Fow & Toos: Introduction Jiun-Lang Huang Graduate Institute of Eectronics Engineering Department of Eectrica Engineering Nationa Taiwan University 1

2 Contents Moving to SoC Design Design Methodoogies Reuse

3 Moving to SoC Design 3

4 Evoution of Siicon Technoogy The gap between siicon capacity and design capabiity is growing. Integration of heterogeneoud device technoogies is yet another chaenge

5 The Consumer Demands Higher-eve of integration and mobiity are the keys. However, under the pressure of shorter product ifespan, and shrinking design cyces

6 Technoogy + Demand = SoC

7 What is SoC? Sysem-on-Chip An IC that integrates the major functiona eements of a compete end-product into a singe chip

8 An SoC usuay contains reusabe IP embedded processor, memory rea-word interface mixed-signa bocks programmabe hardware has more than 500 K gates, use.25 mm technoogy or beow, and is not an ASIC

9 SoC Chaenges Chip compexity Gate count, heterogeneous device technoogies DSM effects Signa integrity, timing Design methodoogy Testing

10 The Design Productivity Gap

11 Design Methodoogy Transition

12 SoC Testing Chaenges Distributed design and test Core provider does not know the target environment. System integrator is responsibe for manufacturing testing. Test access Difficuties to access deepy embedded cores. Bandwidth, I/O pin count imitations. Test optimization Minimizing test cost whie satisfying constraints such as power, resources, coverage, etc

13 SoC Design Methodoogy 13

14 Timing Driven Design Methodoogy Best for moderatey sized and compex ASICs that consists primariy of new ogic on DSM processes, and doesn t have a significant utiization of hierarchica design. Probems: Looping between synthesis and pacement. Long turnaround times for each oop. Unanticipated chip-size growth ate in the design process. Repeated area, power, and timing optimizations. Late creations of adequate manufacturing test vectors

15 Bock-Based Design Methodoogy Ideay, BDD is behavioray modeed at the system eve, where HW/SW tradeoffs and co-verification is performed. New design components are partitioned and mapped onto specified functiona RTL bocks. The RTL bocks are then designed to budgeted timing, power, and area constraints

16 BBD Characteristics Opportunisticay reused functions are poory characterized, subject to modification, and require pre-verification. Hard, firm, or soft programmabe processor cores. Extracting testbench data from system-eve simuation to support functiona verification. A shift from ASIC-out to system-in verification. Processor-dominated or custom bus architecture

17 BBD Characteristics - cont d A predominatey fat manufacturing test architecture is used. Timing anaysis in both a hierarchica and fat context. Top-down panning to create bock budgets for hierarchica timing anaysis. Fat detaied timing anaysis for higher accuracy. Management of guard band becomes critica in DSM design to ensure design convergence. Handoff between the design team and an ASIC vendor often occurs at a ower eve than in TDD. A fuy paced netist is norma, not uncommon to go a the way to GDS II. RTF is attractive, but impractica for a but the east aggressive designs

18 BBD Linchpin Technoogies Appication-specific, high-eve system agorithmic anaysis toos Bock foor panning Integrated synthesis and physica design

19 Patform-Based Design Methodoogy TDD + BDD + extensive and panned design reuse. PBD separates design into two areas of focus: Bock authoring System-chip integration

20 Bock Authoring Bocks are generated so that they interface easiy with mutipe target designs. Two new design concepts must be estabished: Interface standardization: Bock authoring may be distributed among different design teams if under the same interface specifications and design methodoogy guideines. Virtua system design To estabish the system constraints necessary for bock design. For exampe: Power profie, Test options, Hard, firm, or soft,

21 System-Chip Integration Focus on designing and verifying the system architecture, and the interfaces between bocks. Starts with partitioning the system around the preexisting bock-eve functions and identifying the new or differentiating functions needed. System-eve partitioning aong with performance anaysis, HW/SW design tradeoffs, and functiona verification

22 PBD Characteristics A PBD design is either derivative design with added functionaity, or a convergence design where previousy separate functions are integrated. Hierarchica, heterogeneous test architecture The manufacturing test design is incorporated into the standard interfaces to support each bock s specific test methodoogy. BIST, scan BIST, fu/partia scan, JTAG, Hierarchica timing anaysis Based on pre-characterized bock timing

23 PBD Characteristics - cont d Hierarchica routing Interbock routing is to and from area-based bock connectors Constraint driven to meet SI and interface timing requirements. The physica design is a key stage in the design. Usuay 0.25 mm and smaer process technoogy. DSM interconnect-dominated deays. Uses primariy firm or hard VCs. Predictabe, and pre-verified

24 PBD Linchpin Technoogies High-eve, system-eve agorithmic and architectura design toos and HW/SW co-design technoogies. Physica ayout toos focused on bus panning and bock integration. VC-authoring functiona verification toos

25

26 Summary of Design Characteristics TDD BBD PBD Design compexity (gate) Design eve Design team Primary design Design reuse Primary optimization focus Primary design granuarity 500 to 250 K 150 K to 1.5 M 300 K or more RTL Sma, focused Custom ogic None Synthesis, gate-eve architecture Gates and memory Behavior/RTL Muti-discpinary Bocks in context, custom interfaces Opportunistic soft, firm, and hard Foor panning, bock architecture Functiona custers, cores Architecture and VC evauation Muti-group, muti-discipinary Interfacing to system and bus Panned firm and hard Siicon-compatibe system architecture VCs

27 Summary of Design Characteristics - cont d TDD BBD PBD Bus architecture None/custom Custom Standardized/mutipe appication-specific Test architecture None/scan Scan/JTAG/BIST/ custom Hierarchica, parae scan/jtag/bist/ custom Mixed-signa None A/D, PLLs Functions, interfaces Constraint/goa specification Logic sonstraints Bocked-budgeted constraints Interface constraints Verification eve RTL/gate Bus function to cyce accurate/rtl/gate Mixed (ISS to RTL w/ HW and SW) Partition focus Synthesis imitations (hierarchica) Functions (hierarchica) Function/ communications (hierarchica)

28 Summary of Design Characteristics - cont d TDD BBD PBD Pacement Routing Fat Hierarchica Hierarchica Fat Fat Hierarchica Timing anaysis Fat Fat with imited hierarchy Hierarchica Deay cacuation Fat Fat Hierarchica Physica verification Fat Fat with imited hierarchy Hierarchica

29 Reuse - The Key to SoC Design 29

30 IP Reuse TTM wi assume a dominant roe in product panning. NTRS asserts that design reuse is paramount to reaizing their projections. Reusing IP has ong been touted as the fastest way to increasing productivity. However, we have ony seen some sma victories, and a ot of unfufied promise!!

31 Modes of Reuse Persona Source Core VC (Virtua component)

32 Evoution of VC Reuse

33 Persona Reuse Portfoio Human knowedge based Exercised through reappying persona or team design experience to produce derivative projects. Chaenges Does not scae. Dependent on retaining key personne. Changes to technoogy or architecture significanty undermine productivity benefits

34 Transitioning to Source Reuse

35 Source Reuse Portfoio In BBD, the opportunity to reuse designs created esewhere begins to open up. Source reuse provides a pre-existing RTL or netisteve design that can then be modified to meet the system constraints. Chaenges Eroded productivity if re-verification is required. Testbench deveopment often imits productivity for many bocks. Hard to evauate and understand what is avaiabe. Poor predictabiity of performance, area, and power. Most existing IPs are not we documented for reuse, often acking an adequate testbench

36 Transitioning to Core Reuse

37 Core Reuse Portfoio Refined and improved in the foowing ways: More information is avaiabe on the bock reaization in siicon (area, timing, footprint, power). More bocks in firm or hard forms. Reusabe, paced netist is in a reevant ibrary (firm). Quaification constraints exist for entering into the reuse VC database and pruning existing ow-vaue entries. Documentation on the context where the bock has been used and/or reused. Third-party VC bocks are integrated and specific detais on the engagement process with the vendor exist. More participation and mechanisms supporting the bock occur from the author for interna VCs

38 Core Reuse Portfoio - cont d Chaenges The VC core must be modified to adapt to the bus, cock, test, and power environment of the product design. Verification of bocks in the system context after modification is sti a probem. Architectures for deaing with mixed-signa design are ad hoc in terms of bock reuse across products. The productivity benefits are not growing at the same rate as the design size and DSM interconnect probems

39 Transitioning to VC Reuse

40 VC Reuse Portfoio Separation of authoring and integration is most ceary observed. VCs are pre-characterized, pre-verified, and premodeed to target a specific virtua system environment. IPs are differentiated argey by the eegance of the design, the competeness of the modes/documentation, and the options. The bocks are known entities, designed to fit together without change

41 VC Reuse Portfoio - cont d Chaenges TTM forces trade-offs in fexibiity and optimaity. More high-performance anaysis and modeing needed to support HW/SW partitioning decisions. Fundamenta business modes for VC contro and protection are a barrier to inter-company VC sharing. Porting anaog/mixed-signa cores is sti manua