Design Review Process Ver 0. 2 Proprietary Information Dissemination, disclosure, or use of this information is not permitted without the written permission of the author Revision Notice Revi sion A Date 5/15/2006 Written By Venkat Vedam Initial release Comments Overview This document is intended to detail the document review process for RTL based designs done for ASIC based products. It will be enhanced over time to include additional features and concerns.
The purpose of the design review is to make sure that the module is designed to be free from defects, meet the intended requirements, have proper architecture and implementation methods used. This design review process is also intended to insure that other team members understand the operation of the design. The design review should be done at the AFE date of the module. Target Audience: • Architects. • Designers • Verification – unit and system • DFT Required participants: • Module/Submodule architect • Verification representative • Design manager • Senior designer • Implementation team – TE/Synth/Timing.
Designer Preparation: • The designer should have the following complete prior to the design review: Design o Must be checked into the repository. o At All Function Entered (AFE) with some level of unit testing complete. Engineering spec detailing following: (see engineering spec template for full list) o Requirements/features/functions of the module o Block diagram of the implementation o Reset requirements – types, control o Clocking requirements – types, restrictions, gating used, async domains o DFT requirements – Above ordinarily o Brief description of the I/Os of the modules. List of rams/roms used in module Customer spec (initial draft) detailing following o Registers and bit definitions Spyglass reports for resets and async domains Lint report detailing open lint warnings and errors. • • • • • Completed RTL review checklist. (appendix A) Reviewer Preparation: • • Review the engineering spec, develop list of questions Review the RTL, amount of comments, flow, design style, etc. Design Review: The design review should be held by the design after giving the invited reviewed 2-3 days notice to read the engineering specification.
This should be done via NetMeeting or equivalent with teleconference for remote sites. A separate person should track action items and issues resulting from the review. These must be documented and resolved via the CR system (Can be collected into on large CR). The proposed agenda for this is as follows: • Overview o Presentation of module, where this fits into chip, overall function • Requirements of the module • Interface description – how does this communicate with the device. Review of block diagram • Review of reports – lint, spyglass • Open questions • Review of issues/actions Documentation • The results of the design review should be documented: o Include the list of reviewers o list of actions/issues o Results of checklist review in Appendix A o Lint and Spyglass reports. The action items should go into whatever system will guarantee resolution of these. The design manager should then decide if another review is warranted at a later time. • • Appendix A RTL Review Checklist (taken from SURF flow) Action
Presented architecture overview of the design Provided the block diagram of the design (Identify and list analog blocks here) Identified RTL language for all blocks of the design Identified directory and file structure of the design Provided design hierarchy and where files are located Identified IP blocks in the design Identified blocks that have critical timing requirements Identified blocks that have data path logic Identified external interfaces Reviewed the environment file (. projcshrc) for correct libraries and macros.
All members must use the common variables associated with each library. Produced Clocking Diagram Identified primary clock sources and their frequencies Identified generated clock sources and their frequencies Identified relationship of various clocks (synch, asynch, timing relationship between clocks etc) Provided information on asynch. clock domain crossing (Use SpyGlass, if necessary) Identified in the schematic all places where clock muxing occurs. Explain reason behind clock muxing No complex gates (aoi, oai etc. ) is being synthesized representing the mux in the clocking circuitry.
If yes, then recode the RTL and ensure that a MUX is inferred. Use //synopsys infer_mux, if necessary. Identified all test modes in the design e. g. , PLL bypass, Scan mode, Low power mode etc. Identified location of half cycles in the design Check Comments Coded Device ID. In case of ECO, incremented Device ID Design is passing all CNXT rules identified by SpyGlass (Document exceptions) Design does not contain any Latches. Document any “required” latches. Identified the need for implementing scan collar on IP blocks (e. g. , interfaces to analog or custom blocks) All models (. ib) used for Synthesis and STA are available. This includes . lib’s for analog and custom blocks. For testability reasons, is the design suitable for all bond options? If not RTL collar needs to be developed. Pad drive strengths and pullup/pulldowns should not be controlled directly by registers that are in scan chain. Gating should be done so that nominal drive strength is chosen. Pullup and pulldowns are disabled. For designs needing TestKompress. Top level design should incorporate TestKompress logic. Identify scan_mode and scan_enable signals.
If scan mode is internally generated, identify the exact sequence of generation. Scan clock is directly controllable from the IO pad Compute total number of flops in the design by running SpyGlass. This is useful for architecting scan chains (with or without TestKompress) Single scan clock for the entire design All memories have BIST logic implemented Background checks have been implemented correctly Notes: Appendix B – Signoff The Module has been review by the following people and has the following issues/action items: Responsible Engineer Date