WO2007080184A1 - Collaborative platform for electronic system-on-chip design - Google Patents

Abstract

The present invention provides a collaborative platform for electronic system- on-chip (SoC) design comprising an assembly of blocks designed by a plurality of design teams. This platform comprises in combination: a central platform including a centralized SoC project data repository adapted for storing major SoC project versions, a repository management module for controlling said repository, and a delivery platform for exchanging design data with the design teams, a plurality of design stations connected to the central platform through one among several possible network protocols, each station including block design tools for use by a respective design team and a packaging /delivery unit adapted to package each new block version elaborated by the design team by attaching thereto a hierarchical tag-based data structure representative of its contents, whereby a new block version transmitted by a design station to the central platform can be selectively accepted as a current version for accessibility by other design teams through the delivery platform together with its hierarchical tag-based data structure.

Description

"Collaborative Platform for Electronic System-on-Chip Design"

The present invention generally relates to system on chip (SoC) design, and in particular to a new collaborative environment for joint design of such SoCs by a plurality of design teams.

Complex ASIC Design is nowadays a collaborative process involving design teams geographically distributed all over the world. These teams need to have access to a common hardware and software library (including complex reusable blocks or "IPs") as well as to an efficient, server based SoC project status reporting system or project "viewer". It is also desirable that each team benefits from optimized information and file exchange mechanisms during all phases of the design project.

It is reminded here that by intellectual property ("IP"), it is meant a design block of a System on Chip ( SoC) dedicated to be delivered to a customer for integrating in such SoC.

The present invention seeks to provide a novel platform infrastructure presented here fulfilling the above requirements and improving information and design file exchange.

Another aim of the present invention is to provide an improved server-based design data reporting and exchange mechanisms using a specific signature- based exchange.

According to a first aspect, the present invention provides a collaborative platform for electronic system-on-chip (SoC) design comprising an assembly of blocks designed by a plurality of design teams, comprising in combination: a central platform including a centralized SoC project data repository adapted for storing major SoC project versions, a repository management module for controlling said repository, and a delivery platform for exchanging design data with the design teams, • a plurality of design stations connected to the central platform through one among several possible network protocols, each station including block design tools for use by a respective design team and a packaging /delivery unit adapted to package each new block version elaborated by the design team by attaching thereto a hierarchical tag-based data structure representative of its contents, whereby a new block version transmitted by a design station to the central platform can be selectively accepted as a current version for accessibility by other design teams through the delivery platform together with its hierarchical tag-based data structure.

Preferred but non-limiting aspects of this platform are as follows:

• said central platform comprises a user interface for browsing the hierarchical tag-based data structure of each block current version.

• said central platform comprises a project version management unit adapted to selectively accept all current block versions of the project as a current project version for direct accessibility by all design teams.

• said central platform comprises means for providing to the design platform, in response to specific requests, block versions which are former versions of the blocks belonging to the current project version. • said central platform comprises a user interface for browsing through a project-level hierarchical tag-based data structure including all block-level hierarchical tag-based data structures.

• said user interface allows browsing through any selected one of a plurality of project-level hierarchical tag-based data structures corresponding to different project versions.

• said hierarchical tag-based data structures are XML tree structures. • said XML tree structures are pseudo-schemas or schemas complying with the Spirit Consortium XML structures.

According to a second aspect, the present invention provides a method for organizing, packaging and delivering system-on-chip blocks stored in a database and comprising a plurality of block data files, comprising the following steps: for each block in the database, providing a block signature data layer, for each version and/or configuration of said block, providing in said data layer a hierarchical tag-based data structure including version data and/or configuration data and forming a respective signature of said version or configuration.

Preferred but non-limiting aspects of this method are as follows: • the method further comprises the step of: when an order for a given block version configuration is received from a customer, translating said order into a hierarchical tag-based data structure forming an order signature, and packaging and shipping the IP files of said block to said customer based on a translation of said order into a hierarchical tag-based data structure forming a delivery signature.

• the method further comprises the step of: for each block delivered to a customer, storing said delivery signature in the signature data layer.

• the method further comprises the step of: managing delivery history to each customer through said delivery signatures, thereby avoiding to specifically store actual delivered files.

• said delivery signature conforms to a XML schema allowing integration of the corresponding block into a well-structured system-on-chip.

Brief description of the drawings The present will be more fully understood from the following description of preferred embodiments thereof, made with reference to the appended drawings, in which:

Figure 1 is a block diagram showing the main parts of a collaborative platform according to the present invention,

Figure 2 shows the capability of heterogeneous networks afforded by the platform,

Figure 3 graphically shows an example of a XML signature of an IP version,

Figure 4 shows a possible user interface for a collaborative portal included in the platform,

Figure 5 illustrates how different functions can be available or not, depending on the user role,

Figure 6 is an example of an XML text file in XLML format,

Figure 7 illustrates the general architecture of a packaging/delivery station based on XML file signature,

Figure 8 illustrates the basic functions of the architecture of Figure 7 for an IP with static configuration,

Figure 9 graphically illustrates an example of a given configuration of an IP in the form of a configurable processor,

Figure 10 illustrates the basic functions of the architecture of Figure 7 for such a configurable IP, Figure 11 diagrammatically shows an architecture for IP packaging,

Figure 12 illustrates a number of primitives capable of exploiting an XML file signature layer,

