VSIA’s Platform-Based Design Development Working Group ... · PDF fileVSIA’s Platform-Based Design Development Working Group (PBD-DWG) Bob Altizer ... • Alcatel • Analog Devices

ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 1

VSIA’s Platform-Based DesignDevelopment Working Group

(PBD-DWG)

Bob AltizerVSIA PBD-DWG Chair

BASYS ConsultingPhoenix, Arizona USA

[email protected]

BASYSConsulting


VSIA’s Premises on Platform-Based Design

• Platform-Based Design is the reuse paradigm for the next level of issues VSIA is facing.

• The embedded systems industry can reduce risk and cost, and enhance interoperability, time-to-market, and economic return, by applying principles of platform-based design for families of products.

• At present there is no standard, repeatable methodology or approach to defining, scoping, specifying, or reusing a platform, or defining interconnections between hardware and software IP blocks that can be used at different levels of abstraction and product integration.

• Today’s platform is tomorrow’s component!


Why Platform-Based Design?

• Platforms are the catalyst for systematic reuse, rapid development, and integration of derivative products, and can drive dramatic reductions in time-to-market.

• PBD will lead to fundamental agreement on foundationsand definitions, and enable better interaction between suppliers and customers throughout the design chain .

• It’s an integration thing: integration skills and an integration-oriented development flow are vital.

• VSIA members have more to gain by collaboration than by keeping all their work in PBD proprietary.


So What’s a Platform?


The Product Line Approach

• Product Line– A group of products sharing a common, managed set of features, that

satisfy needs of a selected market (NOTE: common features can be instantiated as a platform)

• Product Line Practice– The systematic development and use of IP assets to modify, assemble,

instantiate, or generate the multiple products that constitute a product line– Based on strategic, large-grained reuse as a business principle– Exploits techniques for finding and exploiting system commonalities

(platforms) and for controlling variability (differentiating IP)

• Product Line-Oriented Development – Product development cycle time and customer time-to-market shortens– A low risk, high return proposition– Reuse of validated components leads to quality and reliability improvement– Technical foundations: domain engineering, architectures, reengineering


What’s a Product Family?

Digital Camera PFMP3 Player PF

Cell Phone PF

Wireless HandsetSystems-on-Chip PF

Smart Card PFOrdering GUI PF

Source: TrueScope, Inc. and Motorola SPS


Platform-Based Design DWG Objectives

• Lead standardization of platform engineering for SOC-based embedded systems, based on our definitions of platforms and platform-based design, by identifying:– design flows and methodologies– levels of abstraction and integration– interchange standards

• Specify standards that promote effective platform-based design and interchange of platform-related IP.

• Develop a process for defining platforms and integratable VCs for product families based on SOC platforms:– Product family requirements identification– Economic and technical scoping– Domain analysis and platform architecture description– Integration with system-level design flow and hardware-dependent

software.


PBD DWG Membership

• Sigmatel• SIPAC• Sonics• STARC• ST Microelectronics• Synopsys• Telecom Italia Labs• Toshiba• University of Calgary• Virginia Tech University

• Alcatel• Analog Devices• ARM• BASYS Consulting• Cadence• IBM• Infineon• NCTU• Nokia• Philips Semiconductors

45 Total Members


Platform-Based Design DWG Charter

• The PBD Study Group and DWG will lead standardization of platform engineering for SoC-based embedded systems, based on our definitions of platforms and platform-based design, by identifying design flows and methodologies, levels of abstraction and integration, interchange standards, and other relevant topics, and specifying standards that promote effective platform-based design and interchange of platform-related IP.

• While platform-based design is applicable at many levels of integration within a finished product, our scope will be limited to platform-based products at the SoC level and below. SoCs, which themselves may be built on lower level platforms, will serve as platforms for higher level products.


Relationship Between VSIA DWGs

• When VSIA was first formed, almost everything covered by the roadmap was concerned with RTL and below.

• A system level design (SLD) group was established with the notion that in a few years there might be something above the RTL level.

SW Design HW Design

GateGateLevelLevel

Functional

Performance

RTL

SLDSLD

FVFV

Behavioral

System Design

SW Implementation

HW Implementation

Existing VSIA: OCB I/V TST AMS VCT IPP QLT

PBDPBD

HDSHDS

DESIGNDESIGN VERIFICATIONVERIFICATION

• Today, VSIA addresses a number of groups above the RTL level • The Technical Committee (TC) is the top-level architectural authority, assuring the

role and charter of each group is clear to them and to the external world, and each group’s work is leveraged with the others to the greatest degree.


Platform-Based Key Definitions

• Platform: An integrated, and managed set of features, upon which a set of products or product family can be built. A platform is a type of Virtual Component (VC).

