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
Physical signal Sig2
Physical signal Sig3
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
Physical signal Sig1
Physical signal Sig2
Physical signal Sig3
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 Design XML Example
13
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
25
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
Thanks ! Questions?
31

Verification Automation Using IPXACT

  • 1.
    Verification Automation using IPXACT RohitJindal & Raman Singla ST Microelectronics Date – 22nd Dec,2011
  • 2.
    Agenda  Typical Challengesin verification  Using IP-XACT for verification platform integration  Using IP-XACT for register test generation  IP-XACT history  Q&A 2
  • 3.
    Introduction  Ever increasingdesign complexity  IP Integration  Verification  Increased Cost  ~80% cost is head-count related  TTM pressures  ~89% of designs go over deadline by avg. 44% 3
  • 4.
  • 5.
    Typical challenges inverification • 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
  • 6.
    What if wehave ?  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
  • 7.
    What are thesolutions ?  Excel based solutions  In house solutions  CIDL  Use IEEE IP-XACT standard 7 IP-XACT
  • 8.
    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
  • 9.
    IP-XACT Objects  AnIP-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
  • 10.
    IP-XACT component descriptions 10 Component Physicalsignal Sig1 Physical signal Sig2 Physical signal Sig3 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
  • 11.
  • 12.
    IP-XACT Design File 12 Component Physicalsignal Sig1 Physical signal Sig2 Physical signal Sig3 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
  • 13.
  • 14.
    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
  • 15.
    With IP-XACT: Designiteration 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
  • 16.
    Applying IP-XACT tothe 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.
    17 IP spec IP-XACT IP-XACT Tool TLMskeleton Tool Verification Plt TLM IP verification platform generation flow TLM IP IP Database DUT ROUTER C test HOST Test Env IPIP IP
  • 18.
    18 IP spec IP-XACT IP-XACT Tool RTLskeleton 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.
    19 Registers : Typicalscenario  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.
    20 Use IP-XACT andauto-generate all register specific codes from this file
  • 21.
    21 IP spec IP-XACT IP-XACT Tool Cheader/test Register Generation Flow Register testcases DUT ROUTER test HOST Test Env IPIP IP
  • 22.
    22 Design Flow usingIP-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
  • 23.
    IP-Xact benifits  Standardallows 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
  • 24.
    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
  • 25.
  • 26.
    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.
    27 IP-XACT TC Objectivesand 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.
    28 On the lighterside 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.
    29 On the lighterside Future  Resume of engineer  <skillset>VHDL,Verilog</skillset>  Interviewer asking candidate what is your VLNV  Grenoble Institute of Technology, Electronics, Gregory Bernard, 2010
  • 30.
  • 31.

Editor's Notes

  • #31 Firstly , IP-XACT is widely accpeted due to which it needs few enhancements to cover all corner cases also Secondly people want to use more and more data exchange through XML for verification. Software. Analog etc and this is where the challenge is. Because there is no end to it to usage of XML and where to put the border line. Cosim_wrapper