An IP-XACT Deployment Case: IZARN IP

By Ates Berna (ST-Ericsson), Sparsh Arun (STMicroelectronics), Seyda Aygin, Sinan Topcu, Emrah Armagan (ST-Ericsson)

Abstract

This document presents an IP-XACT deployment case on a complex IP, called IZARN. IZARN is a digital IP which includes an ARM CPU and is targeted to be used in a SoC (System on Chip) for mobile phones.

I.  INTRODUCTION

The objective, for the work presented in this paper, was to build an environment for the IP, such that the IP packaging is based on a well-defined methodology to facilitate the IP top level integration and to allow rapid hierarchical changes in the future due to late modification requests from the customers. We have searched existing solutions within STMicroelectronics (ST), ST-Ericsson (STE) and also 3rd party solution providers. We identified existing know-how built-in ST’s CCSD /PSIP team on IP-XACT methodology. IP-XACT is an Extensible Markup Language (XML) format that defines and describes electronic components and their designs. IP-XACT was created by the SPIRIT Consortium as a standard to enable automated configuration and integration through tools. We started this activity in cooperation with PSIP team in July 2009 and later IP-XACT became an IEEE standard on December 2009. This proved us that we were on the right track for IP packaging. The methodology we used is not depending on a specific product or IP, hence it is fully reusable by IP designers building digital IPs and/or SoC designers building digital systems.

II.    GOALS AND OBJECTIVES

Below are the goals (long-term) and objectives (short-term) we set for our IP-XACT deployment case.

A.    Goals

• Develop IPs which can be easily reused by others
• Find a better way for IP packaging and assembly
  • Reuse existing IPs
  • Automatic protocol based connection
  • Easy hierarchical changes
  • Configurable IPs

B.    Objectives

• Deploy IP-XACT methodology in the first release of IZARN
• Make a delivery of IZARN in three months of time
• Create an IP-XACT top level XML file to be used as an input to FrontEndKit (company specific digital front end design flow kit)

III.    THE SITUATION AT THE START

IZARN is the next generation of anexisting IP called IZAR. For IZAR, all the hierarchical changes were manual, hence requests for making hierarchical changes were taking too much time. There was a requirement for the IZARN to move  all SoC level related modules to SoC top level. Investigating the benefits of IP-XACT, we were convinced that IP-XACT will be beneficial on the long-run. However, it was a challenge to convince all stakeholders for this decision,  as we were expected to make the initial delivery of IZARN in three months of time and , the first deployment of IP-XACT would require more time than classical approach, but it would pay our efforts back once it is there for future deliveries.

IV.    IP-XACT ASSEMBLY FLOW

There are two main parts of the flow;

1. IP packaging: Obtaining already existing bus definitions and developing the custom ones. Packaging is needed to create the IP-XACT views of all the IPs to be assembled at top level.
2. Assembly: Assembly contains 2 parts;
   1. Data Capture: Making the connections (pin-to-pin or interface based) between the IPs in the system
   2. RTL Generation: The design generated during data capture step, can be then given to a netlister to generate the RTL. During assembly certain generators can also be run to automatically generate certain custom blocks like padring, iomux etc...

Figure 1 is a detailed flow chart of the IP-XACT flow we used.

 

Fig. 1  IP-XACT Flow

A.    Packaging

All the IPs, in the design, needs to be packaged. That means the bus definitions need to be clarified for each IP and if it is an already existing bus definition, as in Table I, it can easily be reused during the IP packaging. If the bus used on the IP does not have an existing bus definition, then a custom bus definition can be generated.

TABLE I: BUS DEFINITIONS USED IN IZARN

No	Bus Definition
1	AHB/APB
2	Clock/Reset
3	I2C
4	JTAG
5	SPI
6	Memory
7	UART
8	DMA
9	I2S

After each IP packaging step, XML checks on the IP-XACT view needs to be performed to make sure that the IP-XACT view is consistent and free from errors. An IP-XACT view at this stage can contain ports, bus interfaces, configurable parameters, source file references, component generators, views (e.g. synthesis, simulation, etc.), registers description, memory map, instantiated components and connected instances.

Before starting the assembly step, it is good practice to check the bus interfaces defined on each small IP. In Figure 1, this is depicted as “Module Interface Checks”.

B.    Assembly

