verification coding style

1)Fork --- join
module inline_tb;
//declare variables
//instantiate designs
initial begin
initialize_design;
fork
monitor_data;
monitor_error;
monitor_timeout;
run_test;
join
end
endmodule
Note: fork-join can be implemented in the begin-end block.
2 Stimulus From Loops

initial begin
for (i = 0;i <= 255;i=i + 1）
@(negedge clk) stimulus = i;
#20 $finish;
end
3 readmemb & readmemh
TestBench作相应的定义：
Reg [7:0] A, B;
Reg Start;
……
Reg [33:0] Vector, Test_Vector[0:Test_Length];
…….
$readmemb(“Test_Fixed.v”, Test_Vector);
……
For (I=0; I 按一定时序将Test_Vector[I]送入Vector并送入A、B、Start；

(fwd)Use SystemVerilog for coverage metrics

SystemVerilog constructs suit RTL design, high-level modeling, testbench creation, and assertion specification.

Thomas L Anderson, Cadence Design Systems, San Jose, CA; Edited by Charles H Small and Brad Thompson -- EDN, 3/29/2007

The design-and-verification industry is at the intersection of two important trends in the design and verification of SOC (system-on-chip) devices: the adoption of SystemVerilog HDVL (hardware-description and -verification language) and the increasingly critical role for coverage metrics. The interest in System Verilog is understandable; this IEEE-standard language has the features for RTL (register-transfer-level) design, high-level modeling, testbench creation, and assertion specification (Reference 1).

SystemVerilog also provides constructs for design-and-verification engineers to specify functional coverage points—conditions that designers must exercise for complete verification of the design. Designers increasingly use functional coverage to supplement traditional code coverage. The primary driver for this evolution is the widespread use of constrained-random-stimulus generation.

Traditional verification plans typically include a list of design features or tests that verify features and test status. This approach has worked well with handwritten, directed tests because of the clear correspondence between features and tests. However, verification consists of writing and running each test in simulation, perhaps after turning on some code coverage to help identify features you may have missed in the plan.

Constrained-random-stimulus generation requires a different approach, in which each automatically generated test can exercise many features and parts of the design. A modern verification plan lists features, functional coverage points for the features, and coverage status. You gauge verification closure by the number of coverage points you exercise rather than the number of tests you complete.

SystemVerilog provides all the features necessary to develop both handwritten tests and constrained-random testbenches and to track progress toward closure. Most simulators have built-in code coverage for the new design constructs that SystemVerilog introduces. Thus, code-coverage metrics are available for designs taking advantage of the language's advanced RTL features.

SystemVerilog provides several powerful specification methods for functional coverage. The first is cover property, which is part of the SVA (SystemVerilog Assertions) subset of the language. SVA's assertion features, including temporal sequences, are also available for functional coverage. For example, Listing 1 ensures that the simulator exercises the two extremes—one and five cycles—of a request-acknowledge handshake. Both simulators and many formal-analysis tools support the cover-property construct. If formal analysis can prove that a coverage point is unreachable, a design bug may be blocking important functions from being exercised. If formal analysis instead provides a trace showing how to reach a coverage point, this trace can provide a good hint on how to write or generate a test.

Beyond individual coverage properties, you sometimes must track ranges of values. SystemVerilog provides the cover-group construct, which is not part of SVA, to perform this function. For example, Listing 2 tracks the payload sizes of incoming packets on a network interface and ensures the coverage of corner cases of empty, minimum, and maximum payloads. SystemVerilog also provides the cross construct to measure cross-coverage between two coverage points. This feature allows the tracking of combinations of coverage metrics. For example, Listing 3 specifies an enumerated type for four packet classes for the network interface, adds a cover point to track the packet classes, and crosses the packet types with the payload sizes.

Ultimately, the SOC-tapeout decision must take into account all coverage metrics. Although functional coverage is the primary method, code coverage has value as a backup to identify areas of the design with no functional coverage due to an incomplete verification plan. The project team needs to merge together code- and functional-coverage results to assess verification progress and help determine verification closure. Coverage is critical for modern, constrained-random verification. Without effective metrics, no reliable way exists to gauge status and manage progress. In addition to its other features and benefits, SystemVerilog provides support for functional coverage. By including coverage in the verification plan from the start of the project and taking advantage of SystemVerilog, the SOC team can employ a complete plan-to-closure methodology that greatly increases the chances for a successful product.

Good news and a Paradise for verification engineer:Open Verification Methodology(OVM)

How is it Open?

The OVM is available as a download by anyone, under the Apache 2.0 license. This standard, open license allows anyone to use OVM libraries for any purpose, including creation of derivative work.

Who created OVM?

The OVM is the result of joint development between Cadence and Mentor Graphics to facilitate true SystemVerilog interoperability with a standard library and a proven methodology. Completely open, it combines the best of the Cadence® Incisive® Plan-to-Closure Universal Reuse Methodology (URM) and the Mentor Advanced Verification Methodology (AVM), and is usable on two-thirds of the world's SystemVerilog simulators. The OVM will also facilitate the development and usage of plug-and-play verification IP (VIP) written in SystemVerilog (IEEE 1800), SystemC® (IEEE 1666), and e (IEEE 1647) languages.

When is it available?

The OVM is available for download from this site as of January 9. 2008. Join OVM World (http://www.ovmworld.org)today to get regular updates on the OVM.

Background

Despite the availability of the IEEE 1800 SystemVerilog standard, the benefits of an open verification language have not yet been realized. The availability of multiple class libraries and methodologies have hurt the ability for true interoperability.

• Multiple class-libraries restricted interoperability
• Different language subsets
• Incompatible VIP interfaces
• Linked to just one simulator

• Multiple methodologies restricted reuse
• Prohibitive licensing limited multi-vendor support
• Incomplete and incompatible technology restricted VIP plug & play (e.g. communication, messaging and synchronization, test-writer I/F, etc.)
• Different availability of underlying SystemVerilog language constructs prevented interoperability
• Different set of language constructs implemented in each simulator
• Different evaluation of those language constructs that were aligned

Cadence and Mentor Graphics have collaborated to address these issues and to deliver an open and interoperable class library and methodology, the OVM, which delivers on the SystemVerilog promise.

Key Benefits

• Open
• Written in IEEE 1800 SystemVerilog
• Runs on any simulator supporting the IEEE 1800 standard
• Verified on Cadence’s Incisive and Mentor Graphics’ Questa Verification Platform
• True open-source license agreement (Apache 2.0)

• Interoperable
• Ensures VIP interoperability across ecosystem & simulators
• Enables VIP ‘plug and play’ functionality for designers
• Ensures interoperability with other high level languages

• Proven
• Based on Cadence’s Incisive Plan-to-Closure Methodology - URM Component and Mentor’s Advanced Verification Methodology (AVM)
• Incorporates Best Practices from >10 years of experiences

Verification of ASIC

Verification challeges :

Biggest challenge in IC design is verification because the cost of single error is huge. Verification is both time consuming and requires large amount of resources. Types of verification tasks can be classified into two categories :

1. functional verification : check the functionality of synthesised and optimized design against golden representation of design.
2. implementation verification : Once placement and routing is over. The design is checked for functional correctness once again. Timing and power constraints are also verified.

Black box verification methods include Simulation, and Emulation and hardware accelaration.

White box verification methods involve use of formal methods for example Assertion based Verification

Assertion Based Verification

Assertion based verification is aimed at Digital Designers. ABV is a white-box verification technique. Unlike Simulation it is not applied on the block level once the design is complete. Assertion based verification can be applied alongside design process. In-fact assertion based verification entities reside in the HDL description of the design.

Assertions are active comments embedded with in the design. Assertions turn design specification into verification objects. Assertions can be used to :

• monitor signals on interfaces that connect different blocks
• track expected behaviour of a gate, flip-flop or module
• watch for fobidden behaviour with-in a design block

Assertions are used to capture funcational specifications and assumptions of the design. An example below captures some possible assertions that can be embedded in the HDL description of the design. Since assertions travel with IP, they can be reused. Some examples of assertions are as follows :

• Invariants : To check condition like inputs A and B should never be both high.
• Sequences : If a signal A is high in one cycle then signal B should be high in next clock cycle and C must be high in next cycle.
• Eventualities : all requests have to be granted eventually. This assertion can be captured by using eventuality.

Advantages of Assertion based design :

1. Improves quality of design: assertions are "specifications" that are embedded into the design. This captures the designers intent and assumptions more closely. This also helps to define the protocol that should exist at the interface between various modules.
2. Accelerates Debugging: During its entire life cycle design can be continously checked for assertions. Assertions allows designer to check whether or not design and its environment implement interface correctly. Internal signals can be monitored to ensure that the design operates correctly.
3. IP integration is faster: IP interface with other sections of design may have problems which are easily identified by assertions. Assertions embedded in IP can identify errors in IP.

Languages Used to define assertions :

• Implicit assertions are supported by HDLs like Verilog and VHDL. These assertions are added at the time of design analysis, synthesis and HDL analysis.
• Explicit assertions are user defined assertions. Such assertions are provided by EDA vendors in form of Library like OVL. Academic languages loke CTL, LTL and automata provide a way to define explicit assertions.

Emulation and Hardware Acceleration

Emulator is a hardware device that can be used to emulate a piece of hardware functionality. It is commonly used as a debugging tool to test a system under development for functional correctness..

Emulation is a faster solution to verification problem. In Emulation a portion of emulatable design is synthesised and optimized. The compiled design is then loaded onto an emulator. Rest of the design is simulated by the workstations that are connected to the Emulator. Remember only the portion of the design that is being tested resides on the Emulator. Emulators are able to provide execution speed close to real time. This allows verification engineers to reduce verification time.

Emulation system typically consists of small number of large FPGAs. This provides multi-million ASIC-equivalent gate capacity. Such an emulation system comes as a seperate box. Emulation box can be connected to a collection of workstations using PCI card. The workstations are connected via emulation network architecture.

A complex IC is typically divided into number of different modules. Each module is develeped by a seperate team of designers. Each team verifies the functionality of its own module. The modules then go to an integration team which integrates all the modules and caries out verification. With emulation providing faster methods of design verification last minute changes can be incorporated in the design. This significantly reduces time to market.