FPGA Design: Best Practices for Team-based Design 1441963383, 9781441963383

Citation preview

FPGA Design

5

Philip Simpson

FPGA Design Best Practices for Team-based Design

Philip Simpson Altera Corporation San Jose, CA 95134 USA [email protected]

ISBN 978-1-4419-6338-3 e-ISBN 978-1-4419-6339-0 DOI 10.1007/978-1-4419-6339-0 Springer New York Dordrecht Heidelberg London Library of Congress Control Number: 2010930598 © Springer Science+Business Media, LLC 2010 All rights reserved. This work may not be translated or copied in whole or in part without the written permission of the publisher (Springer Science+Business Media, LLC, 233 Spring Street, New York, NY 10013, USA), except for brief excerpts in connection with reviews or scholarly analysis. Use in connection with any form of information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed is forbidden. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. © 2010 Altera Corporation ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS & STRATIX are Reg. U.S. Pat & Tm. Off. and Altera marks in and outside the U.S. Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)

Preface

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. I worked with the top talent in Altera Engineering to develop a Best Practices Design methodology based upon Altera’s experience and the techniques used by many customers successfully in FPGA design. The resulting methodology was presented and implemented at the customer, with great success. Through the analysis of past customer data and feedback from customers over the last 3 years, it has become clear that this challenge exists broadly in the industry. The challenge is not specific to one specific FPGA vendor; it is an industry wide challenge. As such, I have tuned the Best practices FPGA design methodology over the last 3 years and deployed it at several customers with great success. This book captures the Best Practices FPGA design methodology and now makes it available to all design teams implementing system designs in FPGA devices. San Jose, CA

Philip Simpson v

5

Contents

1 Best Practices for Successful FPGA Design............................................. 1.1 Introduction.........................................................................................

1 1

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..................................................................................

5 5 5 6 6

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.............................................

9 9 9 10

4 Resource Scoping....................................................................................... 4.1 Introduction......................................................................................... 4.2 Engineering Resources........................................................................ 4.3 Third Party IP...................................................................................... 4.4 Device Selection................................................................................. 4.4.1 Silicon Specialty 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.................................................................................

15 15 15 16 16 17 18 19 19 20 20 20 21

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.....................................................

23 23 23 24 25 vii

viii

Contents

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.............................

26 26 27

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.................

29 29 30 30 31 32 33 33 33 34 34 35 36 36 38

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...................................................

41 41 42 42 42 42 43 43 43 44 44 45 46

40 40

46 47 50 50

Contents

  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...............................

ix

51 51 51 53 54 54 54 55 56 57 57 58 59 65 75 75 76 77 78

  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..........................................................................

80 82 83 83 83 85 86 87 87 88 89 90

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............................................

91 91 91 91 92 92

79 79 79 80

x

Contents

  10.3.3 RTL Engineers Interface...............................................   10.3.4 Verification Interface....................................................   10.3.5 Documentation..............................................................   10.4 Summary.......................................................................................

92 93 93 94

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...................................................

95 95 95 96 97 97 98 98 98 98 99 100 100 100 100 101 102 103 104 104 104 105 105 106 106 106

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....................................

107 107 108 108 109 115 115 116 121 122 129 130 130

Contents

xi

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...............................................................

130 131 131 131

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............................................................

133 133 134 134 134 135 138 139 139 140 140 140 141 141 142 143 144

132

14 Design Sign-Off........................................................................................ 145 14.1 Sign-Off Process............................................................................. 145 14.2 After Sign-Off................................................................................. 145 Bibliography..................................................................................................... 147 Index.................................................................................................................. 149

5

List of Figures

Fig. 1.1 Three steps to successful FPGA development................................ Fig. 1.2 Recommended best practices design methodology for successful FPGA design............................................................

2

Fig. 2.1 Percentage complete dilemma.........................................................

7

Fig. 3.1 Sample revision control page..........................................................

11

Fig. 6.1 Example .csv file that interfaces between board design SW and FPGA SW.......................................................................... Fig. 6.2 Design cycle diagram detailing engineering discipline involvement..................................................................... Fig. 6.3 FPGA designer driven flow for creating the FPGA pin-out............ Fig. 6.4 Board designer driven flow.............................................................

3

32 33 37 39

Fig. 7.1 Key elements in accurate power estimation.................................... Fig. 7.2 Graph of standby current versus temperature.................................. Fig. 7.3 Sample power estimation spreadsheet for the Altera Stratix IV GX family...................................................... Fig. 7.4 Probability of nodes toggling.......................................................... Fig. 7.5 Sample power estimation report from Quartus II PowerPlay Estimator...................................................... Fig. 7.6 Best practices for power estimation.................................................

49 50

Fig. 8.1 Fig. 8.2 Fig. 8.3 Fig. 8.4 Fig. 8.5 Fig. 8.6 Fig. 8.7 Fig. 8.8 Fig. 8.9

52 52 53 55 56 57 61 62 62

Behavioral modeling........................................................................ Structural modeling......................................................................... Synthesis.......................................................................................... Synchronizer for an asynchronous reset.......................................... Instantiation versus inferencing....................................................... Two-register synchronizer............................................................... Good design partitioning................................................................. Example bad and good partition...................................................... Sample code for dealing with tristates at partition boundaries........

43 45 47 49

xiii

xiv

  Fig. 8.10   Fig. 8.11   Fig. 8.12   Fig. 8.13   Fig. 8.14   Fig. 8.15   Fig. 8.16   Fig. 8.17   Fig. 8.18   Fig. 8.19   Fig. 8.20   Fig. 8.21   Fig. 8.22   Fig. 8.23   Fig. 8.24   Fig. 8.25   Fig. 8.26   Fig. 8.27   Fig. 8.28   Fig. 8.29   Fig. 9.1

List of Figures

Divide and conquer approach to RTL design.............................. Combine sub-blocks to create an optimized design block.......... Two-LUT levels between registers.............................................. Use of pipeline stages to break up routing delays....................... New data on simultaneous read/write.......................................... Coding style that will infer a RAM that returns the OLD data on a simultaneous read/write................................ Initialize the RAM contents to all 1 s.......................................... Inferencing of a ROM.................................................................. Finite state machine..................................................................... Use of enumerated types in VHDL for state machine inferencing.................................................................... Verilog FSM................................................................................ State machine encoding styles............................................................ Multiply-accumulate operation................................................... Verilog example of a register....................................................... Register in VHDL........................................................................ Synthesis priority of secondary control signals for registers...................................................................... Multiplexer tree........................................................................... N:1 multiplexer............................................................................ Quartus II RTL viewer................................................................. Quartus II state machine viewer..................................................

62 63 67 67 69 69 70 70 70 71 71 71 73 73 73 74 74 75 77 78

Example detailing the use of parameters in a Verilog source file........................................................................ Sample GUI for IP demonstrated by the Quartus II Component Editor......................................................

88

  Fig. 10.1 Sample from Header file generated by the Altera SOPC Builder tool............................................................

92

  Fig. 9.2

84

  Fig. 11.1   Fig. 11.2   Fig. 11.3   Fig. 11.4

Constrained random test flow...................................................... Simple testbench that requires manual checking......................... Example diagram of a self-checking testbench........................... Verification system architecture..................................................

101 102 103 103

  Fig. 12.1   Fig. 12.2   Fig. 12.3   Fig. 12.4   Fig. 12.5   Fig. 12.6   Fig. 12.7   Fig. 12.8

Launch and latch edge diagram................................................... tsu and th diagram....................................................................... Clock arrival and data arrival diagram......................................... Multi-cycle path........................................................................... Input delay................................................................................... Output delay................................................................................ Clock uncertainty......................................................................... Bottom-up design flow................................................................

110 111 111 112 113 113 115 118

List of Figures

Fig. 12.9 Fig. 12.10 Fig. 12.11 Fig. 12.12 Fig. 12.13

Integration of modules in the top-level design............................ Example design partitioned for incremental compilation........... Example of the RTL viewer in the Quartus II software............... Example view of a FSM from the Quartus II RTL viewer.......... Critical Path View in Quartus II technology map viewer................................................................ Fig. 12.14 The Quartus II chip planner detailing the Stratix IV ALM architecture.......................................................

xv

119 119 125 126 127 127

5

Chapter 1

Best Practices for Successful FPGA Design

1.1 Introduction This book which describes the Best Practices for successful FPGA design is the result of 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, what does not work, I have been able to identify the areas of concern in implementing System designs. More importantly, it has enabled me to document a recommended methodology that provides guidance in applying a best practices design methodology to overcome the challenges. This material has a strong focus on design teams that are 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. Best Practices establishes a roadmap to predictability for implementing system designs in a FPGA. The three steps (Fig. 1.1) to predictable results are: 1. Proper project planning and scoping 2. Choosing the right FPGA device to ensure that the right technology is available for today’s and tomorrow’s projects 3. Following the best practices for FPGA design development in order to shorten the design cycle and to ensure that your designs are complete on schedule and that the design blocks can be re-used on future projects with minimal effort All three elements need work together smoothly to guarantee a successful FPGA design. The choice of vendor should be a long-term partnership between the Companies. By sharing roadmaps and jointly managing existing projects, you can ensure that not only is the current project a success but provide the right solutions on time for future projects. A process of fine tuning based on experience working together to guarantee success on projects. These two topics are touched upon briefly in the Best Practices for Successful FPGA Design methodology.

P. Simpson, FPGA Design: Best Practices for Team-based Design, DOI 10.1007/978-1-4419-6339-0_1, © Springer Science+Business Media, LLC 2010

1

2

1 Best Practices for Successful FPGA Design

Key Elements to Successful FPGA Design

Program Management

•Device Selection •IP Reuse •Team Based Design Environment

•Predictable Timing Closure

FPGA Design Methodology

•Project requirements and objectives •WBS & schedule •Resources & costs •Risk assessment & management •Change control •Project execution

Predictability & Reliability

•Optimized verification environment

Vendor Choice & Partnership

•Time to production •Si foundry partner •Technology roadmaps •Component roadmaps •Software roadmaps •IP roadmaps •Early Access to Advanced Tools

Fig. 1.1  Three steps to successful FPGA development

The third topic is the FPGA design methodology. This is the main focus of the best practices methodology. This covers the complete FPGA design flow from the basics to advanced techniques. This methodology is FPGA vendor independent in that the topics and recommendations are good practices that apply to the design of any FPGAs. While most of the material is generic, it does contain references to features in the Altera design tools that reinforce the recommended best practices. The diagram that is shown in Fig.  1.2 shows the outline of the best practices design methodology. Each of the blocks in the diagram is represented by chapters in this book, with an additional chapter on power. Power is its own chapter as it spans many of the other areas of the design methodology. The topics of Board Layout, RTL Design, IP Reuse, Functional Verification and Timing Closure tend to be the areas where design teams have different design methodologies and engineers need guidance on achieving consistent results and shortening the design cycle. Many of the challenges that are faced in FPGA design are not unique to FPGA design but are common challenges in system design. FPGA devices themselves do provide unique challenges and opportunities compared to ASIC designs. The increase in capability of FPGA devices has resulted in much more complex designs targeting FPGAs and a natural migration of ASIC designers to FPGA design. This has resulted in many design teams migrating ASIC design principles to FPGA designs. In general, this has been a benefit to the FPGA design flow; however it needs to be balanced with the benefits that FPGAs bring to the design flow. The programmable nature of FPGAs opens the door to performing more verification

