Most common approach towards any verification is to partition the design in to blocks and testing them individually. There are certainly quite a few loopholes, which doesn’t come into account while considering Block level (or Unit level) testing but requires early attention while initiating System-Level verification. Language should support this to implement and identify. With the help of System Verilog, we can efficiently achieve all these using following attributes
- Reuseability
- Debugging
- Coverage achievement
- Randomization
- Assertions
Applying Coverage Based Verification
Coverage goals are never static..!! They are dynamic. Hence, steps to define “Coverage goal, Metrics and Coverage model” in System Verilog are very important…!! Here are those,
- Define coverage type –Code coverage, Functional coverage
- Define different coverage data to be collected
- Define coverage metrics with weighted, combined/Cross-coverage
- Define coverage model. It is a subset of stimulus/result which increases confidence
Let us see following SoC .it is a network back-plane processing unit (SoC) where a Host-CPU is instruction set configurable and it is interfaced with PCI backplane. Host-CPU and Back-plane controller has it own firmware, which necessitates software coverage. Also multiple protocols such, as PCI ,SONET and DMA controller specific interface require bus and packet specific transactions and their coverage. In-addition to that system coverage must include IO-memory mapping, Interrupt routine vector matching with actual physical addresses in memory, packet loss, packet received and packet types coverage too.
Example: Coverage Driven Verification
Following code describes coverage model for Ethernet packet in order to cover whole frame.
covergroup frame_coverage @ (posedge clk);
option.weight = 100;
option.goal = 90;
option.at_least = 1;
option.auto_bin_max = 2;
c_reset : coverpoint reset;
c_preamble : coverpoint preamble;
c_sfd: coverpoint sfd;
c_dest_addr: coverpoint dest_addr;
c_src_addr: coverpoint src addr;
c_payload : coverpoint payload;
cross src_addr, dest_addr ;
endgroup
);
Defining coverage for other protocols like SONET, DMA descriptors and PCI transactions will make overall coverage model to be dynamic for full functionality.
Achieving Coverage through Test bench Automation and Randomization
Constraint driven test generation allows users to automatically generate tests for functional verification. Random testing will be more effective than traditional, directed testing approach. By specifying constraints , one can easily create tests that find hard-to-reach corner cases and coverage. System Verilog allows users to specify constraints (random, semi-random) in a compact and declairative way. This eventually enhances the coverage model goal achieving.
By default, all variables and class are not random. You need to define them randomize. We can start defining Ethernet payload, src_address etc. to be random.
typedef struct {
int preamble;
rand int src_address;
int dest_address;
rand int Payload;
int sfd;
} ethernet_packet
Suppose you want to define variable which is not random to random, you can use randomize() method to do it run time along with constraining it’s value.
task test_method();
rand_dest_add = randomize(dest_address) with { dest_address < 0×1121 };
endtask;
Generally goal of the methodology is to obtain the maximum level of confidence in the quality of a design in a given time and engineering resources. To accomplish this goal, it uses assertions, functional abstraction, coverage, automation through randomization and reuse techniques all at the same time. The guidelines presented in the above sections are designed to implement a verification process using System Verilog that combines all of these techniques to maximum effect.
- Nilesh Ranpura
