Building an IP-XACT design and verification environment with DesignWare IP

IEEE1685 (IP-XACT) was designed to fit this requirement and Synopsys' DesignWare digital IP cores support this standard, with the IP-XACT file generated as a view of the configured core or subsystem. But why an article on IP-XACT? As more tools support the standard, its use is growing in areas ranging from building configured component documentation (such as register descriptions) to batch flows that can regenerate the RTL for a component, subsystem or SoC. 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. The schema, which is design language neutral, design tool neutral, efficient and proven, is built on the XML (W3C) standard with a standardised API for generator integration called the Tight Generator Interface (TGI). 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! XML was created to structure, store and transport information and 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 predefined 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. IP-XACT files and generators can be thought of as simply 'another view' of an IP block (see fig 1).










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. Fig 2 shows how one component can be configured to generate many different components, each of which has its own IP-XACT representation.


Using IP-XACT, you can connect components with associated interfaces automatically. Consider the 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 connect automatically. An example of this is shown in fig 3.
Companies using IP-XACT as part of their design and verification have noted how using the standard not only has low adoption costs, but it also 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 centre is 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). Essentially, coreKits are a knowledge base that is configured with the coreConsultant tool. The coreBuilder tool allows you to capture the designer's knowledge in the IP package and supports both GUI and command line use. When you start coreBuilder, you are presented with a dialogue box that allows you to select a coreKit (default) or an IP-XACT component. After making that selection, the user is then presented with the development window. The development 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 • customisations • 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. At any point when 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 be edited as updates are made to the IP. Once the information collection process has been completed, coreBuilder generates a coreKit or IP-XACT component. This will include all of the information provided, including help files and configuration dialogues (see fig 4).














How IP-XACT is generated Once the configuration information, registers, memory maps and interfaces are included in the coreKit or IP-XACT component, you can create the IP-XACT component or design file again at any time using coreConsultant. 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 simplicity, let's highlight the flow using coreAssembler as an example. Note that IP-XACT is just one of the many outputs of coreAssembler. 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. The IP-XACT XML can be parsed to build and configure a testbench and, 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, set up some stimuli 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 – an excellent starting point for the larger SoC verification process. John Swanson is senior marketing manager, DesignWare IP, with Synopys.