1.1 Introduction

3

Recommended Design Methodology Project Management

Specification Resource Scoping

Board Design

RTL

IP

SW Development

Functional Verification Timing Design Environment In-System Debug Infrastructure

Design Sign-off

Fig. 1.2  Recommended best practices design methodology for successful FPGA design

in-system. When used correctly, this can greatly speed-up the verification cycle, however when abused it can lengthen the design cycle. The configurable nature of I/Os provides challenges that do not exist in ASIC design. The tools that are used from the EDA industry are also different for FPGAs than for ASICs, in both functionality and cost. This book will help you adopt the best design methodology to meet your requirements. While it is recommended that you read the book in its entirety, you can also focus on the individual chapters of the book that target the areas of the design flow that is causing the biggest challenge to your design team. Acknowledgements  Misha Burich for providing the idea for Best Practices. Brian Holley and Rich Catizone for driving the idea at their customer base and providing a constant source of feedback. Chris Balough for encouragement on creating this book. Thomas Sears – Providing access to his development teams, without whom this would not have been possible. YK Ning, Jeff Fox, Ajay Jagtiani, Alex Grbic, Joshua Walstrom, Oliver Tan & Joshua Fender for contributing material to the original presentations on Best Practices. The many customers who have contributed to the material by describing their design environments and the challenges that they have faced in completing their system designs in FPGA devices. My wife Jill and daughter Kayla for their patience and support through the process of gathering data and writing the book.

Chapter 2

Project Management

2.1 The Role of Project Management The scope of project management is to deliver the right features, on-time and within budget. As such there are three dimensions: 1. Features 2. Development time 3. Resources The project manager needs to find the right balance of these three dimensions to meet the goals of the project. There are numerous books and training classes on project management. This chapter provides a brief overview of the elements of project management. It is recommended that you attend formal project management training.

2.1.1 Project Management Phases Every project can be broken into three project management phases. 1. The planning phase. This is establishing the feature list, creating the project plan and establishing the resource pools and budget. 2. The tracking phase. This involves holding monthly feature reviews, weekly plan updates, reviewing the budget and staffing levels and reviewing any Engineering Change Orders. 3. The wrap-up Phase. This involves project retrospectives, data mining and ­process improvement review and action plan.

P. Simpson, FPGA Design: Best Practices for Team-based Design, DOI 10.1007/978-1-4419-6339-0_2, © Springer Science+Business Media, LLC 2010

5

6

2 Project Management

2.1.2 Estimating a Project Duration Estimating the overall project delivery target is best done with the following steps. 1. Select one of the latest successfully major completed projects. 2. Create a macro model. This involves identifying the major project phases for specification, designing and verification. Extract the exact duration of the phases and any overlap. 3. Set the overall process improvement target. An example would be stating that I want to implement a project of similar complexity 10% faster. 4. Define project complexity metrics such as design characteristics and resource utilization. Design characteristics can include the number of pages of specification, the number of FPGA resources, the number of lines of RTL, design performance technical complexity. 5. Derive the derating factor k. 6. Scale the upcoming project by the derating factor. 7. Evaluate the project with good judgment and make the appropriate adjustments.

2.1.3 Schedule The project schedule should be updated regularly. It is recommended that it is updated at least once a week. Any schedule update meetings should be kept brief and should only focus on collecting the status information. This includes information on whether a task has started, is an activity complete, how long will a task take to complete, and any user task information that determines the level of completeness of a task. The update meetings should also be used to estimate when a task is expected to be complete. The project manager must respect the duration estimates from the resources performing a task but should question any estimates that appear to be wildly wrong.

2.1.3.1 Weekly Schedule Analysis The project manager needs to rigorously analyze the project schedule on a weekly basis. There are ten main tasks involved in this process. 1. Analyzing and scrutinizing the critical paths. 2. Reviewing the planned tasks for the coming week. 3. Discussing and agreeing on the task priorities with the rest of the review team. 4. Identifying a plan to accelerate the critical path. 5. Identifying other at risk paths that are just behind the critical path. 6. Checking the load on the resources assigned to the critical path.

2.1 The Role of Project Management

7

Fig. 2.1  Percentage complete dilemma

7. Confirming the availability of resources with the managers. 8. Determining the part of the project plan that needs more work. 9. Capturing action items. 10. Performing task refinements. It is critical that the project manager does not get fooled by the percentage complete. It is a non-linear function and is not useful in estimating the remaining task duration (Fig. 2.1). 2.1.3.2 Pro-active Project Management It requires an extreme degree of pro-active behavior to deliver a project on time. Be sure to dedicate enough management bandwidth to the project. Due to the dynamic circumstances of design projects, it requires constant manage­ ment attention with weekly rigorous project schedule updates. The complexity of the project require the right tools to facilitate the decision making process. The identification and management of the critical path simplifies the priority setting.

Chapter 3

Design Specification

3.1 Design Specification: Communication Is Key to Success Having a complete and detailed specification early in a project will prevent false starts and reduce the likelihood of Engineering Change Orders (ECOs) late in the project. Late changes to the design specification can dramatically increase the cost of a project both in terms of the project schedule and the cost of the FPGA. The latter occurring as significant changes may result in the need for a larger FPGA device. The purpose of a specification is to accurately and clearly communicate information. Another way of saying this is that specifications are a means to convey information between teams/people. Without a thorough specification, which has been approved by all impacted parties, a project is prone to delays and late changes in the requirements; all of which lead to longer project cycles and higher project cost. A key point in this statement is “agreed upon specification”. This implies that a process is in place for the review of the specification. A fully agreed upon specification ensures alignment between the different teams working on the project. This ensures that the delivered product conforms to the functional specifications and meets the customer requirements. This in turn facilitates accurate estimation of development cost, resource & project schedule. A solid specification enables consistent project tracking, which will ultimately produce a high quality product release. The specification also serves as a reference for the creation of documentation and collateral to be delivered with, or to support the product. All specifications should clearly identify changes that have been made to the specification. In addition, the specification should be stored under version control software. Specifications are required at different stages of the FPGA design from definition through the development process.

3.1.1 High Level Functional Specification The high level functional specification is created and owned by the systems engineering team. This document describes the basic functionality of the FPGA design including P. Simpson, FPGA Design: Best Practices for Team-based Design, DOI 10.1007/978-1-4419-6339-0_3, © Springer Science+Business Media, LLC 2010

9

10

3 Design Specification

the required interaction with the software interface and the interfaces between the FPGA and other devices on the board. This document should be officially reviewed with the FPGA design team Manager and the Software engineering manager. After the review, the document should be updated to reflect the recommend changes and to answer any of the issues raised during the review process. This process is iterative until all issues have been resolved and the FPGA design team understands and agrees upon the requirements. One of the challenges in creating the high level functional specification is successfully describing the functionality in understandable English. Let’s be honest here; most Engineers are strong in mathematics and science but will never be the next John Steinbeck. Executable specifications help resolve this issue. Executable specifications are abstract models of the system that describe the functionality of the end system. It is essentially a virtual prototype of the system. Most executable specifications are created in one of the flavors of “C” (C, C++, System). These languages are good for modeling the desired functionality but do not cover key features such as timing, power and size of design. These need to be covered in an accompanying high level specification to the executable specification. The virtual prototype at this stage is the system model and the testbench which is part of the executable specification. This executable specification can be used throughout the development process to check that the detailed implementation is meeting the requirements of the executable specification. Not all Companies are using executable specifications as part of the FPGA design process, but its use is becoming more common as more complex systems are being implemented in FPGA devices.

3.1.2 Functional Design Specification The team that is creating the FPGA design should create a detailed design specification that represents the needs of the high level functional specification. The owner of this specification is the FPGA engineering team. This specification should be reviewed and approved by the FPGA design team, their management and with representation from the systems engineering and software engineering teams. This should finalize the specification for the functionality of the FPGA design and detail the interfaces with the rest of the system including software. It is critical to agree upon the details of the interfaces to the FPGA with the appropriate development teams that will use these interfaces. Take for example, the H/W to S/W interface for a design where an A/D converter feeds the FPGA. The FPGA in turn feeds data to a microprocessor. The FPGA requirements specification must cover the interface to the A/D and be designed to avoid any functional failures, even under corner case conditions. Failure to do so can result in functional failures not showing up until testing the design in system. Board tests could show the FPGA passing junk data to the S/W interfaces. The S/W engineers

3.1 Design Specification: Communication Is Key to Success

11

will likely not know how to interpret or debug this issue. This can result in extended board test time and under worst case scenario a redesign of either the software and/ or the FPGA design; ultimately this will result in a delay to the schedule.

3.1.2.1 Functional Specification Outline In this section, we will detail the minimum set of requirements that need to be included in the functional specification. 1. Revision history. A sample revision control page is shown in Fig.  3.1. This includes the date of the changes, the author of the changes and the approval of the changes. 2. Review minutes. This should include details on all review meetings on the specification. The minutes should include the meeting date and location, attendees, minutes and the action items that need to be resolved to gain approval of the specification. 3. Table of contents. 4. Feature overview. The feature overview should provide context of the system in which the feature will be provided. If the feature is a subsystem in the end FPGA system design, this section should describe where it fits in the overall system and its purpose, i.e. the problem it solves. The feature overview should also include a high level overview of its required functionality. 5. Source references. This section should describe the driver of the feature request, e.g. High Level Functional Specification, Software Interface Functional Requirements, etc. 6. Glossary. The glossary should describe any industry standard terms and acronyms that are used in the document. More importantly, it should also do this for any internal Company terminology used in the document. It is amazing how much time is wasted and confusion caused due to the use of internal Company terminology. Many new employees or employees from other groups are often embarrassed to admit that they do not understand the “code” words in review meetings, ­resulting in confusion, delays in decision and often the stifling of creativity. Revision History Version Author

Date

Changes

0.9 1.0

psimpson

4-26-09

Initial revision

psimpson

5-11-09

Added timing details to CODEC

1.1

aclarke

5-30-09

Modified register map based upon review with SW Engineering on May 28, 2009.

1.2

jjones

6-3-09

Adding a section to describe the interface to host processor.

1.3

psimpson

6-9-09

Updated host processor interface after second review with SW Engineering on June 4.

Fig. 3.1  Sample revision control page

12

3 Design Specification

7. Detailed feature description. This is really the meat of the document. This section should include descriptions of any of the algorithms used, details on the architecture of the design and the interface with other parts of the design or system. 8. Test plan. The document should refer to the test plan, or at a minimum state the need for a test plan and be updated when the test plan exists. 9. References. In this section the document should refer to all supporting documents that should be read to understand the functional specification. Following the creation of the detailed FPGA design specification, the engineering team will create a number of specifications for internal review within the engineering department. These include the Functional Test Plan and QA Test Plan. Each engineer that is assigned to the project will create an engineering plan and functional test plan for the portion of the design that they will be implementing. This should be reviewed within engineering against the overall functional plan. This ensures that it meets the overall requirements of the FPGA design.

