A Platform Based SoC Design Environment

Abstract:

We present a reusable integrated design environment for platform-based SOC designs. This paper addresses issues faced and benefits of reusable and SOC design environment for getting a verification closure, synthesis and timing analysis in a platform-based SOC. This includes flexibility in meeting the final requirements with tool and technology independence wherever possible in various processes and projects. The other aim is to save effort by avoiding the same work done twice by different people and to reuse the same environment for the different projects. This paper also shows a comparasions of wirelsess SOCs which is applied the proposed environment.

I. INTRODUCTION

As systems on chip (SOC) design complexity increases, it follows that the complexity of the verification and design environments for such designs increases dramatically. But the traditional verification and environment do not provide the enough ability to check the function correctness and cannot ensure the product quality. Verification has become the bottleneck of SOC design and takes 50% to 75% of the overall design effort. To ease the verification bottleneck, numbers of efforts have been made in industry, tools and languages [1], [2]. Verification is no longer merely a test effort, it is also designing a verification environment. Hence in this paper emphasis more on a reusable verification environment and test bench architecting. Although there are several verification languages in the market today, it seems that circuit verification still most often uses simulation as the methodology of choice [3]-[5]. Environment constructed for this purpose and methodology, using standard RTL and scripts, do not rely on specialized tools and run on all major simulators. The verification environment developed for the dynamic functional verification of components is described.

The SOC development process is typically viewed as consisting of the stages of architecture definition, RTL implementation, functional verification, synthesis, test generation, test logic insertion and timing verification. There are many relationships between each other. Typically, this process is divided into the frond-end and back-end, so design environments and script separately exist and is designed. It is difficult to manage the relation of each other [4]. The centralized data structure and integrated design environment is proposed and applies the case study [8]. This paper presents how to apply two projects, how to reduce the design time and comparisons of two projects. This paper proposes the SOC design environment which includes tools environment, technology parameters, synthesis scripts, various variables for the timing analysis and comparisons of successive project. This environment is also designed reusable script and environment that are as tool-, platform- and technology- independent as possible. Moreover having a reusable SOC design environment can give a big benefit. This paper will briefly address these issues in an effort to inform others about this level of integration.

II. SOC DESIGN ENVIROMENT

We make the SOC design environment using Make utility, Perl, Tcl and a Version Control System (CVS) for a complex and a platform-based SOC. The SOC design environment manages modules that include test bench, drivers, Tcl, script and RTL. The heart of the reusable SOC design environment is central data structures containing all design, constraints and characterization information. The environment built on the central data structures include manipulators to across the data structure, simulators, synthesis and shell scripts performing tasks of the methodology [1].

A. Data Structure

A data structure consists of a CVS repository, common data and user data. Fig.1 shows the data structure. The CVS manages and controls a version of data. The common data is the kind of a snapshot. A current snapshot data is automatically updated when new version data is checked in a CVS repository. The common data can has various versions according to a various purposes.

Fig.1. Data Structure

During a build of the design, it is important to have a "snapshot" of the sources used for the build. In this way, we do not need to depend on the source files being stable over any period of time. For instance, you may compile the design on one day, but run synthesis on another. The user data is the individual work space. A Basic data structure consists of the project environment, a fullchip design and various IPs. Because the structure of the Fullchip and each IP block have same sub-directories, it is easy for all users to manage and to access the data base. The sub-directories consist of makefile scripts, RTL, test bench, synthesis scripts and a test driver which includes bus functional model (BFM) and a core functional model. Especially, the project environment has scripts and Tcl that includes technology parameter, tools environment, common synthesis script which are used across the entire project components. The benefit of this centralized data structure is helpful that the designer verifies the interconnection and the difference between the common data and the user data. Each designer confirms the modified user data with the common data and then puts the modified one in the common data base.

B. Design Environment Structure

Make utility is the best one of many utilities which maintains a group of the program. The purpose of the make utility is to determine automatically which pieces of a large program need to be recompiled, and issue the commands to recompile them. Make utility is selected for a main manipulator. The Makefile will automatically re-make itself as others commit their changes to the repository. This avoids issues related to stale Makefiles.

Fig 2. Design Environment Structure

Makefile consists of components list, tools environment, technology parameters, verification, synthesis, and data structure scripts. Each script is divided into two parts on a point of user’s view, the first part is a common script including tools environment, common parameters and design flows on the based project. The other script is a core-script including a module, a test list, a test-specific configuration, clock characteristics and a constraint. Fig.2 describes an SOC design environment structure. The organization of the Makefile components is explained in this paper. Makefile has a list of the components which makes up Makefile for a proper project or a core.

Fig.3. Execution Flow of Makefile

Fig 3 shows the execution of the Makefile. In the first stage of making itself, Makefile make a data path structure by a module name, sub-module and specific configuration. This data path is used for a library search of the simulator and the Makefile. A priority of the search is controllable according to a specific configuration. The next stage is making the environment of simulator, synthesis tools, technology parameters, etc. At the end of these procedures, Makefile assembles the executable target and command for each design flow. Finally Makefile executes a target and command.

C. SOC Design Platform

