IP (VIP) reuse is an important issue for EDA vendors and users alike.
They defined a series of methodologies, most recently the UVM standard,
to ensure VIP compatibility and extendibility and to attempt to maximize
the effectiveness of constrained-random test generation.
VIP should be reusable from the IP block level all the way to the
full-SoC or system level, providing plug-and-play so that multiple VIP
models work together. VIP must also provide coverage metrics so that the
verification team has a way to measure verification closure. This
coverage must be integrated into the IP or SoC verification plan.
primary form of commercial VIP is protocol VIP, specifically designed
to ensure that a design is adhering to a defined interface or bus
protocol. This type of VIP is generally available for all standard bus
protocols as well as for other communications protocols such as USB and
SATA. These provide protocol checking and usually have coverage models
and a set of sequences defined for them. They can be used by a
constrained-random generator to verify an IP block standalone and, at
least in theory, synchronize and coordinate activities on the periphery
of the SoC.
The UVM Approach
adoption of SystemVerilog and methodologies such as the UVM has enabled
human time and effort to be replaced by compute power for block-level
verification. As block size has grown, these systems have adapted to
overcome the inherent limitations of the constrained-random generation
process. However, a fundamental limitation still exists because the
process becomes less efficient as the sequential depth of the system
Figure 1: UVM Verification Component Configuration
1 shows a typical UVM verification component (UVC), a form of VIP
defined by the UVM standard. Constrained-random test generation
limitations are partially overcome by the creation of sequences that
allow snippets of functionality to be defined while still allowing some
degree of randomization. As shown in Figure 2, when several blocks are
integrated together, virtual sequences are used to create higher-level
sequences. These virtual sequences call on capabilities of lower-level
sequences or virtual sequences.
Figure 2: Integration of Multiple UVCs
each level of integration, a new set of virtual sequences has to be
created that combine lower-level sequences. If a new IP block is added
at the same level of the hierarchy, the virtual sequencer may have to be
modified or rewritten. This bottom-up methodology is problematic
because it does not necessarily drive the system verification task in
the same direction as required by the desired system-level
functionality. Many SoC teams have had difficulty using the UVM at the
system level and getting the levels of reuse that they desire in the
verification IP hierarchy.
The problems start when larger blocks
of IP and platforms are considered because many of them contain
processors. Constrained-random test generation was designed for
block-level verification and not system-level verification. As soon as
the system contains one or more processors, the verification team has a
choice to make:
- Remove the embedded processors and drive transactions onto the bus
- Run the production software on the embedded processors or
- Write custom software that will exercise the system
All have problems that will be discussed briefly in the following sections.