Figure 13 illustrates the mechanism of migration from a Spirit XML schema to a XML pseudo-schema,

Figure 14 illustrates the structure of such pseudo-schema, and in particular leaf types and data,

Figure 15 illustrates the tagging of a package for generating different views according to the type of user,

Figure 16 illustrates a user interface for adding a property to a signature,

Figure 17 is an exemplary view of a package with added property,

Figure 18 illustrates the differences between partial views of the package at different levels of abstraction (RTL and TML), and

Figure 19 is a partial package view at the TML level of abstraction.

Detailed description of a preferred embodiment

A collaborative platform according to the present invention aims at improving cooperation between geographically distributed teams working on several subsystems, blocks and hardware or software views of a project. It is conceived at an architectural or system level and is intended to be highly efficient for complex SoC where hardware and software for instance are concurrently developed and need exchange at adequate time slots.

Design teams collaborate by delivering versions of their blocks that are referred in a broad sense as "IPs" (whether hardware design or software). The project is modeled as a server-based hierarchy of IP versions associated with a "project viewer" tool. Management features known per se, such as project and membership registration, access management, upload and download control, are inherited from commercially available IP Reuse station which is a companion tool provided by Design And Reuse, Grenoble, France. Similarly SoC project status reporting between teams as well as data exchange features such as import /export primitives across or within firewalls benefit from proven and powerful management features.

Special emphasis is put on efficient project status reporting. Various views (at various abstraction levels or qualification views or any other views) can be customized and easily available by browsing a so-called "project catalog". Moreover, design data reporting supporting data exchange among the teams is based on a XML file signature which is a preferred aspect of the present invention and will be described at a later stage. As will be seen, such a signature is automatically attached to a design block prior to its delivery and is a mandatory view of the delivery. As an extension, a SoC project signature is the union of the signatures of each block included in the project.

As far as revision control is concerned, one essential aspect of the present invention is the support of the hierarchical aspect of a project as well as heterogeneous revision control environments. The purpose is that each team may have its own workspace based on its own configuration system server but also, that different configuration tools can be used by the different design teams. Revision control is performed both at the block (IP) level exchange, enabling the download of modified files only, and also at the SoC project repository level, which "unifies" the file management system for IPs as well as for the whole project files stored without redundancy.

1 Architecture

The SoC Collaborative Platform of the present invention, as diagrammatically shown in Figure 1 , is organized around:

A SoC project server hosting a so called SoC project status report. Several projects can be handled by the platform. A global administrator manages the whole platform while Design project managers are responsible for each project.

A data hub also called Delivery platform for importing/exporting design data from/to the design teams.

A centralized SoC project data repository controlled by a repository management module storing major SoC project versions and unifying the revision control of each IP at the project level.

Packaging /Delivery stations installed at the design team sites where the designers "package" their block (IP) versions, such packaging including the attachment of the above-mentioned XML signature, and deliver the files to the data hub.

An optional IP library server which stores all existing "reusable" modules (whether hardware or software) relevant to the platform and based on the above-mentioned commercial companion tool (IP Reuse Station).

Design files are resident at the design team site as long as no major released version is delivered by the team and made exchangeable at the project level. When a design team delivers a new major IP version, the XML file signature is exported first to the data hub, followed by the files themselves. Upon acceptation by the Design Project manager, the files are made available to other teams and part of a new working release of the project. The design teams can then download the files, if relevant to their design task. It is the choice of the design manager to release a major version of the whole project, which is then stored in the SoC project repository. This major version release is then archived for as long as needed and is easily accessible for download by the design team from the Project server when a new version has been released but analysis of a previous version is required.

As illustrated in Figure 2, the collaborative platform of the present invention supports heterogeneous networks of design teams not only in terms of independent workspace and revision control systems but also in terms of exchange protocols. For instance, all design teams can be hosted within the same firewall and exchange operates on a LAN using a RMI protocol, or some design teams may be external to the firewall. When registering a design team in the SoC project, the type of communication supported is declared. Data Transfers supported typically are SMTP, FTP, HTTP and JAVA RMI. Future protocols are also to be included when compatible. Broadcast, import/export of signatures and files within and across firewalls are performed through efficient exchange primitives.

2 Overview of synchronization process & XML file signature

Project status synchronization is performed for all participants by the project Design manager. He is in charge of accepting new design block versions released by the design teams. He decides to release major project versions and then alerts all design teams. The project signature and the signature of all IPs of the released project version stay visible on the project server platform while the frozen files are archived in the repository. Design file download from the previous versions or current project version is only triggered upon design team request.

2.1 Communication Steps 2.1.1 Update by design teams and acceptance of a new block

A design team works in his local design environment, when a new block (new IP version) has been created:

The design team announces a new IP version of its block proposed for exchange. a snapshot of the design block (IP) is performed at the team level and its XML file signature is automatically created in the packaging station. It should be noted here that configuration data that may be available locally are captured in the XML signature.

The files associated to this new IP version are exported to the data hub of the SoC project server, and the design manager can then evaluate and /or accept the block. ^■ Upon acceptation, the design manager alerts all design teams about this new block accessible in the current SoC project version.

2.1.2 Releasing a new SoC project status

Upon acceptation of one or several blocks, the project manager may decide to release a new major SoC project version. Then:

