|
|||||||||||||||
Verification IP Reuse For Complex Networking Asics
By Ben Chen, Srinath Atluri of Cisco System and Shankar Hemmady, Rebecca Lipon of Synopsys
April 01, 2008 -- edadesignline.com Maximizing verification IP reuse improves verification productivity. The International Technology Roadmap for Semiconductors (ITRS) projects that 75 percent of design/verification productivity improvement will come from IP reuse and 25 percent from improved EDA tools, flow, or methodologies. However, because of the variety of hardware verification languages and EDA tools, and sometimes the lack of verification strategy, reuse proves a daunting task for engineers as well as managers. Recently, the Cisco, Internet Switching Business Unit Silicon Engineering team, set out to tackle this beast in project X from three different angles: language selection, methodology definition and test-bench implementation. The result: the hybrid SystemVerilog/SystemC verification environment we created lays down the methodology blueprint for future ASIC verification projects in Cisco and stretches the boundary of reuse by finding sources and consumers of verification IPs in other aspects of the product development cycle including modeling, multi-chip co-simulation, and software debugging. With the goal of maximizing verification IP reuse, we kicked off project X with a hybrid SystemVerilog/SystemC verification environment. The result went beyond the successful tape-out of another multi-million-gate ASIC. The project cycle of a brand new three-million gate design was shortened to seven months, compared to the typical nine-month cycle. The verification environment provided some of the first SystemVerilog and SystemC verification IP modules in Cisco. Moreover, the verification methodology we created opened up the possibility of leveraging ASIC verification IP from and to other aspects of the product development cycle including modeling, multi-chip co-simulation, and software debugging. We attribute the success to the following:
How did we come to choose SystemVerilog and SystemC to build the verification environment for project X, as well as for future projects? We have long been capitalizing on the benefits of Constrained Randomization, Object Oriented Programming (OOP), and Functional Coverage from hardware verification languages like OpenVera, C++, etc. In the past five years, a verification strategy built around constrained randomization has helped us expose a larger number of functional bugs at the early stage of verification and speed up convergence as a result. OOP allows us to package common test-bench components for reuse. SystemVerilog and SystemC became the hardware verification languages of choice because, derived from OpenVera and C++, these languages gave us maximum leverage from legacy verification code. Moreover, both languages, as well as the programming interface between SystemVerilog and C++ (SystemC library is written in C++), Direct Programming Interface (DPI), are standardized in IEEE and supported by almost all commercial simulators in the market. Compared to the legacy verification environments that used vendor-proprietary languages, the SystemVerilog/SystemC environment, using all standardized verification languages, eliminates any concerns for tool incompatibility when our test-bench components are examined for adoption as verification IPs. Another reason for using SystemC is that since most of the system-level modeling is done in C/C++ today, using SystemC opens up the possibility of leveraging the system-level C models from our software modeling team for chip-level verification reference models instead of us developing from scratch.
|
Home | Feedback | Register | Site Map |
All material on this site Copyright © 2017 Design And Reuse S.A. All rights reserved. |