3.1.2.2 Test Specification Outline 1. Revision history. A sample revision control page is shown in Fig.  3.1. This includes the date of the changes, the author of the changes and the approval of the changes. 2. Review minutes. This should include details on all review meetings on the specification. The minutes should include the meeting date and location, attendees, minutes and the action items that need to be resolved to gain approval of the specification. 3. Table of contents. 4. Scope. This will provide an overview of what specific features this test plan will cover. If test coverage overlaps with the testing of any subsystems, it should detail what will be covered in this test plan and refer to the other test plans. 5. Test requirements. This should detail any special hardware, software, EDA tools that are required to complete the testing. As part of this it should include any special set-up requirements. 6. Test strategy. This includes the pass/failure criteria. Do the test results require crossverification with any other sub-systems. Will existing tests be re-used or modified to meet the needs of this test plan. Will the tests be automated and if so, how will the tests be automated. How will the tests be run. An example of this would be an automated regtest that is run each night, or manual testing to verify that the graphics appear correctly on the screen when run on a development board. 7. Automation plan. It is desirable to automate as much of the testing as possible. This section will describe how to automate the test. 8. Running the tests. What is the expected runtime of the tests. If the test is not automated, what is the expected time for the tests to be performed manually. 9. Test documentation. This section should include descriptions of the test cases. As standard practice, the test infrastructure should be set-up to isolate each test.

3.1 Design Specification: Communication Is Key to Success

13

Thus each test case should have its own test directory. The documentation should detail how to access the results from the regression tests database. This assumes that a regression tests system has been established. Not establishing such a system is setting a project up for failure as it will be incredibly difficult to monitor the quality of the product. The test documentation should also cover test procedures for the cases where subtests cannot be automated. Under this scenario, it is necessary to document how to manually test the sub-feature. As work begins on the development of the FPGA design, there should be regular design and verification reviews as part of the engineering process to ensure that there are no changes to the plan. These reviews will provide a forum to communicate any changes that may be needed to work around implementation issues and to clear up any areas of ambiguity in the specifications. As a result of these meetings, the specifications should be updated and reviewed. If the recommended changes will impact the high level functional specification or any of the interfaces with the FPGA, there should be formal reviews with the relevant personnel to reach closure on the changes. In summary, the main purpose of a specification is to communicate information between teams such that the design meets the requirements and can be adequately staffed to deliver on the requirements in the specified timeframe. The requirements for the functional specification and test specification will be driven by your Company’s policy on standards compliance, e.g. ISO 9001 compliance. This book does not discuss the details on ISO 9001 compliance. A detailed description of the ISO 9001 standard is available from http://www.iso.org. Recommended further reading: Requirements by Ian Alexander

Chapter 4

Resource Scoping

4.1 Introduction This chapter is broken down into three main sections. The first section deals with engineering resources. Whether you use internal resources or whether you use external contractor resources. The second section deals with IP. Do you have IP within the company that you can reuse, or do you use third party IP? The third and last section deals with device selection. This details how to select the right FPGA with the right resources for your application. It covers the various techniques that you can use to help choose the right device to enable you to meet your project schedule.

4.2 Engineering Resources The assignment of engineering resource to the project is a project management task. It is key that you adequately resource the project with the appropriate personnel for the tasks in the project. When you are working on the FPGA its not only FPGA designers that you need to consider, you need to look at the team of engineers that are required to create the design. So, from a hardware engineer’s perspective you look at who are the engineers that are going to work on the FPGA design. There are the RTL designers, there are the engineers with the experience integrating the design in the FPGA design software and the engineers with design verification experience. In some companies these roles will be performed by the same individual, or the same pool of engineers. However, depending upon the size of the design or the complexity of the project you may well require a team of engineers with different skill sets from the different engineering disciplines. From a hardware engineering perspective, you also need to look at the board design, so you will to need to ensure that you have board layout engineers on the team. They will have to work close with the FPGA designers, so you want to make sure that the members of the team have a good working relationship. If you are creating a high speed design, particularly if you are P. Simpson, FPGA Design: Best Practices for Team-based Design, DOI 10.1007/978-1-4419-6339-0_4, © Springer Science+Business Media, LLC 2010

15

16

4 Resource Scoping

looking at design with high speed transceivers or high speed memory interfaces you are likely going to need someone on the team with signal integrity experience. If your design uses a soft processor such as the Nios® II processor form Altera, you will also want software engineers on the team. Even if the FPGA is interfacing with a microprocessor, you still want the software engineers to be available for when you start to debug the design on the board. You also may need engineers with other system specialties on the team. For example if your design contains DSP algorithms the individual that created the algorithm may not actually be a hardware engineer, thus will not be implementing the design in the FPGA. You need to ensure that the Specialist is available for advice during the design cycle and for debug of the design after implementation. Similarly, for other IP areas of excellence; examples being the main interface protocols such as PCIe or GigE. An important decision in the assignment of engineering resources is the decisions as to what are you going to implement with the engineering resources that exist in the company vs. what will you implement with external consultants.

4.3 Third Party IP You need to look at what third party IP is available and will be used in the design. Similarly what internal IP will be reused, do you have IP available from other projects targeting this FPGA family. Or if you are using third party IP you will probably want to look at what are you getting with the IP, do you get a consultancy service or what is your level of confidence that the IP will meet your exact requirements in terms of area, speed and functionality.

4.4 Device Selection There are seven main factors that influence your choice of device. These are: 1. Specialty silicon features. Are there certain capabilities that you need that dictate that you use a particular FPGA because they are not available in other FPGA devices. 2. Device density. How much logic will your design require? What is the mix of logic to memory blocks to dedicated multiplier blocks that is needed for your application. This will have a big impact on the price of the device that you need. 3. Speed requirements. This will impact the family that you choose and the speedgrade that you need to use. Once again this will have a large impact on the price of the device. 4. Pinout of your device. What kind of package do you require? The choice of package type and the number of I/O in your design will impact both the FPGA

4.4 Device Selection

17

cost and the board design. The package type will also influence the signal integrity and performance of the I/O in your design. 5. Power. What is your power budget for the design and which device is going to help you meet the budget? 6. Availability of IP. 7. The availability of silicon. You want to make sure that production silicon is available when you need it. So these are the areas that we need to look at in more detail.

4.4.1 Silicon Specialty Features The first area that you want to look at is the dedicated resources on the device. Does your design require high speed serial interfaces and if so, how many channels and at what performance. Many of the FPGA devices that are available together come with transceivers. The performance of transceivers tends to fall into three ranges, up to 3.125 Gbps, up to 6.5 Gbps and 10 Gbps+. These are important factors in the decision process as they impact both the performance of your design and the cost of the FPGA. You also need to look at your bandwidth requirements. Both the speed of the transceivers and the number of transceivers will determine your bandwidth. Take for example the communications market; if you are trying to implement 100  Gbit Ethernet, you will likely want a minimum of ten channels of 10 Gbps transceivers. Similarly, if you are completing a design which is math intensive such as a DSP encryption algorithm or radar application, you will require a device with a large number of DSP blocks and adequate RAM blocks to interface with the DSP blocks. The configuration of the DSP blocks is also important. The depth and number of memory blocks will impact how much processing can be performed on chip vs. having to use external memory. Internal memory is important in DSP for caching of processing results between stages of the processing algorithm. You also need to look at both the number and configuration of the dedicated DSP blocks. What is the width of the multiplication operations that you need to perform? If the DSP block does not have sufficient width, you will have to start combining DSP blocks with logic to implement your functionality. This can impact the performance of the operation that you are performing. How many internal RAM blocks do you need? This is becoming increasingly more important as we look at designs that make use of soft processors. Being able to use internal memory blocks as cache can significantly increases the performance of the soft processor. The sizes of block RAM that is available is also important. If your design will use a lot of FIFOs, it’s the number of RAM blocks that are available that matters and not the amount of bits available. FIFO’s are notorious for wasting memory bits when implemented in memory blocks. You also need to consider the debug of your design. Internal block memory is often used in the debug cycle for storing the data from embedded logic analyzers for examination.

18

4 Resource Scoping

4.4.2 Density When selecting the density of the device, it is unlikely that you will be fortunate enough to have the completed design to determine the size of device needed. You will be choosing the device based upon previous experience. Many designs are based upon previous generations of the design. This can be aid in the device selection process. You should recompile the previous design or the portions that will be used at your target FPGA family to get ballpark density estimates. If you have IP that you will be using, compile it to add to your area estimates and if you are evaluating IP for third party vendors, get an area estimate from the vendor. So, use the previous generation of the design, if it exists, add in the area requirements from IP and then using your experience, add in how much additional resources will be used for the new functionality. Once you have done this, add an additional 25% on top. You should always target a larger device than you think you will need; this is where the extra 25% comes into the equation. You should always target a larger device than you think you will need. Designs have a nasty habit of growing and you want to guarantee that the design will fit in the targeted device and be able to close timing. You don’t want to be struggling to meet timing in a 95% utilized device or be put in the position of having to pull functionality out of your system just to fit in the targeted device. Another benefit of using a larger device is that it can help you get to in-system checkout quicker. If there is headroom in the device, the place and route software will likely not have to try as hard to meet timing and will result in shorter compile times. This benefits both the hardware and software engineer. The sooner that you have functional silicon, the sooner the software engineer can accelerate his code development process by trying it out on the targeted hardware. You can start the debug of the hardware and software much earlier in the design cycle. Another benefit of the additional headroom in the device is that it makes it easier to accommodate late ECOs in the device or accommodate growth in future versions of the design after production. After you have the design working functionally on the device and if there is significant unused resources on the device, you can retarget the device to a smaller device to reduce cost and not have to worry about impacting the project schedule. Some of the FPGA vendor design tools have features that enable you to migrate between device densities in the same family while maintaining the same pin-out. These features restricts you to using only the I/O resources that exist across the density ranges selected in the targeted family; the benefit being that you can retarget your design to a larger or smaller density device avoiding a board re-spin. If this feature is not available in your FPGA vendor software you can design the capability in manually by referencing data sheets and application notes. The manual process is painful and prone to user error, but is worth the investment if the automated flow is not available. The key point is that you need to ensure that the ability to migrate between device densities while maintaining the pin-out capability is available in the FPGA family that you are considering for your application.

4.4 Device Selection

19

The recommendation is that you select a device that can migrate up in density to accommodate future design growth and can migrate down in density to allow for possible cost reduction. This functionality is very useful if you intend to ship variations of your product at different price points with changes in the functionality. This enables the same board to be shipped. A single design can be created and functionality removed from the FPGA at the lower price points. Normally the same FPGA is shipped on the same board with a different programming file based on the reduced functionality of the design. By maintaining the same pin-out you can now remove the functionality and retarget the design to a smaller device, further cost reducing your bill of materials.

4.4.3 Speed Requirements This can be determined from your previous design experience. You should compile designs or design blocks that you already have to get an indication of the performance that they get in the targeted device. This can be used as a good best case indicator as to what you can expect from other design blocks. The FPGA vendor’s data sheets are also a good source of information on performance. They will tell you the absolute maximum that you can hope to get in terms of clock and I/O performance. While these numbers are achievable, it is likely to increase your timing closure cycle achieving these numbers, thus you should back off the numbers by approximately 15% to give you a margin of safety for timing closure. The choice of speed-grade will impact the price of the device. When choosing device, we recommend that you always start with the fastest speed-grade to enable you to get the device on the board as soon as possible to start software debug and hardware functional check out as early as possible. If the design meets timing comfortably in the fastest speed-grade, you will benefit from faster compilations as the place and route engine does not have to try as hard to close timing. Later in the design cycle, there is the option to retarget the design to a slower device after the functionality is close to complete, for cost reduction purposes.

