FPGA Design: Best Practices for Team-based Design 2010 edition

Marc Notes: Includes bibliographical references and index. Jacket Description/Back: FPGA Design: Best Practices for Team-based Design Philip Simpson Many Companies struggle with establishing a working FPGA design methodology across design teams in their Company. As design teams become more dispersed globally, the need increases for a standard design methodology. This book describes best practices for successful FPGA design. It is the result of the author s meetings with hundreds of customers on the challenges facing each of their FPGA design teams. By gaining an understanding into their design environments, processes, what works and what does not work, key areas of concern in implementing system designs have been identified and a recommended design methodology to overcome these challenges has been developed. This book s content has a strong focus on design teams that are spread across sites. The goal being to increase the productivity of FPGA design teams by establishing a common methodology across design teams; enabling the exchange of design blocks across teams. Coverage includes the complete FPGA design flow, from the basics to advanced techniques. Presents complete, field-tested methodology for FPGA design, focused on design reuse across design teams; Offers best practices for FPGA timing closure, in-system debug, and board design; Details techniques to resolve common pitfalls in designing with FPGAs."Biographical Note: Phil Simpson is Altera s senior manager for software technical marketing and product planning. In this role, Simpson is responsible for Altera s Quartus II software and third-party EDA interfaces product planning and the creation of the Altera design flow software roadmap. Prior to joining Altera in 1996, Simpson held several engineering roles at various EDA and semiconductor companies, including EDA Solutions, Data I/O and Lucas Aerospace. Simpson holds a BS (with honors) in Electrical & Electronic Engineering from City University, London and an MSC (with distinction) in system design from the University of Central England, Birmingham, England."Table of Contents: 1. Best Practices for Successful FPGA Design -- 1.1. Introduction -- 2. Project Management -- 2.1. The Role of Project Management -- 2.1.1. Project Management Phases -- 2.1.2. Estimating a Project Duration -- 2.1.3. Schedule -- 3. Design Specification -- 3.1. Design Specification: Communication Is Key to Success -- 3.1.1. High Level Functional Specification -- 3.1.2. Functional Design Specification -- 4. Resource Scoping -- 4.1. Introduction -- 4.2. Engineering Resources -- 4.3. Third Party IP -- 4.4. Device Selection -- 4.4.1. Silicon Specially Features -- 4.4.2. Density -- 4.4.3. Speed Requirements -- 4.4.4. Pin-Out -- 4.4.5. Power -- 4.4.6. Availability of IP -- 4.4.7. Availability of Silicon -- 4.4.8. Summary -- 5. Design Environment -- 5.1. Introduction -- 5.2. Scripting Environment -- 5.3. Interaction with Version Control Software -- 5.4. Use of a Problem Tracking System -- 5.5. A Regression Test System -- 5.6. When to Upgrade the Versions of the FPGA Design Tools -- 5.7. Common Tools in the FPGA Design Environment -- 6. Board Design -- 6.1. Challenges that FPGAs Create for Board Design -- 6.2. Engineering Roles and Responsibilities -- 6.2.1. FPGA Engineers -- 6.2.2. PCB Design Engineer -- 6.2.3. Signal Integrity Engineer -- 6.3. Power and Thermal Considerations -- 6.3.1. Filtering Power Supply Noise -- 6.3.2. Power Distribution -- 6.4. Signal Integrity -- 6.4.1. Types of Signal Integrity Problems -- 6.4.2. Electromagnetic Interference -- 6.5. Design Flows for Creating the FPGA Pinout -- 6.5.1. User Flow 1: FPGA Designer Driven -- 6.5.2. User Flow 2 -- 6.5.3. How Do FPGA and Board Engineers Communicate Pin Changes? -- 6.6. Board Design Check List for a Successful FPGA Pin-Out -- 7. Power and Thermal Analysis -- 7.1. Introduction -- 7.2. Power Basics -- 7.2.1. Static Power -- 7.2.2. Dynamic Power -- 7.2.3. I/O power -- 7.2.4. Inrush Current -- 7.2.5. Configuration Power -- 7.3. Key Factors in Accurate Power Estimation -- 7.3.1. Accurate Power Models of the FPGA Circuitry -- 7.3.2. Accurate Toggle Rate Data on Each Signal -- 7.3.3. Accurate Operating Conditions -- 7.3.4. Resource Utilization -- 7.4. Power Estimation Early in the Design Cycle (Power Supply Planning) -- 7.5. Simulation Based Power Estimation (Design Power Verification) -- 7.5.1. Partial Simulations -- 7.6. Best Practices for Power Estimation -- 8. RTL Design -- 8.1. Introduction -- 8.2. Common Terms and Terminology -- 8.3. Recommendations for Engineers with an ASIC Design Background -- 8.4. Recommended FPGA Design Guidelines -- 8.4.1. Synchronous Versus Asynchronous -- 8.4.2. Global Signals -- 8.4.3. Dedicated Hardware Blocks -- 8.4.4. Use of Low-Level Design Primitives -- 8.4.5. Managing Metastability -- 8.5. Writing Effective HDL -- 8.5.1. What's the Best Language -- 8.5.2. Good Design Practices -- 8.5.3. HDL for Synthesis -- 8.6. Analyzing the RTL Design -- 8.6.1. Synthesis Reports -- 8.6.2. Messages -- 8.6.3. Block Diagram View -- 8.7. Recommended Best Practices for RTL Design -- 9. IP and Design Reuse -- 9.1. Introduction -- 9.2. The Need for IP Reuse -- 9.2.1. Benefits of IP Reuse -- 9.2.2. Challenges in Developing a Design Reuse Methodology -- 9.3. Make Versus Buy -- 9.4. Architecting Reusable IP -- 9.4.1. Specification -- 9.4.2. Implementation Methods -- 9.4.3. Use of Standard Interfaces -- 9.5. Packaging of IP -- 9.5.1. Documentation -- 9.5.2. User Interface -- 9.5.3. Compatibility with System Integration Tools -- 9.5.4. IP Security -- 9.6. IP Reuse Checklist -- 10. The Hardware to Software Interface -- 10.1. Software Interface -- 10.2. Definition of Register Address Map -- 10.3. Use of the Register Address Map -- 10.3.1. IP Selection -- 10.3.2. Software Engineers Interface -- 10.3.3. RTL Engineers Interface -- 10.3.4. Verification Interface -- 10.3.5. Documentation -- 10.4. Summary -- 11. Functional Verification -- 11.1. Introduction -- 11.2. Challenges of Functional Verification -- 11.3. Glossary of Verification Concepts -- 11.4. RTL Versus Gate Level Simulation -- 11.5. Verification Methodology -- 11.6. Attack Complexity -- 11.6.1. Modularize Your Design and Your Tests -- 11.6.2. Plan for Expected Operation -- 11.6.3. Plan for the Unexpected -- 11.7. Functional Coverage -- 11.7.1. Directed Testing -- 11.7.2. Random Dynamic Simulation -- 11.7.3. Constrained Random Tests -- 11.7.4. Use of System Verilog for Design and Verification -- 11.7.5. General Testbench Methods -- 11.7.6. Self Verifying Testbenches -- 11.7.7. Formal Equivalency Checking -- 11.8. Code Coverage -- 11.9. QA Testing -- 11.9.1. Functional Regression Testing -- 11.9.2. GUI Testing for Reusable IP -- 11.10. Hardware Interoperability Tests -- 11.11. Hardware/Software Co-Verification -- 11.11.1. Getting to Silicon Fast -- 11.12. Functional Verification Checklist -- 12. Timing Closure -- 12.1. Timing Closure Challenges -- 12.2. The Importance of Timing Assignments and Timing Analysis -- 12.2.1. Background -- 12.2.2. Basics of Timing Analysis -- 12.3. A Methodology for Successful Timing Closure -- 12.3.1. Family and Device Assignments -- 12.3.2. Design Planning -- 12.3.3. Early Timing Estimation -- 12.3.4. CAD Tool Settings -- 12.4. Common Timing Closure Issues -- 12.4.1. Missing Timing Constraints -- 12.4.2. Conflicting Timing Constraints -- 12.4.3. High Fan-Out Registers -- 12.4.4. Missing Timing by a Small Margin -- 12.4.5. Restrictive Location Constraints -- 12.4.6. Long Compile Times -- 12.5. Design Planning, Implementation, Optimization and Timing Closure Checklist -- 13. In-System Debug -- 13.1. In-System Debug Challenges -- 13.2. Planning -- 13.3. Techniques -- 13.3.1. Use of Pins for Debug -- 13.3.2. Internal Logic Analyzer -- 13.3.3. Use of Debug Logic -- 13.3.4. External Logic Analyzer -- 13.3.5. Editing Memory Contents -- 13.3.6. Use of a Soft Processor for Debug -- 13.4. Use Scenarios -- 13.4.1. Power-Up Debug -- 13.4.2. Debug of Transceiver Interfaces -- 13.4.3. Reporting of System Performance -- 13.4.4. Debug of Soft Processors -- 13.4.5. Device Programming Issues -- 13.5. In-System Debug Checklist -- 14. Design Sign-Off -- 14.1. Sign-Off Process -- 14.2. After Sign-Off -- Bibliography -- Index. Publisher Marketing: In August of 2006, an engineering VP from one of Altera s customers approached Misha Burich, VP of Engineering at Altera, asking for help in reliably being able to predict the cost, schedule and quality of system designs reliant on FPGA designs. At this time, I was responsible for defining the design flow requirements for the Altera design software and was tasked with investigating this further. As I worked with the customer to understand what worked and what did not work reliably in their FPGA design process, I noted that this problem was not unique to this one customer. The characteristics of the problem are shared by many Corporations that implement designs in FPGAs. The Corporation has many design teams at different locations and the success of the FPGA projects vary between the teams. There is a wide range of design experience across the teams. There is no working process for sharing design blocks between engineering teams. As I analyzed the data that I had received from hundreds of customer visits in the past, I noticed that design reuse among engineering teams was a challenge. I also noticed that many of the design teams at the same Companies and even within the same design team used different design methodologies. Altera had recently solved this problem as part of its own FPGA design software and IP development process."

Contributor Bio:  Simpson, Philip Born in Jerusalem in 1939, Amos Oz is the author of numerous works of fiction and essays. His international awards include the Prix Femina, the Israel Prize, and the Frankfurt Peace Prize, and his books have been translated into more than thirty languages. He lives in Israel.