Design Reuse and SOC Platform

Design Reuse and SOC Platform
이광엽 (서경대학교, 컴퓨터공학과) Copyrightⓒ2003

목 차 SoC Architectures SoC Design Methodology
목 차 SoC Architectures SoC Design Methodology Reuse : the key to SoC Design SoC Design Process Macro Design Process Platform Based Methodology Platform Based Design Process Example of Platforms Conclusion Copyrightⓒ2003

SoC Architectures Key Drivers Architecture Renaissance
Reusability: design reuse shortens the design time Flexibility: a single architecture should cover multiple applications or their extensions to reduce the NRE cost overhead Architecture Renaissance IP-based SoC Platform Reconfigurable Processor Xilinx Vertex II Pro, Altera Excalibur, Triscend A7, etc. ASIP: Configurable microprocessor Tensilica Xtensa Copyrightⓒ2003

How to Increase Design Productivity?
(1) Reuse What to reuse?  How to reuse? IPs (Intellectual Properties)  IP-based design Previous system design (or architecture), platform  platform-based design Copyrightⓒ2003

How to Increase Design Productivity?
(2) Design at higher levels of abstraction E.g. 200 lines/man-day code size: C > assembly Abstraction levels higher than C code level. SPW, COSSAP, etc. SDL, CORBA, etc. (3) Combine reuse and high-level design Currently, function-architecture co-design Copyrightⓒ2003

Design Methodology Evolution
Copyrightⓒ2003

SoC Design Methodology
Top-Down method Synthesis, platform-based Bottom-Up method Component-based Key idea : to increase the abstraction level Considerable reduction of design time Component-based Design Integration of heterogeneous processors and communication protocols by using abstract interconnection Standard Bus protocol : IBM CoreConnect Standard Component protocol : VSIA VCI CoWare N2C, Cadence VCC, Sonics uNetwork Copyrightⓒ2003

SoC Design Methodology
Transition of Design Methodology ADD > TDD > BBD > PBD Reuse-The Key to SoC Design Personal > Source > Core > Virtual Component Integration Approach IP-Centric vs. Integration-Centric Approach SoC and Productivity Executable Specification Test Automation Real-World Stimuli Higher-Level Algorithmic System Modeling Copyrightⓒ2003

SoC Design Characteristics
Design Level RTL / Behavioral > Architectural / VC Evaluation Design Team Small, Focused > Multidisciplinary > Multi-Group > Multidisciplinary Primary Design Custom Logic > Blocks, Custom Interface > Interface to System / Bus Design Reuse Opportunistic Soft, Firm and Hard > Planned Firm and Hard Optimization Focus Synthesis, Gate-level > Floor planning, Block Architecture > System Architecture Copyrightⓒ2003

Megatrends of SoC Era Design RE-USE becomes common
Quality of reusable IP Ease of Use Efficiency Standardization of Core Protocol Most of design effort is focused on VERIFICATION Accelerating Co-Verification Real-World Stimuli DSM INTERCONNECT Copyrightⓒ2003

Reuse : The Key to SoC Design
Copyrightⓒ2003

Design for Reuse(1/2) A common set of problems facing ASICs design
Time-to-market rapid development Quality of results performance, area, and power Increasing chip complexity verification more difficult Deep submicron issues timing closure more difficult The development team each different levels and areas of expertise Copyrightⓒ2003

Design for Reuse(2/2) Design for Reuse
Designed to solve a general problem To fit different applications Designed for use in multiple technologies For soft macros, the synthesis script For hard macros, effective porting strategy for mapping new technologies Designed for simulation with a variety of simulators Verified independently of the chip in which it will be used Each macro is tested, verified Verified to a high level of confidence Very rigorous verification and building a physical prototype Fully documented in terms of appropriate applications and restrictions => In paricular, valid configurations and parameter value Copyrightⓒ2003

Developing an Integration-Centric Approach
Issue IP-Centric Integration-Centric Create IP Can be modified in all Apps Can be reused /wo change Apps. What IP do I have ? What IP do I need ? Market View IP for any market Key market to serve Design Flow Make IP like ASIC Cell Lib Create system for target market Design Usage Flexible and Re-verifiable Plug into integration platform Product Adaptation To product requirement To product domain Time-To-Market Flexible IP Cab be Change easily Solid IP NO need to Change, PnP ! Copyrightⓒ2003

SoC Design Process Canonical Soc Design System Design Flow
The specifications Problem System design Process Copyrightⓒ2003

A Canonical Soc Design Periperals A miniature version of an SoC design
Processor Memory Controller Memory System Bus I/O Interface Data Transformation I/O Interface Copyrightⓒ2003

