vsia’s platform-based design development working group ... · pdf filevsia’s...
Post on 15-Feb-2018
219 Views
Preview:
TRANSCRIPT
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
bob.altizer@basysconsulting.com
BASYSConsulting
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 2
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!
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 3
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.
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 5
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 6
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 7
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.
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 8
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 9
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.
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 10
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.
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 11
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.)
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 12
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 13
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.
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 14
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.)
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 15
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 16
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 17
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 18
Thanks for your kind attention!
To learn more about participating in theVSIA Platform-Based Design DWG,
contact Bob Altizerbob.altizer@basysconsulting.com
Or contact VSIA at:http://www.vsi.org
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 20
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 21
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 22
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.
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 23
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
Modules & PeripheralsModules & PeripheralsStandard Modules
CoreEmbeddedSoftware
Test Interfaces
System Interfaces
Memory Interfaces
Memories
Standard ModulesStandard Modules
CoreCorePlatformPlatform
CoreCoreEmbeddedEmbeddedSoftwareSoftware
Test InterfacesTest InterfacesSystem InterfacesSystem InterfacesMemory InterfacesMemory Interfaces
MemoriesMemories
Modules & PeripheralsModules & Peripherals
Computing Computing ComplexComplex
Modules & PeripheralsModules & PeripheralsSystemSystem--onon--aa--ChipChip
Product Family MemberProduct Family Member
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 & Peripherals
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 24
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 25
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”
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 26
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”
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 27
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)
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 28
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 29
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 30
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 31
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
ASP-DAC Panel 4B -- Introduction Bob Altizer -- Slide 32
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.
top related