the next generation of ip & soc development platform
TRANSCRIPT
Towards a Dynamic IP& SoC Integration Platform
Ad-hoc Release System
x Ad-hoc heterogeneous methodologies
x Poor performance & scalability
x Poor data traceability
x Workspace population coherency issues
x Release paralysis
x A release is a tag of the entire design hierarchy
x Tags not immutable, trying to hit a moving target
x Frequent resource conflicts
x Weak links to Issue Tracking
x No IP re-use methodology
x Bound to underlying legacy DM system
x Poor ad-hoc data validation
x File system access control
x Manual notification
MDX: correct-by-construction
� Formal & Engineered homogeneous methodology
� High performance, highly scalable
� Persistent components database with full history
� Workspaces built from a known good dataset
� Incremental release & propagation capability
� Aggregated releases thru the component hierarchy
� Immutable releases tags
� Prevent resource conflicts by design
� Tightly-coupled with Issue Tracking
� Database of IP facilitates re-use
� DM agnostic, supports multiple DM systems
� Built-in validation of data on release
� Database-driven access controls
� Integrated Notification System
The “Onion” Approach
A released layer wraps the layers beneath. Any modification in a
layer will require an entire re-release, and verification, of all the
layers above.
The “Flower” Model
A Component is broken up into Deliverables & Component
Resources. These “petals” can be modified and released
independently. On release, the “petals” are validated and
synchronized.
Hands-on Illustration: Altera Ecosystem in Practice
A Corporate Ecosystem: Design Complexity & Teams Interactions
• 11 teams
• 45 unique deliverables
• 201 channels of communication
Deliverables Dependencies
• 42 manifests & root data checks
• 47 context checks
Continuous Dynamic Integration in a nutshell
Propagate throughout the hierarchy Store the changes, Check & Release
1. SCH@v2 is a new, unverified stored Deliverable
2. SCH@v2 is checked: type check, data check
3. SCH@v2 is checked in the context of ADC@v1
4. Verified SCH@v2 is released towards ADC@v2
The only changes from ADC@v1 to ADC@v2 are in the SCH deliverable – all other deliverables are identical
Create a workspace & Edit the data
• Load ADC@v1 into a workspace
• Modify SCH data in a schematic editor
The Next Generation of IP & SoC Development Platform
Starting Node
SoC@v1
Analog@v1
Bluetooth@v1 Radio@v1
ADC@v1
RTL@v1 SCH@v1 LAY@v1
LNA@v1
Digital@v1 Firmware@v1
ADC@v1
RTL@v1 SCH@v1 LAY@v1
ADC@v2
RTL@v1 SCH@v2 LAY@v1
SoC@v2
Analog@v2
Bluetooth@v1 Radio@v2
ADC@v2
RTL@v1 SCH@v2 LAY@v1
LNA@v1
Digital@v1 Firmware@v1
New candidates are dynamically created and
notifications triggered
System Overview
Methodics Database
Release
Manager
Workspace
Manager
Verification
Platform
Web
Interface
Other
e.g.
Analytics
Perforce, Subversion, ClearCase, CVS
DB
DM
DM Clients
(e.g. VersIC,
P4V)
Clients
File System
Deliverable-based Release Methodology Concepts
Deliverable DependenciesDefining The Corporate EcosystemExploring Team Interaction through Deliverables
Place and
Route
Team
Logic
Synthesis
Team
Digital
Design
Team
Architecture
Team
Specification
SPEC
Verilog/
VHDL
RTL
Gate-level
netlist
LEF
Parasitics
SDF
• Identify the teams
• Identify the channels of communication
• Identify the deliverables transiting in the channels
SPEC
RTL
LEF
SDF
Checks
Checks
Checks
• Precedence relationships between deliverables define
required release checks
• Only need to check consistency with direct “neighboring”
deliverables
Understand the Corporate structure:
identify the teams and the data that passes
between them
Mixed Signal Block Deliverables Graph
RTL – Verilog/VHDL
GLN – Gate Level NetlistPNR – Place and Route
SPF – Standard Parasitic Format
Blue – No predecessor
Red – Manual stepsPurple – Derived data
SPEC
TESTBENCH
MISC
DATA
SHEET
GLN
PNR
STATSPNR
ANALOG
LAY
RTL
HDL
TIMING
SCHEMATIC
SPF
GDSABSTRACT
BLOCK
LAY
Web Interface Command Line Interface Extensions
IP
IPIP
Subsystem
Product
LibrarySubsystem
Product
IP
IP
IP
System
Subsystem
Subsystem
Library
IP IP
IP
IP
Bertrand Blanc ([email protected]) & Fergus Slorach ([email protected])
fergus@nexus (MDX)> mdx help simple
mdx by Methodics - common commands
boms List boms in a project
check Runs a verification suite on a deliverable(s).
connect Connect a node in a parent node
create Create a new object (IP or Library) in the database
edit Put one or more deliverables in edit mode
load Load the contents of a node into a workspace
local Place the specified ip in local mode.
node Show the contents of a node
nodes List nodes in a project
refer Place the specified ip in refer mode.
release Release a new version of one or more deliverables
store Create a new IP block release with local changes
fergus@nexus (MDX)> mdx help connect
usage: mdx connect [-h] [--verbose VERBOSE] [-v] [--deliverables]
[--description DESCRIPTION] [--hardlink]
[--release RELEASE] [--purpose PURPOSE] [--force]
[--propagate]
CHILD<,CHILD1,CHILD2,...,CHILD{N}> PARENT@RELEASE
connect - Connect a node in a parent node
• Create resources
• Connect resources to build a design hierarchy
• Load workspaces from a known configuration
• Edit only the deliverable(s) you need
• Check your changes
• Release your changes to create a new verified configuration
• Report status from the database
• Set properties on database objects
• Roadmap tool for project planning and to provide visibility into
project status
• Integrate with regression testing
• Add quality metrics to IP
• Data-mining to get insight into IP Usage, design churn, resource
bottlenecks, etc
• APIs allow for customer-developed extensions
• Generic Digital Asset Release Management – not just IC Design
Dynamic Configuration of MDX
• A Template defines the collection of files for each deliverable
• A Type Check and Data Check is created for each deliverable
• A Context Check is created for each relationship between deliverables
serv
ice
s
Templates Checkers
VP
Registration & Configuration
Perforce
Meta
Data
DesignSync Subversion
File
mapping
end-users
CAD department
Deliverables
super-users