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
- ReRAM NVM in DB HiTek 130nm BCD
- UFS 5.0 Host Controller IP
- PDM Receiver/PDM-to-PCM Converter
- Voltage and Temperature Sensor with integrated ADC - GlobalFoundries® 22FDX®
- 8MHz / 40MHz Pierce Oscillator - X-FAB XT018-0.18µm
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
- An FPGA-Based SoC Architecture with a RISC-V Controller for Energy-Efficient Temporal-Coding Spiking Neural Networks
- Enabling RISC-V Vector Code Generation in MLIR through Custom xDSL Lowerings
- A Scalable Open-Source QEC System with Sub-Microsecond Decoding-Feedback Latency
- SNAP-V: A RISC-V SoC with Configurable Neuromorphic Acceleration for Small-Scale Spiking Neural Networks
- An FPGA Implementation of Displacement Vector Search for Intra Pattern Copy in JPEG XS