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
A Solution for Platform VIP
When using platform IP, or when an integrated subsystem or system contains one or more processors, it is important to ascertain the verification process objective. It is no longer to verify the implementation of blocks, but rather to verify that data can move through the system correctly with the expected latency and bandwidth. This requirement is not met by the UVM for systems that contain processors because there is no suitable VIP that exists at the block level to support the platform.
It is important that additional IP can easily be added to these platforms and the same demand should be placed on the VIP that goes along with it. This requirement is not well met by the UVM either since it requires rewriting virtual sequences. It would be ideal if the same model can be used as the verification plan and coverage model rather than having to write additional models for each. The current UVM methodology is cumbersome on both counts.
A solution exists that matches all VIP requirements and describes the flow of data through IP blocks based on possible outcomes. All possible outcomes for a block are described along with the manner in which that outcome can be created. When multiple blocks are connected together, more complex flows are created with one block establishing demands and other blocks providing the necessary data or conditions. Those blocks in turn establish demands. Thus, a cascade of demands and ways to meet those demands are created by the VIP for each IP block.
When a verification target (one of the outcomes) is specified, a solver finds a possible path through all of the blocks to achieve that outcome. A generator automatically writes the necessary C code to run on the embedded processors. The combined VIP is the set of all possible behaviors and becomes the coverage model as well as the source of both stimulus and result checking. The selection of outcomes becomes part of the verification plan. This form of VIP is a scenario model that can be built incrementally and, as additional scenarios are incorporated, more extensive tests can be generated, or more ways to achieve desired outcomes explored.
Figure 4 shows a commercial example of this approach, the TrekSoC EDA product [4] from Breker Verification Systems. TrekSoC reads in a hierarchy of graph-based scenario models that define all the possible outcomes for the SoC as well as the ways to achieve these outcomes. It then solves for paths through the SoC and automatically generated multi-threaded, self-verifying C test cases to run on multiple embedded processors. Since some of these test cases will send or receive data on the chip’s I/O ports, TrekSoC also coordinates the embedded processors with testbench BFMs, including standard UVCs.
Unlike UVM virtual sequences, scenario models are directly reusable at higher levels of hierarchy. In Figure 4, scenario models for the image processor, camera and SD card controller blocks are instantiated with no change in the SoC scenario model, a platform-based verification solution, with platform VIP as reusable as platform IP.
If VIP for a platform is provided via a scenario model, the addition of a new block creates new ways in which demands can be met or outcomes created. The integration of this new VIP does not require rewriting or extension of existing VIPs. The verification plan and coverage model is also cumulative. Finally, scenario model VIP is implementation independent, working equally well with a virtual platform or a register transfer level (RTL) implementation of the IP blocks and SoC.
Conclusions
In order to continue increasing the productivity associated with the design and verification of complex systems, reuse has to be made scalable and must have a similar impact on both design and verification. Additional functionality is being instantiated at the system level and constrained-random generation is failing to provide capabilities required to verify this functionality.
While platform design IP has increased the efficiency of the design process, VIP has failed to deliver similar gains. A new method of describing VIP, scenario models, is suitable for platform IP. It is reusable and extensible with built in notions of coverage and verification planning.
Without a migration to scenario models, the SoC development process will become even more constrained by the verification task.
References
[1] Universal Verification Methodology (UVM) 1.1 User’s Guide, Accellera, 2011.
[2] “ARM CTO asks: Are we getting value from verification?” by Brian Bailey, EDN, June 13, 2012. http://www.edn.com/design/integrated-circuit-design/4375333/ARM-CTO-asks--Are-we-getting-value-from-verification-
[3] Catch-22 by Joseph Heller, Simon & Schuster, 1961.
[4] “Verifying SoCs from the Inside Out” by Thomas L. Anderson, Chip Design, August 3, 2012. http://chipdesignmag.com/display.php?articleId=5153
About the author:
Adnan
Hamid is co-founder and CEO of Breker Verification Systems. Prior to
starting Breker in 2003, he worked at AMD as department manager of the
System Logic Division. Previously, he served as a member of the
consulting staff at AMD and Cadence Design Systems. Hamid graduated from
Princeton University with Bachelor of Science degrees in Electrical
Engineering and Computer Science and holds an MBA from the McCombs
School of Business at The University of Texas.
If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you).
When using platform IP, or when an integrated subsystem or system contains one or more processors, it is important to ascertain the verification process objective. It is no longer to verify the implementation of blocks, but rather to verify that data can move through the system correctly with the expected latency and bandwidth. This requirement is not met by the UVM for systems that contain processors because there is no suitable VIP that exists at the block level to support the platform.
It is important that additional IP can easily be added to these platforms and the same demand should be placed on the VIP that goes along with it. This requirement is not well met by the UVM either since it requires rewriting virtual sequences. It would be ideal if the same model can be used as the verification plan and coverage model rather than having to write additional models for each. The current UVM methodology is cumbersome on both counts.
A solution exists that matches all VIP requirements and describes the flow of data through IP blocks based on possible outcomes. All possible outcomes for a block are described along with the manner in which that outcome can be created. When multiple blocks are connected together, more complex flows are created with one block establishing demands and other blocks providing the necessary data or conditions. Those blocks in turn establish demands. Thus, a cascade of demands and ways to meet those demands are created by the VIP for each IP block.
When a verification target (one of the outcomes) is specified, a solver finds a possible path through all of the blocks to achieve that outcome. A generator automatically writes the necessary C code to run on the embedded processors. The combined VIP is the set of all possible behaviors and becomes the coverage model as well as the source of both stimulus and result checking. The selection of outcomes becomes part of the verification plan. This form of VIP is a scenario model that can be built incrementally and, as additional scenarios are incorporated, more extensive tests can be generated, or more ways to achieve desired outcomes explored.
Figure 4 shows a commercial example of this approach, the TrekSoC EDA product [4] from Breker Verification Systems. TrekSoC reads in a hierarchy of graph-based scenario models that define all the possible outcomes for the SoC as well as the ways to achieve these outcomes. It then solves for paths through the SoC and automatically generated multi-threaded, self-verifying C test cases to run on multiple embedded processors. Since some of these test cases will send or receive data on the chip’s I/O ports, TrekSoC also coordinates the embedded processors with testbench BFMs, including standard UVCs.
Figure 4: Automatic Generation of Self-Verifying Test Cases
Unlike UVM virtual sequences, scenario models are directly reusable at higher levels of hierarchy. In Figure 4, scenario models for the image processor, camera and SD card controller blocks are instantiated with no change in the SoC scenario model, a platform-based verification solution, with platform VIP as reusable as platform IP.
If VIP for a platform is provided via a scenario model, the addition of a new block creates new ways in which demands can be met or outcomes created. The integration of this new VIP does not require rewriting or extension of existing VIPs. The verification plan and coverage model is also cumulative. Finally, scenario model VIP is implementation independent, working equally well with a virtual platform or a register transfer level (RTL) implementation of the IP blocks and SoC.
Conclusions
In order to continue increasing the productivity associated with the design and verification of complex systems, reuse has to be made scalable and must have a similar impact on both design and verification. Additional functionality is being instantiated at the system level and constrained-random generation is failing to provide capabilities required to verify this functionality.
While platform design IP has increased the efficiency of the design process, VIP has failed to deliver similar gains. A new method of describing VIP, scenario models, is suitable for platform IP. It is reusable and extensible with built in notions of coverage and verification planning.
Without a migration to scenario models, the SoC development process will become even more constrained by the verification task.
References
[1] Universal Verification Methodology (UVM) 1.1 User’s Guide, Accellera, 2011.
[2] “ARM CTO asks: Are we getting value from verification?” by Brian Bailey, EDN, June 13, 2012. http://www.edn.com/design/integrated-circuit-design/4375333/ARM-CTO-asks--Are-we-getting-value-from-verification-
[3] Catch-22 by Joseph Heller, Simon & Schuster, 1961.
[4] “Verifying SoCs from the Inside Out” by Thomas L. Anderson, Chip Design, August 3, 2012. http://chipdesignmag.com/display.php?articleId=5153
About the author:
Adnan
Hamid is co-founder and CEO of Breker Verification Systems. Prior to
starting Breker in 2003, he worked at AMD as department manager of the
System Logic Division. Previously, he served as a member of the
consulting staff at AMD and Cadence Design Systems. Hamid graduated from
Princeton University with Bachelor of Science degrees in Electrical
Engineering and Computer Science and holds an MBA from the McCombs
School of Business at The University of Texas.If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you).
|
|
|
|
|
Navigate to related information