11

An Eclipse Editor for IP XACT

Anthony Berent

ARM Ltd

January 2007

© Copyright ARM Ltd, released under EPL 1.0. All logos are TM of their respective companies.

222

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

333

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).

444

IP-XACT design descriptions

Main elements of IP-XACT designs: Component instances referencing IP-XACT component documents

Point to point interconnections between bus interfaces of component instances.

Component Y Instance 1

Bus interface S

Component Y Instance 2

Bus interface S

Component X Instance

Bus interface M

Component B (bus component) instance

Bus interface MM

Bus interface MSBus interface MS

Interconnection

InterconnectionInterconnection

Design

555

IP-XACT component descriptions Main elements of

components are: 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.

Component

View A

Reference to associated

data (e.g. RTL model)

View B View C

Reference to associated data (e.g. drivers)

Reference to Lower Level Design (IP-

XACT Design Document)

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

666

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.

777

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.

888

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.

999

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

1010

Demonstration of Editor

111111

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.

121212

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.

131313

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.

141414

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).

151515

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)

161616

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.

171717

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.

181818

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.

191919

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.