4.4.4 Pin-Out The type of I/O interfaces that you need for the design will impact the number of pins required and the package type. You need to understand the I/O standards that you need, the requirements for drive strength. How many pins do you need? What are the power supply requirements? A good way of determining these requirements without the design is by looking at what your device will interface with on your board. You also need to look at the signal integrity requirements for the design. Does your design have interfaces with a large number of pins that are likely to toggle simultaneously;

20

4 Resource Scoping

if so, will you have SSN issues? It is worth noting that wirebond packages typically have worst signal integrity and I/O performance than flip chip devices. It is recommended that when looking at the pin count for your design, that you reserve pins for in-system debug. The target should be a minimum of 15% of the device pins. They can be used to route internal signals off-chip for analysis with a logic analyzer.

4.4.5 Power You know the power budget for your design based upon the specification. How many power supplies will be required for the device? Most modern FPGA devices require multiple power supplies as they have separate power planes for the core, I/O’s and often the transceivers. The more power supplies that are required, the more expensive the component cost on the board and the more complex the board design. Once again, your previous FPGA design experience will come into play. Chapter 7 in the book is dedicated to power estimation; it will help master this challenge. To summarize, it is recommended that you use the FPGA vendor’s power estimation spreadsheet together with your previous experience to determine the power that your design will consume.

4.4.6 Availability of IP IP may be available for a particular family of devices but may not have been ported to or verified on the particular FPGA family that you are considering using. This is often the case with devices that are new to the market. Interface IP in particular is a challenge for devices where the silicon has been available for less than 6 months. The devices are normally not fully characterized thus the timing models are preliminary. High performance interface IP cannot be guaranteed to close timing until the models are final.

4.4.7 Availability of Silicon If you have a project on the bleeding edge of technology, the chances are that you will be considering using the latest FPGA devices on the market. You will also likely be considering the latest FPGA device knowing that in the future, the pricing will be more favorable. The decision to use the latest FPGA devices on the market makes financial sense if the design will be going into production in 12 months but you know that your volumes will be shipping for 5+ years such that you will be hitting volume production when the FPGA process has matured and pricing is at its lowest.

4.4 Device Selection

21

4.4.8 Summary We really recommend that when choosing FPGA technology that you quickly stitch together dummy designs effectively to enable the process of successful device selection. You are going to have a good idea of what type of interfaces you are going to need on your device. This will help you to determine the pin requirements and simplify the I/O planning requirements. By creating the dummy design you get an idea of the utilization that you can expect to get out of the device in terms of resources. It will also provide a good guide to the performance that you can expect for your type of design. It also enables you to perform an early power estimate for your design. The creation of a dummy design is instrumental in selecting the appropriate device and should include any known IP blocks that you are going to be used in the design.

Chapter 5

Design Environment

5.1 Introduction The FPGA design environment is best expressed as a combination of all of the tools, techniques and equipment that is required to successfully complete a FPGA system design. The design environment in each company is usually somewhat unique in that it has been customized to meet the needs of the company. However, there are some common elements that exist across all design elements. The goal of this chapter is to make you aware of the bare minimum requirements for a design environment that will enable the successful creation of an FPGA design on time. The design environment can be represented by five main elements. 1. A scripting environment 2. Interaction with Version Control software 3. Use of a problem tracking system 4. A regression test system 5. Data collection for analysis

5.2 Scripting Environment One of the challenges for engineers that are designing with FPGA devices, is when to use a scripted design flow vs. when to use the GUI in the FPGA design environment? Scripts are ideal in the following scenarios: 1. Creation of projects 2. Creation of assignments for the design 3. Compilation of designs. In particular if you utilize a compute farm environment. A compute farm environment enables you to fire off batch jobs to the server for compilation 4. Functional verification and regression testing 5. Integration with version control software P. Simpson, FPGA Design: Best Practices for Team-based Design, DOI 10.1007/978-1-4419-6339-0_5, © Springer Science+Business Media, LLC 2010

23

24

5 Design Environment

This covers most of the FPGA design flow. It may appear that it is recommended to use scripting for every part of the design flow. This is partially true. You really should deploy scripting for any repetitive tasks. It helps other users to easily reproduce your environment and results. So, when is it recommended to use the GUI? The GUI should be used for the parts of the design flow that are interactive. Areas where your actions will change based upon the results that you get. Examples would be the following scenarios: 1. In-system debug of your design 2. Floorplanning operations. This could be looking at the details of the floorplan to gain a better understanding of the device architecture or the resources that are available. This could also be creating a physical layout of your design in the floorplan in a team based design environment 3. Getting started with new tools. The GUI provides a great way for setting up your first project and uncovering the features and capabilities of the tool. Once familiar with the tool, it is recommended that you move to a scripting environment Through the use of scripting you can save time and effort on repetitive tasks. One of the big benefits is that it simplifies the passing of tasks between team members in a team based design. If someone is taking over a project or design block, from another engineer; Rather than having to write detailed instructions describing what needs to be done to get your results, you give them the script which is self documenting. The new engineer reads the script, runs the script and they get started from where you left off on the project. Nearly all EDA tools that are part of the FPGA design flow have scripting interfaces, both a command-line interface for creating batch files and assignment scripting for creating settings in the project. Most of the EDA industry has standardized on Tcl as the scripting interface for tool assignments.

5.3 Interaction with Version Control Software Revision Control software provides a record of the history of changes to your design. When you are designing a FPGA, it is necessary to understand the minimum set of files that is needed for check-in and check-out of the version control system. You need to minimize the number of files because the more files that you check-in, the more storage you will need and the more complex the operation will become. Each time you make a change to your design you need to check the FPGA project back in to the version control software. A good scripting environment helps to simplify this process. The initial set-up of the scripts and the identification of the files that need to be checked in and out may be complex. However, once the scripts are established, the scripts can be shared among the engineers that are working on the project. If you can recreate or describe your project with a script, the version control interaction becomes much simpler.

5.4 Use of a Problem Tracking System

25

Different FPGA design tools require different sets of files to be placed under version control in order to recreate the results; so the set-up that you use for one FPGA vendor may differ significantly than the set-up used for another. The principle however is the same. If the tools use text files, the interaction with version control systems is much simpler than tools that use binary files that store critical information. To date, FPGA vendors have done a poor job in publicly documenting which files need to be checked into version control software to enable you to recreate the results of the previous compilation. This process becomes more complex if you use multiple tools in the FPGA design flow. It is recommended that you contact the vendors of each of the tools to understand their recommendations. One of the major influences on how you use a version control system is the directory structure that you are using for your design environment. This comprises of the location of the RTL design files, location of the RTL and IP libraries, “c” code and programming image if you are using a soft processor, simulation testbenches, location where the results of your regtests are stored and the scripts to compile the design in the FPGA software or in other EDA software. You need to be able to link all of these elements together successfully using the correct versions of the files. You want to avoid the situation were you are trying to debug the design in the lab and you are using the wrong programming image for the FPGA, or you are loading the soft processor with old source code, or a designer is making changes to an out of date version of the RTL. Proper use of version control will provide an environment that prevents these scenarios from occurring. You also want to be able to store the report files in version control as the report files document the status of the design. This provides valuable information to other designers that work on the same project.

5.4 Use of a Problem Tracking System A problem tracking system is not a capability that you get from your FPGA vendor. However, I can guarantee that it is a tool that FPGA vendors use as part of their engineering and product planning process. Problem tracking systems tend to be homegrown systems to meet the needs of the individual company. In fact many of the EDA tool and FPGA vendors have a customer interface to their systems for submitting problem reports. There are commercial systems available on the market. These systems are essentially database system with a customizable front-end to meet your companies needs. In your design environment, you will use the system to track all known issues with your FPGA design. It enables the design engineers to document problems with the design as they occur. This provides the team with an instant status on the design and can be used to track the stability of the design throughout the design process. It makes the other members of the team aware of the problems with your design, avoiding the case were they are trying to debug a problem in their part of the system that is being caused by your design. By looking at this data it can be determined

26

5 Design Environment

whether to use a particular project build or whether to revert to an earlier build that did not exhibit the problems that were introduced into that particular build. It also enables users to document the closing of issues. This enables the team to collaborate on solving the issues in the design. This is very helpful in a team based design environment that spans multiple time zones. As mentioned, the system can be used to provide a snapshot of the health of the project. To do this, it needs to be linked to the regression test system such that test failures automatically file problems reports in the tracking system against the build that is being tested.

5.5 A Regression Test System As part of your testing, the design engineers will create point tests to show that the design meets functionality. It must be a requirement that you have a set of tests that are run regularly on the design to provide a health check on the design. These tests give you confidence that as your design changes that you do not reintroduce old problems or break existing functionality. Regression tests are discussed in more detail in Chapter 11.

5.6 When to Upgrade the Versions of the FPGA Design Tools One of the challenges that you will face if you have a design that spans more than 6  months is when to adopt new releases of the tools that are used in the FPGA design environment. FPGA vendors typically have at least two major releases per year plus a selection of service pack releases that include bug fixes and timing model changes. When should you freeze the version of the design tools that you are using? This decision will be driven by where you are in the design flow. If you are in the early stages of the design, then you should update to the latest release of the FPGA design software unless you are aware of serious problems with the software. This will give you access to the latest bug fixes and features in the software. Normally there is some degree of compile time improvement in the major releases of the FPGA design software. If your design is mostly complete and the version of the FPGA vendor software that you are using contains the final timing models for the devices that you are targeting, then you should consider freezing the version of the design software that you are using. An exception would be if you come across a bug in the design software that impacts your design. This will likely require you to upgrade the design tools to access the fix to the bug. If your design is close to complete but the FPGA vendor timing models are still preliminary you will have to upgrade the version of the design software once the

5.7 Common Tools in the FPGA Design Environment

27

final timing models become available. This can be problematic as it may require you to upgrade the versions of the vendor IP blocks, possibly creating more work for you; in particular in verifying the design. It is strongly recommended that you verify your design against the production or final version of the FPGA timing models. Some of the FPGA vendors provide the capability to read a database from one version of the design software in a later release of the software. Thus the design does not have to be recompiled and only timing analysis rerun to verify that the design still meets timing, with the final timing models.

5.7 Common Tools in the FPGA Design Environment FPGA design software:  This comes from the FPGA vendor and includes the FPGA Place and Route Software and Timing Analysis tools. The major FPGA vendors also include RTL Synthesis, Advanced Timing Closure Features. On-Chip debug and Floorplan Tools. FPGA synthesis software:  This may come from the FPGA vendor or may come from EDA synthesis tool vendors such as Synopsys or Mentor Graphics. Most FPGA synthesis tools support Verilog and VHDL. Some of the tools now support SystemVerilog. Simulation tools:  Some FPGA vendors provide simulation tools but by far the majority of the tools that are used come from EDA tool vendors. The most popular tools are Mentor Modelsim and Questasim, Synopsys VCS, Cadence Incisive and Aldec Active HDL and Riviera Pro. Some of these tools include advanced capabilities for assertion based verification, detection of clock domain crossing, etc. Formal verification tools:  These tools are not commonly used in FPGA designs due to the restrictions that they place on the optimizations that can be performed when using these tools in order to perform a successful verification. Timing analysis tools:  There are timing analysis tools available from EDA tool vendors. However, these are rarely used in FPGA design flows due to the availability of timing analysis tools in the FPGA vendor supplied design software. We recommend that you use the FPGA vendor timing analysis tools for FPGA timing analysis as the timing constraints that are used for timing sign-off are also used by the place and route software for optimization. It is recommended that the EDA timing analysis tools are not used for FPGA verification, but are used for board timing analysis. Board design tools:  EDA tools are used for board design. These include the board schematic tools, the board layout tools and the signal integrity tools. The HSPICE and IBIS models that are used by the signal integrity tools come from the FPGA vendois.

