DesignWare Technical Bulletin 

Building an IP-XACT Design and Verification Environment with DesignWare IP 

By John A. Swanson, senior marketing manager, DesignWare IP, Synopsys

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. Synopsys DesignWare® digital IP cores fully support this standard with the IP-XACT file generated as a view of the configured core or subsystem. Synopsys 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.

fig1
Figure 1: IP-XACT Component

Synopsys provides highly configurable digital IP so customers can easily integrate the IP into their designs configured for the target application. Synopsys generates the IP-XACT file based on the users’ configuration. This allows designers to have an XML master 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.

fig2
Figure 2: Component configuration

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

fig3
Figure 3: Simple APB Master to Slave connection using IP-XACT interface

Companies using IP-XACT as part of their design and verification have stated how using the IP-XACT standard has had low adoption costs, and it provides the data needed to expand on for verification, software tool support and documentation.

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:

coreKitIP-XACT Component
Source code and any required licensing informationComponent Information
Supported implementation toolsSingle ASCII file
Component information including vendor, library, and versionIncludes key data-book like information
Delivered as a single binary file that contains all of the information needed / packaged to use the componentReferences to external files

Table 1: Comparison of coreKits and IP-XACT Components

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.

fig4
Figure 4: coreBuilder startup dialog

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

fig5
Figure 5: coreBuilder Development Window

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.

fig6
Figure 6: High-Level coreBuilder Flow

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.

fig7
Figure 7: Included coreBuilder component information

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.

fig8
Figure 8: coreAssembler flow

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.

fig9
Figure 9: Get the IP-XCT version and vendor information

fig10
Figure 10: IP-XACT memory Map Description

fig11
Figure 11: Enumerations, file locations and parameter information

fig12
Figure 12: Model Views and Component Ports

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 Synopsys’ 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. Synopsys 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.

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



NewsArticlesBlogsWhite PapersWebinarsVideosNewslettersCustomer Successes