He performs a "check in" action under configuration control of the new project version in the repository and this opens a new current project version display. All design teams are alerted and can propose new releases of their block in the new current Project version.

2.2 XML File signature (overview) Turning now to Figure 3, a XML signature of an IP version is a XML file organized around a XML DTD (Document Type Definition) representing the IP directory hierarchy. The nodes or leavers of this DTD are:

XML labels whose values are paths to the native files/packages. ^■ Attributes characterizing the version/revision.

Optional Attributes for supporting Management primitives.

It should be noted here that an IP version has two configuration identifiers:

One coming from the local native configuration system originating from the design team

One as a part of a SoC project which has become a major release.

Figure 3 of the drawings shows an example of an XML signature based on the so-called Medea Toolip profile (more information available at http://www.medeaplus.org/).

3. Project View and management functions

3.1 Project Views

A hierarchical Project view which can be easily browsed is one of the main features of the collaborative platform of the present invention. Such browsing is intended to afford immediate access to any metadata or file from any project version (current and previous) as required by a design team.

As illustrated in Figure 4, successive project versions (here "Leon Project") appear on the home page of the collaborative platform. It can be noticed that private forums, as well as helpdesks specific to a project appear on the right side. When clicking on a project version, the hierarchy of the project pops up as illustrated and it can be noticed that the version ID of each block belonging to the project is clearly displayed. Thus a double level of versioning is supported.

A design team can at any time upload a new IP version into the current version of the project, in addition, a designer can easily issue a download request for a obtaining specific IP version in a specific project version.

3.2 Management functions

The primitives are partitioned according to so-called roles, i.e. different levels of authority, as illustrated by way of example in the pop-up menu at the top right of Figure 4, where the different roles appear, namely Root, Admin, Project Manager, Design team, User such as a visitor, ...). When clicking on a role, the available functions appear.

In a preferred embodiment, the authorized actions for each role are as follows:

Admin

Configure SoC project server Register SoC projects and members Control the Access management ^■ Track the Users

Project Manager

Build project catalog, display IP status and any relevant information Qualify a new block version from the design team ^■ Display this new block for other teams in the current project version

Release new project major version Broadcast signature to all project members

Accept a Download request for IPs of the current version

Grant a Download right for IPs stored in the IP repository.

Design Team (remote actions)

Build an IP version

Package IP version and generate XML signature

Export the IP file from its local working space to the project server data hub ^■ Generate a Download request

Download an IP version from a partner team in the current version

Download any IP from previous major releases of the project stored in the repository.

An example of a corresponding display of the collaborative platform is shown in Figure 5, where actions in dark are available, while greyed actions are not available for a given role.

The platform as described in the foregoing provides a unique hierarchical collaboration environment dedicated to SoC project design.

Project views can be browsed on a project server, and can be customized according to the requirements of the project manager.

More particularly, views can be customized easily and can for instance report on specific aspects of the projects (such quality view reporting specifically on simulation ore verification results).

Design teams can work efficiently in their private environments and share through the collaborative mechanisms, at appropriate instants, releases of their block(s). Such blocks can become, upon the decision of the design manager, part of a major project release, all blocks of which will then remain accessible (either as the current version or as an archive after being replaced by a new version).

4. XML signature (detailed)

4.1 Introduction

Consistency, synchronization and revision control are afforded at the project level through XML signature-based techniques used in the packaging and delivery of IPs from a the server, as will now be described.

This part of the present invention involves the following features: • A concept called " IP file signature" for defining the file content and wrapper of an IP;

An IP packaging/delivery station based on the creation of an XML file signature layer on top of the IP database; this XML layer defines virtual IP version/configurations;

Associated mechanisms including: o automated packaging and shipment of IP files delivered to a customer based on the fact that the order is translated to a XML file signature and from there triggers the packaging process; o automatic back annotating, from the IP file signature, of the customer delivery in the native database; o managing delivery history through the delivered IP file signature preventing from storing actual delivered files; o supporting IP customer based on the delivery file signature; o delivering a XML IP interface wrapper conforming to a XML schema allowing its integration in a so called "well-structured SoC" (a well structured SoC project is a SoC project for which a XML schema defining the integration requirement in the SoC is part of the SoC specification). Such signature may typically apply to 3 cases: an IP version, an IP version with several configurations, or a configurable IP where configurations are generated upon customer request or order.

4.2 Background and summary

Delivering IPs to customers is known to be complex for at least four main reasons: • First, an IP is the result of a design process handled by a design data management system (DDM); An IP is a complex electronic subsystem. Its delivery, as a reusable package, contains a large number of files, corresponding to views at various levels of abstraction. It requires identifiers in terms of version/revision often refined at the package levels; • Second, the IPs have to be "hardened" on the technology/process/library requested by the customer and this may lead to a large number of delivered versions;

Third, most of the IPs are described as generic and configurable objects and giving values to parameters or selecting configuration options creates "IP instances". Therefore distinct instances or configurations will be delivered to various IP customers. A large number of architectural configurations for instance may exist for one same generic IP. • Finally, the provider may have to tune the IP delivery to the customer environment namely RTL language, formats, EDA tools, simulation environment...

This part of the invention aims at resolving these problems by providing a mechanism for identifying IP versions/configurations through "XML file signatures", an XML file signature being an abstract view which does not require actual physical IP files storage, thus avoiding redundant storage and providing straightforward IP packaging, delivery as well as supporting all related IP management functions. It relies on the creation of a XML layer between the database managed by a DDM (design data management) tool and the IP packaging and delivery management environment.

