|
|
|
|
|
|
 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
IPZIP - an IP Distribution Tool
By Cristiano Araújo, Edna Barros, Millena Gomes, Williams Azevedo,Informatics Center, Federal University of Pernambuco
Guido Araújo, Institute of Computing, University of Campinas Recife Brazil Abstract In this paper is presented the IPZip tool. A graphical wizard that allows the automatic distribution of SystemC TLM IP Cores based on the SPIRIT IP-XACT 1.2 standard. The main goal of IPZip is to abstract the set of XML files specified in SPIRIT 1.2 from the IP developers and to generate a zip file containing the IP Core SystemC source code of different implementations of the IP at several abstraction levels, documentation and the corresponding XML SPIRIT files. The tool has been applied successfully to several SystemC IPs like SimpleBus, AMBA and AVALON buses, memories, cache memories and processors like the MIPS and SparcV8. Some of these components were described several times in different abstraction levels and ipziped together. Furthermore, these ipziped components were successfully imported to the PDesigner Framework, a graphical environment for the modeling, simulation and analysis of MPSoCs. Allowing the SoC designers to drag and drop the IPs in a graphical environment, change their parameters, connect their interfaces and generate executable simulators of the platforms. 1 INTRODUCTION One of the critical problems related to SoC design is the reusability of third party IPs. Difficulties arise during the integration of these components due to incompatibilities in the component interface and insufficient of documentation. The industry is seeking for an efficient integration mechanism for IPs[1], as sometimes the benefits of integrating a third party IP is not worthy the effort. Depending on the complexity of the design, the effort to adapt the interface and protocols of the third party IP to the interfaces and protocols of the system is similar to designing a new component from scratch. These problems change the focus of the SoC integrator from refining and testing the architecture to dealing with the connection problems between the modules, specially the design of new modules that help the integration of the acquired IP Core. Another important aspect of SoC design is that high abstraction level models of IPs are being made available by IP vendors [3] and also the distribution of the IP at several different abstraction levels on one package [2][3]. These IP models, described in system languages like SystemC, allows a SoC designer to quickly evaluate his/her design and also to decide for the purchase of a particular IP Core distribution. The industry has proposed some interesting initiatives that ease IP Core designers and system integrators tasks. One of the most promising approaches is the SPIRIT Consortium [4]. This is a initiative of the leading semiconductor and EDA companies to provide a common basis for the automatic exchange of IPs between IP Core design and SoC integration tools. Despite the advantages of the SPIRIT initiative it aims at RTL IP distribution, lacking some support for the distribution of IPs at higher abstraction levels. This paper presents IPZip, a graphical tool that enables SystemC TLM developers to distribute their IPs in a manner that they can be reused automatically in a SoC modeling environment, giving support to components distributed at several different abstraction levels and keeping its consistency. The IPZip tool is based on the SPIRIT IP-XACT 1.2 standard, meaning it can be adapted to other modeling tools that are compliant with the SPIRIT standard. The great advantage of the approach is that it abstracts completely the IP Core designer and SoC integrator from the XML files of the distribution. The rest of the paper is structured as follows. The SPIRIT IP-XACT 1.2 distribution scheme is explained in section 2. The IPZip distribution flow of an IP is described in section 3. Section 4 details the IPZip tool. The results are discussed in section 5. Finally, some conclusions are given in section 6. 2 SPIRIT 1.2 IP DISTRIBUTION The SPIRIT Consortium [4] has proposed a solution for IP distribution that enables the exchange of IPs between EDA tools. It is based on the distribution of a set of XML files together with the source or binary code of the IP Core and its documentation. This set of files is currently in the SPIRIT IP-XACT 1.2 version and applies tfor the distribution of RTL IPs. The consortium has also work going on the IP-XACT 1.4 specification that will handle the distribution of high level IP models. The SPIRIT 1.2 standard creates the necessary base to describe IP and IP packages, defining their interfaces, address formats and mapping, a differentiate description between their interconnection structures and their internal connection and a simple platform definition, covering the requirements of a RTL design. SPIRIT IP-XACT 1.2 standard defines, beyond XML tags, the necessary files to support the IP description, defining them by the purpose and detail levels. The set of files defined to describe and distribute the IP is composed by six types of files, called schemas, as described in the Table 1.
The SPIRIT IP-XACT 1.2 does not provide support to the description and distribution of components designed in SystemC [5] at high abstraction levels. It does not deal with communication protocols, as TLM [6]. It also lacks support for application loading in processors in a SoC. So, in this work it is proposed a distribution flow that modifies the SPIRIT IP-XACT 1.2 to provide support to the features mentioned above. 3 PROPOSED DISTRIBUTION FLOW The proposed IP distribution flow is depicted in Figure 1. It is based on the standard SPIRIT distribution and has been improved by adding some steps for providing IP distribution information, support for several abstraction levels and zip file generation. It is important to note that, despite some new information has been added to SPIRIT it does not prevent IPs distributed using IPZip to be used by SPIRIT IP-XACT 1.2 compliant tools. The added steps are detached in gray and explained below. At the first step the designer provides some basic information about the component, by indicating its name, type, vendor and owner. The type information identifies whether the component is a processor, memory, bus, peripheral device or a wrapper. This information is necessary, as some tools need to classify the components in their library to the designers. The owner information identifies who has developed the IP Core. In this step the type and owner information are not part of the SPIRIT and have been added to the distribution. In the next step, the component interfaces are described by defining their name, direction, protocol, connection and the multiplicity of the interface, that is, how many similar interfaces the component can have. Once defined the interfaces, the designer must declare the parameters used to configure the component and its structure as name, description, data type, format and options, in the case of having pre defined values. At the Insert Component Source Files step, the designer must list the component source files and indicate the Makefile (at Insert Component Makefile) that enables the compilation of the component at the SoC modeling tools. After that, the main structure of the component distribution is ready. The next steps describe the abstraction(s) level(s) of the component distribution, by giving its name and type, and configuring each one. The abstraction level configuration consists on the definition of the steps and structures that must to be followed by a SoC modeling tool to instantiate and integrate the component. During the configure abstraction level step, the designer defines the files that must be used to compile it, the constants used on its definition and the structure of the component constructor, connections and functions.
As the SPIRIT standard was developed to cover the distribution of RTL IPs it does not work with the abstraction level concept. The proposed distribution flow presented deals with SystemC TLM IPs, that enables them to be distributed in different abstraction levels as cycle accurate, timed estimate, untimed and RTL. The final step consists in the generation of a compacted zip file that contains the IP .source/binary code, documentation and the SPIRIT XML files. 3.1 DISTRIBUTION FILES The proposed approach has extended SPIRIT in two ways. In the first some SPIRIT files were modified by the inclusion of new XML tags. A second extension was the creation of a model for the configurator schema file. It is not a new file that has been added. In this section the extensions and proposed file model are described in more detail. New XML tags were added to the SPIRIT schema files in order to implement the proposed flow. The component and pmd schemas files were extended with the new tags and it has also been defined a model to the configurator file. This extension supports the SPIRIT standard 1.2, adding new functionalities, as abstraction levels description and ports multiplicity; and facilities for tools configuration, by the configurator schema model definition. The first modified file was the component schema file. This file is responsible by the IP description (interfaces, files, memory map and parameters). The extended component schema file allows the designer to define the component type by using the added tag called spirit:type.This new tag is used to classify the IP core in one of the following categories: processor, bus, memory, wrapper or device. Devices are a special kind of category that applies to any component that is not classified as the previous ones. Beyond being worried about the description of the component interfaces, the spirit:name tag purpose was modified to define the name of the interface protocol. The multiplicity of the interfaces should also be treated in a different way, diminishing the size of the description and assisting the design tools to represent them. For that reason, the spirit:maxInterfaceType was added to define how many equal interfaces the component has and whether this number is static or dynamic. Interface types can be master, slave or system. In our approach the existence of a Makefile fille is mandartory and is supporsed to be distributed with the other source or binary files. These proposed modifications in the SPIRIT standard can be observed in Figure 2, where they are in highlighted. The second modified file, the PMD schema file, has been extended to support the distribution of IPs at different abstraction levels. The first extension to the file was treat the spirit:name attribute of spirit:dependsOn tag as the abstraction level name and add a spirit:type attribute to identify the abstraction level type. Another extension was use the spirit:elements tag to match the abstraction level, recognized by its name, with its related configuration file. Those modifications are showed in detached in Figure 3. For the configurator schema file, as the SPIRIT did not define it, it was necessary to define a model to allow frameworks that recognized it to know how to use the distributed IPs. To allow it, a model for the configurator schema was developed to make a uniform configuration of components possible. This model has been applied to SystemC components. The configurator schema file model is shown in figure 4. Several XML tags were created and are described below: The spirit:IncludeFiles tag lists the IP source files necessary to allow the component use. Those files must be already listed at insert source files step. After that, the IP constants must be described at spirit:prepareComponent tag, by defining its function (type), name and value.
The spirit:constructor tag describes the component initializers structure by defining the class that implements the IP, its name and parameters used to allow the initialization, based on the following main structure: InstanceType instanceName (parameter1, …, parameterN) The parameters are defined by its type (text, number, reference, pointer, or no symbol) and value that can be a constant or a variable (when a component parameter is passed to configure the IP initialization). For describing the connection structure of the IP interfaces, first it is necessary to identify whether the defined structure allows a connection with a master or a slave interface identified in the spirit:type attribute of the spirit:connection tag. After that, it is necessary to identify the name of the component connected, the function that enables the connection (special function name or port name) and parameters used to allow it. Those parameters are described as mentioned above. The last step to describe an IP configuration is defining its functions used to allow the IP execution or to generate simulation logs at the spirit:initialize tag. On this tag, the component instance name, the function name and its parameters are configured. The IPZip did not modify any tag at the design schema file and let the design tools free to create a standard to platform manipulation. IPZips creates a platform schema that describes the instances and gives to them graphical characteristics, as position to be used in graphical editors, application mapped into processors and clock definition tags.
4 THE IPZIP TOOL The IPZip tool is focused on the creation of IP Cores distribution in a graphical framework, allowing the designer to create it in an easy and transparent way. The tool implements the distribution flow described in section 3 through a set of wizards. The IPZip tool is a graphical framework based on Wizards, as showed in Figure 5 and 6, developed in Java, running on Eclipse IDE[7], that automatically generates an zip file that represents the IP distribution package, composed by the components source files and the component description in IPZip SPIRIT standard, that can be used for design tools. The wizard windows of the IPZip follows the distribution flow showed in section 4. The main flow passes for six steps, that are represented by windows through which the whole component is described and the structure of distribution that are used by some design tools are generated, allowing them to use and configure the distributed IP.
Figure 5 IPZip Wizard Window at Interface Description Step
Figure 6 IPZip Wizard Window at Abstraction Level Configuration Step To create the distribution package, the designer just need to fill the indicated fields at the tool wizards, describing the component. After the IPZip file creation, if the designer needs to modify the generated archive, the IPZip tool allows him/her to edit the generated file. For this option, the tool uses the wizard standard used to create it, and fills all the fields with the information of the source zip file, making possible its edition for the user. 5 RESULTS The IPZip tool was used for creating the IPs distribution packages of the components used in the PDesigner framework [8]. Figure 6 depicts 2 MIPS processors, one SimpleBus and a memory that were IPZiped and exported to the PDesigner library. The SoC modeling framework automatically recognizes the interfaces and parameters of the components. The generated packages were composed by the sources files and IPZip SPIRIT schema files, and its results are listed in the Table 2, where only the data referent to the schema files generates are showed to each component passed through the IPZip tool.
Table 2 IPZip Results The IPZip tool uses an extended SPIRIT standard. For this extension tags were added and modified. The modified ones had only the use changed to another. No tag was removed. Table 3 shows the number of tags added and modified per each file schema.
Table 3 SPIRIT 1.2 modifications to IPZip SPIRIT numbers 6 CONCLUSIONS In this paper it has been presented the IPZip tool, a wizard graphical tool that allows the distribution of SystemC TLM IPs simultaneously at different abstraction levels. This tool is based on the industry distribution standard SPIRIT IP-XACT 1.2 and has extended it in order to support the distribution of IP at different abstraction level. Our approach has also proposed a model for the configurator schema file that is suitable for SystemC TLM distribution. The advantage for the IP core designer to use IPZip is that it completely abstracts the XML files from the user. The designer focus on what he/she knows better, the IP Core design and its use. The IPZip tool has been used to distribute several different IP cores designed by different people. These IPs included processors, busses, memories, and cache memories. These ipziped IPs were used successfully in a SoC modeling, simulation and analysis framework, Pdesigner. The tool has recognized the interfaces, parameters allowing the designers to interact with them graphically. The SoC simulator could also been automatically generated due to the configurator schema files that have been proposed. 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. 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. [3] 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. [4] SPIRIT Consortium available at http://www.spiritconsortium.org [5] SystemC available at http://www.systemc.org [6] TML available at http://www.systemc.org [7] Eclipse Framework available at http://www.eclipse.org [8] PDesigner Framework available at http://www.pdesigner.org |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
Home | Feedback | Register | Site Map |
|
|
|
All material on this site Copyright © 2017 Design And Reuse S.A. All rights reserved. |
