A Semi-Automatic IP Distribution Tool

By Millena Gomes, Cristiano Araujo, Felype Santiago and Edna Barros
Informatics Center (CIn) - Federal University of Pernambuco

Abstract :

This paper presents the IPZip2, a tool that allows the semi-automatic distribution of SystemC TLM IP Cores based on the SPIRIT 1.4 standard. The advantage of this tool is that it generates the package from the IP source code, thus requiring minimum user interaction. The IPZip2 tool has been validated in the PDesigner platform modeling and simulation framework. SystemC TLM IPs, including bus and memory, has been distributed to the tool, allowing the SoC designers to drag and drop the IPs in a graphical environment to model MPSoC platforms.

1. INTRODUCTION

Modern complex integrated circuits are in several cases platforms composed of heterogeneous components like processors, memories, interconnection structures and peripherals. These systems were usually described using synthesizable hardware description languages (HDLs). This approach, despite being well known for hardware designers, has the drawback of slow simulation performance.

In order to overcome the problems related to the complexity of the ICs some approaches were adopted. One approach is the use of higher abstraction levels for faster modeling and better simulation performance. This is done using electronic system level (ESL) languages like SystemC TLM.

Another approach is the use of pre-designed and pre-verified circuit designs (IP-Cores) to reduce the implementation time. One of the goals of IP-Cores usage is its ability to be reusable. The reuse characteristic of IP-Cores are obtained by the usage of description standard, documentation and parameterized models, that facilitates its configuration and usage in different systems, reducing the circuit development time.

The strategies to make an IP reusable, such as documentation and parameterization, are not enough to allow EDA tools to understand the reusable IPs. IP description and distribution information must be standardized to be used by EDA tools. Those problems can be solved using standards to distribute IP-Cores, such the standard defined by the SPIRIT consortium, that do not use just source code and natural language.

The usage of non HDL and ESL languages and non natural languages has the drawback of the difficult of the adoption of distribution standards and the rise of the time used for distribution package generation.

On this context, this paper presents a SystemC TLM IP Core distribution flow that minimizes user interaction and consequently errors. It is also presented the IPZip 2 tool, which implements the proposed flow. The tool generates one IP distribution package, compliant with the IP XACT 1.4 standard, from the IP Core SystemC TLM source code and a usage example.

The rest of the paper is structured as follows. Related work is presented in section 2. The proposed distribution flow is described in section 3. Section 4 details the IPZip2 tool. A case study of the tool is presented in section 5. The results are discussed in section 6. Finally, some conclusions are given in section 7.

2. RELATED WORK

KaSCpar[9] is the Karlsruhe SystemC Parser suite designed to parse SystemC 2.1 keywords by tokenizing the structural and behavioral aspects of the language. It is divided in two tools, the SC2AST, that generates an Abstract Syntax Tree (AST), composed by the tokens found in the source code, at XML format; and the AST2XML that generates an elaborated description using an XML file that represents the information gotten from the code.

Despite KaSCpar be able to get information from SystemC code and elaborate it, the generated files are not ready to be used as IP distribution information, since it does not have all the information needed to manipulate the IP Core.

The SPIRIT Consortium has proposed the IP XACT standard[4], a solution for IP distribution that enables the distribution of IPs between EDA tools. It defines a set of XML format files, called schemas, that together with the source or binary code of the IP Core and its documentation, allows the use of the IP by SoC design tools. In its 1.4 version IP-XACT provides support for SystemC TLM IP distribution. The drawback of this approach is the difficulty of describing the IP in XML format and high possibility of the writing of wrong files caused by human mistakes.

3. THE IPZIP2 DISTRIBUTION FLOW

This section describes the semi automatic IP distribution flow implemented by IPZip2. Its goal is to generate an IP XACT 1.4 distribution package from the source code of the IP and a usage example automatically. Leaving the user interaction to only provide vendor related information. Thus, minimizing the interaction with the user and the probability of errors in the package.

The proposed IP distribution flow is depicted in Figure 1. The first step of the proposed flow is the obtain the vendor information, such as authors and vendors name, and about the component as its name, type, such as memory, cache memory, processor, bus, device and wrapper, and a brief description of the component. This step does not use information from the source code, it must be provided by the user.

The second step generates an Abstract Syntax Tree (AST) representation of the IP structure. The input for this step is the SystemC TLM source code of the IP and a usage example.

For the AST generation we have used the SC2AST tool, from KaSCpar. This tool generates an AST representation of the source code in a single XML file. This XML file structures all the information divided by file and information type, as constructors, functions, parameters and ports.