4.3 Detailed description

4.3.1 Preliminary definitions

4.3.1.1 Static e_Version/Revision and customer configuration of an IP

An IP is the result of a design flow process put under revision control; such a design process commonly uses a Design Database Management (DDM) system.

Once an IP version/revision has been released in the native database, it comprises a large number of files including files related to some intermediate design or validation steps. Only a subset of these files constitutes the reusable IP package and will be sent out to IP customers. Such a set of files, dedicated to be sent out as deliverables over a network (Internet/Intranet), to a customer or another designer in a collaborative design environment, is called in this paper an e_Version, the "e" prefix emphasizing the "exchangeable" capability over the network through an online download mechanism such as FTP (File Transfer Protocol).

Thus, an IP e_Version /Revision is defined by a subset of files of a native released IP version in the design database, each package or file is identified by its paths or tag bridging of the native directory.

An IP version can be a soft IP containing only VHDL views or can be refined to a technology/process library and therefore will be labeled with the technology/process/library information. It can also be related to a specific EDA / format environment.

From an IP version/Revision called "reference version", several subsets of delivered packages can be extracted in terms of files content linked for instance to a business agreement. As an example, an IP can be delivered both through its VHDL model only for simulation but also through a VHDL model together with as a "netlist" (firm IP) for integrating in the design.

Specific customers may ask for simulation or validation results performed with specific tools and some others may even ask to be provided with the synthesis scripts.

Il will be noted here that some packages (Core model for instance) belong to all delivery while optional files/packages are identified through configuration options.

4.3.1.2 Configurable IPs

A large number of IPs are in fact created by a generator. At a high level of abstraction, this may correspond to architectural options. These options are diversified and application specific; one can mention memory architecture option, processor option, polynomial selection for encoder/decoders, etc.

It is of course often desirable to satisfy a large number of customers in terms of architectural options often related to cost/performance trade off.

