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.

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

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

IP-XACT design descriptions Component X Instance Bus interface M Design Interconnection Component B (bus component) instance Bus interface MM Bus interface MS Bus interface MS Interconnection Interconnection Component Y Instance 1 Bus interface S Component Y Instance 2 Bus interface S Main elements of IP-XACT designs: Component instances referencing IP-XACT component documents Point to point interconnections between bus interfaces of component instances.

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 Memory map map1 Bus interface B1 Bus type X Slave Register R0 Bus interface B2 Bus type Y Master Register R1 Signal Map Signal Map Signals Physical signal Sig1 Physical signal Sig2 Physical signal Sig3 View A View B View C Reference to associated data (e.g. RTL model) Reference to associated data (e.g. drivers) Reference to Lower Level Design (IP-XACT Design Document)

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.

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.

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.

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

Demonstration of Editor

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.

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.

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.

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

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)

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.

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.

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.

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.