A general SOC design contains the following components: a processor, a peripheral bus, many peripheral devices such as UART, IIC, etc, a bridge between two buses. Lot of effort is spent in creating and testing these devices independently before they are integrated into the SOC. Reuse of monitors, external test pattern generator, and driver for the module will help to boost the SOC verification environment [6] [7]. The block level verification platform is shown in the fig 4. With this approach we can enable the reusability of verification components associated with the design under verification (DUV) in the SOC level and across the entire SOC where the IP is being reused.

Fig.4. Block Verification Platform

In addition, it is also important that the block level test cases are easily ported to the system level environment as well. This can be done by using scripts to convert the tests to system level. The main purpose of doing this is to perform a sanity check of the module. Not all tests can be ported to the system level because of the constraints in the system level. The test cases such as module register access, interrupts triggering and its basic functionality can be ported depending on the complexity. The toggle coverage between the interface of the module and the system can serve as a measurement in such checks.

Reusability concepts can also be applied to verification. The design cost can be reduced and the verification can be improved, if the IP verification platform can be reused partly or completely in the SOC verification platform.

Fig.5 shows the SOC verification platform. By implementing the above steps, the verification engineer can hence focus more on SOC level checks instead of recreating test cases for checking the integration of the module into the system. An example of the system level test would be to coordinate two or more modules in the system to perform specific routines. In some cases, the block verification platform can also serve as a guide for verification engineers, who are new to the module, to properly setup and program the module. This would speed up the effort required to learn the new module, especially for the case of very complex modules.

Fig.5. SOC Verification Platform

The IP verification platform is made with the bus function model, driver, monitor and etc. Then we make the SOC verification platform like the IP verification platform for reusability. And we can verify the IP function with a ROM file which is converted a C-program into.

D. Synthesis scripts Reuse

Generally, the overall synthesis compile and optimization strategy may be relatively constant, but there are many choices to be made in managing the tradeoffs of power, timing, area, and run time. We make these scripts which isolate these choices in a separate section of user-selectable parameters with error checking and default settings representing the best mainstream approach.

These scripts are divided into two parts. The first part is the mainstream scripts which are located in the synthesis script directory of the project environment and consist of compile, insert scan and timing analysis script. The other script is the clock and boundary condition script which located in the synthesis script directory of the block for each block. This script share these constraints with the synthesis process and allow for the annotation of backend extracted parasitics for final sign-off. Having parameterized, flexible, and complete constraints for each block and the fullchip with built-in examples and error checking facilitates the entire implementation process. A set of constrains and clocks are customizable. This way, we expect to make appropriate choices without having to reverse-engineer the gory details in the scripts and without risking introducing a bug into such scripts. In the execution and compile steps, the option of make utility controls and selects which flow of the overall synthesis script. Therefore we should expect to enjoy the benefits of that knowledge in the form of reusable and configurable synthesis scripts.

III. THE CASE STUDY OF WIRELESS SOC

In this paper, we design a v2.0+EDR Bluetooth SOC for a multimedia application. This SOC supports full v2.0+EDR Bluetooth specifications. We employ an extended instruction set computer (EISC) to effectively manage designed functional blocks and implement Real-Time OS on EISC. For verification, we build a test bench including functional models of a packet processor, an RF modeling, bus functional models (BFMs) and Protocol Monitor. This verification environment is excellent to reuse components which verify each block and a fullchip. For a synthesis process environment, as like above synthesis environment, we build common compile, clock and constraint scripts.

This SOC design environment is applied to the v2.0+EDR Bluetooth SOC development. This SOC includes an extended instruction set computer (EISC) and a RF, a MODEM, a Link Controller and a SBC. We reconstruct the proposed environment of each IP and a fullchip form the previous project. The previous project environment consists of an ARM7 processor, a MODEM, a Link Controller and an adaptive differential Pulse Code Modulation (ADPCM) codec. We need to the constructed time of new design environment, but we get more advantage and the reusability of the proposed environment. Each block is made up the proposed data structure.

A. SOC Design Environment

The SOC design environment using a make utility controls and manages across all design flow. The maker script will automatically re-make itself as others commit their changes to the repository. The Makefile scripts developed for this work consists of the following major components:

Each component is a makefile script consisting of a project variable, a search path and each role description. Depending on the functionality encapsulated in the component, one or more of these sections may be absent in a specific component. For example, a component such as a CRC computation module may have no ports and no time-consuming code.

B. Verification

The dynamic verification consists of a test driver, BFMs, a monitor and DUV. All block environments including a soft IP and an internal IP are changed into the sub-data structure form. The block-dependent environment and the sub-block is reused in system level. The simulatable test environment is written in verilog in the traditional way, and optional components are selected by a generic test name and a test-specific verilog configuration. Not only have they the stimulus patterns driven by compiled verilog components, but also they are controlled by makefile. Members of the designer have written a number of test vectors, all of which are available to the persons writing test-specific verification code.

C. Synthesis Flow

We code these scripts which include the mainstream scripts and clocks and constraints script. The synthesis process flow is described in Fig.6. The execution of the synthesis process is called by the Makefile and the synthesis step is controlled by the target options. The general synthesis procedure can be also decided by the block designer

