English
Configuration-based Environment that Supports Scalable PHY Verification
By Thomas J. Sheffler, PhD., Rambus Inc
November 13, 2007 -- edadesignline.com
Leading-edge analog/mixed-signal design requires custom flows built with a variety of tools that use a multiplicity of design representations. When it is a centralized resource, a single verification team may be faced with overwhelming complexity when supporting multiple design teams, each with multiple tools and a variety of design representations. A verification environment engineered for configurability can provide the flexibility and scalability needed to manage this complexity.
A Configuration-based Verification Environment factors flows and configuration into separate objects. A flow is a template describing a series of tools to be applied to achieve a particular purpose. The flow is described in terms of an abstract project, with placeholders for design files, tools, commands, and other objects. A configuration describes the design files, flags affecting the interpretation of the design files, tools, their versions and shell command settings.
A configuration is a named object that is tracked and revision controlled. Its name is unique across the enterprise. With this capability a Configuration-based Verification Environment explicitly identifies a particular collection of design representations and the tools involved in an analysis. As configurability provides flexibility, it increases security, stability and reproducibility.
The configuration database is meta-information applied to the objects in the design database. Users in potentially distributed sites share design files and communicate the ways in which these files are used to perform a verification task by using a named configuration. Figure 1 shows the relationship of design data and configuration information. In the example shown three users have checked out separate workspaces at two sites, they are working together on one design. Two of the users are coordinating their attention on the mixed-signal representation while the third is focusing on RTL.
November 13, 2007 -- edadesignline.com
Leading-edge analog/mixed-signal design requires custom flows built with a variety of tools that use a multiplicity of design representations. When it is a centralized resource, a single verification team may be faced with overwhelming complexity when supporting multiple design teams, each with multiple tools and a variety of design representations. A verification environment engineered for configurability can provide the flexibility and scalability needed to manage this complexity.
A Configuration-based Verification Environment factors flows and configuration into separate objects. A flow is a template describing a series of tools to be applied to achieve a particular purpose. The flow is described in terms of an abstract project, with placeholders for design files, tools, commands, and other objects. A configuration describes the design files, flags affecting the interpretation of the design files, tools, their versions and shell command settings.
A configuration is a named object that is tracked and revision controlled. Its name is unique across the enterprise. With this capability a Configuration-based Verification Environment explicitly identifies a particular collection of design representations and the tools involved in an analysis. As configurability provides flexibility, it increases security, stability and reproducibility.
The configuration database is meta-information applied to the objects in the design database. Users in potentially distributed sites share design files and communicate the ways in which these files are used to perform a verification task by using a named configuration. Figure 1 shows the relationship of design data and configuration information. In the example shown three users have checked out separate workspaces at two sites, they are working together on one design. Two of the users are coordinating their attention on the mixed-signal representation while the third is focusing on RTL.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
|
||||||
Related Articles
- Scalable Verification Environment Using OCP Compliant Cores and eRM Compliant eVCs
- API-based verification: Effective reuse of verification environment components
- High bandwidth memory (HBM) PHY IP verification
- Solutions to Resolve Traditional PHY Verification Challenges
- An efficient way of loading data packets and checking data integrity of memories in SoC verification environment
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)