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.
When writing a verification test, it is much more efficient for the designer to write the test at a high level of abstraction. Then, he or she just has to translate the test into events at the design's signal level. This approach simplifies the test-development process by extracting the implementation details. Transactors play a pivotal role in this process. They translate the test from one level of abstraction to another. By capturing these transactors as reusable IP, a verification engineer can create new tests very quickly.
SystemC already supports this capability. In Figure 1, the left-hand side illustrates an abstract read function that the designer would like to use when writing the test. The right side represents the precise signal-accurate interface. In the middle sits the class transactor, "if." This transactor implements the read function on the left in terms of the basic design ports on the right. By saving these transactors as reusable IP, designers can quickly create tests that are capable of simulating complex behaviors.
The verification working group knew that it needed to help design teams build a foundation for performing transaction-based system-level verification. Much of its effort was focused on the development of three key capabilities in the SCV library: data introspection, randomization services, and transaction recording. It then had to face some difficult questions. For example, how can verification engineers analyze third-party data types and user-specified composite types? Ideally, toolbench developers would like to be able to extract information from these types and manipulate them. They don't want the user to be required to modify the source code.
DATA INTROSPECTION Data introspection gives the engineer the ability to analyze a data type using the practical specialization of templates. This process does not affect the basic underlying code. Two templates are available for this purpose:templatetemplate
The first template adds a standard access interface to arbitrary data types. This interface is called t-extensions-if. Through the application of this interface, an engineer can use a piece of code to extract type information, perform value access, and assign value to a variable. None of these tasks call for the code to include specific type information at compile time. The second template adds extra storage for callback registration, randomization, and other purposes to the arbitrary data type.
By handling arbitrary data types, data introspection allows the engineer to import legacy code. It also simplifies the reuse of the same code for multiple libraries. As such, it plays an extremely important role in the use of constrained randomization.
Constrained randomization is another new function introduced in the SystemsC Verification Library standard. By using it to generate stimulus, verification engineers can create more complex tests. This capability leads to higher design confidence and the better utilization of simulation resources.
Building on the data-introspection facility that was already discussed, the SCV supports constrained randomization on arbitrary data types. The following example illustrates how the constrained-randomization function operates: The process begins with a basic packet with source, destination, and data going from the source to the destination. Using the embedded introspection capability within a smart pointer, the engineer generates random values for source, destination, and data within this packet using the next function.
If the engineer only wants to randomize the destination and the data—but not the source field—he or she can use a disable_randomization function.
The next step is to apply the constraint. In this example, the engineer will implement a constraint called my_constraint. This constraint indicates that the source and packet are not the same. It then adds constraints, which indicate that all of the data fields are less than 10. When the next function is implemented on the constrained packet, it will satisfy those constraints. A constraint solver will then be embedded within the SystemC reference implementation.
Engineers can also use the object-oriented nature of C++ to add constraints by way of inheritance. Here, in Figure 2, the original my_constraint is extended to include the nine previous constraints. Another constraint is added, which dictates that the first two data fields cannot be identical. This new specialization of the original constraint is called new_constraint.
For a simple example of when this capability might be used, look to the task of modeling the different levels of a protocol stack. At the lowest level, verification engineers might use a constraint called level_0 to define valid data. To model higher levels of the protocol stack, they would have to introduce additional constraints like level_1. These constraints would build on the constraints in level_0, but add additional criteria.
Occasionally, verification engineers may want to use their knowledge of the design to concentrate the test stimulus on certain areas. For example, specific ranges of an address space may be more likely than others to produce bugs. For those situations, SCV provides support for "weighting." This capability enables verification engineers to designate a special condition. For example, they could specify that 60% of the stimulus must have an address between 0x1000 and 0x2000.
TRANSACTION RECORDING The electronics industry is rapidly migrating toward the use of packet-based protocols and away from traditional bus-based protocols. As a result, the designer's ability to visualize a design at the transaction level rather than at each individual transaction is becoming increasingly important. To allow verification engineers to work at this higher level of abstraction, the SystemC Verification library adds support for manual transaction recording. This important capability permits an engineer to annotate high-level transactions onto a waveform diagram.Among the many new capabilities offered by the SystemC Verification library in this area is the ability to overlap one transaction over another. Overlapped transactions are a common requirement, for instance, when modeling an architecture that features a pipelined bus. Figure 3 illustrates how such a transaction might be implemented. SCV also offers the ability to link transactions. This capability allows the verification engineer to easily track related transactions, such as a request for data and the response to that request.
While the first release of the SCV production code will take place in early 2004 much work still remains to be done. The verification working group, in collaboration with the OSCI Steering Group, is already examining a variety of enhancements to the SystemC Verification Library. One topic under review is a way of automating at least part of the transaction-recording process. At the same time, the verification group is looking at the possibility of adding support for assertion-based verification. Coverage monitoring for either random-constrained or non-random test patterns is also under consideration. In the meantime, some EDA vendors may add their own classes to the underlying verification infrastructure in SCV. They could choose to support the coverage-monitoring or analysis capabilities that are layered on top of transaction recording.
As an open-source industry standard for system-level design, the modeling capabilities in SystemC 2.0 represent a step toward the acceptance of a common design platform. Design teams need to be able to use the same environment to detect bugs early in the development cycle. They also need to be able to reuse and refine a testbench for RTL verification. Until these capabilities become reality, the advantages of SystemC will be limited. This is why the SCV has simplified the development of testbenches to go with system-level models. It promises to accelerate SystemC's acceptance as an industry-standard approach. Soon, SystemC may be seen as the key to the rapid development of higher-quality products at lower cost.