²ÝÁñÉçÇø

Introduction

As today¡¯s SoC designs incorporate more IP components and time-to-market pressures rise, designers are looking for a way to build and update designs easily. The IEEE-1685 standard (IP-XACT) was designed to fit this requirement. ²ÝÁñÉçÇø DesignWare? digital IP cores fully support this standard with the IP-XACT file generated as a view of the configured core or subsystem. ²ÝÁñÉçÇø also provides tools that allow designers to package their own IP and easily integrate it into their design flow.

Why an article on IP-XACT? Simple: As more tools support the standard, we see uses in a areas from building configured component documentation (such as register descriptions), to batch flows that can easily re-generate the RTL for a component, subsystem or SoC. Additionally, we see companies extracting the needed information to build a verification environment. This article focuses on the IP-XACT standard, how to build and generate IP-XACT IP, and how to get the IP-XACT view of your components¡¯ configuration.

What is IP-XACT?

IP-XACT is an XML schema for language and vendor-neutral IP descriptions that includes a generator interface for ¡°plug-in¡± functionality. It is design language neutral, design tool neutral, efficient, and proven. The schema is built on the existing XML (W3C) standard with a standardized API for generator integration called the Tight Generator Interface (TGI). The schema, first released by the SPIRIT Consortium, is now an IEEE standard that is validated and released in accordance with the IEEE policies published as IEEE-1685.

XML schemas are used to define the legal building blocks of an XML document or document structure. An XML schema defines:

• Elements and attributes that can appear in a document
• Which elements are child elements
• The number and order of child elements
• Whether an element is empty or can include text
• Data types for elements and attributes
• Default and fixed values for elements and attributes

It is important to note that XML DOES NOT DO ANYTHING! It was created to structure, store and transport information. XML is just plain text. Software that can handle plain text can also handle XML. However, XML-aware applications can handle the XML tags specially. The functional meaning of the tags depends on the nature of the application. With XML, you invent your own tags, as XML has no pre-defined tags. XML is designed to support schemas like IP-XACT.

IP-XACT provides XML descriptions of components and systems. A component has several attributes that can map directly to XML. These include:

• Memory maps
• Registers
• Bus interfaces
• Ports
• Views (additional data files)
• Parameters
• Generators
• File sets

When multiple components are connected, it becomes an IP-XACT design file. This includes the attributes above, as well as the interconnect information of all the components in the design. Figure 1 shows how IP-XACT is mapped to a component. Think of the IP-XACT files and generators as simply ¡°another view¡± of an IP block.

²ÝÁñÉçÇø provides highly configurable digital IP so customers can easily integrate the IP into their designs configured for the target application. ²ÝÁñÉçÇø generates the IP-XACT file based on the users¡¯ configuration. This allows designers to have an XML manager view of their configuration without having to deal with IP-XACT limitations related to configurable IP. Figure 2 shows how a single component can be configured to generate many different components, each of which has its own IP-XACT representation.

Using IP-XACT, you can automatically connect components with associated interfaces. Consider a simple example of an AMBA? APB manager connecting through an APB bus to an APB subordinate. As the APB interface has been defined, the three components can automatically connect. An example of this is shown in Figure 3.

Building IP-XACT digital IP

There are multiple approaches to building IP-XACT digital IP. At the center is the tool, coreBuilder. The coreBuilder tool is an IP packaging tool that allows you to generate an IP-XACT view or a coreKit (which includes features not supported by the standard.) We will not elaborate on coreKits here, other than to state that they are a knowledge base that is configured with the coreConsultant tool. The difference between coreKits and IP-XACT components is shown in Table 1:

The coreBuilder tool allows you to capture the designer¡¯s knowledge in the IP package. It supports both GUI and command line use, but we will show the GUI for this article. When you start coreBuilder, you are presented with a dialog box that allows you to select a coreKit (default) or an IP-XACT component, as shown in Figure 4.

After selecting either a coreKit or IP-XACT component, you are presented with the development window shown in Figure 5.

This window walks you through the flow of adding all of the information related to the IP. Typical data includes:

• Source code
• Configurability information
• Design constraints
• Documentation
• Testbench
• Customizations
• Assembly intent / interfaces
• Tool versions supported
• IP-specific information

The minimum data required to build a coreKit or IP-XACT component is the source code. All other information is optional and can be added incrementally. A high level view of the flow is shown in Figure 6.

At any point in using the GUI mode you can save a batch file to return to that point in development. Designers often choose to do the initial IP packaging with the GUI, and then write out the batch file and use it for updates to the core. The batch file is a TCL script that can easily be edited as you make updates to your IP.

Once you have completed the information collection process, coreBuilder generates your coreKit or IP-XACT component. This coreKit or IP-XACT component includes all of the information you provided, including help files, configuration dialogs, etc., as shown in Figure 7.

How IP-XACT is generated

Once the configuration information, registers / memory maps, interfaces, etc, are all included in the coreKit or IP-XACT component generated by coreBuilder, you can create the IP-XACT component or design file again at any time with the coreConsultant tool.

While coreConsultant generates coreKits for a single IP core, coreAssembler can be used for interface and rules-based assembly of coreKits, IP-XACT components, or RTL source code for multiple IP cores.

For this article we will simply highlight the flow using coreAssembler as an example. Note that IP-XACT is just one of the many outputs of coreAssembler. Figure 8 shows the flow with coreAssembler.

Extending the flow into verification

You can jump-start your verification environment with the information available in the generated IP-XACT component. To illustrate this, let¡¯s examine a portion of the schema from a simple design: a UART with an APB interface. You want to know the registers, and how to connect a Verification IP (VIP) component. Figures 9-12 show how the IP-XACT XML can be parsed to build and configure a testbench.

With this information formatted for easy parsing, you can build a data model to enable assembly of a testbench, configuration of a VIP component, and in some cases even set up some stimulus to execute on the testbench. As ²ÝÁñÉçÇø¡¯ VIP supports the AMBA protocol, coreAssembler can generate a connectivity test that will build a testbench, configure the VIP, and execute a write / ¡°read expect¡± test to the registers of the components in your design. This creates an excellent starting point for the larger SoC verification process.

Summary

IP-XACT components basically create an electronic databook for the core. ²ÝÁñÉçÇø digital IP cores provide generated IP-XACT which include: RAL files, configuration documentation, IP versions, memory and register maps, and a batch script that allows you to recreate your component or design configuration at any time. Whether you are using a single IP core or building a subsystem with multiple components, you will see the benefits of the generated files that reduce your design and verification time.

²ÝÁñÉçÇø was a charter member in creating the IP-XACT specification, and continues to be involved in the Accellera working groups to develop the next IEEE version of the schema.

For more information or information on training classes, please contact ²ÝÁñÉçÇø.