IP qualification of reusable designs

IP qualification of reusable designs Andreas Vörg, Natividad Martínez Madrid, Wolfgang Rosenstiel, Ralf Seepold FZI Forschungszentrum Informatik, Microelectronic System Design Haid-und-Neu-Str. 10-14, 76131 Karlsruhe, Germany [voerg, martinez, rosenstiel, seepold]@fzi.de Abstract In order to realize System on a Chip (SoC) designs and to meet Time to Market (TTM) window at the same time, the development of a qualification methodology is necessary because transfer of IP modules is crucial. Since design for reuse (IP) is one possibility, but requires a design to be compliant to certain guidelines. This enables a quick integration of an IP module into a system. Detailed guidelines exist which the designer must check manually. Therefore it is nearly impossible to ensure compliance to all guidelines. Thus it is necessary to automate the qualification of IP modules. In today s design flows several existing tools can be used manually to assure compliance to standards and thus high quality designs. This paper will show that the qualification of the design can be performed in a semi-automatic manner to meet TTM and to avoid resources being bound unnecessarily. The approach proposed also takes care of the packaging of a soft IP module, which typically consists of about one hundred files and some megabytes of data. Furthermore an IP certification phase will also be part of the IP qualification system. 1 Introduction The development of microelectronic systems has been and will in the future be driven by the highly increasing integration density of transistors. As predicted by Moore s Law, integration density increases by 58% per year whereas designer and tool productivity increases by only 21% per year [7]. Closing the design gap between productivity and increasing density is one technical challenge. The pressure of meeting TTM makes this task more difficult, because the time for a development cycle was shortened in the past and will also be shortened in the future. One solution aimed at meeting both the TTM problem and to narrow the design gap is the reuse of circuit designs of functional blocks. These blocks (IP modules) will then be combined with other blocks into a SoC [4]. In the Department of Microelectronic System Design of FZI, an IP qualification methodology has been developed 1. Thus IP modules can be automatically checked against well-defined quality characteristics, which substantially improve the reusability of IP modules. The methodology is not restricted to a special kind of soft IP modules (e.g. processor core, audio or video decoder), but represents an application and design independent solution. In order to be able to use automatic qualification processes independent of a specific design, an IP structure is used as a basis for the qualification processes. The developed IP qualification system is then embedded into an existing design flow. Furthermore the developed methodology has been checked with a prototypical implementation on a real soft IP module from an IP provider. The test module consists of 13 megabytes of data in 260 files and counts about 3800 gate equivalences. 2 State of the art Technical, business and legal interests must be considered in conjunction with the SoC design and the use of IP modules. The VSIA [13] develops technical methods in order to improve the quality of IP and thus eases the integration of IP of different origin into a SoC or platform. Also in the RMM [3] for example, rules are defined, whose observance leads to the production of qualified IP. But all these rules and guidelines have to be checked manually by the designer. And, of course, it is difficult and time consuming to produce high quality IP modules only by this manual procedure. There is a method for IP qualification missing, which enables an automatic examination of the IP modules ([5], [6]). For an IP licensing and distribution procedure, IP users and IP providers are supported by the work of VSIA and VCX ([12], [13]). However the IP provider is not supported by tools to show compliance or completeness of its delivery package. 1 This project is partly supported by the German government under the label 01M3048B [16]. At the same time, it is a Medea+ project under the label A511 [15]. Page 1 of 5