The figure 2 shows a fragment of a memory (simple_bus_fast_mem) source code and how this code is represented in the AST file. The first fragment shows information about its port (bus_port), constructor and some parameters such as name, star_address and end_address. The second fragment shows how the information about the constructor is described in the AST file.



Figure 1 IPZip2 distribution tool

The main function used as the usage example, must include information about the component initialization, connection and functions that manipulates its parameters or enables extra functionalities of the IP as generation of statistics information during simulation or printing it contents as the dump function of the memory as showed in figure 3. The files that must be included to use this IP Core also must be declared in the main function.

The next step of the distribution flow extracts distribution information from the AST file and main function. In this step, the AST file is navigated and the useful information: interfaces, parameters, and constructors, functions, and connection structures found are filtered and classified. The structure information in addition with usage information defines how to initialize the IP Core, how to integrate it with others components, how to configure it, and how to use all its functionalities.

The information presented in the AST, extracted from the header file, that represents the main structure of the component, is used to get the necessary data about the component interfaces, such as its type, name, direction and protocol. Beside interfaces, this file is also useful to get information about the constructor, such as its structure and initialize parameters as detached in Figure 2, and to list all its functions.





Figure 2 Simple bus fast mem AST file representation fragment

The usage example, represented by a main function, is used to get information about the IP configuration and its usage. At this step, the structure of the IP Core connections is obtained. The port name, or functions structures that enables connection are extracted from the AST. It is also helpful to get information about the IP Core functions structures, which are composed by its name and a list of parameters.



Figure 3 Simple bus fast mem main function fragment example

The component parameters are also obtained at this step, since, in this approach, they are considered parameters just if they are used in at least in one function, connection or constructor. This step extracts the parameter name; data type and default value, when it exists.

The obtained data are classified by its purpose as interfaces, parameters, constructors, functions, connections structures and included files, and used as input to the next step of the IPZip2 distribution flow.

The next step uses the obtained data to generate the distribution files compliant to IP-XACT 1.4, such as the component model as showed in figure 4.



Figure 4 Component model of Simple_bus_fast_mem

Information about IP Core constructor, connection and functions structure in addition to include files information, that are obtained directly from the main function file because they are not present in the AST file, are used to generate the configurator XML file. This configurator file contains all the necessary information to configure the component and integrate it into a platform, as showed in the figure 5.

The configurator file is composed by information about files from the IP Core source code that are necessary to be included to allows the use of the IP, called included files in this approach, by the IP Core initialize functions structures, by the IP Core connections structures and the IP Core functions structures. This file structure was presented and used at the IPZip 1 tool [10], the first version of this distribution tool that generates the distribution files through data explicitly informed by the user.

All the information about the IP Core architecture, as the IP interfaces, parameters, and source files are used as input for the XML step that is responsible of generating the IP distribution files at XML defined by the SPIRIT IP XACT 1.4 standard, such as the component model file. At this step the makefile of the component informed by the user is added to the component model file.



Figure 5 Simple bus fast mem configurator model fragment

Once all the distribution files are generated using the information obtained from the source code, a compressed distribution package is created in the last step of the IPZip2 distribution flow. The package is generated in the zip compression format. The source code files, distribution files, in XML format, and a makefile, compose this distribution package when it is necessary, used to generate the IP Core.

4. THE IPZIP2 TOOL

The IPZip2 tool is a graphical framework based on Wizards, as showed in figure 6, that implements the distribution flow described in section 3. It has been developed in Java, running on the Eclipse IDE[7] as a plugin.

IPZip2 has just two interactions with the user: one to get the source code directory path, the zip destination path and the makefile, when it exists, and other to get the VLNV (Vendor, Library, Name and Version) information. The user provides information about the developers, as the IP Core authors and vendor, as showed in figure 6. This wizard also requires from the user the component name, its type, such as processor, bus, memory, cache memory, device or wrapper, and a brief description of the IP. All the other information is obtained from the source code.

The second type of information provided by the user is the source code path. The tool uses this information to get the list of all the IP Core source files and the usage example, which are used as input for the rest of the flow.

After interacting with the two wizard windows, the IPZip 2 generates a zip package with the source files, the distribution files compliant to IP-XACT 1.4 standard, the configurator file defined and a makefile when it is necessary to compile the IP Core.



Figure 6 IPZip2 wizards

5. CASE STUDY

