Transcript IP-XACT and Eclipse DSPD

IP-XACT and Eclipse DSPD
VPP launch meeting
Anthony Berent
ARM Ltd
1
What is IP-XACT?
 Developed by The SPIRIT Consortium (http://spiritconsortium.org).
 Originally developed for delivering IP descriptions of components to EDA
tools, and for exchanging IP descriptions of designs between EDA tools:

Now starting to be used in other contexts, including the description of debugger
targets.
 An IP-XACT description of a design or component consists of a set of XML
documents referring to one another:

Main document types are:
 Design – A high level description of a design



Component – A description of a component type, including interfaces,
memory maps, and registers
 Bus Definition – A description of a bus type.
References between IP-XACT document are by 4 element identifier (vendor,
library, name and version; often abbreviated to VLNV).
IP-XACT also defines an interface for generators, which are utilities called up
from Design Environments to process IP-XACT data.
2
IP-XACT design descriptions
Design
Component X
Instance
Bus interface M
Interconnectio
n
Bus interface MM
Bus interface MS
Component B (bus component) instance
Interconnection
Bus interface MS
Interconnection
Bus interface S
Bus interface S
Component Y
Instance 1
Component Y
Instance 2
 Main elements of IP-XACT designs:
 Component instances referencing IP-XACT component documents
 Point to point interconnections between bus interfaces of component
instances.
3
IP-XACT component descriptions
 Main elements of
components are:
Bus interface B1
Memory map map1
Bus interface B2
Bus type X
Register R0
Bus type Y
Slave
Register R1
Master

Component
Signal map
Signals

Signal Map

Physical signal Sig1
Physical signal Sig2

Physical signal Sig3
View A
Reference to
associated
data (e.g. RTL
model)
View B
Reference to
associated
data (e.g.
drivers)
View C
Bus interfaces,
referencing bus
definitions to describe
the bus type
Memory maps,
including register
descriptions
Physical signal
descriptions
Views, referencing
non-IP-XACT data or
lower level designs.
Reference to
Lower Level
Design (IPXACT Design
Document)
4
IP-XACT bus definitions
 Bus definitions contain:
 A list logical bus signals:
 Includes signal direction, width, etc.
 mapped onto physical signals in components by the signal maps in

bus interfaces
Other connection restrictions:
 E.g. The maximum number of bus masters and slaves.
5
IP-XACT generators

Generators are tool independent utilities that process IP-XACT component or design data


Sometimes distributed with IP-XACT components (and referenced by them)
The Tight Generator Interface (TGI) defines remote procedure calls that run over SOAP
(Simple Object Access Protocol):
 Design rule checkers
 Documentation generators
 Programming language independent
 Defined using WSDL
 Provides access to DE’s model
 No other communication allowed between generator and DE
2. DE invokes generator
1. User
requests
generator
invocation
Design
Environment
3. Generator
makes TGI
calls to read
and modify
DE’s model of
the current
design
4. Generator
creates other
output
Generator
Other
Output
6
The SPIRIT Consortium membership
Board of
Directors
Contributing
Members
Reviewing
Members
Moxon
Design
Associate
Members
7
IP-XACT versions
 Most widely implemented version is IP-XACT 1.2:
 Released Summer 2006
 Only supports RTL component interfaces
 There is no IP-XACT 1.3!
 IP-XACT 1.4 was released in March 2008:
 Includes support of transactional component interfaces for ESL



modeling
Some significant enhancements to RTL support
Uses Tight Generator Interface (TGI) for generators
User guide rewritten as formal standard:
 Probably easier to follow than 1.2 user guide
8
IP-XACT and Eclipse DSPD
 What is IP-XACT?
 IP-XACT for debug, and the IP-XACT editor
 VPP and IP-XACT discussion
9
Using IP-XACT for embedded debug
 In the old days embedded systems were simple:





One processor
One bus (maybe two)
A few peripherals
The only debug hardware (if any) was a breakpoint unit on the
processor.
Hence easy to describe to debugger
10
Using IP-XACT for embedded debug
 Embedded systems are now much more complicated:





Many processors (sometimes dozens!)
Many buses
Many peripherals
(Sometimes) lots of debug hardware:
 E.g. ARM’s CoreSight debug peripherals and buses.
Difficult to describe to debugger
11
Using IP-XACT for embedded debug
 We need a language for describing systems to debuggers.
 IP-XACT fits well:





Already exists
Describes most of what debuggers need to know
Hardware and debugger neutral
Can be created by hardware design tools.
Can be converted to proprietary debugger formats, or used directly by
debuggers as their format.
 The SPIRIT Consortium have created a Debug Working Group
to support this activity
 Eclipse DSDP have chosen to use IP-XACT as their standard
way of describing embedded targets.
12
Data-flow between Design Teams
IP Components
IP vendor
ETB
ARM
CPU
TRACE
FUNNEL
DSP
DAP
PERIPHERALS
Other IP
Component I/O and memory map
information as a IP-XACT XML File
System designer
ARM CPU
DAP
ROM, RAM
EDA /
ESL
Tools
ETM
DSP
CTI
PERIPHERALS
FUNNEL
SoC
PERIPHERALS
Other tools:
• IP-XACT editor
• Proprietary tools
• Autodetect from SoC
Topology and System Memory Map
Description as IP-XACT XML
Software
developer
Emulator
Reads debug access
descriptions from IP-XACT files
Debugger
Reads programmer’s
model from IP-XACT
files
13
Why develop an editor for IP-XACT?
 IP-XACT was originally developed as a standard for exchanging data
between EDA tools:


Typically large expensive tools (~ $1,000s per seat)
Often assume that IP-XACT component descriptions are supplied by IP
suppliers, hence have no tools for component description creation.
 When IP-XACT used for debug target description:



EDA tools may not be conveniently available.
IP-XACT design flow may not be complete.
New components and designs may need to be described (or descriptions
enhanced).
 Hence an IP-XACT editor would be valuable.
 Also useful for other IP-XACT users:

ARM and other IP vendors: for creating and editing component descriptions.
14
What does the IP-XACT editor do?
 Provides Enhanced and Customized XML editor


Automatically uses IP-XACT schema
Some context sensitive knowledge of IP-XACT semantics, used to give editing
hints.
 Provides view of IP-XACT library:



VLNVs of IP-XACT documents may not correspond to file name or folder
structure.
Library view sorts documents by vendor, library, name and version.
Library objects can be dragged to the editor window to create new references
to them:
 Components can be dragged into designs to create new component
instances
 Bus definitions can be dragged into components to create new bus
interfaces.
15
What does the IP-XACT editor do?
 Searches for and displays uses of and references to IP-XACT
documents.
 Includes references window and search window.
 Provides Wizards for:
 Creating new IP-XACT documents
 Inserting new elements into IP-XACT documents
 Includes IP-XACT semantic checker to check (mainly cross
document) rules that are not enforced by IP-XACT schema.
16
The IP-XACT Editor
17
The IP-XACT editor – current status
 Initial work contributed to DSDP/DD early 2007
 Europa (Eclipse 3.3) includes early preview version:
 IP-XACT 1.2 only
 Other limitations
 Ganymede (Eclipse 3.4) includes late preview version:
 Functionality basically complete
 Support for IP-XACT 1.4
 Full release (1.0) will be in DSDP/DD November release:
 Will tidy up and formalize APIs
 Intended to make reuse and extension easier.
 No significant functional changes from Ganymede version.
 All work to date contributed by ARM.
18
VPP and IP-XACT discussion
 What does VPP want to provide for IP-XACT support, and
relationship to needs of DSDP/DD. Possibilities include:
 API providing some level of abstraction of IP-XACT (what level?)
 TGI server, or server framework
 TGI library for generator
 Improved (graphical?) editing or analysis tools for IP-XACT
 How does the IP-XACT work relates to other VPP work?
 How do DD's IP-XACT work and VPP's IP-XACT work relate?
 Offers of participation in the IP-XACT work.
19