28

5 Design Environment

High-level synthesis:  Most of the tools in this space are based on designing in “C or C++” and having the code produce RTL or a netlist for an FPGA. The adoption of these tools in the FPGA market has been slow. These tools have matured a lot and are slowly gaining momentum in creating design blocks for certain applications, as opposed to creating a complete FPGA design. These tools tend to be mainly focus on the High Performance Computing Market and DSP algorithm implementation. All of the offerings that are available are from EDA Companies. The next class of High-Level Synthesis is Model based design tools. These utilize optimized libraries in the Mathworks Simulink environment. Their target markets are military markets and Modem designs. These tools rely on the Mathworks Matlab environment and are available from the main FPGA vendors and EDA Companies. Load sharing software:  This is software that is used to schedule jobs that are being processed on compute farms. Load sharing solutions are heavily used in FPGA development, particularly in script based design flows. There are commercially available software packages as well as freeware. Some of the options in the FPGA software include a form of load sharing software. Version control software:  Version control tools are not considered EDA tools per se, but are a major part of the design flow environment, commonly used version control software with FPGA designs are Clearcase, Perforce and PVCS.

Chapter 6

Board Design

6.1 Challenges that FPGAs Create for Board Design In order to meet the fast performance and high bandwidth of today’s system designs, FPGA devices are providing a large number of pins with increasingly faster switching speeds. These higher package pin counts, together with the fact that the devices support many different I/O standards and support different package types, creates a challenge in successfully creating the FPGA pin-out efficiently and correctly. The cost of a board re-spin, due to a problem with the pin-out, is expensive in terms of both the cost of the board re-spin and the impact on the project schedule. FPGAs provide pin-out flexibility by supporting many different I/O standards on a single FPGA and by providing user control over drive strength and slew rate. This flexibility also results in complex rules for the creation of a legal FPGA pin-out and impacts the termination requirements for the Printed Circuit Board (PCB). The high package pin counts create an EDA tool flow challenge in the management of data between the board design software and the FPGA design software. Due to the complexity in designing high performance PCBs, the PCB design cycle needs to begin early in the system design cycle. This creates a challenge in aligning the final FPGA pin-out with the board design cycle. Often the board layout needs to be complete prior to FPGA design completion. In fact, it is becoming increasingly common that the FPGA design and the board development are being undertaken simultaneously and that for many user system designs, the board design is often complete prior to the RTL code for the FPGA existing! Early in the design cycle, it can be difficult to predict the size of the FPGA device that is required for the project. Most FPGA families have a technical solution to this problem; they support pin migration between devices of different density in the same package. Thus, it is advised that designers select a FPGA device that has several densities in the same package. This creates the challenge for the board designer in creating a pinout that is migratable across all the device densities. Once again, help is at hand from some of the FPGA design tools via a feature that is often referred to as device migration. Device Migration is the ability to transfer a design from one device in an FPGA family to a different density device in the same device family which has the same device package. This enables you to transfer a design from the design’s target

P. Simpson, FPGA Design: Best Practices for Team-based Design, DOI 10.1007/978-1-4419-6339-0_6, © Springer Science+Business Media, LLC 2010

29

30

6 Board Design

device to a larger or smaller device with the equivalent pin-outs, while maintaining the same board layout and pin assignments. This is a feature that can be selected in the FPGA vendor software when making the device selection. This feature will prevent the user from making pin assignments to pins that cannot be migrated across the different device densities. It is recommended that you include this requirement as part of your design plan as insurance against unforeseen changes in the FPGA design, particularly if creating a pinout early in the FPGA design cycle. This enables you to use a larger device if the changes to the design results in a significant logic growth or potentially the ability to use a smaller, hence cheaper device, if the design size permits this. The increase in system performance and bandwidth has resulted in faster pin speeds. At the time of writing, FPGAs are capable of interfacing with 64-bit DDR III SRAM running at 533 MHz. This is a data rate of 1,067 Mbps per pin. This can produce a number of simultaneously switching pins on the FPGA, which can in turn result in functional failures due to noise. The device needs to have a pin-out that avoids Simultaneously Switching Noise (SSN) and the FPGA needs to be terminated on the board in a manner that avoids SSN issues. Many FPGAs also include transceiver blocks that can operate up to 11.3 Gbps and support various I/O protocols such as PCI Express, Serial RapidIO®, Gigabit Ethernet (GbE), to name a few. These high speed transceiver based interfaces require careful termination on the board to avoid Signal Integrity (SI) issues. Now that we have identified the potential pitfalls in creating a PCB design for high performance systems containing FPGA devices, we will focus on the techniques that can be deployed to ensure that the board design is right first time. The remainder of the chapter describes the challenges in more detail. It describes the roles of different teams in the board design process. It presents a methodology that addresses all of the challenges that we have described and culminates in a check list that can be used on any FPGA project to achieve successful FPGA pin-out and board design.

6.2 Engineering Roles and Responsibilities The engineers that are involved in the board design of systems containing FPGA devices can be classified into three distinct engineering skill sets. These are FPGA design engineers, PCB Design Engineers and Signal Integrity Engineers. In some organizations there is overlap in the functionality, but in general they are distinct disciplines and the functions are performed by different engineers or engineering teams.

6.2.1 FPGA Engineers FPGA Engineers are familiar with the FPGA vendor software. The FPGA engineer is typically responsible for writing and verifying the RTL code for the design. He, or she, is also responsible for implementing the design in the FPGA and helps with the debug of the design in the end system.

6.2 Engineering Roles and Responsibilities

31

The FPGA engineer has a keep role to play in the PCB design. He is responsible for the generation of the FPGA pin-out from the FPGA design software. As such, he interfaces heavily with the PCB design engineer, providing updates to the pin assignments and implementing and verifying any recommended changes from the PCB design engineer. The FPGA Engineer also acts as the interface to the Signal Integrity engineer. He provides the pin-out information, as well as any HSPICE and/or HSPICE models and netlists that are generated by the FPGA design software.

6.2.2 PCB Design Engineer The PCB design engineer is familiar with PCB schematic and layout software. The PCB design engineer is typically responsible for creating board schematics, including the generation of device symbols. He is also responsible for creating the board layout, which includes routing the board. The board layout and in particular the routing of the board is heavily dependent upon the pin-out of the devices on the board. As such, the PCB design engineer has a strong influence on the FPGA pin assignments, as these greatly impact his task and the potentially the cost of the board. While the PCB design engineer influences the choice of pin assignments for the FPGA, he typically has no desire to use the FPGA design software. This creates the requirement for an efficient means of passing information to/from the FPGA engineer and the Board Designer. This is effectively the need for a two-way interface mechanism between the FPGA design software and the board schematic software, from EDA tool vendors. Today, some EDA tools provide a two way interface to the FPGA design software. However, the most commonly used interface for the communication of information between these two engineers is Microsoft Excel. Most of the FPGA design software offerings from the FPGA vendors have the ability to read and write the .csv format, which is used as the interface to Microsoft Excel. Similarly some of the board schematic software packages can read the .csv format. It is common practice within industry for board design engineers to create scripts that generate the appropriate schematic symbols from the .csv format or from the FPGA vendor pin report. Thus the .csv format serves multiple purposes. 1. A source of integration between the FPGA and Board design software packages. 2. Documentation of the design pin-out. As such, it should be stored under revision control. An example of a .csv file that can be used to interface between the FPGA design software and board schematic software is detailed in Fig. 6.1. A key point is that the csv details much more than the pin assignments. It includes details on the I/O standard and current strength. These are important as they impact the signal quality on the board, as well as the I/O timing.

32

6 Board Design

Pin Name

Direction Location I/O Bank VREF Group I/O Standard

clk_in in_port_to_the_button_pio[3] in_port_to_the_button_pio[2] in_port_to_the_button_pio[1] in_port_to_the_button_pio[0] ext_flash_enet_bus_data[7] ext_flash_enet_bus_data[6] ext_flash_enet_bus_data[5] ext_flash_enet_bus_data[4] ext_flash_enet_bus_data[3] ext_flash_enet_bus_data[2] ext_flash_enet_bus_data[1] ext_flash_enet_bus_data[0] out_port_from_the_led_pio[7] out_port_from_the_led_pio[6] out_port_from_the_led_pio[5] out_port_from_the_led_pio[4] out_port_from_the_led_pio[3] out_port_from_the_led_pio[2] out_port_from_the_led_pio[1] out_port_from_the_led_pio[0]

Input Input Input Input Input Bidir Bidir Bidir Bidir Bidir Bidir Bidir Bidir Output Output Output Output Output Output Output Output

PIN_B13 PIN_AE6 PIN_AB10 PIN_AA10 PIN_Y11 PIN_A8 PIN_B8 PIN_C9 PIN_D9 PIN_G10 PIN_F10 PIN_C8 PIN_D8 PIN_AA11 PIN_AF7 PIN_AE7 PIN_AF8 PIN_AE8 PIN_W12 PIN_W11 PIN_AC10

4 B4_N1 8 B8_N1 8 B8_N1 8 B8_N1 8 B8_N1 3 B3_N0 3 B3_N0 3 B3_N1 3 B3_N1 3 B3_N1 3 B3_N1 3 B3_N1 3 B3_N1 8 B8_N1 8 B8_N1 8 B8_N1 8 B8_N0 8 B8_N0 8 B8_N0 8 B8_N0 8 B8_N0

Current Strength

3.3 -V LVTTL (default) 3.3 -V LVTTL (default) 3.3 -V LVTTL (default) 3.3 -V LVTTL (default) 3.3 -V LVTTL (default) 3.3 - V LVTTL (default) 3.3 -V LVTTL (default) 3.3 -V LVTTL (default) 3.3 -V LVTTL (default) 3.3 -V LVTTL (default) 3.3 -V LVTTL (default) 3.3 -V LVTTL (default) 3.3 -V LVTTL (default) 1.8 V 1.8 V 1.8 V 1.8 V 1.8 V 1.8 V 1.8 V 1.8 V

24mA (default) 24mA (default) 24mA (default) 24mA (default) 24mA (default) 24mA (default) 24mA (default) 24mA (default) 24mA (default) 24mA (default) 24mA (default) 24mA (default) 24mA (default) 12mA (default) 12mA (default) 12mA (default) 12mA (default) 12mA (default) 12mA (default) 12mA (default) 12mA (default)

Fig. 6.1  Example .csv file that interfaces between board design SW and FPGA SW

The PCB design engineer also interfaces with the Signal Integrity engineer, by providing details of the board layout characteristics that are used to generate the model of the board for Signal Integrity modeling.