• Platform Based Design: An integration-oriented design approach emphasizing systematic reuse, for developing complex products based upon platforms and compatible hardware and software VCs, intended to reduce development risks, costs, and time to market.

• Integration Platform: In the SoC context, a library of virtual components and an architectural framework, consisting of a set of integrated and pre-qualified software and hardware Virtual Components (VCs), models, EDA and software tools, libraries and methodology, to support rapid product development through architectural exploration, integration and verification. (Within VSIA, the scope of the integration platform is the SoC.)


PBD Point of View: Hierarchy & Evolution

Multiple levels of platforms exist within any product or system, with at least some degree of hierarchy between levels (though that hierarchy is probably imperfect) and evolution across platform generations.

Source: Carlos Oliver-Yebenes, ARM

Full ApplicationFull ApplicationLevelLevel

Implementation Implementation Technology LevelTechnology Level

Subsystem LevelSubsystem Level

ASIC Style Platform

P

ASIC Style Platform

P

ProcessorCentric

PlatformQ

ProcessorCentric

PlatformQ

3G WirelessPlatform

H1

3G WirelessPlatform

H1 3G WirelessPlatform

H2

3G WirelessPlatform

H2

ASIC Style Platform

P1

ASIC Style Platform

P1

ASIC Style Platform

P2

ASIC Style Platform

P2

ProcessorCentric

PlatformQ1

ProcessorCentric

PlatformQ1 Processor

CentricPlatform

Q2

ProcessorCentric

PlatformQ2

Evolution

HierarchicalDependence

Highly Programmable

PlatformQ

Highly Programmable

PlatformQ

3G WirelessPlatform

H

3G WirelessPlatform

H


Platform-Based Design DWG Objectives

• Lead standardization of platform engineering for SOC-based embedded systems, based on our definitions of platforms and platform-based design, by identifying:– design flows and methodologies– levels of abstraction and integration– interchange standards

• Specify standards that promote effective platform-based design and interchange of platform-related IP.

• Develop a process for defining platforms and integratable VCs for product families based on SOC platforms:– Product family requirements identification– Economic and technical scoping– Domain analysis and platform architecture description– Integration with system-level design flow and hardware-dependent

software.


Accomplishing PBD DWG Objectives

• Tailor existing, successful technologies for use in the SOC platform environment.

• Carry out a sequence of specific tasks defined and directed by the PBD DWG and “run like a project” with specific goals, deliverables, schedules, and named resources (task duration will be limited to six months or less each)

• Current work products under development:– Definitions and Taxonomy– White Paper “Introduction to PBD of SoCs”

• Meeting– Bi-weekly DWG teleconferences– Face-to-face meetings at industry meetings (ASP-DAC, DATE,

DesignCon, USA-DAC, etc.)


PBD Definitions and Taxonomy

• Now on working draft 0.10• Wrap-up and release in 1Q03• Focus on three platform types:

– Application-driven (top-down)– Architecture-driven (middle-out)– Technology-driven (bottom-up)

• Needs:– Examples of our defined types in the real world– “OSI Model” of platforms to define hierarchy, enable standards for

interconnect and relationship between levels of integration


PBD Taxonomy Axes and Styles

StructureMark

et

Func

ti on

Block-based(below Platforms)

Technology-Driven(bottom-up)

Architectural-Driven(middle-out)

Applications-Driven(top-down)

FunctionApplication

Component

System

StructureLibrary Framework Application

Market

Statistical

Segment

Specific

Source: Larry Cooke


Opportunities for Participation