A simple bus distributed by ArchC[11] was used as a case study to validate the distribution flow and the IPZip2 tool.

In the first phase of the tool development, the simple bus was used as a mechanism of study and and a base for obtaining information about SystemC TLM component structure and data type. The main sources of information about a component file header and the main were studied thoroughly. These two files together with all source files of simple bus, totalizing twenty-three files, were used to generate the simple bus distribution package.

Using the tool, the intermediary file simple_bus_res.xml.ast.xml containing the AST was generated, as defined in the step 2 of the IPZip2 flow, using the SC2AST tool from KaSCpar. Some fragments used from that file which contains almost ten thousands lines of code are presented in Figure 7.

The generated AST file was used to extract distribution information, as it interfaces, parameters, constructors and functions, while the main function file was read to obtain the list of included files.

After handling of information obtained of this file, XML files were generated complaints to IP-XACT 1.4. The information about the structure of the IP is in the file simple_bus.xml, that represents the component model, while the information about the configuration specially extracted of the main file are in file simple_bus_configurator.xml, that represents the component configurator model.



Figure 7 Simple bus AST file fragment

The whole flow was executed in one minute for an average user. That distribution time considered the interactions of the user with the IPZip2 tool to indicate the simple bus source code directory, the destination directory, the makefile path, the component description, name and type, and the VLNV information, and the time needed by the tool to generate the distribution package from the simple bus source code.



Figure 8 Dual Mips platform modeled in PDesigner

The generated distribution package compressed as a zip file was used and validated in a SoC Design Tool called PDesigner [8]. The file was automatically recognized and integrated to the library of the PDesigner framework, as showed in figure 8.

To analyze the occurrence of any problem related to integration problems or distribution mistakes, a dual mips platform, composed by two mips processors, one simple bus fast mem and a simple bus, was modeled in the PDesigner and simulated using the FFT (Fast Fourier Transformer) benchmark.

6. RESULTS

IPZip2 was used to generate some IP distribution packages as simple bus, simple bus fast memory, among others, distributed by the ArchC group. Using the case study as an example, the tool generated the files and results showed in table 1, using as input the twenty-two source files, the main function file and makefile totalizing twenty-four files and 2085 lines of code. Using the IPZip2 tool the distribution files listed in Table 1 were automatically generated, diminishing the time to generate the files from approximately one hour, for experienced users to generate them manually, to one minute using the IPZip2, considering the time used to indicate the directories path.

The generation of the distribution files and package is, in average, realized in ten seconds, depending on the complexity of the component, that grows with the quantity of source files, parameters, ports and functions.



Table 1 IP distribution files information

7. CONCLUSIONS

High abstraction level IP Core reusability is an important technique to allow the development of complex platforms in a reduced development time. The reusability just can be automatically done with the usage of distribution standard as IP XACT 1.4 largely used by the industry.

On this context, this paper has presented a distribution flow that reduces the time for the distribution of SystemC IP Cores. The flow also increases the probability of distribution packages with no errors. As it is at IP XACT format, the generated distribution packages can be semi automatically used in design tools. The flow has been implemented in the IPZip2 tool and integrated in a SoC development environment.

The usage of the tool has shown a reduction in distribution time without loosing information and warranting the correctness of the distribution files.

As a future work it is intended to apply the same approach for the distribution of RTL IP Cores described in HDLs like Verilog and VHDL.

8. REFERENCES

[1] C. Lennard et al. Industrially proving the SPIRIT consortium specifications for design chain integration. In the Proceedings of the conference on Design, automation and test in Europe DATE '06,pp 142-147, Munich, Germany, 2006.

[2] A. Bruce et al. Maintaining consistency between SystemC and RTL system designs. In the Proceedings of the 43rd annual conference on Design automation DAC '06, pp 85-89, San Francisco, CA, USA, 2006.

[3] A. Baganne et al. A Multi-Level Design Flow for Incorporating IP Cores: Case Study of 1D Wavelet IP Integration. In the Proceedings of the conference on Design, Automation and Test in Europe DATE '03, pp 20250, Washington, DC, USA, 2003.

[4] SPIRIT Consortium

[5] SystemC

[6] TML

[7] Eclipse Framework

[8] PDesigner Framework

[9] KaSCPar

[10] ARAUJO, C., BARROS, E. ; GOMES, M. ; ARAÚJO G. Ipzip - An IP Distribution Framework. In: IP/SoC, 2006, Grenoble. Proc. of the IP/SoC 2006, 2006

[11] ArchC