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
- HBM4 PHY IP
- Ultra-Low-Power LPDDR3/LPDDR2/DDR3L Combo Subsystem
- MIPI D-PHY and FPD-Link (LVDS) Combinational Transmitter for TSMC 22nm ULP
- HBM4 Controller IP
- IPSEC AES-256-GCM (Standalone IPsec)
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
- ElfCore: A 28nm Neural Processor Enabling Dynamic Structured Sparse Training and Online Self-Supervised Learning with Activity-Dependent Weight Update
- A 14ns-Latency 9Gb/s 0.44mm² 62pJ/b Short-Blocklength LDPC Decoder ASIC in 22FDX
- Pipeline Stage Resolved Timing Characterization of FPGA and ASIC Implementations of a RISC V Processor
- Lyra: A Hardware-Accelerated RISC-V Verification Framework with Generative Model-Based Processor Fuzzing
- Leveraging FPGAs for Homomorphic Matrix-Vector Multiplication in Oblivious Message Retrieval