Assembly is the step, where all small IPs are integrated at the top level of the final IP. In order to do that all the connections (interface or ad-hoc) needs to be performed. This approach will be a flat connection approach without considering additional internal hierarchies. If there is a need for internal hierarchies which groups a bunch of small IPs (e.g. all AHB slaves are grouped in an AHB_CORE hierarchy), this can be defined separately. The RTL codes for the internal hierarchies will be generated at the end of the assembly step. The ability to define internal hierarchies as you wish gives you the flexibility to create/remove internal hierarchies easily. This is especially important and speeds up the design time, in case hierarchical changes need to be done on an IP. The IP-XACT views for the internal hierarchies will be automatically generated by the IP-XACT assembly tool.

C.    Downstream Design Flow

 We are using an environment that creates working areas through the execution of a dedicated executable script. These working areas are then used to run a composite set of CAD tools  to perform various digital front-end tasks like RTL checks/simulation, synthesis, formal verification, DFT, power analysis

IP/SoC designers in the company use a similar environment as ours. Within the scope of IP-XACT flow, the benefit of the environment we are using is its ability to take an IP-XACT view of a design and create the necessary compilation scripts for the downstream tools automatically. In this way, one can generate all the necessary compilation scripts for the downstream tools from a single source, which is IP-XACT view.

V.    IP-XACT DEPLOYMENT EFFORT

A comparison for the deployment “effort” of IP-XACT is given in Table II. The initial total effort we spent for our first delivery was six and a half man months (MM) with a break-down of one MM on bus definition and IP packaging, five MM for data capture and half MM for assembly. After IP-XACT was deployed, for bus definition and IP packaging we spent only half a day. For data capture, we spent one man week (MW) and for assembly no effort was needed as it was push button. To summarize; , we spent 6.5MM for our first delivery and this figure also includes the learning phase of the team. Once IP-XACT was deployed the total time to make a new release was reduced to 1.5MW.

TABLE II: IP-XACT DEPLOYMENT EFFORT

Task	Initial Effort	After IP-XACT is deployed
Bus Definition and IP Packaging	1MM	0.5MD
Data Capture	5MM	1MW
Assembly	0.5MM	0
Total Effort	6.5MM	1.5MW

As seen in Table II, Data Capture step took most of the time during the deployment phase. The main reason for this was major hierarchical changes. However, if we were to deploy IP-XACT on a stable design where no hierarchical changes were to be done, we expect the effort for data capture to be reduced to 1MM, or even less, as there are now tools on the market where they can take the existing RTL and generate the IP-XACT view of the top level design.

One important point to mention here is the amount of effort required to make a certain RTL change with IPXACT flow as opposed to conventional VHDL coding. In IZAR (where IP-XACT was not used) there was a change requirement for a bus matrix structure. It took 2MW to reflect these changes on the RTL. However for IZARN case, incorporating this new bus matrix structure including its data capture and RTL generation only took 1MW (as seen in Table II (no-packaging done for bus matrix as IP-XACT view was ready, just data-capture step done).

VI.    SUGGESTIONS

Having deployed IP-XACT on a complex IP, here are a few suggestions that might help IP/SoC designers who are intending to use IP-XACT for the first time;

• If IP-XACT will be deployed on an existing IP, do not take any design modifications into consideration at first run of IP-XACT deployment. Considering design modifications while deploying IP-XACT only complicates the deployment phase, making especially the design capture during assembly step longer. Having a proven RTL reference for the automatically generated RTL files is also a plus when something goes wrong.
• Select an assembly tool which provides a GUI. This will facilitate your debugging related to connection based issues.
• Pay attention to check points in the flow we present in Figure 1. The earlier the problem is found the better.
• Check whether your flow/needs are supported in IP-XACT. For example, will you generate VHDL, Verilog or SystemVerilog during assembly step? Or do you need to use “generate” VHDL statement to be able to instantiate different modules once the RTL codes are generated?
• Include register information in the IP-XACT views for your IPs. This will help you to create documentation like programmer’s manual or to create C-header files automatically using available solutions, which can read IP-XACT and generate information in different formats.

VII.    CONCLUSION

Here is a list of benefits IP-XACT provides;

• IP-XACT saves considerable time during RTL assembly at the top level (both for IP and SoC). Shortened RTL assembly time by automatic protocol based connection.
• It provides flexibility to make hierarchical changes on an IP easily.  
• It offers a methodology for IP packaging and assembly. IP-XACT 1.5 is an IEEE standard 1685-2009: IPs can be reused easily.
• Tool interpretable way of describing constraints and integration requirements of an IP.
• Applicable to all IPs (new or legacy; any design style).
• Consistent data can be derived across design flow.