It is widely accepted that system verification is the most imposing obstacle to meeting time-to-market schedules. Now, the verification process has become even more time-consuming and expensive. These factors can be attributed to rising chip densities, the growing use of third-party IP blocks, and escalating design complexity. Complicating these issues is the sequential approach to system design, which is commonly used in register-transfer-level (RTL) flows. Here, an architectural phase is followed by the design of specific modules. Verification only begins at the end of the development cycle. Of course, bugs found at this late stage are extremely difficult and expensive to resolve.

Clearly, the key to minimizing the time and cost spent on verification is to begin the process as early as possible. It also is important to reuse the testbench data later in the verification phase. By commencing high-level verification in parallel with the architectural phase of a design, developers can reap significant time-to-market benefits. If they find errors before the system architecture is completely defined, they can solve those problems more easily. They can then build higher-quality, less expensive solutions. By reusing testbench components during HDL verification, developers can improve the efficiency of their verification process. To achieve these goals, however, designers need to perform system-level modeling and verification in the same language.

To address this issue, a working group within the Open SystemC Initiative (OSCI) recently launched an effort to develop a SystemC Verification (SCV) standard. As an independent group of EDA, semiconductor, IP, and systems companies, OSCI is dedicated to supporting and advancing SystemC as the industry's open-source standard for system-level design. The organization's goal is to develop a modeling platform and language that accelerates system-level co-design and IP exchange. Currently, the OSCI working group is targeting a library that provides a verification foundation for SystemC.

The group's efforts reflect the growing challenges faced by today's chip designers. As IC gate counts have skyrocketed, hardware designers are increasingly caught between the escalating complexity of their designs and the need to meet shorter development cycles. To confront this challenge and improve productivity, chip architects need to model their systems at higher levels of abstraction. Such levels need to be above hardware description languages, such as VHDL and Verilog. Moreover, the architects need a design methodology that will allow them to easily move functions between hardware and software implementations.

The preferred language for hardware designers is C/C++. But that language lacks the syntax needed to describe concurrency and clocking. As a result, companies have developed their own extensions to C/C++, fragmenting the market for system-level design tools and IP models. This issue, in turn, has made the hardware design cycle more time-consuming, costly, and inefficient.

To solve this problem, the industry needs a standard interoperable modeling platform. The ideal platform would allow designers to quickly and simply exchange system-level C++ models while promoting easy tool integration. Fortunately, it appears that SystemC is such a standard. As a common design language built in C++, it takes designers from concept to implementation in hardware and software. Plus, it is an accepted industry standard. Designers can use it to accelerate the exchange of system-level IP models and executable specifications in a common C-based modeling platform.

SystemC comprises two parts. First, there's the language, which consists of syntax and execution semantics. The second is a "reference implementation," which is made up of source code. When compiled and linked with SystemC models, that source code executes per the prescribed semantics. With this language and open-source reference implementation, designers should be able to create, validate, and share models and executable specifications with other companies that use standard ANSI C++. At the same time, EDA vendors can build tools that are automatically interoperable.

EYE ON VERIFICATION
Initially, the efforts of OSCI focused on developing system-modeling capabilities. If SystemC was to serve as a comprehensive open-source tool for system-based design, however, developers needed to extend the language to verification. In early 2001, representatives from ST Microelectronics, Motorola, and Fujitsu jointly proposed the creation of a working group within OSCI. This group would explore the development of verification extensions and methodologies for SystemC. In the second half of that year, a working group was set up. Its goal was to begin identifying the technical requirements for developing an object-oriented verification methodology that would support SystemC.

This working group comprised a number of EDA companies, semiconductor developers, and system/IP companies. It included ARM, Cadence Design Systems, CoWare, Forte, Fujitsu, Mentor Graphics, Motorola, ST Microelectronics, and Synopsys. In addition, representatives from a variety of academic institutions made key contributions. These individuals had performed extensive research in SystemC and verification. Among the institutions that were represented were the University of Chemnitz and the University of Tuebingen, both located in Germany.

Originally, the developers of SystemC provided a platform upon which developers could build various design methodologies. This working group set out to achieve a similar result for verification. Its goal was to define a set of classes within SystemC. These classes would provide a basis for developing various verification methodologies. The beta version of the SystemC Verification Library (SCV) is available for download from www.systemc.org. The production code will be available in early 2004.

Certain key capabilities within SystemC were crucial to the development of the SystemC Verification Library standard. To facilitate system-level verification, this standard adds application programming interfaces (APIs) for multiple new functions. Yet its development would not have been so rapid without SystemC's embedded support for transactors.