6.2.3 Signal Integrity Engineer SI engineers are familiar with signal integrity simulation software from leading EDA vendors such as Synopsys, Mentor Graphics, Cadence, Agilent, etc. They are responsible for verifying that the signal quality (e.g. overshoot/undershoot), including simultaneous switching noise (SSN) effects are within specification. Ultimately, the SI engineer is responsible for verifying that the board timing meets the system requirements. In the past, most FPGAs were designed without using the services of Signal Integrity Engineers. In truth many FPGAs are still being designed today without the services of SI engineers. Board designers have tended to lay the board out conservatively when interfacing with FPGAs and assumed, correctly in most cases, that this will meet their requirements. However, based upon the reasons stated earlier in this chapter, this approach is no longer adequate. The increase in I/O speeds for interfaces such as DDR II/III SRAM memories, plus the addition of high speed transceiver blocks require correct board termination to prevent SI and SSN issues. These types of interfaces can be successfully designed by following the guidelines that are provided in the application notes provided by the FPGA vendors. However, each board design is different and it is recommended that SI engineers simulate the I/Os that have high performance requirements. This creates the requirement that the board designer interfaces with both the FPGA and the board designer.

6.3 Power and Thermal Considerations

Board Engineer

33

Board Specifications

FPGA Engineer Signal Integrity (SI) Engineer

Pin Signoff

PCB Design & Verification

PCB ready

SI Signoff RTL Design & Verification, Implementation

Early Pin Planning

Early SI Analysis

Qualification, Debug & ECO

SI analysis with actual board traces

Development Time

Fig. 6.2  Design cycle diagram detailing engineering discipline involvement

He requires the HSPICE or IBIS models from the FPGA design engineer and the details on the board traces, etc. from the Board designers. SI simulations tend to be lengthy and should only be performed on the pins of the FPGA that are considered a high risk for Signal Integrity. That is the high performance I/O in the design. The diagram in Fig. 6.2 details the stage in the design cycle where each of the engineering disciplines should be involved throughout the FPGA design cycle. The diagram is explained in more detail in the section of this chapter on Design Flows for creating the FPGA pinout.

6.3 Power and Thermal Considerations FPGA power estimation helps guide power supply design for the board.

6.3.1 Filtering Power Supply Noise In order to reduce system noise it is critical to provide clean and evenly distributed power to all devices on the board. Low frequency power supply noise can be filtered out by placing a 100 mF electrolytic capacitor adjacent to where the power line joins the PCB. If you are using a voltage regulator, the capacitor should be placed at the final stage that provides the Vcc signal to the devices. In order to reduce the high frequency noise to the power plane it is recommended that decoupling capacitors are placed as close as possible to each Vcc and ground pair.

6.3.2 Power Distribution A power bus network or power planes are used to distribute power throughout the PCB. A power bus network is the least expensive solution but does suffer from

34

6 Board Design

power degradation. As such this should only be considered for cost sensitive applications on two-layer PCBs. The recommended approach is to use two or more power planes. The power planes cover the full area of the PCB and distribute Vcc evenly to all devices, providing good noise protection. It is recommended that you do not share the same plane for analog and digital power supplies. Virtually all FPGA devices now contain PLLs, thus board design must accommodate an analog and digital power plane for the FPGA. In summary, the power distribution recommendations are: –– –– –– –– ––

Use separate power planes for the analog and digital power supplies. Place a ground plane next to the PLL power supply plane. Avoid multiple signal layers when routing the PLL power. Place analog and digital components over their respective ground plane. Isolate the PLL power supply from the digital power supply.

6.4 Signal Integrity Digital designs have not traditionally been impacted by transmission line effects. As system speeds increase, the higher frequency impact on the system means that not only the digital properties, but also the analog effects within the system must be considered. These problems are likely to come to the forefront with increasing data rates for both I/O interfaces and memory interfaces, but particularly with the highspeed transceiver technology being embedded into FPGAs. Transmission line effects can have a significant effect on the data being sent. However, as speed increases, high-frequency effects take over and even the shortest lines can suffer from problems such as ringing, crosstalk, reflections, and ground bounce, seriously hampering the integrity of the signal. Poor signal integrity causes poor reliability, degrades system performance, and, worst of all, causes system failures. The good news is that these issues can be overcome by following good design techniques and simple layout guidelines.

6.4.1 Types of Signal Integrity Problems There are four general types of SI problems. These are Signal Integrity on one net, cross talk between adjacent nets, rail collapse and electromagnetic interference (EMI). 6.4.1.1 Signal Integrity on One Net Drive strength specifies how much current the driver sources/sinks, while the slew rate specifies how fast it sources/sinks the current. Together, these two settings determine the

6.4 Signal Integrity

35

rise and fall times of the output signal. Process technologies with smaller feature sizes allow faster clocks, but faster clocks also signify shorter rise and fall times. This means that switching times are reduced even on low frequency signals as the rise and fall times are set by the technology. This reduction of the switching time comes together with larger transient current; consequently, larger switching noise. For a high fmax link signal, it might be necessary to have short rise and fall times, but for a low fmax link signal, you may reduce the noise by using longer rise and fall times. 6.4.1.2 Crosstalk Whenever a signal is driven along a wire, a magnetic field develops around the wire. If two wires are placed adjacent to each other, it is possible that the two magnetic fields interact causing a cross-coupling of energy between the signals known as crosstalk. The following PCB design techniques can significantly reduce crosstalk: 1. Widen spacing between signal lines as much as routing restrictions allow. 2. Design the transmission line so that the conductor is as close to the ground plane as possible. This couples the transmission line tightly to the ground plane and helps decouple it from adjacent signals. 3. Use differential routing techniques where possible, especially for critical nets. 4. Route signals on different layers orthogonal to each other, if there is significant coupling. 5. Minimize parallel run lengths between signals. Route with short parallel sections and minimize long coupled sections between nets. 6.4.1.3 Rail Collapse Rail collapse is noise in the power and ground distribution network feeding the chip. Switching I/Os can cause a voltage to form across the impedance of the power and ground paths. This effectively causes a voltage drop with less voltage reaching the FPGA, further accentuating the problem. The solution is to design the power and ground distribution network to minimize the impedance of the power distribution system.

6.4.2 Electromagnetic Interference EMI is a disturbance that affects an electrical circuit due to either electromagnetic conduction or radiation. The disturbance may interrupt, obstruct, or otherwise degrade or limit the effective performance of the circuit. The source of EMI is rapidly changing electrical currents. FPGAs are rarely a source of EMI, however the possibility of EMI being generated increases with the use of heatsinks, circuit board planes and cables.

36

6 Board Design

EMI can be reduced on FPGAs through: 1. The use of bypass or “decoupling” capacitors connected across the power supply, as close to the FPGA as possible. 2. Rise time control of high-speed signals using series resistors. 3. VCC filtering. 4. Shielding. This is typically used as a last resort due to the added expense of shielding components. The two most common sources of EMI on boards are: 1. The conversion of differential signal into a common signal, which eventually gets onto an external twisted pair cable. 2. Ground bounce on a board generating common currents on external single-ended shielded cables. These EMI effects can be controlled by grouping high speed signals away from where they might exit the product. The key to efficient high-speed product design is to take advantage of analysis tools that enable accurate performance prediction. Use measurements as a way of validating the design process, reducing risk and increasing confidence in the tools.

6.5 Design Flows for Creating the FPGA Pinout There are two flows that are recommended to successfully create an FPGA pinout for the board design. In both flows there is significant communication between the board designer and the FPGA designer.

6.5.1 User Flow 1: FPGA Designer Driven In this design flow, the FPGA engineer generates the initial FPGA pin-out and provides the FPGA pin-out details to the PCB design engineer. The board design engineer makes suggested pin changes to ease the board design and provides these details to the FPGA engineer. The FPGA engineer makes the pin changes in the FPGA design software and confirms if the changes will work for the FPGA design. This process is continued until a final pin-out is obtained that meets the needs of both the FPGA designer and the board design engineer. In reality the initial pin-out that is developed by the FPGA designer needs to be created with knowledge of the board layout, i.e. the relative location of the board components, such as memories, transceivers, microprocessors, etc. that the FPGA will interface with. The FPGA engineer can then make flexible pin assignments, such as assigning memory interfaces to particular I/O banks and leave the FPGA design software to make the actual pin assignments. This approach will speed-up the pin planning process such that the communication between the board design

6.5 Design Flows for Creating the FPGA Pinout Fig. 6.3  FPGA designer driven flow for creating the FPGA pin-out

37

Step 1.Create Project and Choose Device

Step 2. Add Pins and I/O Properties

Step 3. Define Design Interfaces

Step 4. Make Pin Assignments

Iterative pin changes

Step 5.Perform I/O Rules Checking

engineer and the FPGA designer is basic pin swapping for ease of board design to minimize board trace crossovers, etc. as opposed to large scale changes (Fig. 6.3). Step 1:  This first step occurs in the FPGA design software. The FPGA designer will create an FPGA design project targeting the appropriate FPGA device and package. At this stage it is recommended that the designer enables any device migration capabilities that exist in the FPGA design software to accommodate future design expansion or contraction. Step 2:  The FPGA designer starts to enter pin information based upon the FPGA design. The FPGA design is unlikely to be complete at this stage in the design cycle however the interfaces must be solid. At a minimum, a top-level design file should exist. This provides enough information for the designer to enter the pin names and to start entering properties of the pins, such as I/O standard, current strength, etc. This information can be entered into the FPGA design software manually or in most cases can be imported from other sources, such as Microsoft Excel. The recommendation is that this information is defined in the specification for the design and that the specification enables this information to be available in the .csv format for import into the FPGA design software. This will greatly shorten this process and reduce the risk of human error. If interface IP is being used, some of the IP may already contain the pin properties information. The source files should be added to the design. The FPGA design software can usually read in the pin properties information.

38

6 Board Design

Step 3:  Define the design interfaces by configuring the ports and parameters of any IP being used to make the port connections to the top-level HDL File. As mentioned previously, it is recommended that a top-level design file already exists, however, in the case were the specification is complete and the design file does not exist, some of the FPGA design software solutions can automatically generate a top-level HDL wrapper file based upon the Pin information that is entered in the FPGA design software. The top-level design file is needed to enable I/O rules checking in the FPGA design software. By creating the design interfaces, you are effectively creating a top-level block diagram of the interfaces to the FPGA design. By providing as much design information as possible to the FPGA design software, the more complete the I/O rule checks that can be performed by the FPGA design software. Step 4:  Make the pin assignments. If you know the exact pin locations that you want, you should enter them directly into the FPGA design software. These can often be imported for IP. If you only know the general area of the device that the pin needs to be assigned to, then you can make broader assignments such as I/O Bank 1 and allow the FPGA design software to select the actual pin location. Step 5:  Perform I/O rules checking and generate a valid pin-out. All FPGA design software has an I/O rule checking capability. This should be run to check the validity of the pin assignments. Some of the FPGA design software packages have the ability to generate pin assignments based upon assignments to a specific area of the device as opposed to specific pins. These assignments can be accepted by the user to replace the board assignments and passed to the board designer. I/O rule checking options in the FPGA design software is limited in the mount of rules it can reliably check without a complete design. Hence, it is strongly recommended that you create a dummy design that includes all of the IP for the interfaces and clock network details. The interfaces can be terminated with dummy logic such as FIFO’s where internal design blocks are not yet available. This approach enables the FPGA design software to check all of the I/O rules with confidence that the same pinout can be used when the internal design blocks are added to the design in the future. Steps 4 and 5 are now performed iteratively until an FPGA pinout is achieved that works on both the FPGA and the board. As the design becomes complete any potential pin-out issues should be communicated back to the board designer and changes made at either the board or FPGA design level. Changes will not be required for dummy designs that are representative of how the final design will communicate with the pins in the FPGA.