Ratings exist like OpenMORE [8], which should support the IP user in deciding which of the IP modules with the same functionality is the easiest to integrate in a system design or platform. Nowadays, however, the IP provider must create these ratings manually, which is of course time-consuming and not very objective. Besides the VSIA and RMM efforts to give hints on how to produce qualified and reusable IP modules, there are already individual tools available, like rule checkers [1], code coverage and synthesis tools ([11], [9]). These tools could also be used for IP qualification aspects. In the same way as is usual today to have a verification plan (not necessarily formal verification) for electronic designs, a qualification flow must be also integrated into the design flow. It is obvious that a comprehensive IP qualification flow has to be implemented in order to support several different roles (e.g. IP provider and IP user) and to enable quick and efficient IP qualification. Therefore, the following items have to be covered: 1. Showing compliance to design guidelines in an automatic manner 2. Helping the IP user to decide on an IP module by reliable certification and 3. Developing an IP qualification methodology, which could be inserted in an existing design flow 3 Definition of quality characteristics First it must be defined what is understood by quality. To achieve this, quality characteristics are determined. In the next step of the qualification process, the compliance to the defined quality characteristics must be checked. The following quality characteristics have been stated: (1) Reusable source code, (2) Synthesizable source code, (3) Verified functionality, (4) Compliance to the specified timing performance, (5) Sufficient documentation, (6) Version and configuration management and (7) Completeness of the IP module. This paper concentrates on the first three points. 3.1 Reusable source code In the past, it has been demonstrated that the source code of IP modules has to fulfill specified characteristics to be easily reusable. In this sense, the observance of guidelines is important with respect to maintainability and locality of failures. This means that an occurring failure in an IP module should not affect other modules or even the whole system or platform in which it is integrated. Often guideline violations can be detected at an early implementation phase. This helps to avoid problems in the following phases (e.g. synthesis, system or platform integration). A redundant or insufficient sensitivity list in a VHDL design, for example, can cause simulation problems. Latches at an output port of an IP module can cause timing problems. This can affect other IP modules or even the whole system design. Therefore, extensive coding guidelines exist. The designers often only poorly consider the coding guidelines, as they have to check them manually and there are too many guidelines distributed over several documents. Therefore, it is absolutely necessary to have tools to support the developer in this early implementation phase to avoid problematic coding. Such tools are available under the name rule checker (e.g. ARDID, Avant! ExploreRTL, Interra SpyGlass, etc.). Problems discovered at an early stage can be corrected more easily and, more importantly, more economically than problems, which are uncovered at later design phases. Because of these reasons, it is necessary to integrate a rule checker into an IP qualification system, that is able to check de-facto standard rules, e.g. the RMM, and company internal rules. Then the source code could easily be designed more reusable, because guideline violations are detected before they become problematic. This increases the quality of an IP module. 3.2 Synthesizable source code Since soft IP modules are not delivered synthesized, the synthesizability of the RTL source code must be ensured during the design process. Frequently, it is not well known into which technology the IP user would like to synthesize the IP module. It is important to execute at least a synthesis to an example technology. Thus it is guaranteed that the source code does not contain non-synthesizable constructs. The synthesis tools produce important additional information, on which way the design has been synthesized. So, for example, information is generated on the estimated timing performance, power consumption, chip area and the way some source code constructs have been synthesized (e.g. latches, flip-flop). This information can be analyzed automatically. The synthesis must be a constituent element of the design/qualification flow, even if the IP module is not to be delivered synthesized. The examination whether a synthesis of the IP module has taken place must be made by an IP qualification system. With accomplished synthesis, customer-specific desires can be Page 2 of 5