As an example, a real case of a configurable 16-bit processor which is a "Soft IP" from a provider, can be delivered with a large numbers of options (for example, each peripheral can be selectable individually and some processor's options, like the number of interrupts, can be configured). In such real life example, it might happen than more than a million configurations can be selected and delivered to customers. This means that the IP is in fact a parameterized VHDL model generator and the set of parameter values are entries of the generator.

4.3.2 XML Signature of a static e_Version/Revision XML file signature

4.3.2.1 The XML file signature of an IP version is defined by a pair

This pair includes:

^* a File Signature infrastructure also called profile

^*File Signature data.

The File Signature Infrastructure is a XML DTD tree (Document Type Definition) representing the IP directory hierarchy, the leaves (or nodes) of which are either:

XML labels whose values are paths to the native files /packages Attributes characterizing the version/revision whose values respect the attribute type; The set of attribute types is extensible, a basic set being for instance integers, multi-valued attributes, etc... These attributes play a role of embedded documentation while the file paths define the file content

Each file /package is "XML-stamped" by 2 static identifiers aiming at bridging to the native directory of the IP version, i.e.:

A tag imported from the native design data management

A header which is a logic identifier of the file in the native database

These identifiers are useful for the back annotation process as will be described later as well as for package sharing between versions. The XML file signature defined here is a model that may be called a XML "pseudo-schema" as far as it is the combination of a hierarchical description expressed by a XML DTD and of an open extensible set of XML attributes types at the leaves, the paths to the native files as mentioned above being the key of the signature process.

Once values are assigned to the leaves of the infrastructure, the resulting XML file is called the signature of the IP version, an example of such signature in hierarchical format being shown in Figure 3 as mentioned above.

Figure 6 shows the actual textual form of the XML signature.

It will be understood here that XML file signatures can be perceived as incremental directory contents (Delta) between 2 versions/revisions; Specific "delta attributes" or "new attributes" identify the new files added to the second version.

4.3.3 A File Signature based IP packaging/delivery station

Figure 7 illustrates the overall architecture of a packaging/delivery station based on XML file signature as described above.

A snapshot of an IP e_version is identified in the native design database through its XML file signature automatically associated to the selected files; upon request from a customer or permanently if appropriate, a compressed version of the IP is stored in the so called "delivery platform" operating as a data hub.

A download request form a customer triggers the transfer of both the XML signature and the compressed files of the IP. Preferably, all state-of-the-art transfer protocols are supported (nowadays HTTP, SMTP, FTP, and Java RMO if behind the same firewall (e.g. in a LAN).

Various situations, depending on whether the configuration of the IP is static or dynamic, will now be described.

4.3.4 Packaging and delivery station for an IP with static customer configurations

4.3.4.1 Static Configuration of an IP version

A provider may define and declare in his IP catalog a fixed set of configurations to be delivered to the customers.

File packages are partitioned into obligatory packages and optional packages; each optional package is labeled by a configuration option ID included as a XML attribute in the File signature (cf. Figure 9).

A configuration is identified by the subset of optional packages belonging to the configuration. Therefore, each configuration is identified by a string of configuration option identifiers.

4.3.4.2 Architecture of a packaging/delivery station for an IP with static customer configurations

As illustrated by Figure 8, the various configurations signatures are extracted from a version file signature; two levels of XML signatures are now existing: on top of the version signature, configuration signatures are created; like previously upon delivery request, an automated compression of the configuration is performed and provided to the delivery platform where the customer will get both the signature and the files through any of the available protocols.

A configuration can be deleted after download and only the configuration signatures are to be stored in the delivery management record.

It is thus understood that both redundant storage and efficient information storage are achieved at the same time.

4.3.5 XML signature for dynamically configurable IPs

4.3.5.1 Declaration of the desired configuration

A generator has commonly a high level entry allowing the customer to define the configuration he wishes to obtain.

In the example of Figure 9, the XML signature of a configuration of a given version of a configurable processor is represented; the order of the configuration is represented at the right side; Each option is labeled by a symbol or character (for instance option "A" for the "Standard Peripherals", which in practice corresponds to a standard peripheral with at least one PCA module as indicated) and the order is translated into a string of characters.

On the left side of the file signature representation, the light gray plain folders (or packages) are the packages shared by all configurations (compulsory files); they will appear for instance in yellow color on the display; an optional package as mentioned above preferably appears in a different color, e.g. in red. The configuration options selected in the order are automatically translated into entries of the generator as well as into a XML signature defining the configuration in terms of packages/files.

4.3.5.2 Architectures and functions of packaging/delivery station for dynamically configurable IPs

Starting from the configuration signature, a core generator is triggered and generates the output files which, as previously explained, are automatically compressed and put on a delivery server or data hub for actual delivery through the communication protocol linking the supplier to the customer.

A shipment is identified by the customer order. To facilitate the support, an automated back annotation process allows to insert a tag which is the order ID in the files in the DDM that are part of the delivery and shipped to the customer; thus at any time the set of delivered files are identified without having to store them explicitly.

Figure 10 illustrates the packaging an delivery process; In this case the XML layer does not operate as a filter for selecting files but triggers the generator and back annotates the files with the customer ID for further management.

4.3.6 Extension of the signature for including wrapping data

Figure 11 shows the packaging part of the file delivery system, which outputs the wrapper or interface data according to a XML schema of the well structured SoC; it should be mentioned here that a XML schema is now formally defined according to W3C (World Wide Web Consortium) specifications. A strict schema definition leads to a strongly typed XML file with a fixed set of complex types and aims at allowing type verification, automatic assembly by EDA IP assembly tools; these tool need to work on predetermined data types.

The extended XML file signature of is the union of the signatures of the delivered file as described above and of the signature of the wrapping data.

This signature of wrapping data is represented, similarly to the file signature as described above, by a XML DTD representing the file hierarchy and the leaf types, designed so as to support all the types imposed by the schema associated to the well structured SoC.

4.3.7 Primitives of a XML file signature based IP packaging/delivery station

In order to take benefit of the XML signature based approach, a wide set of management functions can be implemented in the packaging/delivery station for cooperating with these XML layers, a very powerful feature being the capability of enabling and disabling each function individually.

Figure 8 shows be way of example classes of functions (primitives) that are efficiently implemented thanks to the abstraction allowed by the file signature according to the present invention.

The actions implemented in the packaging delivery station of the present invention will now be more specifically described:

a) XML file signature generator for an IP version

^* uploading values at the leaves of a predefined file signature infrastructure ^* interactive concurrent creation of the infrastructure and data upload * automatic signature creation by an import of an IP Version from its native design database.

b) Wrapper signature generator ^* importing/parsing the XML schema of the SoC, and more specifically:

^* decomposition into a XML DTD and typed leaves defined by the XML schema

* creation of the XML wrapper file

^* checking compliance with the reference schema.

c) Automated file packaging from a customer order

* file selection,

* file extraction,

* file compression, * file transfer to a delivery station.

d) Customer delivery

* support of order request based upon the visibility if the IP file signature

* automated delivery through any of: • Automated shipment

* On line download

* FTP delivery

* delivery panel generation: for each shipment ID, zoom to the delivered XML file signature in a delivery panel

e) Back annotation in the design database

^* based on the file signature of a delivery, access via the DDM to files identified by the signature and insert a tag having the customer order/delivery ID

f) Support and bug management ^* each time support is needed, the delivered files which have been sent to a customer are identified by the delivered version/configuration signature

^* display signature by searching in the delivery panel

^* when a bug and associated to a file is located, an automated process can be run in order to find all versions/configurations affected as well as all customers to be warned based on the file signature analysis.

5 Generic Spirit-compliant loose generator interface

5.1 Introduction