6.5.2 User Flow 2 In this design flow, the PCB design engineer generates the initial FPGA pin-out in the board design software and provides the FPGA pin-out details to the FPGA design engineer. Optionally the Board Design Engineer can run the FPGA design software to enter the pin details. In reality this is rarely the case unless the same

6.5 Design Flows for Creating the FPGA Pinout

39

engineer is performing both the FPGA and board design. The FPGA design engineer makes the pin assignments in the FPGA design software and confirms if the assignments will work for the FPGA design. If there is an issue with the assignments, the FPGA design engineer makes suggested edits that the FPGA design software shows to be legal and feeds these changes back to the board designer. This process is continued until a final pin-out is obtained that meets the needs of both the FPGA designer and the board design engineer (Fig. 6.4). Step 1:  The board designer creates the FPGA pin assignments based upon the components on the board that will interface with the FPGA. This requires details on drive strength and clock restrictions on the FPGA. In reality the Board designer will work with the FPGA designer on this step, asking questions on where the transceivers are located on the device, power rail requirements and other possible restrictions to pin-out. The board designer will then create a first pass at creating the pinout and pass this information to the FPGA designer. Step 2, 3 and 4:  This is the same as steps 1, 2 and 4 in user flow 1. The FPGA designer will create the FPGA project, make the pin assignments and assign the pin properties. Step 5:  The FPGA designer can run the I/O rule checker to validate the pin assignments and communicate any recommended changes back to the board designer. This process will continue until a satisfactory pinout is achieved. As in user flow 1, the FPGA

Step 1.Create Pinout in Board Design Software

Step 2. Create FPGA Project & Choose Device

Step 3. Add Pin Properties

Iterative pin changes

Step 4. Make Pin Assignments

Step 5.Perform I/O Rules Checking

Fig. 6.4  Board designer driven flow

40

6 Board Design

designer should create a dummy design or use the real design to ensure that the pin-out will work.

6.5.3 How Do FPGA and Board Engineers Communicate Pin Changes? There is a tendency to communicate the pin-out changes verbally or via email. However, this approach is prone to error. There needs to be an official document which resides in version control that is used to communicate the changes between the board designer and the FPGA designer. As mentioned earlier in this chapter, Microsoft Excel tends to serve this purpose in many Companies. One of the advantages of using Microsoft Excel is that many of the board design tools and some of the FPGA design software can import and export .csv files.

6.6 Board Design Check List for a Successful FPGA Pin-Out 1. Perform Power Thermal Analysis to ensure that all power planes can deliver the maximum current required while keeping the voltage rail within specification. 2. Perform pin assignment checking. a. Check pin assignments in FPGA design software b. Terminate unused inputs to Ground c. Terminate unused I/Os as desired d. Check correct VCCIO for each I/O bank e. Does design meet the SSN guidelines? f. Select migration devices to accommodate future design growth or reduction 3. Perform configuration mode check against vendor configuration handbook. 4. Check Power supply connections and decoupling against vendor power supply recommendations. 5. Perform board Signal Integrity simulations. 6. Compare I/O Timing to I/O Timing Requirements. This requires the design to be complete or at least the I/O interface portions of the design. 7. Complete board design review between FPGA design team and PCB design team.

Chapter 7

Power and Thermal Analysis

7.1 Introduction The increase in density and performance of FPGAs has resulted in an increase in power consumed by the FPGA. Both FPGA and PCB design engineers need to consider the power when making the choice to use an FPGA and a particular FPGA vendor, as the power consumed by the FPGA will impact the design of the PCB power supplies, choice of voltage regulators, the heat sink and the system’s cooling system. In short, it is crucial in developing the power budget for the entire system. For applications that are power sensitive and where it is anticipated that meeting the power budget will be tight, the design engineer needs to perform power analysis during the development of the design and deploy power saving techniques as appropriate. Throughout the design cycle, the engineers need to be able to refine the estimates and apply the appropriate power management design techniques. Today’s FPGAs come with a variety of features for reducing the FPGA power, including power optimization options in the FPGA design software. Details on power optimization techniques are covered in the RTL coding guidelines and Timing Closure chapters of the book. FPGA vendors also provide solutions for estimating the power that will be consumed by the FPGA at different stages of the design flow. In this chapter we will review the basic elements of power consumption in FPGA devices, as well as the main factors that impact the ability of a designer to obtain an accurate estimation of a design’s power consumption. We will look at the tools and techniques for performing power estimation very early in the design cycle, in order to enable the right choice of FPGA technology and to select the right power regulators and components for the board design. Then we will examine the tools and techniques to enable you to perform a more detailed power estimation based upon the design implementation. Finally we will review the best practice recommendations for dealing with power in FPGA designs.

P. Simpson, FPGA Design: Best Practices for Team-based Design, DOI 10.1007/978-1-4419-6339-0_7, © Springer Science+Business Media, LLC 2010

41

42

7 Power and Thermal Analysis

7.2 Power Basics Thermal power is the component of total power that is dissipated within the device package. Designers need to consider the thermal power in determining whether they need to deploy thermal solutions on the FPGA, such as heat sinks, to keep the internal die-junction temperature within the recommended operating conditions. The total power consumed by a device, considering its output loading and external termination, is comprised of the following major power components.

7.2.1 Static Power Static power is the power consumed by a device due to leakage currents when there is no activity or switching in the design. This is the quiescent state. This type of power is often referred to as standby power and is independent of the actual design. The amount of leakage current depends upon the die size, junction temperature, and process variation. This data can be extracted from the FPGA device data sheet or from the vendors Early Power Estimation Spreadsheet. It is recommended that you extract the data from the vendors Early Power Estimation Spreadsheet as the data is generally reported in a much clearer format than in most data sheets.

7.2.2 Dynamic Power This is the power consumed through device operation caused by internal nodes in the FPGA toggling. That is, the charging and discharging of capacitive loads in the logic array and routing. The main variables affecting dynamic power are capacitance charging, supply voltage, and clock frequency. A large portion of the total dynamic power consumed in FPGAs is due to the routing fabric of the FPGA device. Dynamic power is design dependent and is heavily influenced by the users RTL style.

7.2.3 I/O power This is the power consumed due to the charging and discharging of external load capacitors connected to the device output pins and any external termination networks. Again, I/O power is design dependent and is impacted by the I/O standard, data rate, the configuration of the pin as either input or output or bidirectional. The termination on inputs, and the current strength, slew rate and load for outputs impact the I/O power.

7.3 Key Factors in Accurate Power Estimation

43

7.2.4 Inrush Current Inrush current is the current, hence power, that the device requires during initial power-up. During the power-up stage, a minimum level of logic array current (ICCINT) must be provided to the device, for a specific duration of time. This duration depends on the amount of current available from the power supply. When the voltage reaches 90% of its nominal value, the initial high current is usually no longer required. As device temperature increases, the inrush current required during power-up decreases, however the standby current will increase.

7.2.5 Configuration Power Configuration power is the power required to configure the device. During configuration and initialization, the device requires power to reset registers, enable I/O pins, and enter operating mode. The I/O pins are typically tri-stated during the power-up stage, both before and during configuration in order to reduce power and to prevent them from driving out during this time.

7.3 Key Factors in Accurate Power Estimation Before discussing the best approach to performing power and thermal analysis for an FPGA design, we will look at the key factors for accurate power estimation (Fig. 7.1).

Operating conditions & device characteristics

Toggle rates & signal probabilities (from simulation, user entry and/or vectorless techniques)

Power models of circuitry

Fig. 7.1  Key elements in accurate power estimation

Power Report

44

7 Power and Thermal Analysis

7.3.1 Accurate Power Models of the FPGA Circuitry These are the models that are provided by the FPGA vendors as part of their power estimation solutions. The FPGA design engineer must trust that the FPGA vendor is being honest with the models. These models are typically developed from HSPICE and the models correlated with silicon characterization. This process varies slightly across FPGA vendors. The accuracy of the models will vary depending upon the maturity of the FPGA family. If the FPGA family is new to the market, the power models will be preliminary and subject to change as the FPGA vendor completes characterization of the family. The negative impact of the variation should be minor if the FPGA vendor is conservative in the development of the initial HSPICE models. Asking the silicon vendor for details on how they develop their power models will help set your expectations on the accuracy of the models.

7.3.2 Accurate Toggle Rate Data on Each Signal Toggle rate data, also referred to as Signal Activity, relates to the performance of the design. While clock speed is important, the average number of times that a signal changes value per unit of time is more important as this transition impacts the power consumption. A logic ‘1’ condition consumes more power than a logic ‘0’, thus the amount of time that a signal is logic ‘1’ will impact power. This tends to have an impact on I/O power on pins that use terminated standards. Toggle rate data is under the control of the FPGA design engineer, in that it is dependent upon system operation. This information is usually derived from design simulations or toggle rates which are based upon previous design experience. As such, entering reasonably accurate toggle rate data is an easier task for designs that are derivatives of previous designs than for new designs. I cannot overemphasize the importance of using toggle rate data that is reflective of the end system operation, as gross inaccuracy in the prediction of the toggle rate is the main source of error in power estimation. In many cases, the simulation data fails to represent real world operation. If simulation is performed for the purpose of measuring code coverage, it is likely to over predict the power that will be used in operation. As a designer, you need to avoid the dangerous situation of under predicting the toggle rate, as this will result in an under estimation of power. However, an over prediction of power may result in a more expensive power management solution. The power estimation solutions from the FPGA vendors assume a default toggle rate of 12.5% unless specified otherwise by the FPGA design engineer. For many applications, this is sufficient very early in the design cycle, as most designs do not have a high toggle rate on all nodes, and the end application is specified to cope with a margin of error within 30% of the total power. However, this may not be the case for designs in which the majority of the design performs high performance

7.3 Key Factors in Accurate Power Estimation

45

processing, as is the case in many DSP processing applications. These designs will typically exhibit a higher toggle rate. The FPGA vendor power estimation solutions allow you to easily change the toggle rate values and to quickly see the impact that it has on power. It is recommended that you do what you can to correctly estimate the toggle rate for your application. It is also recommended that if you are not sure of the toggle rate that you try a range of toggle rate values to indicate a possible best case and worst case scenario. Note that it is unlikely that a complete system design will have a toggle rate above 40%.

7.3.3 Accurate Operating Conditions When we look at the impact of temperature on standby power, particularly for devices at process geometries of 65 nm and below, we can see that there is a dramatic increase in power above Tj of 85°C (Fig. 7.2). Temperature has a big impact on static power, as the leakage power is an exponential function of Tj. High leakage increases Tj, which, in turn, further increases the leakage, forming a potential positive feedback loop. Tj = Ta + qja × (standby power + dynamic power) where Ta is the ambient temperature, and qja is the thermal resistance between the device junction and ambient air. It is essential to ensure that the junction temperature remains within its operating range and does not enter a positive feedback loop. The more power a device consumes, the more heat it generates and this heat must be dissipated to maintain operating temperatures

Standby Power

Standby Power vs. Temperature

Adequate Heat Dissipation

85°

65°

25°

50° 75° 100° Junction Temperature (°C)

Insufficient Heat Dissipation Curve affected by Heat Sink & Cooling System 125°

