Verification Automation Using IPXACT

Verification Automation using
IPXACT
Rohit Jindal & Raman Singla
ST Microelectronics
Date – 22nd
Dec,2011

Agenda
 Typical Challenges in verification
 Using IP-XACT for verification platform
integration
 Using IP-XACT for register test generation
 IP-XACT history
 Q&A
2

Introduction
 Ever increasing design complexity
 IP Integration
 Verification
 Increased Cost
 ~80% cost is head-count related
 TTM pressures
 ~89% of designs go over deadline by avg. 44%
3

DAC Study
4
significant efforts

Typical challenges in verification
• Developing Testbench
• Integration of components
• Configuration of IPs
 Developing Register test cases
 Changes are inevitable during design process
 Add/remove registers
 Register definition/bit fields
 Register location
 Register type
 Register implementation
 Monotonous work
 How to be consistence with Design and Architecture
Team
5

What if we have ?
 One specification for all information
 All representations/code generated from the
single source
 Single description for all registers
 Fully automated flow
 Industry (IEEE) standard
6

What are the solutions ?
 Excel based solutions
 In house solutions
 CIDL
 Use IEEE IP-XACT standard
7
IP-XACT

8
What is IP-XACT ?
 IP-XACT is an XML schema and semantics providing:
 Unified authoring, exchange and processing of design meta-data
 Complete API for meta-data exchange and database querying
 IP-XACT enabled meta-data provides language (and vendor)
independent description for IP’s
 Component meta-data describes
 IP ports and interfaces
 Registers
 IP Configurable parameters
 Design meta-data describes:
 Component instances
 Connectivity
 Provides mechanism to model IP at different abstraction levels

IP-XACT Objects
 An IP-XACT description of a design or component
consists of a set of XML documents referring to one
another:
 Main document types are:
 Component – A description of a component type, including
interfaces, memory maps, and registers (IP)
 Bus Definition – A description of a bus type.
 Design – A high level description of a design (SoC Netlist)
 References between IP-XACT document are by 4
element identifier (vendor, library, name and version;
often abbreviated to VLNV).
9

IP-XACT component descriptions
10
Component
Physical signal Sig1
Bus interface B1
Bus type X
Slave
Bus interface B2
Bus type Y
Master
Signal map
Signal Map
Memory map map1
Register R0
Register R1
Signals
Main elements of
components are:
Bus interfaces,
referencing bus
definitions to describe
the bus type
Memory maps,
including register
descriptions
Physical signal
descriptions

IP-XACT component XML Example
11

IP-XACT Design File
12
Component
Bus interface B1
Bus type X
Slave
Bus interface B2
Bus type Y
Master
Signal map
Signal Map
Memory map map1
Register R0
Register R1
Signals
Main elements of
components are:
Bus interfaces,
referencing bus
definitions to describe
the bus type
Memory maps,
including register
descriptions
Physical signal
descriptions

Pre IP-XACT : Separate design threads
14
Verification
Solution
Synthesis
Solution
RTLIP Spec
CPU
CPU
CPU
No exchange of
system configuration
… implies difficult
design iteration
and consistency
management
System
Profiling and
Exploration
CPUCPUIP Spec
SystemC Design Environment
Verification TB
IP Spec

With IP-XACT: Design iteration simplified
15
Co-Verification
Solution
Synthesis
Solution
CPU
CPU
CPU
I
System
Profiling and
ExplorationCPUCPUYour IPIP
IP-XACT XML
SystemC Design Environment
RTL Design
IP-XACT SoC
configuration XML

Applying IP-XACT to the verification platform
Integration
 What is Required
 IP-XACT descriptions of RTL design and verification components
 Testbench comprises of
 Component instances (design and verification)
 Connection between components
 Configurable Parameters of design and verification components
 Output
 IP-XACT Design file
16

17
IP spec
IP-XACT
IP-XACT Tool
TLM skeleton
Tool Verification Plt
TLM IP verification platform generation flow
TLM IP
IP
Database
DUT
ROUTER
C test
HOST Test Env
IPIP
IP

18
IP spec
IP-XACT
IP-XACT Tool
RTL skeleton
Tool Verification Plt
RTL IP verification platform generation flow
RTL IP
IP
Database
ROUTER
BFMs
sc wrapper
C test
HOST Test Env
RTL
IPIP
IP

19
Registers : Typical scenario
 Cost per register type
 Specifications ( 0.5 page )
 Datasheets
 Register tests
 RTL register decoder / netlist
 TLM models / netlist
 Register tests ( 30 lines per registers* [1..n] )
 Register C header, eSW (20 lines per registers *[1..n])
 Memory map representation ( ?? )
 There are hundreds of register in a typical IP
 Who will ensure coherency ?

20
Use IP-XACT and auto-generate all
register specific codes from this file

21
IP spec
IP-XACT
IP-XACT Tool
C header/test
Register Generation Flow
Register testcases
DUT
ROUTER
test
HOST Test Env
IPIP
IP

22
Design Flow using IP-XACT
Functional
Spec
IP -XACT
Description
IP
C header
IP
Register
test
Mixed
TLM/RTL
testbench
IP / (Sub)system architect
IP Verification team
Chip integration team
SW Driver team
Spec import
Check
QA Cosim wrapper
export
Header / Reg test export
Datasheet
Tech Pub
Datasheet export
TLM
Skeleton/
Netlist
TLM Modeling team
TLM Skeleton / netlist
export
Edit
Verilog
RTL
decoder
IP Design Team
Register bank export
IP
Register
test

IP-Xact benifits
 Standard allows multi vendor IPs/EDA tools use.
 Simplified integration
 Coherency with other design teams
 No duplication
 Automatic flow to avoid manual repetitive jobs
 Benefits: dramatic TTM Improvements
23

How SPIRIT evolves…
 Six companies started the SPIRIT Consortium in
2003 with the initial goal is to provide a standard for
describing IP to enable
 maximum design automation with multisource
IPs/multi vendor design flows
 reuse
 vendor neutral approach
 IP-Xact evolves as an industry standard to describe
IPs
 IP-Xact now an IEEE standard(p1685)
 SPIRIT Consortium now merge with another EDA
standards organization, Accellera
24
PHILIPS

26
Background of IP-Xact
 IP-XACT 1.5 was handed off to the IEEE P1685 Working
Group in late June 2009.
 Later in June 2010, IEEE released the standards as IEEE
Std1685-2009
 Merger of Electronic Design Automation (EDA) industry
organizations, Accellera and The SPIRIT Consortium

27
IP-XACT TC Objectives and Goals
 To collect requirements from all members for IP-Xact
enhancements
 Discuss and proposed solution amongst TC members
 Update IP-Xact standard as accellera extensions
 Handover the IP-Xact Accellera extensions to IEEE
 To ease the adoption of IP-Xact standard in industry
If you liked IP-XACT based flow and want to participate
in TC, join us through Accellera.

28
On the lighter side
Present
 Verification plan and reports are in XML
 Output logs and debug reports are in XML
Near Future
 Comments of code in XML
 Minutes of meeting in XML
Future
 Discussion between team members in XML
 For no further discussion - slash(/) discussion

29
On the lighter side
Future
 Resume of engineer
 <skillset>VHDL,Verilog</skillset>
 Interviewer asking candidate what is your VLNV
 Grenoble Institute of Technology, Electronics, Gregory Bernard,
2010

<lastslide> Thanks </lastslide>
30

Verification Automation Using IPXACT

More Related Content

What's hot (20)

Similar to Verification Automation Using IPXACT (20)

More from DVClub (20)

Recently uploaded (20)

Verification Automation Using IPXACT

Editor's Notes