• PBD DWG membership open to any VSIA member institution or individual member. (http://www.vsi.org)

• Immediate opportunity to contribute to the ongoing Definitions and Taxonomy, and initial White Paper

• Define and refine the fundamental models and methods for using platforms at the SoC and sub-SoC integration levels:– Core Platform contents– Platform/Differentiating IP interfaces and interconnects– APIs at Core Platform and SoC level– Methodologies for platform scoping and specification– Integration-oriented design processes

… and plenty more


Thanks for your kind attention!

To learn more about participating in theVSIA Platform-Based Design DWG,

contact Bob [email protected]

Or contact VSIA at:http://www.vsi.org


Backup Slides


Application/Technology Driven SOC Platforms

ProductProductRequirementsRequirements

PlatformArchitectures

Family 2Family 2

PlannedDerivatives

Platform 1Platform 1

Family 5Family 5Family 3Family 3

Family 1Family 1

Platform 2Platform 2

AnalysisAnalysis

TopDownDesignIP Lib

Application DrivenPlatforms

IP Lib

BottomUp

Design Technology

Function

Flexibility

Size

Performance

Power Analysis

Old Designs

Technology DrivenPlatforms

Source: Larry Cooke


Platform Attributes (partial list)

Very stable (for life of product family)

Fairly stable (evolves as TF components change)

Volatile (may not have many real “derivatives”)

Stability

“What do I need to support a product line?”

“What HW/SW support do I require?”

“What can I put in that’s cool?”

Platform designer’s driving question

Reuse without rework of core or SOC platform

Reuse without rework of the TF

Traditional; seeking optimization

Platform integrator’s design method

System and product levels; middle-out IP

Technology foundation composition exploration

Component and interconnect levels

Creation emphasis on…

Product line need, driven by feature set evolution, new standards

Technology Foundation change

Capability breakthrough or planned evolution in key technology

Platform change trigger

TechnologyLoose coupling to both apps & technology

ApplicationsAgnostic WRT…

System-level, based on application product family

System-level, based on composable technology foundation

Traditional designPlatform creator’s design method

Top-DownMiddle-OutBottom-UpApproach

Application-Driven Platform

Architecture-Driven Platform

Technology-Driven PlatformAttribute


Applying Platform-Based Design

• Where is it useful?

In a product line/product family environment, where several product family members can be built as derivatives of a common, domain-specific platform.

• Where is it NOT applicable?

Most everywhere else: full custom design, silo products, derivatives of“platform products,” opportunistic reuse, etc.


PBD Point of View: Multiple Platform Levels

SystemSystem--onon--aa--ChipChipProduct FamilyProduct Family

Modules & PeripheralsModules & PeripheralsStandard Modules

CoreEmbeddedSoftware

Test Interfaces

System Interfaces

Memory Interfaces

Memories

Standard ModulesStandard Modules

CoreCorePlatformPlatform

CoreCoreEmbeddedEmbeddedSoftwareSoftware

Test InterfacesTest InterfacesSystem InterfacesSystem Interfaces

Memory InterfacesMemory InterfacesMemoriesMemories

Modules & PeripheralsModules & Peripherals

Computing Computing ComplexComplex

Modules & PeripheralsModules & PeripheralsSystemSystem--onon--aa--ChipChip

Product FamilyProduct Family



Test Interfaces

System Interfaces

Memory Interfaces

Memories




Test InterfacesTest InterfacesSystem InterfacesSystem InterfacesMemory InterfacesMemory Interfaces

MemoriesMemories



Modules & PeripheralsModules & PeripheralsSystemSystem--onon--aa--ChipChip

Product Family MemberProduct Family Member



Test Interfaces

System Interfaces

Memory Interfaces

Memories




Test InterfacesTest InterfacesSystem InterfacesSystem Interfaces

Memory InterfacesMemory InterfacesMemoriesMemories




At least two levels of integration platform:• Core Platform: Basic computing/information processing

capability, including some embedded software.• System-on-Chip: Integrates core platform and differentiating

IP to form market-specific system-level platform


PBD Point of View: Product Family Approach

Product FamilyRoadmap(all products) Product Family RoadmapProduct Family Roadmap

= Architecture

= Design andImplementation

S L1

L2PlatformDevelopmentV1

V2

Platform RoadmapPlatform Roadmap (Commonalities)

Differentiating IPRoadmapDifferentiating IP Roadmap (Variabilities)

Differentiating IPDevelopment

Pi = Different Products in the Same Product FamilyVi = Platform VersionLi = Manufacturing ReleaseS = Start of Project TTM = Time to MarketTBSP = Time Between Successive Products

Product Roadmap(Family Members)

Product Roadmap

Product FamilyMemberDevelopment

S LP1

LP2

S LP3

TBSP

TTM’

TTM S


PBD Point of View: The Dual Life Cycle

CommonElement

Identification

CommonArchitectureDevelopment

BuildingBlock

Development

DomainModels*

DomainArchitectures*

ReusableBuildingBlocks*

ProductRequirements

ProductDesign

ProductDevelopment

DomainCustomer

Needs

DomainModel

DomainArchitecture

ProductCustomer

Needs

ProductRequirements

ProductArchitecture

RefinementsRefinementsRefinements

Delivery

Applications

Platform &IP Assets

DevelopmentTechnology

Info

Platform &IP Assets

Repository/Maintenance

RequirementsElicitation

MarketResearch Product

Development(Platform &IP Assets

Consumers)CustomerInput

Customers* Reusable “Core Assets”


PBD Point of View: The Platform “Power Tower”

Top Tier

Derivative Products(platforms plus differentiating features)

Platform #3

Platform #2

Platform #1

Market Tiers(as needed)

Market Segments

Market Applications Middle Tier

Bottom Tier

Product Platforms

(Successivegenerations of theproduct platform)

BuildingBlocks

ConsumerInsights

ProductTechnologies

ManufacturingProcesses

OrganizationalCapabilities

Source: Marc H. Meyer and Alvin P. Lehnerd, “The Power of Product Platforms”


Definition Needed: What is a Platform?

• There are as many definitions as people asked!

• Some theoretical definitions beginning to emerge:– “A platform is, in general, an abstraction that covers a number of possible

refinements into a lower level. For every platform, there is a view that is used to map the upper layers of abstraction into the platform and a view that is used to define the class of lower level abstractions implied by the platform” (Alberto Sangiovanni-Vincentelli, GSRC white paper on Platform-Based Design)

– “An integration platform is a reuse mix-and-match environment designed specifically to target an application domain. The domain is selected based on market objectives and is focused to yield a high probability of reuse over a target period of time.” (Cadence white paper “The IP Reuse Evolution”)

– “A platform is a collection of assets which can be used to leverage reuse and rapidly develop new products. At a minimum, it defines the operating environment, high level product architecture for all products developed based on this platform, and set of development policies for extending the platform and developing point products from the platform.” (Motorola PCS/ATSO “Reuse Lifecycle Model, v1.0”)

– “An embedded system platform is an architectural framework for rapid integration of embedded SoC-based designs, consisting of a set of pre-qualified software and hardware IP blocks and a methodology to support rapid architectural exploration, integration, and verification.” (Frank Pospiech, Alcatel)


PBD Point of View: Platform Postulates

• Sets of functional components can be defined that can serve as the basis for multiple derivative SOC products (i.e., platforms; aggregations of IP)

• Platform-based development depends on the existence of:– defined and verified platforms – integratable IP components– integration-oriented design flow – tool, application and systems support

• Economic advantage from derivative products will be realized through:– enhanced product capability – improved time to market– improved margins – improved quality

• Advantages will be large enough to justify investment in developmentof platforms, collateral IP, tools, and support


Agreement with the VSIA TC

• Platforms address the bigger picture:– Embedded software– Integration-based development flows– Connectivity– Verification– System-level modeling– System-level design intersects a portion of platforms

• Charter, taxonomy, and vision are the key deliverables– Coordinated charter and “Grand Unified Taxonomy” with HDS, SLD,

and FV DWGs– Characteristics in common across all taxonomies– Include characteristics and categories of existing platform approaches

• PBD activities will be undertaken with “project orientation”– Define finite tasks to which members can be assigned – and be accountable – Plan for task completion in 6 months or less


PBD Point of View: Platform Types

• There is not just one kind of platform; we have to consider several independent issues:

– Level of Integration (within the overall product)– Viewpoints (the concerns of some stakeholder)– Application Domains (wireless, industrial, networking, automotive, etc.)

Leve

l of I

nteg

ratio

nLe

vel o

f Int

egra

tion

ViewpointsViewpoints

Application Domains

Application Domains


PBD Point of View: Platform Types

• Some as-built examples exist describing patterns or types of platforms (e.g., full application, processor-centric, communication-centric, and reconfigurable platforms); others can probably be identified as well. Some of these may be linked hierarchically.

Processingsubsystem

Cellular BB

Cellularengine

Personalcomm-unicator

PlatformsSW components

RTOS

modem L1 SW

L2/3 SW

ApplicationOS

SW devtSupport

L1 API, peripheral/processor HAL

OS hooks

Application cellu API, accessory API,game API, etc.

HW devt support

Si library,back-end tools, bus generators

PCB data

Mechanical constraints

Logistics

Design rules, process/design dataavailability, supported EDA

P&R, proto relationship

Componentsourcing

Manufacturing

HW components

µC core, DSP core, I/O, cache, flash

Processor, custom modem logic

Cellu BB, RF, DRAM, mic, LCD, speaker

Cellu Engine,mechanics,accessories

Compiler, debugger, HW API

Front plate/ battery rules

SLDsupport

L1 SDL stub

L2/3 stub

UI emulator

Processor Cmodels,bus analysis tools

Source: Anssi Haverinien, Nokia


PBD Point of View: Implementation, Tools, Models

• A platform at any level exists as a black box• Platforms must have:

– a real implementation (an integrated, verified set of both hardware and software functional components);

– a definable, complete architectural description (may be derived from an as-built implementation);

– a complete and accurate set of models describing its actual behavior (this may be redundant with the AD, or the AD may call for more models than yet exist);

– a set of tools to permit integration of the platform model into the model of a higher level system;

– a set of tools to permit integration of the real platform implementation into the implementation of a higher level system.

Documents

VSIA’s Platform-Based Design Development Working Group ... · PDF fileVSIA’s Platform-Based Design Development Working Group (PBD-DWG) Bob Altizer ... • Alcatel • Analog Devices