System Design Flow Changing design flows
waterfall model  spiral model top-down  a combi. of top-down & bottom-up Copyrightⓒ2003

Waterfall Model “toss over the wall” S/W development after H/W design
Up to 100k gates, down to 0.5um For Large System Physical design issue must be considered early (due to deep submicron) S/W & H/W concurrently developmented Specification development RTL code Functional verification Synthesis Timing Place and route Prototype Build and test Copyrightⓒ2003

SYSTEM DESIGN AND VERIFICATION
Spiral Model Goal : maintain parallel interacting design flows SYSTEM DESIGN AND VERIFICATION PHYSICAL TIMING HARDWARE SOFTWARE Parallel, concurrent development of H/W & S/W Parallel verification and synthesis of modules Floorplanning and P&R included in the synthesis process Modules developed only if a predesigned macro is not available Physical Specification: Area, power, Clock tree Design Preliminary Floorplan Updated Floorplans Trial placement Timing Specification: I/O timing, Clock Frequency Block timing Specification Block Synthesis Top-level synthesis Hardware Specification Algorithm Development & macro Decomposition Block Selection / Design Verification Top-level HDL verification Software Specification Application Prototype Development Testing testing TIME Final place and route Tapeout Copyrightⓒ2003

Top-down vs. Bottom-up The classic top-down process
As a recursive routine that begin with specification and decomposition, end with integration and verification. Write complete specification Refine its architecture and algorithms including S/W Decompose the architecture into well-defined macros Design or select macros Integrate macros into the top level Deliver the subsystem to the next higher level of integration Verify all aspects of the design Copyrightⓒ2003

Construct by Correction
A single team took the design from architectural definition through P&R. The team is able to see the impact that their architecture had on the area, power, and performance of the final design. First pass through the design cycle as fast as possible, and multiple iterations through the entire process Sun, Ultrasparc The opposite : “correct by construction” Copyrightⓒ2003

Planning for iterations
Iteration is an inevitable part A methodology minimizes the number of iterations, especially in major loops. We prefer a tight, local loop : coding, verifying, and synthesizing small blocks A rich library of pre-designed blocks helps Taking the time to carefully specify a design Copyrightⓒ2003

The Specification Problem
The most crucial phase of design. The cost of documenting Much less that the cost after the design is completed. Requirements H/W Functionality, Timing, Performance External interface to other H/W or S/W Physical design issue such as area and power S/W Interface to H/W S/W structure, kernel Copyrightⓒ2003

Type of Specifications
Formal specification Independently of any implementation Not only functional behavior, but timing, power, and area requirement VSPEC for VHDL Not widely used Executable specification Widely used For high level specifications – C, C++, SDL, Vera, or Specman Low level specifications – Verilog or VHDL To verify the basic functionality and interfaces of the H/W and S/W before the detailed design begins Only the functional behavior Copyrightⓒ2003

The System Design Process
System Specification Preliminary specification ( with marketing ) The high-level model (C,C++) can be used as the reference for future versions of the design Model refinement and test A verification environment for refining and testing the high-level design The multiple models developed The behavioral model : fast simulation The detailed, cycle-accurate model : final S/W debug Hardware/Software partitioning (decomposition) The division of system functionality between hardware and software Manual process requiring judgment and experience Definition of interface between H/W and S/W Copyrightⓒ2003

The System Design Process (cont.)
IDENTIFY System requirements Block Specification System behavioral model and cosimulation Continues throughout the design process, verifying the interoperability between the H/W and S/W at each stage of design WRITE preliminary specifications DEVELOP High-level algorithmic Model C/C++/MATLAB/SES/ Nuthena/Bones/COSSAP REFINE and TEST Algorithms C/C++/COSSAP/SPW/SDL Characterized library Of hardware/software Macros & interface protocols DETERMINE Hardware/software partition WRITE Hardware specification DEVELOP Behavioral model for hardware WRITE Software specification DEVELOP Prototype of software DEFINE interfaces PARTITION Into macros DEVELOP software Hardware/software XOSIMULATION Macro 1 macro WRITE Preliminary specificaton For macro Copyrightⓒ2003

System-Level Design Issues
The standard model Design for timing closure Design for verification System interconnect and on-chip buses Design for low power Design for test Prerequisites for reuse Copyrightⓒ2003

The Standard Model(1) a consensus emerging about some of the key aspects of reuse-based design to do SoC design well-designed IP Discipline Simplicity Locality problem – achieving timing closure functional verification Copyrightⓒ2003

