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.
To read the full article, click here
Related Semiconductor IP
- JESD204E Controller IP
- eUSB2V2.0 Controller + PHY IP
- I/O Library with LVDS in SkyWater 90nm
- 50G PON LDPC Encoder/Decoder
- UALink Controller
Related Articles
- Solutions to Resolve Traditional PHY Verification Challenges
- High bandwidth memory (HBM) PHY IP verification
- Testing the HyperTransport PHY core
- Testable SoCs : Testing the HyperTransport PHY core
Latest Articles
- Crypto-RV: High-Efficiency FPGA-Based RISC-V Cryptographic Co-Processor for IoT Security
- In-Pipeline Integration of Digital In-Memory-Computing into RISC-V Vector Architecture to Accelerate Deep Learning
- QMC: Efficient SLM Edge Inference via Outlier-Aware Quantization and Emergent Memories Co-Design
- ChipBench: A Next-Step Benchmark for Evaluating LLM Performance in AI-Aided Chip Design
- COVERT: Trojan Detection in COTS Hardware via Statistical Activation of Microarchitectural Events