Featured post

Top 5 books to refer for a VHDL beginner

VHDL (VHSIC-HDL, Very High-Speed Integrated Circuit Hardware Description Language) is a hardware description language used in electronic des...

Showing posts with label Systemverilog Coverage. Show all posts
Showing posts with label Systemverilog Coverage. Show all posts

Monday, 25 March 2013

Use SystemVerilog for coverage metrics

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).

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,

MiniMuM and MaxiMuM response
minimum_response: cover property (@(posedge clk)
(req ##1 ack ));
maximum_response: cover property (@(posedge clk)
(req ##5 ack ));

Above example 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,

PayLoad sizes of incoming Packets
minimum_response: cover property (@(posedge clk)
(req ##1 ack ));
maximum_response: cover property (@(posedge clk)
(req ##5 ack ));
covergroup payloads_seen (@(packet_received);
coverpoint payload_size {
bins empty = { 0 };
bins minimum = { 1 };
bins maximum= { 1023 };
bins others = default; }
endgroup : payloads_seen

Above example 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,

EnumEratEd typE for four packEt cLassEs

enum { read, write, atomic, ctrl } packet_class;
covergroup packets_seen (@(packet_received);
coverpoint payload_size {
bins empty = { 0 };
bins minimum = { 1 };
bins maximum= { 1023 };
bins others = default; }
coverpoint packet_class;
cross payload_size, packet_class;
endgroup : packets_seen

Above example 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.

Wednesday, 19 December 2012

Functional Coverage Options features

Dear Readers,

Functional Coverage is very important in Test Bench Design. It gives us a confidence on covered items listed on verification plan/items. Usually the goal of verification engineer is to ensure that the design behaves correctly in its real environment.

Here I would like to share some of the important feature of System Verilog Functional Coverage which helps engineer during verification activity.

Coverage Options available in System Verilog through which you can specify additional information in the cover group using provided options

1. Cover Group Comment - 'option.comment'
You can add a comment in to coverage report to make them easier while analysing:

covergroup
CoverComment ;
option.comment = "Register Definition section 1.1";
coverpoint reg;
endgroup

In example, you could see the usage of 'option.comment' feature. This way you can make the coverage group easier for the analysis.

2. Per Instance Coverage - 'option.per_instance'

In your test bench, you might have instantiated coverage group multiple times. By default System Verilog collects all the coverage data from all the instances. You might have more than one generator and they might generate different streams of transaction. In this case you may want to see separate reports. Using this option you can keep track of coverage for each 88instance.

covergroup
CoverPerInstance ;
coverpoint tr.byte_cnt;
option.per_instance = 1;
endgroup

3. Threshold using - 'option.at_least'
This feature is useful when you don't have sufficient visibility in to the design to gather robust coverage. There might be the cases where you just have an information of number of cycles that are needed for the transfers to cover required errors to get generated/simulated for defined cover point. Here you could set the option.at_leaset. For example if we know that we need 10 cycles to cover this particular cover point, you could define option.at_leaset = 10.

4. Control on Empty bins - option.cross_num_print_missing = 1000

System verilog coverage report by default shows only the bins with samples. But usually as a verification engineer our job is to verify all cover point that are listed in verification plan.

covergroup
CoverCrossNumPrintMissing ;
ByteCnt : coverpoint tr.byte_cnt;
Length : coverpoint tr.length;
option.cross_num_print_missing = 1000;
endgroup

5. Coverage Goal - option.goal
In system verilog, coverage goal for a cover group or point is the level at which the group or point is considered fully covered.

covergroup
CoverGoal ;
coverpoint tr.length;
option.goal = 80;
endgroup

These are the few important coverage option features which are very useful in defining/coding System Verilog Functional Coverage.

Get free daily email updates!

Follow us!