DIGITAL SYSTEM

DESIGN

LECTURE
NO. 7
VERIFICATION IN HARDWARE DESIGN (2.7)
Introduction to Verification
• Verilog is especially designed for hardware modeling and lacks features that facilitate
verification of complex digital designs. In these circumstances, designer’s resort to using
other tools like Vera or e for verification.
• In 2005, the IEEE standardized Verilog and System Verilog languages. Many advanced
features have been added in System Verilog. These relate to enhanced constructs for
design and test bench generation, assertion and direct programming interfaces (DPIs).
INTRODUCTION TO VERIFICATION (2.7.1)

• The EDA industry is trying to respond to increasing demands to elegantly handle chip design
migration from the IC scale to the multi core SoC scale.
• Verification is the greatest challenge, and for complex designs it is critical to plan for it right
from the start. A verification plan (Vplan) should be developed by studying the function
specification document.
• As SoC involves several standard interfaces, it is possible that verification test benches already
exist for many components of the design in the form of verification intellectual property (VIP).
• Good examples are the test benches developed for ARM, AMBA and PCI buses.
INTRODUCTION TO VERIFICATION (2.7.1)
• Simulators are very common in verifying an RTL design, but they are very slow in testing a
design with many million gates.
• In many design instances, after the design is verified for a subset of test cases that includes
the corner cases, more elaborate verification is performed using FPGA based accelerators.
Finally, the verification engineers also plan verification of the first batches of ICs.
• Many languages and tools have evolved for effective verification. Verilog, SystemVerilog, e
and SystemC are some of the most used for test bench implementation; usually a mix of
these tools is used.
APPROACHES TO TESTING A DIGITAL DESIGN (2.7.2)

Black-box Testing (2.7.2.1)

• This is testing against specifications when the internal structure of the
system is unknown.
• A set of inputs is applied, and the outputs are checked against the
specification or expected output, without considering the inner details of the
system.
• The design to be tested is usually called the ‘device under test’ (DUT).
WHITE-BOX TESTING (2.7.2.2)
• This tests against specifications while making use of the known internal structure of the system.
• It enables the developer to locate a bug for quick fixing. Usually this type of testing is done by the
developer of the module.
ANY QUESTION