considered concerning power consumption, timing performance and size of the design and can be analyzed on the basis of the generated report files. 3.3 Verified functionality The kind of verification, which is done in the design flow, belongs to the guidelines of each company. In this sense verified functionality does not necessarily mean, that a formal verification is applied. In this paper verified functionality means verification through simulation. At our partner s company the testbenches for validation are developed by experts parallel to the IP module development. Therefore, the quality characteristic verified functionality is guaranteed through a code-coverage tool, which checks the covered functionality by the testbench. The level of quality that has to be fulfilled is a 100 % of statement, 100 % of branch and 90 % of condition coverage. 4 Methodology After fixing the quality characteristics an IP qualification methodology has to be developed, which could be embedded in an existing design flow. Part of the overall IP qualification system (Figure 1, part 1-6) is an IP certification (Figure 1, part 4) and delivery phase (Figure 1, part 5). Qualification starts with different qualification phases (Figure 1, part 1-3 and 6) during the design. Then the IP modules are labeled in the IP certification phase. Therefore an IP user has a reliable quality characteristic in order to decide on a specific IP module. Within the IP delivery Figure 1: IP qualification system phase the IP provider ensures the completeness of the deliverables. Figure 1 shows the different phases of the IP qualification system and their embedding into a typical design flow. The design accompanying application phase (1), the final (2) and the custom specific application (3) could be seen. It can also be seen that an IP certification takes place (4) before the IP delivery phase (5) starts. For example, in (4) the compliance report of the VSIA and an IP-Evaluation (e.g. OpenMORE) would be performed on the basis of the generated data during the qualification. IP certification can be done for both: according to (de-facto) standards or to those from a specific customer. In the following IP delivery phase (5) defined contract models support the completeness of an IP module. The integration of foreign IP into the design flow (6) is also taken into account by checking the compliance to the defined IP structure. Then the foreign IP module accepts the qualification flow as shown. For the examination of the operability of this generally formulated methodology an IP qualification system has been implemented as a prototype. 4.1 IP qualification phases Within the IP qualification phases (Figure 1, part 1-3 and 6) available or commercial tools should be used and individual programs must be developed, if no tools are available. In addition, tool-specific configuration files and developed scripts have to be adapted to the IP structure. The IP structure enables project and application-independent reuse of the IP qualification phases by sorting the files of an IP module in a well-defined directory tree of a file system, database, etc. It is important to mention that the adapted tools are executable in two ways: alone and in conjunction with a subset or all of the other adapted qualification tools that belong to the IP qualification phases. Therefore all the phases have the same basic structure and differ only in the number and kind of qualification tools that are executed. We distinguish between three different qualification phases: design-accompanying (Figure 1, part 1), final (Figure 1, part 2) and custom (Figure 1, part 3) qualification. During the design-accompanying qualification phase, there is no need for a complete qualification. Therefore, only a subset of the defined quality characteristics has to be checked. It is of more importance that the design-accompanying IP qualification is quick and the developer s attention is drawn to possible problems, before stepping into a new phase of the design flow. Three possible design-accompanying application cases should be mentioned during the implementation, verification and synthesis phase: Page 3 of 5

1. The examination during coding phase on compliance to internal coding guidelines as well as defacto standards. 2. During the simulation phase the quality of the simulation must be guaranteed by checking the test bench with a code coverage tool. 3. During synthesis phase synthesizability and compliance to the specified timing performance should be checked. To be flexible in the combination of the different tools the qualification tools must be independently executable. The final IP qualification is an additional phase and after that, the development of the IP module has finished. The files have to be tagged after the qualification to indicate them as deliverable version, a release. This can be done by the use of a version control system. In summary a complete qualification, which checks all quality characteristics, has to be done. This qualification phase is necessary to check already developed IP modules, in which design flow no IP qualification has been integrated. 4.2 IP certification phase Within the above mentioned IP certification phase the IP module is checked for compliance to (de-facto) standards like the VSIA compliant certificate. The advantage of having certificates or delivery standard is, that IP users can rely on a minimum scope of Figure 2: VSIA compliance database supply. The VSIA has released a document available which defines what an IP provider has to deliver to an IP user if he wants to be VSIA compliant. This document includes a checklist, which has to be filled in manually for each IP module. Within this work a database has been created, that includes the information also stated in the compliance document from the VSIA (Figure 2 lines 1 to 4) plus additional content of the referenced VSIA documents (Figure 2 line 6), the possibility of including a documentation deliverable in a specific document (Figure 2 line 5) and the ability of filling in the compliance report and storing the data within the database (Figure 2 line 7 and 8). Therefore, it is easy to adapt the compliance report to future VSIA specifications, to generate documentation templates for the IP documentation and to generate the necessary compliance report. 4.3 IP delivery phase After the certification phase the IP module will be delivered to an IP user. For the delivery task it is important that all necessary files are included in the final IP package. Therefore, IP provider specific contract models have been created, which - in conjunction with the IP structure - support the IP provider to take care of dependencies between files and groups of files. For example, the contract model might include: VHDL source code files, test benches, simulation related files, synthesis scripts, qualification reports, documentation and information on the file versions, a file with an graphical directory tree of the IP module and a checksum file. This task has been automated. 5 Results In Table 1 all defined quality characteristics are listed in the first column and the method of checking for compliance is listed in the second column. Therefore, the aim to check all defined quality characteristics has been fulfilled. But only one aspect could not be implemented, because it was not possible to define company internal rules with the version of the used rule checker Avant! Nova-ExploreRTL at implementation time. This problem could be solved, by integrating a newer version of the rule checker or replacing it by another one, e.g. ARDID or Interra SpyGlass. Quality characteristic Reached aim Reusable source code With a rule checker company and de-facto standard rules could be automatically reviewed Verified functionality Improvement of simulation coverage through a code coverage tool Page 4 of 5

