the IP modules ([4], [5]). For an IP licensing and distribu- tion procedure, IP users and IP providers are supported by the work of VSIA and VCX ([2], [6]). However ...
A Qualification Platform for Design Reuse R. Seepold1, N. Martínez Madrid1, A. Vörg1, W. Rosenstiel2, M. Radetzki3, P. Neumann3, J. Haase3 1
Forschungszentrum Informatik Dept. Microelectronic System Design Karlsruhe, Germany
2
University of Tübingen Dept. Computer Engineering Germany
Abstract The application and development of reusable components (Intellectual Property, IP) has become a regular part of modern design practices. The IP provider on the one hand side and the IP integrator (user) on the other side may be in the same company or separate participants in the microelectronic design market. In both cases, the transfer of IP remains a complex and time-consuming task. The qualification of IP gains a significant relevance for successful application and transfer of IP. This paper proposes an IP qualification methodology for an automated quality check that also incorporates current standards. Through embedding of the new concept into the regular design flow, IP transfer comes closer to an easy mix and match of virtual components. The presented approach has been validated during an industrial case study.
1. Introduction The Intellectual Property market keeps growing at a good pace. According to a survey [1], it increased 40 percent last year. The highest relative gain has been among the “domain IPs”, where companies focus on a technology area and provide application-specific standard products, which typically comprise a high number of IPs. Since the application of IP inside a design occurs quite often and it will further increase in the near future, one of the biggest challenges for IP providers and for third-party IP purchasers is ensuring the quality of the IP block. The providers want to gain the confidence of the customers, and the users want to minimize risks and be able to evaluate and select the right core. As time to market remains a key factor for success of the product, a very short period is available for taking the right decision when selecting an IP. This demand is difficult to
This work has been partly supported by the German government under the project IPQ (01M3048B). In parallel, it is running in the Medea+ project TOOLIP (A511).
3
sci-worx GmbH Hannover, Germany
fulfil because the evaluation of the “IP quality” is poorly formalised and varies at least from company to company (e.g., with respect to different coding guidelines). The evaluation of third-party IP and the quality-oriented development of own IP – passing all relevant internal qualification procedures during design – remain an open issue. There is a need for a new methodology, incorporating quality criteria and standards supporting IP provider and integrator. Furthermore, automatic tool support is required to enable more objective measurements, and thus increase its applicability. A common infrastructure (framework) has to be developed for evaluation of IP that is flexible to be tuned to different existing design environments in the companies. This framework needs to support at least three different but related scenarios: the incorporation of third-party IP, the check of design rules during the development of the design project and the final check of the developed item (e.g., an IP). In the following section, the state of the art is summarized. In Section 3, the requirements are detailed. Section 4 presents the framework model and Section 5 documents the case study and the latest results extracted. Finally, the conclusion summarizes the work.
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 [2] develops technical methods in order to improve the quality of IP and thus eases the integration of IP into a SoC or platform. Also in the Reuse Methodology Manual (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. There is no comprehensive method for IP qualification, which enables an automatic examination of the IP modules ([4], [5]). For an IP licensing and distribution procedure, IP users and IP providers are supported by the work of VSIA and VCX ([2], [6]). However, the IP provider is not supported by tools to show compliance or com-
Copyright 2002 IEEE. Published in the Proceedings of ISQED/2002, March, 2002 at the DoubleTree Hotel in San Jose, CA, USA. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works, must be obtained from the IEEE. Contact: Manager, Copyrights and Permissions / IEEE Service Center / 445 Hoes Lane / P.O. Box 1331 / Piscataway, NJ 08855-1331, USA. Telephone: + Intl. 732-562-3966.
pleteness of its delivery package. Ratings exist like for example OpenMORE [7], which should support the IP user in deciding which of the IP modules with the same functionality is the most appropriate for integration in a system design or platform. However, the IP provider must create these ratings manually, which is of course time-consuming and not very objective. Besides VSIA and RMM, there are already individual tools available, like rule checkers [8], code coverage and synthesis tools ([9], [10]). These tools could also be used for IP qualification aspects. But it is obvious that an IP quality 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. Show compliance to design guidelines by an automatic tool support 2. Help the IP user to select an IP module by reliable certification 3. Develop an IP qualification methodology, which could be inserted in an existing design flow.
3. Quality requirements The quality criteria, which have to be taken into account, come from various sources: The RMM contains a set of rules and guidelines that help ensure that a design is reusable and technology-independent. IEEE Standard 1076.6 (VHDL Synthesis Subset) [11] describes the language subset of VHDL that is synthesizable with any compliant tool. Further efforts on quality are under way in the Virtual Socket Interface Alliance (VSIA). The integration of these criteria according into a design flow will be based upon the IP project structure. It is accompanied by revision control, local (private) design areas for each designer, global (public) areas for administration by the project manager and conventions about directories, file names etc. The code quality is related to the reusability, maintainability and portability of IP cores. Here, compliance or synthesizability is key. Furthermore, an assessment of the verification quality requires evaluating code coverage after passing different test cases during the design. The design quality is determined by the measurement of area, gate count, power and timing. These values can be compared to alternative IPs and the user’s requirements. Finally, the physical validation remains an important criterion as a reference implementation.
4. IP quality framework model After fixing the quality characteristics, an IP qualification methodology has been developed that has been later embedded into an existing design flow. Part of the overall
IP qualification framework model (Figure 1, part 1-6) is an IP certification (Figure 1, part 4) and a delivery phase (Figure 1, part 5). Qualification starts with different qualification phases (Figure 1, part 1-3 or 6) during the design. Then the IP modules are qualified and finally certified. An IP user requires a reliable quality characteristic in order to decide on a specific IP module. Figure 1 shows the different phases of the IP qualification process and their embedding into a typical design flow. There is a design accompanying application phase (1), the final (2) and the custom specific application (3) of the qualification system. It can also be seen that an IP certification takes place (4) before the IP delivery phase (5) starts. The integration of foreign IP into the design flow (6) is also taken into account by checking the compliance to the defined IP structure.
4.1. IP qualification phase Within the IP qualification phases (Figure 1, part 1-3 and 6) the model supports the application of commercial tools as well as the incorporation of individual programs. In addition, tool-specific configuration files or 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. 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. Since, no IP core is delivered unless an IP quality engineer has formally qualified it. Within this process, the IP core package will be received and all actions, like e.g. unpack, have to be performed. With this check, a customer installation can be simulated without any impact of proprietary environments that may be used by the IP developer. In addition, the deliverables are checked for VSIA compliance, and a VSIA compliance report is created. If no errors occur and all qualification steps are successful, the design is tagged as ready to be delivered and entered into an IP core database that is the source of all deliveries to customers.
4.2. IP certification phase In the certification phase (cf. Figure 1, part 4) the compliance reports of VSIA or OpenMORE evaluation are performed on the basis of the generated data during the qualification phase. IP certification is applied for both: according to (de-facto) standards or customer specific.
4.3. IP delivery phase After the certification phase the IP module will be deliv-
ered to an IP user. This is covered by Figure 1 part 5, which contains also the contract model. 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, contract models 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. Quality framework implementation During a case study, the model presented has been installed and embedded into an existing design flow of an IP provider. The test module consists of 13 megabytes of data in 260 files and counts about 3800 gate equivalences. In the following, the three main phases, IP qualification, IP certification and IP delivery are described in more detail.
5.1. IP qualification The qualification phase contains code quality, verification, design quality and physical validation. Each aspect will be described in one sub section: • Code quality Code quality affects the reusability, maintainability, and
portability (tool- and technology-independence) of IP modules. Therefore, a coding standard, including coding styles and design rules, has been developed and long-term applied by the IP provider. Code reviews have been installed in the design process to verify all VHDL code against the coding standard. This coding standard has been now revised with the following goals: • Compliance to the RMM for all significant rules (e.g., regarding synchronous design, but not regarding naming conventions). • Ensure synthesizability by checking the code against IEEE 1076.6 (VHDL Synthesis Subset). • Consider other emerging rule works (from IP brokers, for FPGA compliance, etc.). • Formulate rules in a way that they can be checked automatically. A programmable rule checker [8] has been integrated into the IP qualification framework. The predefined and configurable rules of this tool are used as much as possible and allow covering a large portion of the coding standard. Additional rules are currently being implemented using the programmability features of the tool. The output of this checker, a list of all violations, is postprocessed by a Perl script that counts the number of occurrences of each violation, sorts violations by severity and frequency, and generates a condensed table that summarizes all violations in a comprehensive way. While this table is used to assess quality, the full report must be checked to locate critical sections in the source code. These sections have to be corrected by the designer, and any remaining
Figure 1: IP qualification framework model
warnings or errors must be justified. Before a module is added to the IP repository, the IP quality responsible repeats the check and compares it with the results and explanations obtained from the design team. With this implementation, about 80% of the rules can now be checked by a tool. • Verification In this case study, the IP verification quality is judged only by means of code coverage analysis. Various code coverage measures exist: for statement, branch, condition or path coverage determination. Code coverage is activated in the design flow by turning on a simple switch in the simulation setup. Initially, designers are advised to simulate without collecting coverage information (i.e., at higher speed) until the design passes all test cases. Then, code coverage shall be activated. If the above criteria are not fulfilled, test cases must be added in order to achieve a higher coverage. Before an IP core is tagged as qualified, the IP quality responsible must repeat the coverage assessment for all portions of the design. • Design quality Here, the term design quality comprises attributes of the synthesized circuit. Currently, the following design quality attributes receive special attention during IP core design: • Area / gate count: By synthesizing and mapping the design to a cell library, its gate count and area information can be determined. • Testability: A scan path is inserted into the synthesized design, and a test pattern generator tool is applied. • Power: Test patterns obtained from the previous step are used for power estimation of the synthesized design. Since test patterns are compacted to toggle many internal nodes simultaneously, the results are considered as near worst-case. Application patterns, if available, should be used in addition. • Timing: Any timing violations are extracted from the synthesis report. An IP core passes the final qualification only if the specified timing conditions (in many cases, determined by the typical application clock frequency) are met. Since the designed IP is soft IP (synthesizable RTL code), a synthesis is performed to ensure that the synthesized circuit fulfils all quality criteria significant at this level. All tool
invocations are controlled by automatically generated makefiles. Only the technology-specific constraints must be edited manually in specific files. • Physical validation After an IP core has been qualified w.r.t. code, verification, and design quality, and is verified against a behavioural reference model, it achieves a considerably high quality level. For many customers it is important that an additional physical validation is performed. This can be an implementation on an ASIC done by a reference customer, or an FPGA-based prototype. As an ARM approved design center, ARM based prototyping platforms validate not only the design, but also its interaction with software. The validation status is reported as part of the IP core documentation.
5.2. Certification Within the IP certification phase the IP module is checked for compliance to (de-facto) standards like the VSIA compliant certificate. The VSIA has released a document that 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. The extracted description starts in Figure 2 lines 1 “DWG Specification” to 4 “Required”: Here, the according document, the location and the kind of deliverable is specified. Additionally, the criteria classification is extracted (e.g., a “recommended” criteria). Relevant text sections of the referenced VSIA documents are extracted (Figure 2 line 6 “Description”) and there is an option to include a documentation deliverable in a specific file (Figure 2 line 5). For the compliance report, the required input is stored also within the database (Figure 2 line 7 “Comply” and 8 “Comment”). 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. The report generation has been implemented, too.
Figure 2: VSIA compliance database
5.3. IP delivery After certification 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. The goods delivered depend on the contract model chosen (cf. Section 4.3). A developed delivery script automates the task of packaging all files needed for the delivery, checks completeness and the presence of the “ready to be delivered” tag for this customer. This finally ensures the absence of unqualified last-minute bug fixes. In Table 1, implemented 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
Quality characteristic Reusable source code Verified functionality Synthesisable source code Compliance to specified timing Sufficient documentation Version- and Configuration management Completeness of the IP module
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 [12] or Interra SpyGlass [13].
6. Conclusion The goal of this work was the development of a methodology for automated and design flow-oriented IP quality checks, in order to fill an existing gap in the IP exchange process. The developed IP quality methodology can be mapped onto existing design flows. For the case study, commercial tools have been customized and embedded in the flow and several scripts have been developed when no commercial solution was available. The invocation of the tools (including all required parameters) is automatically
Reached aim With a rule checker company and de-facto standard rules could be automatically reviewed Improvement of simulation coverage through a code coverage tool 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
[2]
performed and in most cases, the analysis can be done without user interaction. The results achieved are very promising: For example 80% of the rules relevant for code quality can be checked automatically. All tool invocation for design quality is controlled by automatically generated makefiles. Only some specific constraints (e.g., technology, design or customer) must be edited manually. The time reduction achieved is particularly remarkable. The time needed for packing an IP module could be shortened from 4-8 hours down to approximately 40 minutes. Of these, only about 10 minutes are required for manual interaction, the remaining 30 minutes are dedicated to computer run time. Modification belonging to changes in the certification 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, too. The future work will focus on the elaboration of quality standards and metrics. Furthermore, both aspects will be incorporated into the proposed qualification methodology.
[12]
References
[13]
[1]
Dataquest Inc., “Worldwide Semiconductor Intellectual Property Market Share Rankings, 2000” .
[3]
[4]
[5]
[6] [7] [8] [9] [10] [11]
Virtual Socket Interface Alliance (VSIA); VSIA Homepage; 2001; http://www.vsi.org. Keating, M.; Bricaud, P.; Reuse Methodology Manual for System-on-a-Chip Designs; Second Edition; Kluwer Academic Publishers; 1998. Seepold, R.; Martínez Madrid, N.; (eds.); Virtual Components Design and Reuse; Kluwer Academic Publishers; December 2000; ISBN 0-7923-7261-1. 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. Virtual Component Exchange (VCX); VCX Homepage; 2000; http://www.vcx.org. Synopsys; Mentor Grapics; OpenMORE Homepage; http://www.OpenMORE.com; 2000. Avant!; Nova-ExploreRTL VHDL User Guide I/II; 2000. Synopsys; Design Compiler; http://www.synopsy.com; 2000. TransEDA; Verification Navigator Cover Homepage; http://www.transeda.com/products/vnco.html; 2000. 1076.6-1999 IEEE Standard for VHDL Register Transfer Level (RTL) Synthesis. IEEE, 1999. 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. Interra Information Technologies; SpyGlass (RTL rule checker); http://www.interra.com/eda; 2001.