The Spirit initiative has been widely announced since the priority date of the present application (cf. for instance http://www.spiritconsortium.com/) and the benefits of standardization attempts for block assembly are obvious.

One of the benefits that has been very early claimed is an easy IP assembly process within design platforms offered by the major EDA vendors.

Another aspect of the present invention aims at using the XML Spirit schema as an interface for automatically extracting specific data and importing said data in surrounding design tools, by providing a so-called Spirit-compliant loose generator interface.

More particularly, according to this invention, a new user interface or "viewer" is proposed which is based on a "Design entity" such as a block or IP starting from a Spirit-compliant "Design entity" described by its XML schema. This user-friendly viewer, which will be referred to as "Spirit Viewer", allows to display the hierarchical Spirit model of a SoC design as well as the Spirit models for the respective components. This viewer is preferably hosted in the project server so that the descriptions can be browsed by all design teams involved in the SoC project.

However, such a viewer can also be hosted on designer stations when server-based architecture is not desired/possible.

Using the above described packaging/delivery mechanisms, it will be shown how the Spirit data can be accessed as a whole or individually for each component and each abstraction level and this for viewing, data uploading and downloading.

Therefore specific friendly user interfaces per component and per abstraction level are accessible and the data related to a specific view can be gathered into a file and can be used to feed in design tools that precisely require these data as input and organized around this central viewer.

The example underlying this study is an interface between the Spirit viewer and RTL and TLM simulator and constitutes a typical example of a loose generator interface as defined in Spirit IP-XACT.

5.2 Design capture

5.2.1 Spirit compliant XML schema generation

A standardized XML schema defining IP interfaces is defined and updated on a regular basis by the Spirit working group.

Once data have been entered according to this schema, a XML file, so called XML "wrapper", is associated to each IP or component of a design as well as to the whole design. Such IP wrappers can be automatically generated when using the design platform of the major EDA vendors. To allow interactive creation of such a XML wrapper, the present invention provides a decomposition of the schema into a so-called XML "pseudo schema" which is the composition of a XML DTD exhibiting the hierarchy of the design through a XML DTD and of typed leaves (tables, attributes, files, hyperlinks).

To a leaf type are associated a Java template and a GUI template where the designer may be able to enter data in an interactive upload mode.

After an interactive upload process, a Spirit compliance checking procedure is triggered as shown in Figure 13, which illustrates the migration from a Spirit XML schema to a XML pseudo schema.

5.2.2 Design display

When parsing the Spirit XML schema, a DTD or hierarchy tree is automatically created and imported in the "Spirit Viewer". In the example of Figure 14, the system composed of a "Leon2" processor and five peripheral components exhibits its hierarchy as a tree, and specific icons may indicate certain leaf types such as tables (address Spaces, memory maps, ports), attributes, file links etc. When clicking on a XML label at the left side, the set data which have been entered at the corresponding leaves appear in the page at the right.

5.3 Defining configuration options

In order to extract and isolate selected fields as part of a specific view, properties or attributes are defined and can be used for tagging any item in the schema. In the present example, for each package a label can be entered, specifying to which level of abstraction such as RTL (Register Transfer Level) or TLM (Transaction Level Model) the package belongs and also specifying whether the data will be fixed during the design process (dependent) or can be freely entered by the users (user defined).

The "user defined" data are for example data set by users for use by external tools requiring the data of this subset.

In Figure 15, a package has been referred as part of the "TML View" (Config_Option = TLM_XXX_VIEW) and as a refinement may be tagged (e.g. by resolve="user") depending on the application considered.

It will be understood that any other description partitioning can be introduced by using these generic label identifiers in the design profile or XML DTD.

As illustrated in Figure 16, when clicking on a package label in the profile, a pop-up window opens and the user can add an attribute or a property. When selecting "Property", a so-called "configuration option" label can be entered.

The status "FIXED" appearing in the menu of Figure 16 means that the value has to be entered during the profile creation.

5.4 A loose generator interface

5.4.1 Extracting Views

A loose generator interface has to isolate all the structured data that a generator needs. This extraction is performed by extracting a view corresponding to one package identifier or the intersection of plural package identifiers. For instance, the interface of a "TLM Simulator" identifies packages corresponding to the "TLM view" and having the property of being "user defined". This means that: • Such a simulator may require all TLM level data;

• A subset of these fields is defined during the design phase;

• A subset of these fields is filled in when launching the simulator by the corresponding user.

Thus, by positioning the labels as described above, a TLM user view can be isolated and the designer can import data and verify the completeness of such a view.

In Figure 17, the TLM data defined by the designer are illustrated.

5.4.2 Simulator Interface

For triggering a simulator, a user-friendly interface is offered to the design team members.

Figure 18 shows the distinction between RTL and TLM fields while Figure 19 focuses on the TLM view. In both cases, the data are captured in a file that can automatically feed the simulator.

5.5 Conclusion

It has been shown in the foregoing how the Spirit schema attached to a design can be used as a backbone for extracting views and generating interface when calling design tools. It should be noted that a portal or server- based display is also supported as an option for sharing views, creating interfaces or extracting files. 6 Independence of features

It will be noted here that the collaborative platform, IP signature and loose generator interface can be used independently from each other, having their own specific advantages.

7 Bibliographic references

7.1 Collaborative platform

[1] G. Saucier, L. Ghanmi, M. Hamdoun, T. Pfirsch, M. ten Have, M.

Radetzki "IP Transfer: a mapping problem" International Workshop on IP- Based SoC Design, October 2002. [2] P. Blouet, G. Saucier, L. Ghanmi, K.Skiba "IP Management and

Collaborative Design Exchange of hardware dependent software IPs"

International Workshop on IP-Based SoC Design, October 2002.

[3] G. Saucier, M. Hamdoun, "XML Encapsulation Portal", MEDEA+ Design

Automation conference, October23-25, 2002 [4] Ghanmi Lassad "Echange de composants electroniques virtuels", PHD

Thesis September 2002, INPG, Grenoble France

[5] Ghrab Mahamed Arafat "Recherche dans des catalogues de composants electroniques virtuels", PHD Thesis September 2002, INPG, Grenoble

France [6] Hamdoun Mohamed Mourad "Generateur de Catalogues Internet/Intranet de composants electroniques Virtuels", PHD Thesis September 2002, INPG,

Grenoble France

[7] Missaoui Brahim "Gestion de droit d'acces", PHD Thesis September

2002, INPG, Grenoble, France [8] Skiba Karima "Modelisation de systeme integre a base de composants electroniques virtuels", PHD Thesis September 2002, INPG, Grenoble France;

[9] G. Saucier, K.Skiba, L Ghanmi, Ph. RoIs, Ph. Coeurdevey, H.N. Nguyen "An ASIC Platform Design Management Portal", page 163-170, International Workshop on IP Based SoC Design, Grenoble, 13-14 November 2003; [10] L Ghanmi, M.Hamdoun, B.Missaoui, K.Skiba, F.kleitz, I.Hrynchyshyn, A.Hanczakowski, M.Vandendriessche, "Lessons learnt in IP Reuse", page 179-184 International Workshop on IP Based SoC Design, Grenoble, 13-14 November 2003;

[11] G. Saucier, L. Ghanmi, M. Hamdoun, Didier Maurer, "IP packaging and delivery based on XML signatures: Best Practice to standard", page 113, International Workshop on IP Based SoC Design, Grenoble , 7-8 December 2005

7.2 XML signature

7.2.1 PHD

[1] B. Behnam : « Modelisation d'echange d'lnformations de composants Electroniques Virtuels » Laboratoire CSI-INPG. 13 novembre 1998. [2] M.A.Ghrab : « Recherche dans des catalogues de composants electroniques virtuels » Laboratoire CSI-INPG. 25 septembre 2002. M. M. Hamdoun : « » Laboratoire CSI-INPG. 25 septembre 2002. [3] L. Ghanmi : « Echange des composants electroniques virtuels »

Laboratoire CSI-INPG, 26 septembre 2002.

[4] K. Skiba : «Modelisation de systemes integres a base de composants electroniques virtuels». Laboratoire CSI-INPG. 26 septembre 2002.

[5] B. Missaoui : « Gestion de droits d'acces sur composants electroniques virtuels». Laboratoire CSI-INPG. 26 septembre 2002. 7.2.2 Publications

[1] B. Behnam, G. Saucier: An IP Catalog, an important gateway into the world of IP business. 1^st EURIPIDES Workshop, Paris, France, September 1997.

[2] B. Behnam, Saucier: IP Catalog, the catalyst of worldwide IP business.

IWLAS'97, Grenoble, France, December 1997.

[3] B. Behnam, Babba, Saucier: IP taxonomy, IP Searching in catalog.

Design, Automation, and Test in Europe (D.A.T.E.), Paris, France, February 1998.

[4] R.Rafidinitrimo, P.Coeurdevey, G. Saucier, An object-oriented IP management system. IWLAS'98, Grenoble, France, December 1998.

[5] R.Rafidinitrimo, P.Coeurdevey, G. Saucier, "IP key features and an IP

Catalog management system", Design, Automation and Test in Europe (D.A.T.E), Munich, March 1999.

[6] R. Rafidinitrimo, M. Hamdoun, B. Missaoui, SA. Senouci "Rights

Management for IP Exchange" International Workshop on IP-Based

Synthesis and System Design, December 1999, Grenoble, France.

[7] A. Maitra, G. Saucier, M Hamdoun, B. Missaoui "Management Framework for IP e-commerce", DATE(user forum) 2000 Munich, Germany.

[8] LGhanmi, O.Chich , G.Saucier,. 'An Efficient Bridging Solution between working Space Management System', International Workshop on IP_Based

Synthesis and SoC Design, Grenoble, December 2000

[9] LGhanmi, B. Missaoui , G.Saucier, K.Skiba,. 'Intranet Based IP Supply Chain for SoC Project Management', page 43 -50 International Workshop on

IP_Based SoC Design, Grenoble, December 2001 ,

[10] M. Hamdoun, A.Ghrab, P.Hernandez, G.Saucier "IP XML Encapsulation

Portal" International Workshop on IP-Based System On Chip Design 2001

Grenoble, France. [11] LGhanmi, A.Grhab, M.Hamdoun, B.Missaoui, G. Saucier, K.Skiba 'E- Design Based on the reuse paradigm' Design Automation and Test in Europe (DATE) Paris, March 2002, pages 214-220,

[12] LGhanmi, K.Skiba, MT. Have, M. Radetzki, P. Neuman. 'IP Exchange Platform', MEDEA+ Workshop, Stresa, 22-23 October 2002

[13] M. Hamdoun, A. Ghrab, B. Missaoui, G. Saucier, A. Brϋning,

M. Radetzki, T. Pfirsh. "IP XML Gateway" (Medea workshop, Agrate, October

2002)

[14] G. Saucier, L Ghanmi, M. Hamdoun, T. Pfirsh, M.Ten Have, M. Radetzki. 'IP Transfer: A Mapping Problem', page 43 -50, International Workshop on IP Based SoC Design, Grenoble, 30-31 October 2002

[15] P.BIouet, L. Ghanmi, K.Skiba, G. Saucier,. 'Exchange of Hardware dependent software IPs', page 245-250 International Workshop on IP Based SoC Design, Grenoble, 30-31 October 2002 [16] G. Saucier, K.Skiba, L. Ghanmi, Ph. RoIs, Ph.coeurdevey, H.N. Nguyen . "An ASIC Platform Design Management Portal", pages 163-170, International Workshop on IP Based SoC Design, Grenoble, 13-14 November 2003 [17] L Ghanmi, M.Hamdoun, B.Missaoui, K.Skiba, F.kleitz, I.Hrynchyshyn, A.Hanczakowski, M.Vandendriessche, "Lessons learnt in IP Reuse", pages 179-184 International Workshop on IP Based SoC Design, Grenoble, 13-14 November 2003

[18] G. Saucier, L. Ghanmi, M. Hamdoun, Didier Maurer, "IP packaging and delivery based on XML signatures: Best Practice to standard", page 113 International Workshop on IP Based SoC Design, Grenoble , 7-8 December 2005.

7.2.3 Master degrees

[1] P.Coeurdevey : "base de donnees de composant Virtuels", DEA de Micro- electronique. Laboratoire CSI-INPG, Juin 1997. [2] L. Ghanmi : "Modelisation et Mecanisme d'echange de composants electronique Virtuels", DEA de recherche Operationnelle. Laboratoire CSI- INPG, Septembre 1999.

[3] B. Missaoui : "Gestion de Droits d'Acces", DEA de Recherche Operationnelle, Laboratoire CSI-INPG, Septembre 1999.

7.3 Spirit-compliant loose generator interface

[1] Lennard, Granata, "The Meta-Methods: Managing design risk during IP selection and integration", European IP 99 Conference, November 1999.

[2] John Wilson, "IP Reuse Simplifies SoC Design and Verification", EE

Times, 10 November 2004.

[3] "SPIRIT 1.1 Specification", SPIRIT Consortium, www.spiritconsortium.org, June 2005.

[4] "Extensible Markup Language (XML) 1.0" World Wide Web Consortium,

Third Edition, 2004.

[5] "XML Schema Part 1 : Structures", Second Edition; "XML Schema Part 2:

Datatypes" World Wide Web Consortium, Second Edition, 2004. [6] SOAP Specifications: www.w3.org/TR/soap.

[7] Geoff Mole, "Philips Semiconductors Next Generation Architectural IP

ReUse Developments for SoC Integration", IP SoC Conference, December

2004.

[8] Ron Wilson, "Revolutionary Pay-Off', EE Times, 28 February 2005. [9] Denis Bussaglia, "Automated Implementation Flows based on IP-level constraints and synthesis intent in XML", IP SoC Conference, December

2005.

[10] Bricaud, Pierre-Keating, Michael Springer, "Reuse Methodology Manual for SoC Designs"

Claims

1. A collaborative platform for electronic system-on-chip (SoC) design comprising an assembly of blocks designed by a plurality of design teams, comprising in combination: a central platform including a centralized SoC project data repository adapted for storing major SoC project versions, a repository management module for controlling said repository, and a delivery platform for exchanging design data with the design teams,

• a plurality of design stations connected to the central platform through one among several possible network protocols, each station including block design tools for use by a respective design team and a packaging /delivery unit adapted to package each new block version elaborated by the design team by attaching thereto a hierarchical tag-based data structure representative of its contents, whereby a new block version transmitted by a design station to the central platform can be selectively accepted as a current version for accessibility by other design teams through the delivery platform together with its hierarchical tag-based data structure.

2. A collaborative platform according to claim 1 , wherein said central platform comprises a user interface for browsing the hierarchical tag-based data structure of each block current version.

3. A collaborative platform according to claim 1 or 2, wherein said central platform comprises a project version management unit adapted to selectively accept all current block versions of the project as a current project version for direct accessibility by all design teams.

4. A collaborative platform according to claim 3, wherein said central platform comprises means for providing to the design platform, in response to specific requests, block versions which are former versions of the blocks belonging to the current project version.

5. A collaborative platform according to claim 3, wherein the central platform comprises a user interface for browsing through a project-level hierarchical tag-based data structure including all block-level hierarchical tag- based data structures.

6. A collaborative platform according to claim 5, wherein said user interface allows browsing through any selected one of a plurality of project- level hierarchical tag-based data structures corresponding to different project versions.

7. A collaborative platform according to any one of claims 1-6, wherein said hierarchical tag-based data structures are XML tree structures.

8. A collaborative platform according to claim 7, wherein said XML tree structures are pseudo-schemas or schemas complying with the Spirit Consortium XML structures.

9. A method for organizing, packaging and delivering system-on-chip blocks stored in a database and comprising a plurality of block data files, comprising the following steps: for each block in the database, providing a block signature data layer, for each version and/or configuration of said block, providing in said data layer a hierarchical tag-based data structure including version data and/or configuration data and forming a respective signature of said version or configuration.

10. A method according to claim 9, further comprising the step of: when an order for a given block version configuration is received from a customer, translating said order into a hierarchical tag-based data structure forming an order signature, and packaging and shipping the IP files of said block to said customer based on a translation of said order into a hierarchical tag-based data structure forming a delivery signature.

11. A method according to claim 10, further comprising: for each block delivered to a customer, storing said delivery signature in the signature data layer.

12. A method according to claim 11 , further comprising the step of managing delivery history to each customer through said delivery signatures, thereby avoiding to specifically store actual delivered files.

13. A method according to claim 9, wherein said delivery signature conforms to a XML schema allowing integration of the corresponding block into a well-structured system-on-chip.