Transcript The IP-XACT editor for Eclipse

An Eclipse Editor for IPXACT
Anthony Berent
ARM Ltd
January 2007
© Copyright ARM Ltd, released under EPL 1.0. All logos are TM of their respective companies.
1
An Eclipse Editor for IP-XACT
 Summary of IP-XACT
 Why develop an editor for IP-XACT?
 What does it do?
 Demonstration of editor
 How does it work?
 What doesn’t it do (yet)?
 Other issues

Editor contribution (still to be accepted) in Bugzilla 169333
2
Summary of 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).
3
IP-XACT design descriptions
Design
Component X
Instance
Bus interface M
Interconnection
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.
4
IP-XACT component descriptions
Component

Memory map map1
Bus interface B1
Register R0
Bus interface B2
Bus type X
Register R1
Bus type Y
Slave
Master
Signal Map
Main elements of
components are:
 Bus interfaces,
Signal Map

Signals
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
Reference to
Lower Level
Design (IPXACT Design
Document)

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.
5
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.
6
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 (~ $10,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.
7
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.
8
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
9
Demonstration of Editor
10
How does the editor work?
 Basics:

Built on top of Web Tools XML editor, with some extensions and additional
views.
 Plug-ins:


…ipxact.editor.core:
 Partial object models of IP-XACT document types and some IP-XACT
elements.
 IP-XACT content types for each IP-XACT document type.
 IP-XACT library implementation
 Various small utilities
…ipxact.editor.ui:
 Extension point implementation for context sensitive editing hints.
 Library, cross-reference and search views
 Drag and drop implementation:
 Including enhancements to XML editor drop implementation.
 Property sheet implementation (extended version of XML editor property
sheet).
 Wizards, dialogs, preference page.
11
Implementation of context sensitive hints

Uses org.eclipse.wst.xml.core.modelQueryExtensions
extension point to plug into XML editor:
 Private extension point, but based on discussions on Bugzilla bug
153563 likely to become public (in some form) in future.

Derives property sheet from XML editor property sheet, and
plugs it in using org.eclipse.wst.sse.ui.editorConfiguration:
 Why does ModelQueryExtension not provide property sheet support?
 Possible bug, not yet reported in bugzilla.
 Deriving from the XML editor property sheet classes breaks API rules,
but I couldn’t find any other way to do this.
 UI code creates a SpiritDocument object from the editor input
 SpiritDocument provides an interface for getting hints for

attribute or element values.
The implementation of this is incomplete in the IP-XACT core.
SpiritDocument only provides a hints in a few cases.
12
Library and library view




Library is generated at Eclipse startup from all resources in
workspace with IP-XACT content types:
 Listens for new and removed resources, and updates as needed.
Each library entry references a SpiritDocument for the
resource (which includes a DOM model).
Three structures for finding entries:
 Resource name to entry hash
 VLNV to entry hash (with duplicate VLNV handling)
 4 level VLNV tree.
Library view is simple 4 level tree:
 Context menu items for opening and finding references.
13
Drag and Drop from library window
 New SpiritDocumentTransfer class simply serializes the VLNV
 Drag source provided by LibraryViewDragSource class
 Drop handled by:






SpiritDragAndDropManager
 Replaces XMLDragAndDropManager.
 Calls DragNodeCommand from XML editor for local drags
SpiritViewerDropAdapter
 Replaces XMLViewerDropAdapter
DragComponentCommand
 Creates dialog using CreateNewInstanceDialog
DragBusDefinitionCommand
 Creates wizard using CreateNewBusInterfaceWizard
All of this uses internal XML editor interfaces, but we could not find an
alternative (short of rewriting the XML editor from scratch).
 Plugged into editor by replacing XMLMultipartEditorPart and
XMLTableTreeViewer with Spirit equivalents (SpiritMultipartEditorPart and
SpiritTableTreeViewer).
This has been significantly modified in the last week (not yet in Bugzilla).
14
Drag and Drop from library window

Inserting components or bus interfaces requires access to
editor’s structured model:
 Accessed through IStructuredModel interface:
 Currently internal to SSE (Structured Source Editor; Web Tools editor
framework) but widely used elsewhere within Web Tools.
Handled by EditorHelper class (in …ui.utils package).


Bus interface wizard also requires knowledge of IP-XACT
elements and semantics.
 Provided by SpiritObject class and subclasses (in …core.object
package)
15
What doesn’t the editor do (yet)?

New features:
 IP-XACT Semantic Checker:
 Being developed as additional plug-in. Will be added to submission.
 Register and address space views
 Graphical views and editors:
 Totally separate from current editor:
 Complimentary since graphical editor only likely to work when
starting from syntactically and semantically correct IP-XACT file.
 Can probably be created using GMF (Graphical Modeling
Framework):
 I have done some initial experiments on this, but still at an early
stage.
 GMF itself is still developing, so time may not be right yet.
16
What doesn’t the editor do (yet)?

Extensions to current features:
 Context sensitive content hints very incomplete
 More drag and drop options possible (e.g. drag design to component


view to insert hierarchical design).
Allow drag from navigator view (as well as IP-XACT library view)
IP-XACT specific outline and/or design views:
 E.g. component instance names shown without having to expand
component instance node.
 Difficult to do without major surgery on XML editor.
17
Other issues


IP-XACT schema itself cannot be included in Eclipse
contribution due to incompatible license:
 Read from web location when editor starts.
 Users could download it and create an XML catalog entry for it.
Various minor bugs known in editor:
 E.g. assumes in some places that the XML prefix for IP-XACT is always


“spirit:”
We will be fixing these over the next few weeks or months.
Also some minor structural improvements possible.
18
Other issues

Use of non-API functions and extension points:
 Biggest problem is use of XML editor classes, since, from discussion in
Bugzilla 131262 there is no intention to add these to the API.



Various bugs found in existing Eclipse code:
 Bugzilla entries 113565, 132842, 136325
 Some needed workarounds in editor code:
 Including creating modified copies of two classes
No automated tests in contribution:
 Some exist for core plugin; but not complete or IP clean
 None for UI.
No user documentation in contribution:
 Will follow.
19