Design Article
Tell us What You Think
We want to know what you thought about this Design. Let us know by adding a comment.
Design Reuse without Verification Reuse Is Useless
Adnan Hamid, Breker Verification Systems
11/26/2012 10:32 AM EST
Verification IP
Verification 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.
Ideally, 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.
The 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
The 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 increases.
Figure 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.
At 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:
All have problems that will be discussed briefly in the following sections.
Next: Removing the Processors
Verification 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.
Ideally, 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.
The 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
The 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 increases.
Figure 1: UVM Verification Component Configuration
Figure 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
At 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.
Next: Removing the Processors
|
|
|
|
|
Navigate to related information