The Standard Model(2) Soft IP vs. Hard IP
blur the distinction between hard and soft IP The Role of Full Custom Design in Reuse non-portable, hard to modify designs redesigned Copyrightⓒ2003

Design for Timing Closure : Logic Design Issues(1)
Interfaces and Timing Closure the uncertainty in wire delays the wire delay between gates can be much larger than the intrinsic delay of the gate increase the drive strengths of cells insert additional buffers Macro interface both inputs and outputs should be registered buffers special design between a processor and cache memory Copyrightⓒ2003

Subblock interfaces have all the timing information registering all interfaces fully synchronous, flip-flop based design Synchronous vs. Asynchronous Design Style synchronous and register based difficult timing analysis of each latch Copyrightⓒ2003

Clocking use the smallest possible number of clock domains required clock frequencies Reset Synchronous reset easy, free-running clock Asynchronous reset Difficult problem of resetting tri-state buses Copyrightⓒ2003

Design for Timing Closure : Physical Design Issues(5)
Floor planning the chip size is critical to meet its timing, performance, and cost goals Synthesis Strategy and Timing Budgets overall design goals for timing, area and power should be documented before macros are designed or selected a bottom-up synthesis approach Copyrightⓒ2003

Design for Timing Closure : Physical Design Issues(6)
Hard Macros cause blockage in the placement and routing of the entire chip Clock Distribution chip size, clock distribution architecture, target library use a balanced clock tree require clock buffers for large, high-speed lower power consumption – technique similar to that used on boards Copyrightⓒ2003

Design for Verification
Reduce both the number of iterations and the time each iteration takes – Locality Bottom-up verification difficulty to develop test benches use test bench creation languages and code coverage tools Copyrightⓒ2003

System Interconnect and On-Chip Buses(1)
Basic interface issues A hirarhy of buses Tri-state and Mux Buses Tri-state buses for board-level design Multiplexer – based buses Much portable and no technology dependent Reuse Issus and On-Chip Buses VSIA : a series of bus adapters Standardize on a few buses Copyrightⓒ2003

System Interconnect and On-Chip Buses(2)
IP to IP Interfaces a small block with the FIFO and two simple interfaces communication to take place over the bus design or select macros that have flexible or parameterizable interfaces : FIFO-based Design for Bring-Up and Debug on-chip debug structures controllability and observability Copyrightⓒ2003

Design for Low Power(1) for portable devices static and dynamic power
Lowering the Supply Voltage running the core at the lowest possible voltage slow the timing performance use pipelining and parallelism I/O voltage at the required voltage Copyrightⓒ2003

Design for Low Power(2) Reducing Capacitance and Switching Activity
good low-power library use architecture and design techniques to reduce system power Memory design, I/O cells, clocking network Memory architecture partition the memory into several blocks I/O cells minimizing the internal, short-circuit switching current and the capacitance of the external load Copyrightⓒ2003

Design for Low Power(3) Sizing and Other Synthesis Techniques
Clock distribution single clock, flop-based designs clock gating – very technology dependent Sizing and Other Synthesis Techniques optimizing the gate-level design reduce the number of transitions Copyrightⓒ2003

Design for Test System Level Test Issues Memory Test : BIST
different test strategies for each blocks Memory Test : BIST Microprocessor Test full or partial scan and parallel vectors Other Macros full scan technique Logic BIST LFSR Copyrightⓒ2003

Prerequisites for Reuse
Libraries a full set of views, including synthesis, physical, and power views needed to be validated in hardware have accurate, validated wire load models include a set of memory compilers Physical Design Rules several pieces of hard IP are integrated from different sources standard DRC and LVS decks be developed Copyrightⓒ2003

Macro Design Process Specification and Partitioning
Subblock Specification and Design Testbench Development Timing Check Integration Productization Copyrightⓒ2003

Macro Design Planning and Specification
Functional requirements Physical requirements Design requirements The block diagram Interface to external system Manufacturing test methodology The software model Software requirements Deliverables Verification plan Overview Technical goals of the designs Functional requirements Technical perspective Physical requirements Packaging, die, size, power, and other physical design requirements Design requirements A standard design guideline Interface to external system Signal names and functions Transaction protocols with cycle-accurate timing diagram Legal values for input and output data Timing specification Setup and hold times on inputs Clock to out times for outputs Special signals Asynchronous signals and their timing Clock, reset, and interrupt signals and their timing Manufacturing test methodology Full scan, scan insertion and ATPG JTAG-based boundary scan technique The software model Hardware registers the are visible to the software Software requirements Set of software drivers for the system Deliverables Created, archived, and delivered at the end of the project Verification plan Functional tests Performance Copyrightⓒ2003

