Spirit compliant Platform Design using an IP Repository

The aim of the Spirit Consortium is to define a standard way of packaging IP so that it can easily be transferred between creation and integration teams. The standard will facilitate the use of platform design tools that will raise the level of abstraction used to define the way in which the component parts of a SoC will be connected together so that it becomes a 'drag and drop' exercise. However, for a integrator to be effective in using the platform design tool there needs to be a pool of components available that are compliant to the Spirit packaging standard. Some of these components will be supplied with the tool, others may have to be obtained from an internal creation group, or may have to be obtained from an external IP provider.

Mentor Graphics has developed an interface between its Platform Design tool and its IP Repository System that is based on a set of http URLs, so enabling access to IP from the design tool. Mentor has also developed a loader that takes a candidate IP core, does some checks on it, then packages and loads it into the IP Repository System so that it becomes available as a Spirit compliant component.

Once the IP Repository has been populated, integrators using the platform design tool can search for Spirit compliant functions and compare them against each other before selecting them. A link stored within the downloaded IP allows the integrator to access a knowledge base and help desk for those occassions when it is unclear how to use the IP, or if a suspected bug is found. The end user can also subscribe to email notification when there is a change or update to the IP.

A third party IP provider can use the system to control the level of access integrators have to the IP. For instance, a design team evaluating the IP would only be allowed access to encrypted simulation models compiled for a simulator of choice, whereas a full licensee would have access to RTL source code.

The system also has the flexibility to allow integrators to configure the IP before downloading a model. This mechanism could be used for ensuring that only the required data is transferred from the creator to the integrator in the case of generated IP. It also has the flexibility to allow the transfer of generators for particular tools which can be used to generate particular views of the overall SoC, this is particulary useful for the generation of verification environments and for facilitating verification reuse.

This paper will describe the system and illustrate the power of combining a Platform Design tool with an IP Repository to facilitate the rapid integration and verification of a SoC using Spirit compliant IP.

Introduction

Most SoC designs are based around a CPU core with memory and functional blocks interconnected via one or several On Chip Buses (OCBs). This approach to constructing a SoC is often referred to as Platform Design, since the various blocks fit together in a common fabric. Simplistically, this style of design appears to consist of little more than drawing a block diagram, deciding on the blocks to be put together and then joining up the dots between them. The reality is quite different, finding the right Virtual Component (VC) to populate each block can require considerable investigation effort. The process of integrating the VCs together is manual and potentially error-prone. Decisions on system level details such as address maps and interrupt priorities have to be made early so that the appropriate structures are coded and put in place. Changing these structures is again a manual, and potentially, time consuming task. When this is combined with the fact that there is a general lack of standardisation in the VC industry, then the whole integration cycle of a Platform Design including third party IP could be lengthy.

Spirit Overview

The Spirit Consortium came together with these and other issues in mind in June of 2003. The initial members of the consortium are ARM, Beach Solutions, Cadence, Mentor Graphics, Philips, ST and Synopsys, providing a balance of VC providers, integrators and EDA software vendors. The primary objective of Spirit is to make it easy for Platform developers to integrate IP from different VC providers. The approach taken by the consortium is to define a set of XML schema to define the meta data associated with a VC and its interconnect with a defined bus and with other VCs that it may be dependent on. The meta data files are distributed in a defined library structure and also include an index of the design files associated with the VC and their purpose. In addition to the design data and meta-data, the consortium is also working on the definition of a standard API for Platform design tools, enabling the creation of generators that will run on any compliant design tool to create a specific EDA view of the Platform.



Fig.1 – Spirit Standard

Applicaton of Spirit principles

Mentor Graphics has developed a commercial EDA tool for Platform Design called ‘Platform Express’. This software package has been made available via the web and can be used by Platform development teams free of charge. The design cockpit of Platform Express allows the user to select a CPU core from a library and then drag and drop it onto a schematic page. The tool prompts the user for basic system level information such as whether to use little or big endian data ordering and then generates some OCB stubs aound the processor. The user then selects a VC from a library and drags and drops it onto one of the bus stubs, at this point the tool uses the meta data stored with the component to determine whether it supports the type of bus it is being connected to. If the VC has an interface to a different OCB, then Platform Express looks through a library of bus bridge generators and puts a bridge in place. The user is then prompted for information concerning the address map of any registers in the block, and for information relating to interrupt priority and DMA requirements. This information is used to generate address decode logic, interrupt controller logic and wiring, and DMA logic. The tool allows the user to change these parameters at any time, and regenerates structures as required. Using this approach a representation of a Platform design can be put together in a matter of minutes. Once the Platform has been defined, Platform Express will generate an EDA view of the Platform design, examples include a compilation for a hardware simulator, compilation to a hardware software co-verification environment, synthesis to a target technology netlist, or the insertion of a scan chain.

