2. 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
3. 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
5. 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
6. 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
7. What are the solutions ?
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
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
10. 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
12. 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
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: 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
16. 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. 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. 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. 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. 20
Use IP-XACT and auto-generate all
register specific codes from this file
22. 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
23. 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
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
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 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. 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. 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
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