Use of C/C++ Models for Architecture Exploration and Verification of DSPs David Brier Texas Instruments Inc. Dallas, TX, USA +1-214-480-4047 dbrier@ti.com Raj S. Mitra Texas Instruments Inc. Bangalore, India +91-80-25048132 rsm@ti.com ABSTRACT Architectural decisions for DSP modules are often analyzed using high level C models. Such high-level explorations allow early examination of the algorithms and the architectural trade-offs that must be made for a practical implementation. The same models can be reused during the verification of the RTL subsequently developed, provided that various "hooks" which are desirable during the verification process are considered while creating these high level models. In addition, consideration must be given to the qualitative content of these high level models to permit an optimal verification flow allowing for compromise between features of the model and the completeness of the verification. Thus, high quality design and verification are achieved by the use of valid models and the valid use of models. In this paper, we describe our approach and show examples from a typical image processing application. Category and Subject Descriptors C.3 SPECIAL-PURPOSE AND APPLICATION-BASED SYSTEMS, Signal processing systems; B.6.3 LOGIC DESIGN, Design Aids, Hardware description languages, Simulation, Verification; General Terms Algorithms, Documentation, Design, Languages, Verification. Keywords Verification, C/C++, Simulation, Formal, RTL. 1. Introduction The design process of a DSP system typically starts with development of the algorithm in C language, which includes an exploration of the design space and experimentation with different data structures and algorithms. This algorithm becomes the “valid” golden model on which rests the subsequent steps of design and verification of the DSP module. This model is validated (with reference to the system specification which represents the System Architect’s intent) through a set of testcases that measure the algorithm’s performance and tests its functionality. Subsequently, the C model is translated into its RTL form, and this RTL is verified against its C reference. Architecture exploration with the help of high level (C) models is a fairly common practice, because of its ease (of making changes) and speed (of simulation) as compared to doing the same at a lower level of abstraction (RTL). What is not so well understood is how this C model can be used to efficiently verify the lower level RTL and determine its correspondence with the C model. This correspondence is not always straight-forward, due to micro- architectural changes made at the RTL for pipeline efficiency and other purposes. In the absence of a proper verification methodology, the (often manually created) RTL stands the risk of inaccurately representing the high level intent which was signed off as the C golden reference. This paper discusses the utilization of high level C models throughout the Specification stage, the Development stage and the Verification stage of a design. Specifically, we show that verification hooks built into the model facilitates the verification task, and we illustrate the methodology with examples taken from a typical Image Processing application – the resizing of an image for vertical and horizontal zooming. In general, this methodology is used throughout all designs of this type but there are often specific characteristics which require some small modifications to the flow. The paper is organized in the following way. Section 2 discusses and compares the roles of the Specification, the C model, and the RTL, and how they are inter-related. Section 3 describes the Resizer design, and this design is used as a case study in subsequent sections. Sections 4 and 5 describe the validation of the C model and the verification of the RTL respectively, and Section 6 discusses the difficulties in verification and the strategies used – both by simulation and formal techniques. Section 7 concludes the paper, and points to future areas. 2. Specification, C model, and RTL Intent of the design must be documented so that a hard target may be established to which the design must comply. Written specifications are paramount to creating a permanent record of the requirements of the design as well as the evolution of these requirements. These written specifications also serve as a product definition documentation, and is reviewed by the upstream and downstream organizations in the development process. Writing a good robust C model may be deemed as an executable specification but in the absence of a written specification it will not be sufficient to create a complete and proper design. Specifically, esoteric requirements such as “Image Quality” Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. DAC 2006, July 24–28, 2006, San Francisco, California, USA. Copyright 2006 ACM 1-59593-381-6/06/0007…$5.00. 7.1 79