Fig.6. Synthesis process flow

If the each block engineer needs to modify owns synthesis script, he can modify the each block Tcl which has the variable of $core without risking introducing a bug into such scripts and understanding the overall synthesis process. Each block expects to represent a unique set of challenges corresponding to the added flexibility inherent in its form.

D. The Comparison of wireless SOCs

In this paper, we apply this environment on Bluetooth SOC two times. For verification, we build a test bench including functional models of a packet processor, an RF modeling, BFM and a Protocol Monitor. This verification environment is excellent to reuse components which verify each block and a fullchip. For a synthesis process environment, as like above synthesis environment, we build a synthesis, clock and constraint scripts. We need to reconstruct the proposed environment form the previous project, but we get more advantage and the reusability at the third project. All IP block environments are changed into the sub-data structure form. The block-dependent environment and the sub-block are reused in system level. The simulatable test environment is written in verilog in the traditional way, and optional components are selected by a generic name and a test-specific configuration. Designers have written a number of test vectors, all of which are available to the persons writing test-specific verification code.

It is difficult to analysis a reusability and an efficiency of the environment [6]. These benefits change according to a man power, a different degree and a machine power, etc. Therefore we compare with a pervious and a current project, and then this unified environment is helpful to reduce the design time and to improve reusability. A test vector and various scripts which are used in each block reuse in the fullchip level. Then an IP, a fullchip and an interconnection are concurrently designed and verified. TABLE I is comparisons of several projects. When the project is started, the development IP is completed and fullchip designer co-works with one designer per each block. The design time section (TABLE I) means the SOC integration, verification and backend time. A RF, a MCU and a baseband are integrated on a single IC in 0.18um CMOS-RF. The second project is fully certified to meet almost Bluetooth v2.0+EDR specifications and offers excellent performances, a low power and a small size. The third project successfully tapes out in a shorten time.

TABLE I. PROJECT COMPARISONS SUMMARY.

A die photo and layout of Bluetooth SOCs are shown in Fig.7. Fig.7 (a) is a die photo of the first project is applied the propose environment and (b) is layout of the second project. As shown, RF, EISC, and baseband are integrated on a single IC in 0.18um CMOS-RF. The device is fully certified to meet almost Bluetooth v2.0+EDR specifications and offers excellent performances, a low power and a small size.

(a) Chip Photo of Project B

(b) Layout of Project C

Fig.7. Die Photo of a Bluetooth SOC

V. CONCLUSION

This paper presents a platform-based SOC design environment that includes Perl, Tcl, and Makefile can be successfully built and used. This paper focuses on the reusability of environment as the issue to reach quality and time-to-market goals for a platform-based SOC. The paper presents the design and verification environment. In the case study of wireless SOC, we prove that the reusability is improved and the design time reduces in the proposed environment. This paper discussed the design and implementation of techniques to develop SOC design environment using the relatively new v2.0+EDR Bluetooth SOC as a case study. Use of the environment presented in this paper will reduce development time and expense, and result in successful tape out and a good test result. This environment supplies a reusable synthesis, a timing analysis and verification. We reduce the total design time in compare with the one of the old design environment. We present the comparison results between a pervious and a current project

ACKNOWLEDGMENTS

This work was supported by Korean semiconductor Intellectual Property EXchange in Korea.

REFERENCES

[1] J.M. Pendleton, C. Burns,. “An integrated CAD environment for system design”, Proceedings of the Twenty-Second Annual Hawaii International Conference on System Sciences, Vol. 1, pp39-48, Jan 1989.

[2] Falconeri, G. Naifer, W. Romdhane, N, “Common reusable verification environment for BCA and RTL models”, Design, Automation and Test in Europe, Proceedings, pp. 272 - 277 Vol. 3. 2005.

[3] McKinney, M.D., “Integrating Perl, Tcl and C++ into simulation-based ASIC verification environments”, Proceedings of the Sixth IEEE International High-Level Design Validation and Test Workshop, pp19 – 24, Nov. 2001.

[4] M. Bocchi, C. Brunelli, ”A System Level IP Integration Methodology For Fast SOC Design” International Symposium on System-on-Chip, pp.127-130, Nov 2003.

[5] Sagahyroon, A.; Lakkaraju, G.; Karunaratne, M., “A functional verification environment”, Circuits and Systems,. 48th Midwest Symposiumon, pp. 108 – 111, August, 2005.

[6] Rui Wang, Wenfa Zhan, “Reuse Issues in SoC Verification Platform”, The 8th international conference on computer supported cooperative work, pp.685-688, 2003.

[7] M. Boccchi, C. Brunelli, et al, “A system level IP integration methodology for fast SOC design”, IEEE Proceeding. 5th International Conference on ASIC, Vol 1 pp.278-281, Jan 2003.

[8] Jeonghun Kim, Jungwon Jeong, Taesik Bang, Suki Kim, “ Integrating Makefile, Tcl and Perl into SoC-based Design Environments”, IEEE Proceeding of 3rd IEEE International Conference on Circuits and Systems for Communications (ICCSC 2006), July 2006