SoCs: Supporting Socketization -> Socketization process stocks design-reuse store
Socketization process stocks design-reuse store
By Mark Birnbaum, EE Times
January 3, 2000 (3:08 p.m. EST)
URL: http://www.eetimes.com/story/OEG20000103S0039
Socketization is the process that prepares a design block for reuse and turns it into a virtual component (VC). The design phase of the socketization process requires all the EDA models, and the design views needed by the hierarchy of design steps-from system-level models to polygon-level GDSII. The views required depend on whether the VC is hard, soft, firm or analog mixed signal. These design views need to comply with the Virtual Socket Interface Alliance (VSIA) standard, and should have enough additional initialization and constraint information to allow reproducible results. If the VC comes in different configurations or derivative implementations, each should be defined and described clearly, with explicit directions for setting up and initializing the configuration. System-level modeling and behavioral objects need to be included as described in a VSIA standard on system-level behavioral documentation, which is now being deve loped by the VSIA. Without system-level modeling, the system designer cannot model his system before implementation, resulting in potential rework and delays in time-to-market. If there are software virtual components as well as hardware, they must be equally well-socketized to be reusable. If the company decides on one or more protection schemes to protect or detect theft of its intellectual property (IP), then the socketization process needs to have steps to insert the watermarking, encryption or other method of protection. Socketization also requires a well-described test plan. In such a plan, the author describes how testing was done, what the results were and how to reproduce them. This is critical so the system-on-chip (SoC) designer can understand what can be tested, and how, and further explains how the device works. It is also essential so the system designer can plan the SoC tests, using the individual VC tests. Any guidelines or constraints for developing and speeding up the chip-m anufacturing tests should also be included. In addition, socketization requires a complete and modular testbench with tests to check the VC thoroughly, as a standalone block or for the embedded case. The testbench needs to include tests for all data and control inputs. All VC functions must be tested, with a range of data values from minimum to nominal to maximum. To ensure robustness, a check for legal/illegal data, error inputs, voltage and clock variations should also be included. To ensure the quality of the piece of silicon that contains the respective VC, the testbenches should contain not only the testing of the proper design functions but also the manufacturing testing. Since the VC is to be reused, it is important that the entire design be reproducible. Typically, this will not be needed in a standard single-use flow. This means that all final test and verification steps need to record the tool and revision, design files and revisions, test files and revisions, and results f iles and revisions. Any silicon and characterization data derived from those design files needs to be documented with the same correlated package. Socketization also requires a well-defined quality assurance process-all the way from a simple check that all the required data and documentation are present, through design guidelines and good practices, to the VC deliverables and robust testing of the VC. Paper trail If a paper trail is maintained, then an audit of the process is possible. That allows process improvement and improves the overall quality. Complete documentation should be kept on what the VC is, how it works, its functions and interfaces, the EDA tools and settings used, and test suites for the design and test of the VC. This is typically much more thorough and detailed than a normal single-use embedded block would need, because its functions and interfaces are known by the single-use designers. The VC performance claims should be specified with the standard catalog attributes so the VC can be accessed by an internal or external catalog or VC directory. To ensure reproducibility, a log should be kept of which verifications were done, the results, the tools and revisions used, initial conditions/assumptions, configuration data and so on. If the design has been silicon-proven, the specific process(es) should be documented and characterization data supplied. Overall, it is a large task to perform the socketization of an IP block to make it into a robust, readily integratable virtual component. Estimates of the extra time needed to design a block to be reusable (or to convert it) range from 2x to 7x the time to design a block for single use in a specific chip, without thought for reuse. The range of additional activities and the long list of documentation deliverables support those numbers. MARK BIRNBAUM IS A MEMBER OF THE VSIA EXECUTIVE STAFF AND IS DIRECTOR OF STRATEGIC TECHNOLOGY AT FUJITSU MICROELECTRONICS INC. (SAN JOSE, CALIF.).
Related Articles
- SoCs: Supporting Socketization -> Reuse goal : fast tapeouts
- SoCs: Supporting Socketization -> Ready, set, reuse: A socketization primer
- SoCs: Supporting Socketization -> Socketization gets to core of plug-and-play IP
- SoCs: Supporting Socketization -> Decouple core for proper integration
- SoCs: Supporting Socketization -> Methodology key to quality
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)
E-mail This Article | Printer-Friendly Page |