A platform design tool can make a significant contribution to design and verification productivity, however in order to be effective it needs access to the VCs from which a platform is constructed. This is why initiatives such as Spirit are so important. The availability of Spirit compliant VCs enables platform design tools to deliver the required results. However, the platform integrators need to be able to locate suitable IP and to be able to instantiate it in their designs. The natural solution to this problem is to interface the Platform Design tool to an IP repository system.

An IP Repository system consists of a vault for storing released configurations of a VC design database, combined with a catalog system that allows the VC integrator to be able to browse or search for candidate VCs. Ideally the system should support the VC selection process by being able to provide information on the components various attributes, give some indication of its level of maturity and quality, allow downloads of datasheets and other documentation and allow side by side comparison of different VCs. Once a component has been selected it can be downloaded into a project workspace, subject to the appropriate entitlements. When a Platform Design tool is connected to an IP Repository, then it is possible for Platform Integrators to browse or search a catalog from within the platform tool and make an informed decision about which VC to integrate into their design.

Typically, an IP Repository is in use within an organisation’s firewall and is used to store Virtual Components that have either been created by the organisation’s development teams or third party IP that has been licensed. Depending on company policies and business processes, access to the contents of the repository may be controlled. Transfer of IP between companies occurs under strict control and only after legal and contractual agreements have been reached.

In order to support business models for the distribution of IP between companies, an IP Repository needs to have functionality that allows the provider to control either what is visible to the person using the catalog, or to control what that person can download. These controls can be either via a set of structured permissions, or via more global controls on the visibility of components or their deliverables. For instance, if an IP Repository is used to drive a web portal, then only public domain information would be visible to a general ‘guest’ user. That ‘guest’ use might be allowed to progress to an ‘evaluator’ level of access after registration with the provider, this may entitle the user to download a compiled simulation model to start integration and verification in parallel to going through the process of becoming a licensee. Once a license is in place, then the ‘evaluator’ would be promoted to a licensee level of access that would allow access to the full VC design database.





Fig. 2 – Process for VC Selection from IP Repository to instantiation in Platform Design tool.

At Mentor Graphics, we have integrated the Platform Express tool with Mentor’s IP Repository Solution, the QuickUseTM IP Reuse Station, to enable VC creators to distribute their components to Platform integrators. This integration uses Java Server Pages to drive a web interface and is designed to work within a company intranet or via the internet. From within the Platform design tool, the integrator is able to browse or search for candidate IP, then make an informed selection. Once selected, the VC can be configured via a GUI that is driven by an XML file transferred from the IP Repository. On completion of any required parameter configuration, the VC is packaged up by the IP Repository and transferred to the Platform tool, ready to be instantiated. The provider can control what the integrator receives in the package, dependent on the level of entitlement, in other words the transfer could include the whole design, or be limited to simulation model for evaluation.

During the life time of a Platform design, questions may arise as to the best way to use a VC, or issues may be uncovered, in which case the integrator needs to have access to a support infrastructure. This can be facilitated using a URL within the VC icon in the Platform Schematic to connect the IP Repository’s help desk and knowledge base. This allows the integrator to search for Technical Notes and Defect Reports that may relate to the question they have. If the issue does not appear to have a known solution, then the integrator can request help by raising a ticket. As the ticket is actioned, the integrator receives email notification each time the ticket makes a step towards resolution. The integrator is also able to subscribe to email notification of events surrounding the component, for example that a new version of the component is available.

In order to enable users to create Spirit Compliant VCs from an arbitary design database, a Spirit loader has been developed that packages the VC via a ‘Wizard’ style web based GUI. The loader prompts the user for meta data relating to the VC that is used to generate catalog information for end-user searches. Then the GUI helps the user identify which parts of his design database relate to which part of the Spirit Component structure. Any relevant XML descriptor files are generated automatically and bus bridges and other such infrastructure are identified and associated with the component. Once the package is ready, checks are made to ensure that it is complete and then it is loaded into the IP repository. Once some further set-ups have been made by the IP administrator, the new component can then be published on the web interface and can be found by any Platform Express tool that is aware of the server. This packaging tool speeds up the process of creating a spirit compliant VC by an order of magnitude over manual methods.

The Spirit consortium’s definition of meta data and a standard API also enables EDA vendors to distribute generators for specific EDA views that can be made to work with Platform tools. The IP Repository can perform a useful role in supporting the distribution of these generators, and in providing alternative versions for specific tool configurations. Within the Platform Express tool, each generator is associated with a tool button within the tools menu system. When a new generator is downloaded, the software can be made aware of the location of the generator and reconfigures itself to include the new functionality.

Conclusion

Using the packaging standards being developed by Spirit, it will be possible to readily exchange VC between providers and integrators. The combination of Spirit compliant and enabled Platform Design tools and IP repositories will provide a powerful solution to Platform integrators. The provision of component packaging and loader tools that support the standard will also accelerate the overall development and adoption cycle of VCs within Platform Designs.