Quality characteristic Synthesis able source code Compliance to specified timing Sufficient documentation Version- and Configuration management Completeness of the IP module Reached aim The IP qualification system informs the IP provider if no synthesis is made and if errors during synthesis occurred Information about the timing compliance is extracted from the synthesis reports In making the documentation the IP provider is supported by templates which could be generated out of a VSIA compliance database Use of a version control system IP delivery with contract models Table 1: Quality characteristics und reached aims The time reduction achieved is particularly remarkable. The time needed for packing an IP module could be shortened from half a day to one day to approx. 40 minutes. Now only approx. 10 minutes are necessary for manual interactions. The remaining 30 minutes are dedicated to computer run time. Modification belonging to changes in the certificate requirements is made easier because of database support. Through partly automatically generated documents, the time needed to fill in a certification report has been shortened. 6 Conclusions and future work Th e developed IP qualification system helps to design IP modules of high quality and gives IP users confidence in IP modules bought from outside the own company. Especially in the IP delivery phase it could be demonstrated, that with automated qualification, certification and delivery processes time and money could be saved. This helps to meet time to market. In the future, the rule checker has to be updated or even replaced. An automated rating (e.g. OpenMORE) should be introduced into the IP qualification system and the possibilities for an automatic technology mapping will be analyzed. Furthermore, the IP user will get information on an unknown IP module and also information on how easy it could be integrated into his SoC/platform. Therefore, a quality metric will be implemented into the IP qualification system. This work will be continued in the MEDEA+ project ToolIP (A511). ToolIP stands for Tools and Methods for IP ([14], [15]). Also the German BMBF is funding this project under the national label IPQ [16], which stands for IP qualification for efficient system design. Acknowledgements We would like to thank Dr. J. Haase and Mr. P. Neumann for their excellent support during the work and for providing all resources needed at the location of sci-worx company. References [1] Avant! ; Nova-ExploreRTL VHDL User Guide I/II; 2000. [2] Dalpasso, M.; Bogliolo, A.; Benini, L.; Specification and validation of distributed IP-based designs with JavaCAD; DATE 99 Session 10C, IEEE Computer Society Proceedings; 1999. [3] Keating, M.; Bricaud, P.; Reuse Methodology Manual for System-on-a-Chip Designs; Second Edition; Kluwer Academic Publishers; 1998. [4] Seepold, R.; A European Perspective on IP Reuse; FDL 2000; Tübingen; September 2000. [5] Seepold, R.; Martínez Madrid, N.; (eds.); Virtual Components Design and Reuse; Kluwer Academic Publishers; December 2000; ISBN 0-7923-7261-1. [6] Seepold, R.; Standardization of System-Level IP, GI/ITG/GMM- Workshop: Methods and description languages for the modeling and verification of circuits and systems; Meißen, February 2001. [7] Semiconductor Industry Association; The National Technology Roadmap for Semiconductors; http://public.itrs.net/files/ 1999_SIA_Roadmap/Home.htm; 1999. [8] Synopsys; Mentor Grapics; OpenMORE Homepage; http://www.openmore.com; 2000. [9] Synopsys; Design Compiler; http://www.synopsy.com; 2000. [10] Torroja, Y.; Lopez, C.; García, M.; Riesgo, T.; Torre, E. de la; Uceda, J.; ARDID: A Tool for Quality Analysis of VHDL based Designs; FDL 1999. [11] TransEDA; Verification Navigator Cover Homepage; http://www.transeda.com/products/vnco.html; 2000. [12] Virtual Component Exchange (VCX); VCX Homepage; 2000; http://www.vcx.org. [13] Virtual Socket Interface Alliance (VSIA); VSIA Homepage; 2000; http://www.vsi.org. [14] ToolIP project Homepage; Medea+ A511 project, 2001; http://toolip.fzi.de. [15] Medea+ Homepage; 2001; http://www.medea.org. [16] BMBF Homepage; 2001; http://www.bmbf.de. [17] TransEDA and sci-worx press release; http://www.transeda.com/news/index.html Page 5 of 5