What is the Platform A Platform specific to an application or a product family is constituted by the Architecture Platform and its associated Design Platform Architecture Platform is a predefined SoC architecture which consists of various families of components such as processor, e_memory, e_software, IPs, On-chip-bus/communications Design Platform is constructed as an integration design flow with multiple levels at which component modeling and simulation environment are provided Copyrightⓒ2003

Platform Based Methodology
Platform Based Design: Application mapped on architecture Performance evaluation and iterative refinement Challenges: Complete system simulation Complexity management Composability and reuse Key elements for composability Identification and use of useful models of computation FSMD,DE,DF,CSP,... A flexible, extensible language platform to capture the functionality Composability can be achieved using Object-oriented mechanisms: Copyrightⓒ2003

Platform Based Design Application Space Platform API application
Application instance application software Platform specification Software platform System platform Hardware platform Platform Design-Space Exploration input output RTOS + BIOS + Device drivers + Communication subsystem Platform instance Architectural Space Copyrightⓒ2003

How to Build A Platform First pick your application domain
Then pick your Star IP (e.g. processors)-processors 'drag' along detailed communications choices e.g. processor buses, Then pick your on-chip communications architecture and structure (levels and structure of buses/private communications) Dedicated memory access Pick application specific HW and SW IP Other IP blocks not available 'wrapped' to the on-chip communications may work with IP wrappers. VSI Alliance VCI is the best choice to start with for an adaptation layer Copyrightⓒ2003

Pros & Cons of Platform-based Design
Advantages can substantially shorten design cycles Large share of pre-verified components helps address the validation bottleneck for complex designs Enable quick derivative designs once the basic platform works Rapid prototyping systems can be used to quickly build physical prototypes and start S/W development Limitations Limited creativity due to predefined platform components and assembly Differentiation is more difficult to achieve, needs to be done primarily in application software Copyrightⓒ2003

Platform Levels Level 0: Foundation Layer
Infrastructure & Standards Level 1: Integration Platform General purpose Flexible and Reuse of the key IPs Level 2: System Platform Application Specific Useful for derivative design Process technology specific Copyrightⓒ2003

Example of platforms Market segment TAGET APPLICATION PLATFORMNAME
Manufacturer CONSUMER = ~140 platforms Digital Camera Raptor Ⅱ Conexant PDA PXA240 Intel PDA Palm DRAGONBALL MXI Motorola DVD R/W Dimension9600 LSI SET TOP BOX Omega Sti5512 ST DIGITAL TV TL850 seies Teralogic DAP (Digital Audio Player) TMS320 Daxx TI MP3 jukeboxⅡ Maverick Cirrus Eureka DAB TMS320DRE200 TI/radioscope Home Plog Piranha chip set Cogency WIRELESS TERMINAL = ~140 platforms CDMA MSM3000 Qualeomm GSM 2.5G SGOLD Inineon OMAP710 3G I300 Mobilian BLACKBERRY 5810 SoftFone + OEM ADI + RIM 802.11b+BT TRUERADIO 802.11a/b/hiperLan TONDELAYO Systemonic 802.11a access point AR5001AP Atheros BLUETOOTH BLUECORE CSR GPS SIFSTAR Ⅱ/t Sirf Copyrightⓒ2003

Some of Platform Examples
Configurable platforms Multiple processors, programmable logic device, bus structure E.g. : Tality's ARM-based SoC, Triscend's CSoC, Cypress MicroSystem' PSoCTM, Altera's ExcaliburTM, Wipro's SOC-RaptorTM, Palmchip's PalmPakTM, Philips RSP. Other platforms TI's OMAPTM, Improv's PSATM Jazz Copyrightⓒ2003

Conclusion Platform-based design
From board design to SoC design From executable spec., i.e. C/C++, to SystemC System-level design and SW/HW Coverification Performance power evaluation Task mapping to soft ware and hardware Communication refinement Embedded software layer architecture Coverification from higher level Virtual prototyping Copyrightⓒ2003

Trends Recently, the platform-based design approach to SOC designs
This approach arose in consumer applications such as wireless handsets and set-top boxes System platform definition Coordinated family of hardware software architectures that satisfy a set of architectural constraints, imposed to allow the reuse of components Copyrightⓒ2003

Design Reuse and SOC Platform

Similar presentations

Presentation on theme: "Design Reuse and SOC Platform"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Design Reuse and SOC Platform

Similar presentations

Presentation on theme: "Design Reuse and SOC Platform"— Presentation transcript:

Similar presentations

About project

Feedback