Lower Temperature = Lower Power © 2005 Altera Corporation - Confidential 4

Fig. 7.2  Graph of standby current versus temperature

46

7 Power and Thermal Analysis

within specification. For the FPGA and board designer it is essential that this is modeled during power estimation and that the tools used to calculate the power consider the heatsink used, air flow and other factors to correctly model Tj. Thus it is important that the FPGA and/or board design engineer uses the appropriate thermal management technique to minimize power consumption.

7.3.4 Resource Utilization There is a fourth element that impacts power and that is the utilization of the resources in the FPGA device. In general, the more logic used, the more power consumed. However, as a designer you need to be aware of the impact of the different types of resources in the FPGA device on power. As the designer or implementer, you have the ability to trade-off resource type usage, e.g. Logic element usage versus dedicated hardware blocks, such as RAM and DSP Blocks. If you look at a typical FPGA design, approx. 65% of the power is core dynamic power, 24% is core static power, 10.5% is IO dynamic power and about 0.5% is IO static power. If we dig into the core dynamic power in more detail, the majority of it can be attributed to routing and combinational logic in the logic elements. RAM blocks also consumes significant dynamic power. The dynamic power for the clock networks consists of the global clock routing resources plus the power consumed by the local clock distribution within the LEs, RAM and DSP blocks. Designers can control the dynamic via the choice of resource type and the use of clock control blocks. This is discussed in more detail in Chap. 12.

7.4 Power Estimation Early in the Design Cycle (Power Supply Planning) As mentioned previously, FPGA Vendor data sheets do not provide much data on the typical power consumption of an FPGA family. FPGA vendors do however provide Power Estimation tools to report the power for a given device. Early FPGA power estimation helps guide power supply design for the board. More often than not, this task needs to be performed before the FPGA design is complete or started. The power estimation spreadsheets provided by the FPGA vendors can be used to estimate the power for your design and to perform preliminary thermal analysis on your design at various stages of the design cycle. Figure 7.3 shows a sample power estimation spreadsheet for the Altera Stratix® IV GX family The vendor provided spreadsheets are based upon Excel and can be downloaded from the FPGA vendor website free of charge. The accuracy of the power estimation increases as you provide more information that is indicative of your operating conditions

7.5 Simulation Based Power Estimation (Design Power Verification)

47

Fig. 7.3  Sample power estimation spreadsheet for the Altera Stratix IV GX family

and of the final design. The maturity of the devices will also impact the accuracy, i.e. are the vendor power models final or preliminary. With minimal effort this can provide a good ballpark estimate on power, i.e. within 30% of real numbers; enabling you to choose the right FPGA technology for your application and to specify the power supply design. By investing more time on entering more detailed data on your design and operating conditions, you can typically get within 20% of the real power. These tools allow designers to enter details on their design and operating conditions. Some of the FPGA vendor tools have the capability to import data from their compiled designs into the Power Estimation Spreadsheet. This feature works well for partial designs or estimating power based upon legacy information. This information serves as a starting point and the details, such as the different resource counts, number of clocks, etc. can be edited in the spreadsheet to reflect the expected size and characteristics of the final design. This is a much quicker and less error prone approach to entering data by using the power estimation and analysis solutions that exist in the FPGA vendor software as discussed in Sect. 7.5.

7.5 Simulation Based Power Estimation (Design Power Verification) Simulation based power estimation provides the most accurate power estimation solution, providing the simulation vectors are representative of real system operation. Simulation based power estimation uses the results from running a simulation

48

7 Power and Thermal Analysis

in standard EDA tools, such as Mentor Modelsim, Synopsys VCS and Cadence Incisive, to name a few, in order to simulate the device operation. The resulting simulation data is used as stimulus to the FPGA vendor simulation based power estimation tool. A Vector Change Dump (VCD) file is normally used to transfer the data from the EDA simulation tool to the FPGA vendor software. The reason why the power estimation solution in the FPGA vendor software is more accurate than the spreadsheet power estimation solutions is that full Place and Route has been completed on the design and at this point the modeling takes into account the actual placement and the routing types used on the design. The ability to use real life operation vectors also has a large impact on the accuracy of the estimation. Having a design plus accurate simulation vectors implies that the design is complete or is very close to being complete. Therefore it is recommended for most designs that this type of analysis is run towards the end of the design cycle to determine what the real power consumption is for the design. Thus, it is more of a sanity check that the design is within power budget rather than something that is run continuously throughout the design cycle. An exception is power sensitive designs where this data can be used to determine if the RTL needs to be optimized for power or whether to utilize power optimization options that exist in the FPGA vendor software. Simulation based power estimation can be run early in the design cycle on blocks of RTL that already exist to determine the toggle rate on these blocks for use in the spreadsheet based power estimation solutions. The power report on these blocks of reusable IP can also be included in the documentation on the blocks to give other users of the design blocks or IP, background data on the expected power consumption for the block. One of the challenges with simulation based power estimation is that the most accurate power estimation is based upon gate level simulation of the design, as the toggle rate data from the simulation will be available for every node in the design. However this type of simulation tends to be runtime intensive for certain application spaces, such as video and image processing. So while this type of analysis provides the most accurate power results, the simulation time may make it impractical for certain applications. Thus, it is recommended that RTL simulations be used for these types of applications. Gate level simulations can be run as a sanity check on the design, i.e. only to model certain operating conditions of the design. It is recommended that you use gate level simulation if the simulation time is feasible for your end application. An RTL simulation will contain the correct toggle rate on the I/O pins and on most of the registers. There will be some level of inaccuracy on the registers as synthesis will perform register duplication and register merging as part of its optimizations. The combinational nodes will also be inaccurate as the names will not match due to the optimizations performed. This however is not a huge issue, as most of the simulation based power estimation solutions contain a mode called vectorless estimation, which can be combined with RTL simulation based estimation to provide an acceptable level of accuracy. Vectorless power estimation uses a statistical analysis approach to predict the probability of the nodes between known good data points toggling. If we look at the

7.5 Simulation Based Power Estimation (Design Power Verification)

49

circuit in Fig. 7.4, if we know the static probabilities and toggle rates of inputs A, B, C, D, E, F, G and H, it is possible to estimate the static probabilities and toggle rates at I, J, K, L; hence the final output M. This capability can be used to enhance the accuracy of RTL simulation based estimation. As part of best practices we recommend running a sample of gate level simulations, but for long simulations, RTL + Vectorless estimation is the recommended approach. It is also advised that you perform simulation based estimation at certain checkpoints throughout the design process. In reality, at this stage in the project this should be more of a sanity check rather than a necessity. After performing the early power estimation, you ought to have left sufficient headroom on the power budget such that you are not constantly optimizing your design for power. As with Early Power Estimation, you need to vary the operating conditions in terms of temperature and voltage, to ensure that you are reflecting the real world operating conditions. The simulation based power estimation tools generate reports aimed at facilitating both thermal and power supply planning requirements. These reports pinpoint which device structures and even design hierarchy blocks are dissipating the most thermal power, thus enabling design decisions that reduce power consumption. This provides very high quality power estimates which are usually within 20% of device measurements, provided the toggle rate data is accurate (Fig. 7.5).

A B C D E F G H

I M J L K

Fig. 7.4  Probability of nodes toggling

Fig. 7.5  Sample power estimation report from Quartus II PowerPlay Estimator

50

7 Power and Thermal Analysis

7.5.1 Partial Simulations One of the challenges in a simulation based approach to power estimation is the initialization time in the testbench and hence simulation. This can reduce your effective toggle rate if the simulation is not run to reflect a long period of operation. You can perform a simulation where the entire simulation time is not applicable to the signal activity calculation, reducing the accuracy of the estimation. For example, if you run a simulation for 10,000 clock cycles and reset the chip for the first 2,000 clock cycles. If the signal activity calculation is performed over all 10,000 cycles, the toggle rates are typically only 80% of their steady state value (since the chip is in reset for the first 20% of the simulation). Some of the FPGA vendor solutions allow the user to specify the useful parts of the .vcd file for power analysis, enabling you to ignore the initialization stage as part of the power estimation.

7.6 Best Practices for Power Estimation See Fig 7.6.

Stage of Design Cycle

Task

Tools

Device Selection

Legacy Designs Previous Experience Design Specification FPGA Vendor Power Estimation Spreadsheet Early RTL code

Additional Content

Board Power Supply Specification

FPGA Vendor Power Estimation Spreadsheet Legacy Designs Previous Experience Design Specification Early RTL code FPGA Vendor Board Design Guidelines FPGA Vendor Power Estimation Spreadsheet

Early Power Estimation

Evolving Design

Final Design

Board Design Spot check Power Based Upon Evolving Design Estimate Power for Power Optimization Determine Final Power Estimate Power for Power Optimization

Measure Power on Board

Fig. 7.6  Best practices for power estimation

FPGA Vendor Board Design Guidelines FPGA Vendor Power Estimation Spreadsheet HDL Design Testbench FPGA Vendor Simulation Based Power EDA Simulation Tools Estimation Tool HDL Design

FPGA Vendor Simulation Based Power Estimation Tool

Testbench EDA Simulation Tools Final Board and Test Equipment

Chapter 8

RTL Design

8.1 Introduction The high level challenges that designers face when writing RTL for FPGA devices are similar to the challenges that are faced when writing RTL code for ASICs. 1. What is the goal for my design block? 2. Am I trying to achieve the highest performance or smallest area? 3. Is my code functionally correct and is it easy to synthesize in the target synthesis tool? 4. Is my RTL code reusable? 5. Is my design easy for place and route to successfully compile the design? There are however unique high level goals that apply to writing RTL for FPGAs. 1. Is my RTL optimized for the target FPGA architecture or can the RTL be targeted across multiple FPGA architectures? 2. Is my RTL optimized for compile time? As we look in more detail at writing RTL for FPGAs, we come across more differences compared to writing RTL for ASICs. These differences are due to the architecture of FPGA devices. This provides us with the first rule of writing RTL for FPGA devices; “understand the architecture of the target FPGA.” This chapter provides getting started tips to designers of various backgrounds. It describes some general FPGA architecture features, before covering general good practices in writing RTL. It then provides RTL coding guidelines that are optimized for FPGA architectures, before ending with a summary of best practice recommendations of RTL design for FPGAs.

8.2 Common Terms and Terminology HDL: Hardware Description Language is a software programming language that is used to model a piece of hardware. P. Simpson, FPGA Design: Best Practices for Team-based Design, DOI 10.1007/978-1-4419-6339-0_8, © Springer Science+Business Media, LLC 2010

51

52

8 RTL Design

RTL: Register Transfer Level, defines input-output relationships in terms of dataflow operations on signals and register values. Behavior Modeling: A component is described by its input-output relationship. Only the functionality of the circuit is described and not the structure of the end implementation. There is no specific hardware intent and the coding style is generic such that it can target any technology (Fig. 8.1). Structural Modeling: A component is described by interconnecting lower-level components and primitives. It describes both the functionality and structure of the circuit. It is created with the implementation of the hardware in mind (Fig. 8.2). Synthesis: This is the translation of HDL to a circuit and then the optimization of the circuit. Basically the RTL description of your design is interpreted and hardware created for the targeted FPGA architecture. The synthesis tools require certain coding styles to generate correct logic. The coding style is important for fast and efficient logic (Fig. 8.3).

output1, .., outputn

input1, .., inputn

if (input1) for (j=0, j