Characterizing FPGA Design Practices and Methodologies

Characterizing FPGA Design Practices and Methodologies B.Mody 1, N. Kyriakopoulos1, N. A. Alexandridis1 and M. Younis2 Dept. of Electrical and Computer Engineering The George Washington University1 Dept. of Computer Science University of Maryland, Baltimore County2 P-80

Outline • Scope and Motivation • FPGA Design Categorization • FPGA Design Methodology • Design Practice Categorization • Relating faults to Design Practices • Fault Taxonomy • Dependability Critical Design Practices • More on Design Practices • Summary P-80

Scope and Motivation • There is a pressing need for using a more structured approach to design FPGA based systems • There is a definite lack of specific guidelines for FPGA technology based design • This is one of the principal reasons for FPGA design failure • Our approach revolves around characterizing FPGA design practices and establishing their relation to faults using a Fault Taxonomy model P-80

Definitions • Schön (1987) characterizes design practice “as ‘a protracted conversation with the situation,’ in which designers embody their ideas in some representational medium, reflect on them, and then modify them”. • Thimbley (1990) makes the suggestion “that work by an individual is a special case of cooperative work -- reflexive cooperative work -- in which various concrete artifacts support individuals in collaborating with themselves over time”. • Such is the nature of design practices where every designer has their own process on how to apply the design P-80

FPGA Design Methodology • Design Stage • Involves an abstract representation of the system connections and their description • Implementation Stage • Mapping of the abstractions produced in the design stages to the FPGA Note: The process is iterative and we are making this distinction to create a basis for characterizing design practices P-80

FPGA Design Practice Categorization • This is an overall categorization of practices involved in the design of an FPGA based system based on the design flow • The Practices indicate the classes • The detailed description gives the attributes of each class P-80

Critical Practices • This figure gives a view of Critical Practices • By the term ‘critical’ we are mean those practices in design that can have a direct effect on the reliability of a design if they are not followed correctly P-80

There is a direct relation between minimizing errors and following correct practices A fault means a defect in the system, namely, a deviation from the specified system parameters Some dictionary definitions of an “error” can be stated as follows An act, an assertion, or a belief that unintentionally deviates from what is correct, right, or true The condition of having incorrect or false knowledge A mistake Other definitions include the improper design performance in terms of speed/area/power/electrical interfaces/radiation/fault recovery These definitions point to errors introduced during the various stages of the design process A few examples of this relationship between errors and practices are given Poorly documented requirements could be the cause of errors attributed to incorrect or false knowledge or to a belief that deviates from what is correct, right or true Poor coding standards and style that makes the code very difficult to communicate, read and debug could be the cause of errors attributed to deviation from an accepted code of behavior Poor use of tools, such as editors of linting tools, which verify the sanity of the code, could be the cause of Simple mistakes, such as syntax errors Design – Errors & Faults P-80

Fault Taxonomy • Fault Cause • Attributes in this class which indicate the reason why a fault may have resulted in an error can be directly traced to the design practice categorization as Specification Mistakes, Incorrect Design • Fault Source • The source of a fault could be in the circuit description or in the design stages which can further be classified as tool faults or programming practice faults. In contrast hardware faults map to the manufacturing stage of the design flow P-80

Failure & Design Practices P-80

Failure & Design Practices • It is clear from the table that there is a direct relationship between failure in an FPGA and the design practices that have been followed • We can also observe from the table that based on the findings from our industry survey that majority of the failures have been caused by not following the practices that we had earlier identified as critical to producing a reliable design • Designers therefore need to lay particular emphasis to make sure that these critical practices are followed in the correct manner P-80

Design Migration Issues (ASIC FPGA) • FPGAs provide flexibility in terms of the overall system design • FPGA Re-programmability saves many ASIC mask turns and therefore product market windows • This gives rise to faster, better, cheaper (FBC) paradigm of design • We would like to raise the question like several others before us ‘at what cost?’ • Migration issues are usually not considered important by several design teams • A large amount of time and energy can be saved if ASIC engineers design with migration in mind as planning for migration could eliminate the time and effort spent in relearning the circuit and uncovering potential errors from an ASIC design point of view P-80

Some issues that indicate why design practices are important to the design process are Increase in productivity and time to market Early planning will save time/effort later by resolving system specification, memory, and testing issues. Many errors are created if one skips too many design planning steps. There are significant differences in bug rate and maintainability of well designed RTL vs. poorly designed RTL. A typical design schedule and documentation. If a bug is caught in early stages, as a part of a schedules process, it will be dealt with in a timely and efficient manner. Writing a requirements document allows the client to understand what is being produced. Writing a specification document helps set a clear goals for the designer and help him or her envision the structure of the design Surveys of development organizations have found the same problems afflicting many projects some of which can be stated as Poorly written System Requirements Documents (SRDs) A lack of adequate hardware and software development and test tools Inaccurate and overly aggressive development schedules On the other hand a well-designed methodology can set standards for project documentation, address staffing and scheduling issues. One of the main requirements for an organization to establish a useful design methodology is that the projects development life cycle has to be explicit. Why design practices are important? P-80

Design Implementation & Management • It is important to have an experienced team or at least a minimum number of experienced members that can guide the design implementation • A design guideline document that is easy to read but at the same time defines design rules is essential • A good and consistent naming convention which serves to provide information about objects and about the handling and timing of information implied by those objects • An exception handling mechanism for error conditions that may be detected and managed by hardware with the possible co-operation of software • Version control software for Design Management helps to reduce errors because it automates the storing, retrieval, logging, identification, and merging of revisions. P-80

Perceptions in Design • The perceived view of the amount of time spent on various stages of FPGA design and development is quite different to the actual time one spends in that stage • For example, contrary to popular belief the most amount of time is spent in debugging and tuning the design whereas only a small percentage of time is actual time is spent in partitioning and implementation • This affects scheduling and time to market as designers with bad planning in the earlier stages of design are bound to face difficulties in the latter stages • With regards to time spent on the requirements phase the perceived and actual measured time are in close agreement • However in either case the amount is a very small fraction of the total development time • The most worrying factor is that much needless time is consumed later in the project because of bad or ambiguous requirements • The only real solution to this is to spend more time in the initial stages of design which would in effect reduce the time and effort required in the debugging and tuning phases P-80

Design Practices Wish List • Designers should stop approaching FPGA design in a ad-hoc manner • Instead of using trial and error to solve design issues they should follow the sound principles of design that can be adapted from other fields such as ASIC design • Make a clear distinction between the design stage and the implementation stage and accordingly make necessary adjustments to suit the two stages • Follow documentation guidelines so that there is no ambiguity with regards to the design and anyone replacing the current design team can continue without any major problems • Avoid certain practices early in the design to prevent them from magnifying later P-80

Summary • Using a broad Design Practice Categorization we narrowed these practices down to certain critical design practices • Using our Fault Taxonomy we were able to confirm that failures in different application/devices could directly be mapped to the critical design practices • By following design practices in a structured manner it may become possible to standardize FPGA design and make it more of a science than the ‘art’ that it is commonly perceived as today P-80

Characterizing FPGA Design Practices and Methodologies