1.2..er Mp... .31.. x .1 .. . . .r . . a .3... :11... . T 1112...... h 5. 25.311. .11 . .1 .1. .i... I. z _ . 111. 1. . a. 1 19...? xx? 14 . Tfiwflkkuuf! . . 2 . 51:41:... )1 i 3 11.1 I 1.: .1..... y 3.. z .1. .1..-alt: 1y .3 I..I1:r.. 3.1-1.3511. 1.1.. .1 1. 11 11 121:3;311 1..va I}: I , 3...... 1...: if i 112...}...31 x , . . $.52: .- 111.. .11. 1. 1.2.5.311 \ >115. a: .3 Ixxawxus. 1‘11: 2 31133.11 . 72:. r y . 12x1 . . z...- 1tzl 1.5!: 1.. 1...." 13:..11 11...: I 1.31. ( y 1 ¥ 7...!!! .txfsrxxltl .\I 11131;: . 7.2.1:: :1: 111.11.. 2:21.... 3.. 1.1.33.1.931 51...». 1:. 5.... :1 3:... . 1.. .111 . a :1: 11:111.? II I. . IIXlu)II :v)llasa.£.lb7luu {.1va .1... J 3.131131 5.3.51.5; :11 3:1111 (1:31.... v 151)! s: x: I. 111....nrycrvfi13‘: :v x5111. 1.32.11. 1 11. '1..sz .. 11.. 13...? 2.1.; .. .11.)..117-3. l7 1:174:1Cl II 11 a .. 13.1.: 1,137.5... 2:1 32.1.5.1}. F ....\ .11....1...” . I. _ 5.3.... :fizfirhn Lrsnun1.§$&1 xfiauanuéizagi M I {L 111‘ i z..- 4‘31. n 13“»! \RI3’nuufln21-Hndgl\nd£wa 5... 1 if... r .11": $1.151... tiny I 11.1.1.9!!! .1. rift—zqu-‘fi. . l¥x:.:lia|£ 41.. .1’31Si 1..) THESlfi Willi“lililllillllli 1 31293 015 This is to certify that the thesis entitled IMPLEMENTING DIGITAL DESIGNS USING PLDS presented by Tracie Yvette Green has been accepted towards fulfillment of the requirements for MS degree in Electrical Eng .N Major professor Date 7/17/97 O~7639 MS U is an Affirmative Action/Equal Opportunity Institution LIBRARY Michigan State University PLACE IN RETURN BOX to remove this checkout from your record. TO AVOID FINES return on or before date due. DATE DUE DATE DUE DATE DUE I IL..— ___'_ .I If; _ I |I__JL___IL__I I l I; ll MSU Is An Atfirmative Action/Equal Opportunity Institution WmmunS-m IMPLEMENTING DIGITAL DESIGNS USING PLDS BY Tracie Yvette Green A THESIS Submitted to Michigan State University in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE Department of Electrical Engineering 1997 ABSTRACT IIVIPLEMENTING DIGITAL DESIGNS USING PLDS BY Tracie Yvette Green Digital design with FPGAS and CPLDs have become the trend among engineers. The faster tum-around times and easier testing cycles have made it possible for even the most complex of systems to be prototyped in a matter of months, weeks, and sometimes days. Their impact on digital technology has been phenomenal and will continue to push digital technology into higher limits as more engineers become equipped to utilize not only these devices but also the software tools used to program them. This paper discusses the trends of the FPGA and CPLD market and provides a practical approach to implementing a design on one of these devices. It also provides sound evaluation methods for setting up an environment which takes full advantage of what FPGAS and CPLDs have to offer. This paper is dedicated to my parents, Barbara and Robert Green, and in loving memory of my friend, Talisha Nicole Morris. iii ACKNOWLEDGEMENTS A special thank you is extended to my friends, family, and faculty who supported me throughout this research project. Special recognition is given to Pastor H. L. McClendon whose continuing guidance and support was instrumental in enabling to complete this work. Most importantly, special recognition and thanks goes to my advisor, Dr. P. D. Fisher, whose patience, encouragement, guidance, and support were essential in allowing me to finish this project, and to whom I owe a great amount of gratitude and appreciation. iv TABLE OF CONTENTS List of Tables List of Figures CHAPTER 1: INTRODUCTION 1.1 Problem Statement 1.2 Approach 1.3 Expected Contributions 1.4 Organization of the Thesis CHAPTER 2: BACKGROUND 2.1 FPGA (Field Programmable Gate Array) 2.2 CPLD 2.3 Comparison between an FPGA and CPLD 2.3.1 Siginificant Physical differences 2.3.2 Relative Strengths and Weaknesses 2.4 WorkView Office 7.2 2.5 Falcon Framework 2.6 Comparison of Falcon Framework and WorkView Office 7.2 2.7 XACTstep V6.0.1 2.8 Summary CHAPTER 3: DESIGN FLOWS 3.1 Fundamental Learning Curves 3.2 Design Process for FPGAS 3.2.1 Design Entry 3.2.2 Design Implementation 3.2.3 Design Verification viii 10 13 14 16 18 22 26 35 38 39 3.3 Linking an EDA tool(WorkView 7.2 ) and an FPGA vendor tool (XACTstep) 3.4 Summary CHAPTER 4: DEMONSTRATION PROJECTS 4.] Combinatorial: Multiplier design 4.1.1 Design specifications 4.1.2 Design process 4.1.3 Results 4.1.4 Problems encountered 4.2 Sequential Design : Counter 4.2.1 Design Specifications 4.2.2 Design Process 4.2.3 Results 4.3 Processing unit 4.3.1 Design specifications 4.3.2 Design Process 4.3.3 Results 4.3.4 Problems encountered and their resolution 4.4 FIR filter 4.4.1 Design Specifications 4.4.2 Design Process 4.4.3 Results 4.4.4 Problems Encountered CHAPTER 5: SUMMARY AND CONCLUSIONS 5.1 Problem Restatement 5.2 Contributions 5.2.1 Checklists for the implementation of designs on PLDS 5.2.1.1 Design methodologies 5.2.1.2 Checklist for choosing PLDS (FPGAS and CPLDS) 5.2.1.3 Checklist for developing EDA environments 5.2.3 Problems that could be encountered and their resolutions. 5.2.4 Raised level of awareness concerning PLDS and EDA environments 5.3 FUTURE WORK APPENDIX A (LIST OF FPGA/CPLD AND EDA SOFTWARE VENDORS) vi 58 62 63 64 64 65 66 66 68 68 68 69 70 70 70 71 72 74 74 74 75 76 79 79 79 80 8O 8 l 83 84 87 87 89 APPENDIX B (DEMONSTRATION PROJECTS) 91 LIST OF REFERENCES 134 vii Table l: WorkView Office 7.2 Tools Table 2: Falcon Framework Tnnls LIST OF TABLES 19 73 Table 3: Common Tools Between WorkView Office and Falcon Framework 78 Table 4: Falcon Framework Tools not Available in WorkView Office 70 Table 5: WorkView Office Tools not Available in Falcon Framework 17 Table 6: Prices For Falcon Framework and Workview Office 7.2 1% 36 Table 7: XACTstep Tnnls viii LIST OF FIGURES Figure 1: Basic FPGA Architecture .............................................................................................................. 6 Figure 2: Configurable Logic Block (XC4000) ............................................................................................. 8 Figure 3: Architecture of XC7 300 ............................................................................................................... l 1 Figure 4: Learning Chart .............................................................................................................................. 41 Figure 5: Design-Flow Options .................................................................................................................... 44 Figure 6: Simulation data for Multiplier ...................................................................................................... 97 Figure 7: Schematic for Counter ................................................................................................................ 103 Figure 8: Simulation Data for Counter ....................................................................................................... 104 Figure 9: Schematic for Processor ............................................................................................................. 108 Figure 10: Simulation data for Processor ..................................................................................................... 109 Figure 11: Schematic for FIR filter .............................................................................................................. 120 Chapter 1: INTRODUCTION As silicon technology continues to advance, digital design begins to infiltrate markets that were at one time off limits [1]. Communication, military, data processing, and consumer applications are only a few examples of how digital circuits in the form of ASICS have simply revolutionized every aspect of human life. Designers are no longer spending vast amounts of time in the layout and verification phases of digital design. This reduction of the time spent in those phases has allowed automobile designers more flexibility to use digital circuits in a broader range of applications [2]. N 0 longer can business offices function as usual. Meetings that often required several hours of travel, only require a video camera and a multimedia interface. Important messages can be mailed electronically as opposed to being delivered by a special courier. Even those people who are strictly analog designers cannot deny that digital technology has taken the world by storm. What has caused this seemingly whirlwind turn of events? One important answer is the development of the Field Programmable Gate Array (FPGA) and the Complex Programmable Logic Device (CPLD). These two devices have added a degree of flexibility to the digital design market which at one time seemed like a mere dream to some engineers. Designers are currently placing designs, encompassing thousands of gates, on a single chip. Complete systems are now done within months rather than years. The terms “Reconfigurable” and “Rapid Prototyping” have become the buzz words of the digital industry [3]. These devices have pushed digital design to new heights, a change welcomed by every designer. Along with technological growth, there comes a situation which can be described as “growing pains”. Since the introduction of the FPGA and CPLD, many vendors have come out with what they think is the best device. While there are many FPGA vendors, the two leaders in the market are Xilinx and Altera. However, for engineers, the focus is not who is the leader but rather will the device meet my requirements and will the software used to program it have a small learning barrier. Unfortunately for the digital market, hardware and software hardly ever seem to be on the same page when it comes to the programmable logic devices. The way software tools interface and the method of design entry are issues which are constantly being debated. 1.1 Problem Statement The purpose of this thesis project is to bring to the forefront some of the issues involved in digital design and offer valid evaluation methods for approaching such issues. This paper is meant to highlight certain issues which will hopefully be addressed by FPGA vendors and software developers for the sole purpose of expanding a potentially powerful market. It is also meant to offer a design methodology for those doing digital design with programmable logic. Moreover, this thesis will also serve as a tool to raise the level of awareness about the FPGA design environment here at Michigan State University. 1.2 Approach The principal goal of this thesis is to address the issues which are important when designing with programmable logic devices, and provide viable evaluation techniques in order to address these issues. The process to do this involves an extensive research into the growth of the programmable logic market. It also involves an extensive use of both the WorkView Office 7.2 Software [4] and the Xilinx Software packages [5]. Moreover, three demo projects will be implemented which will provide both qualitative and quantitative data for analysis and evaluation. 1.3 Expected Contributions The following is a list of contributions which will come from this thesis: 1) Develop a design methodology for programmable logic devices. 2) Deve10p a checklist for deciding on a particular design environment. 3) Develop a checklist for choosing a particular FPGA. 4) Develop a list of problem fixes for the current design environment at MSU. 5) Raise the level of awareness at MSU about FPGA programming environments. 1.4 Organization of the Thesis In Chapter 2 of this paper, FPGAS and CPLDs will be discussed as well as software tools. Chapter 3 will discuss design flow. Chapter 4 will encompass the demonstration projects and the design process for each, and Chapter 5 will offer recommendations and conclusions for not only what is currently going on in the programmable logic market but what the future holds for the programmable logic. Chapter 2: Background The uses for programmable logic are very wide ranging and continuously expanding. Hence, programmable logic devices have become powerful design components within digital circuits. During the year of 1995, the prograrmnable logic industry experienced a 38% growth. While this is a long way from the 9% increase in 1996, analysts still believe that by the year 2005, programmable logic will surpass standard logic [6]. What features have made programmable logic such an explosive field in the technical industry? This chapter will explain some of the attributes of programmable logic devices which make them very attractive to circuit designers in both digital and analog applications. Along with this explanation of the devices, there will be a discussion concerning Electronic Design Automation (EDA) tools used to enter, implement, and verify designs for use with these programmable devices. 2.1 FPGA (Field Programmable Gate Array) Field Programmable Gate Array, otherwise known as FPGA, is a multi-level programmable logic device [ 5]. This device features an array of functional logic blocks placed along an interconnection network. Its function is determined in the “field” or at the point of application. This application is always user defined, that is, the logic blocks and their interconnections are configured by the user [8]. This ability to configure the logic blocks and the interconnection network permits the designer to exercise a greater degree of flexibility within his designs. These designs are sometimes equivalent to as many as 10,000 gates. With the use of an FPGA, these designs with high gate counts, are easier for the engineer to obtain faster turn-around-times, as well as, obtain a realistic prototype of complex digital systems which lie beyond the scope of the conventional breadboard logic [8]. The basic architecture of most FPGAS consists of some type of input/output block, logic blocks for implementing boolean functions, and an interconnection network. The names for these blocks are specific to the vendor who developed them. For Xilinx’s FPGAS, the input/output blocks are called I/O Blocks and the logic blocks are called CLBS. The configurable logic block(CLB) of an Xilinx FPGA provides the internal logic that implements the functions of a user-defmed application. These blocks are connected by a programmable interconnection network specific to the Xilinx FPGA. To further explain the architecture of an FPGA, a detailed discussion of the Xilinx FPGA will be given. For the Xilinx 4000 series FPGA, the architecture is illustrated in Figure l [7] on the following page. Xilinx FPGAS have a considerable number of I/O blocks which lie around the outer edge of the FPGA as shown in Figure 1. They serve as a user-defined interface between the external package pins and the internal logic of the device These blocks can serve as inputs, outputs(sequential or combinatorial), or they can serve as bi- directional signals. If not used as an input or an output, they have pull-up and pull-down resisters which will minimize their power consumption when not in use. A slew rate control which is found within the block can be used to help reduce the amount of noise from a signal or ground bounce [10]. A delay model is included within the I/O block. This delay unit “guarantees” a zero hold time for a latched or registered output for this unit. Without this unit, the hold time would be much longer. All of these features, combine to make the I/O block of the FPGA a rather useful component. Basic FPGA Architecture l/O Blocks (IOBs) afieeeaeeaeaeee amenaauuna Engagement Engagement tnunaennafi tannnnannt tun neeaaa imam enemas a mean a ea eeeeee e / \ 9 9 o o Programmable Interconnect urable Logic Blocks (CLBs) /\8 ic FPGA A rchitectu re Bas 1: Figure Inc. 1997. All rights reserv © Xilinx, Inc. rtesy of Xilinx, [COU nd tex Figure a The Xilinx CLBS are usually arranged in an n x 11 matrix surrounded by 1/0 blocks. AS seen in Figure l, the CLBS for the XC4000 is arranged in an 8x8 matrix. In general, the arrangement of the logic blocks within any FPGA is determined by the vendor providing the device. The internal structure of a CLB is illustrated in Figure 2 [9] on the following page. The CLB consists of thirteen inputs and four outputs. Within the CLB, two four input function generators are used to implement boolean functions of the design. The “F” and “G” function generators are completely independent of each other [10]. This independence allows the user to implement two four input boolean functions at one time. A third function generator, “H”, is also included in the CLB. This extra function generator allows the user to implement a nine input boolean function, or a five input boolean function by using the H1 (shown as C1 in Figure 2 ). These function generators are based upon a Look-Up Table technology or SRAM (Static RAM ) technology. Utilizing, SRAM technology allows the inputs of the CLB to be utilized as address lines. These address lines are then used to access certain data which is residing at that particular address. This type of access allows the user to implement functions faster and with less delay [10]. The four outputs of the CLB can be either registered or combinatorial. The registered outputs all have an external DIN (shown as C2). This particular input can be selected by a multiplexer to be the input to the D flip-flop. The S/R and EC (shown as C3 and C4 respectively) are used as the set/reset control and the enable input for the flip— .3239. 3:3.— =< .33 .95 .5.sz @ .95 £55m .«e 33.58 i3 can 9.53 A8805 :8:— ewfi ESSESG "N 2:5 3.5669. use W“ nit—0.0.u—l . .2500 mm. 3:930 m._o v I 128.“. .3 E 1 F0 6 Cu Val—.0 I 8 8 u. 3 if. .. «e $8.530 I #0 «0 N0 .0 229555 .3505: m I mu_0 cccvox flops. The K input is used as a clock. This input is also multiplexed to give the functionality of a two phase clock [10]. The interconnection network of the Xilinx XC4000 is user programmable. The user can either program the interconnection to be direct, general purpose (Single-line), or long-line. The direct interconnection is utilized to connect a CLB to another CLB or IOB. The general purpose interconnect is the most flexible for the designer. This interconnection network is grid-like and composes a network of CLB and ICE inputs and outputs via a switching matrix. This interconnection allows the designer to control the flow of the data through the FPGA. A downfall to this network is that if it crosses too many channels then it becomes rather slow which can impact a lot on timing specifications. The long-line interconnections are utilized, most often, have in systems which have high fan—out [10]. A potential downfall to this interconnection process is the high capacitance which can be encountered to increase the delay of the design. This interconnection network completes the overall architecture for the Xilinx XC4000 series FPGA. The basic components of the FPGA consist of input/output blocks, logic blocks, and interconnection networks. Unlike the Xilinx series, some FPGAS can be fused or one time programmable. They can even be a combination between the SRAM technology or the fused programmable technology. No matter what the programming technology being used, FPGAS provide features which allow users to implement rather intricate systems. 2.2 CPLD Complex Programmable Logic Device (CPLD) is another device which has made the use of programmable logic a valuable asset to digital designers. These devices which are quickly phasing out the Simple Programmable Logic Devices(SPLD) have experienced a growth over that of FPGAS in the past few years. According to Pace Technologies the market for CPLDS has grown from $300 million in 1994 to over $700 million in 1995 and by the turn of the century will be grow to be a $2 billion market [6]. AS consumer demand for CPLDS continue to grow , vendors proceed to improve on different features of the CPLD which will result in higher densities and better performance [11]. Currently CPLDS consists of technology that integrates the functionality of several PALS (Programmable Array Logic) on a single chip. This integrated network consists of universal-logic elements in a grid-like interconnection framework. The on-chip routing resources are connected via a switching matrix [11]. This feature allows them to have - higher speeds at lower gate counts. Moreover, their behavior is very predictable and can be very well defined. To illustrate some of the different aspects of the CPLD, a discussion of the Xilinx CPLD will be provided. A view of the internal architecture of the Xilinx XC7300 series CPLD is provided in Figure 3 [7] on the following page. This CPLD features what is called a dual block architecture. The “dual “ term describes the existence of a high density function block (optimized for area) and a fast function block( optimized for speed). These blocks are XC7300 Dual BlockT'V' Architecture Universal Interconnect Matrix P AL-Iike Function Block - SMARTswitch \ Z / High __ High Density Density Input Function __ Function V0 Registers Block Block UIM 3.3 I5 Volt I/O Fas‘ ‘_ “fl: Fast High Drive Function unction‘ F0 Block —— _fi Block F0 ' 24 mA _/ FAST FAST 5 ns Pin to Pin tsu = 4.0 ns fCLK =167 MHZ tCO = 5.5 “s Figure 3: Architecture of XC7300 Figure and text courtesy of Xilinx, Inc. © Xilinx, Inc. 1997. All rights reserved. connected by a Universal Interconnect Matrix (UIM) which encompasses smartswitch technology which is specific to the Xilinx CPLD. The high density function block within this CPLD contains nine macrocells. These macrocells can be setup to have registered and combinatorial outputs. The registered output is obtained through the use of D Flip-flops within the macrocell. Each of the macrocells can implement up to 17 product terms. These product terms are implemented via an internal ALU and 12 uncommitted Shared product terms [ 10]. The ALU can be configured to implement both logic or arithmetic functions. An additional feature which is contained in the function block is a carry look ahead generator. This carry lookahead generator can predict the carry across all nine of the macrocells. The carry look ahead feature results in the reduction of delay for ripple carry applications for wide arithmetic functions [12]. A final feature for this function block is a D flip-flop. This flip-flop contains independent sets and resets for each macrocell, as well as, a synchronous or asynchronous clock. With all these features, the high density function block is quite a powerful component. The fast function block of the XC7300 features a collection of nine macrocells. Each macrocell is driven by five product terms via programmable AND-gate intercon- nect. Four of the terms can be ORed together and inverted, if necessary. Like the high density function block, the outputs of this block can also be registered or combinatorial. The macrocells D flip-flops all have synchronous clocks and independent sets. They can implement functions up to 167 MHZ and have a propagation delay of 5 to 7.5 ns across the macrocell. The Universal Interconnect Matrix (UIM) is the interconnect between the macrocells of this dual block architecture. It supplies 21 outputs to the high density block and 24 outputs to the fast function blocks. Any inputs to the UIM can be interconnected to the outputs. Furthermore, the delay is constant across the UIM which means that the delay is independent of distance, fanout, or fan in. A feature called smartswitch is utilized within this particular matrix. This feature looks to see if several inputs are connected to a particular output. If so, then the smartswitch performs the proper inversions and ANDS the function within the UIM instead of the macrocell. Implementing the function within the UIM, frees up some resources within the macrocells which can be utilized for other functions [11]. U0 blocks and F0 (fast output) blocks are the final components which complete the architecture of the Xilinx CPLD. These I/O blocks have inputs which can be direct, latched, or registered. This function is determined by the user via enable signals. The outputs of the I/O blocks are tri-Stated and can be combinatorial or sequential. Several global signals reside in the I/O block. Three fast ‘clock enables’ which deal with the fast function block and two regular clocks which go to the high density function block are also available to the user. When the fast clock is enabled on the I/O , the FO block can Sink up to 24mA of current which is important when implementing high speed applications. All of these components together, comprise the XC7300 series CPLD. Like FPGAS, CPLDS continue to revolutionize VLSI technology. As they continue to grow in sales, CPLD vendors are increasing the functionality, speed, and density of their devices to meet the needs of circuit designers. These improvements will allow CPLDS to become a comparable force with FPGAS in digital design. 2.3 Comparison between an FPGA and CPLD As CPLD technology continues to advance, some engineers would argue that the there is a very thin-line line between the CPLD and the FPGA. While this assumption may be more accurate in a few years than it is right now, it illustrates a very interesting point when discussing FPGAS and CPLDS. What are the differences between these two devices? Of course these devices differ physically; however, there are some differences in using these devices which should be considered when implementing digital design with them. 2.3.1 Siginificant Physical differences The first major physical difference is in the interconnection networks of the CPLD and the FPGA. The FPGA uses additional hardware which allows the interconnection network to be user programmable. This “overhead” in circuitry increases the area of the FPGA, as well as, the cost [5]. Moreover, the segmented nature of the interconnection network causes the timing for the FPGA to be rather unpredictable. This problem arises due to the additional capacitive load of the programming circuitry. The CPLD does not have this problem because of the grid-like framework which is interconnected via a switching matrix [11]. N 0 extra circuitry is added or needed; thus making the timing more predictable and the performance better due to a lesser degree of capacitive loading. Another important difference between the FPGA and the CPLD is the basic internal architecture of these devices. An FPGA contains logic cells (CLBS (Xilinx) or LABS (Altera)) which implement the logic functions for a given application. These cells are connected by the interconnection network, previously discussed. This type of architecture for FPGAS make is another contributing factor to making the performance rather unpredictable . However, it does provide a broader range of functional capacity for the FPGA depending upon the choice of the cells and the way an application is routed [13]. CPLDS, on the other hand, consists of many blocks which resemble the architecture of Programmable Array Logic (PAL). The PAL architecture features a fixed OR plane in series with a programmable AND array. These planes can be used in conjunction with macrocells (additional logic cells) which can implement quite a large design. This architecture, however, does not allow for the implementation of large designs like FPGAS do. The implementation of large designs which are comparable to those on an FPGA will cause the CPLD to dissipate more power [12]. Despite this fact, the architecture of the CPLD allows for predictable timing ,while the timing of the FPGA is dependent on the end application and the placment and routing algorithm of the programming tool. Another distinctive feature between FPGAS and CPLDS is the programming of the devices. FPGAS can be either reprogrammable (SRAMS) or one time programmable (Anitfused or fused). The reprogramming of the FPGA can take place within the system via a cable or whatever the vendor has decided to use. The disadvantage to using SRAM technology FPGAS is that the memory is highly volatile. In other words, once power is removed from the target system, the program must be re-downloaded. Fortunately, the FPGA can stay within a system unlike most CPLDS [l l]. EPLDS, a special group of CPLDS, are erasable and can be reprogrammed but they must be removed from the system. Some vendors like Xilinx, Lattice, and Altera have come up with CPLDS which are in system programmable (ISP). This additional feature to CPLDS is an illustration of the rapidly fading differences between the FPGA and CPLD. Yet, for reasons discussed in the next section, making the CPLD in-system programmable does not overcome all the other key differences discussed in the next section . 2.3.2 Relative Strengths and Weaknesses FPGAS and CPLDS , outside of the physical differences, each has issues surrounding their usage which must be considered by the designer when using either device. One of these issues involves cost. FPGAS are much more expensive than CPLDS. The complex architecture and the circuitry for reprograrnmability increases the area of the FPGA which directly affects the cost. Furthermore, the non-recurring engineering(NRE) costs that accompany the use of the FPGA increases the price for using it. NRE costs are those costs incurred from the time a netlist is generated until the time a prototype is done. According to Dataquest, design revisions for the FPGA usually cost around $25,000. This price is of course usually dependent upon the vendor. If the designer does not have his own set of test vectors, then the vendor adds on another $2,000 to $7,000 to the prices. These prices apply to each iteration of the design. For the FPGA, there are at least two iterations. These costs mean that a 20,000 gate design will have NRE costs totaling close to $45,000 in 1998 if this trend continues [14]. CPLDS are particularly more attractive because they do no include the NRE costs incurred by the use of FPGAS. Unlike the FPGAS, CPLDS are fully tested and guaranteed before shipment. Moreover, the generation of test vectors for FPGAS, a six week process, is not required for CPLDS. The fact that these devices are fully functional at the time of shipment allows the consumer to do in system testing earlier. Thus, allowing the customer to get their product into the market place in a shorter time. This idea of a faster time—to-market makes CPLDS extremely attractive devices to digital designers. Despite the fact that FPGAS are more expensive than CPLDS, FPGAS give designers more flexibility. Reconfigurability is the term which is utilized to explain this flexibility provided by the use of FPGAS. The term reconfigurable simply means in— circuit reprograrnmable. An individual can change the application of the chip without ever removing the chip from the system. This attribute allows the designer to redo designs to different specifications of the customer with little time-to-market loss. Moreover, the designer can “Shape “ the device to the application. This “shaping” of the device allows the designer to develop and optimize application specific designs more quickly than the traditional ASIC designers, thus making FPGAS very attractive [2]. CPLDS are not as flexible as FPGAS due to the fact that they are not in circuit reprogrammable. Even though a few vendors provide ISP CPLDS, the dominant architecture of CPLDS dictate that they must be removed from the system to be reprogrammed. This down time to remove the device from the system could result in a loss in revenue. The design approach and the design environment for FPGAS and CPLDS are rather different. The designer who uses the CPLD usually has a more than basic understanding of the device thus the designer tends to optimize the design to fit the device. For FPGAS, with its complex architecture, the designer typically takes a “try it and see what happens” approach [7]. This approach is usually taken because most designers do not want to take the time or do not have the time to understand the inner workings of the device, thus they produce a less than optimal design which leads to several iterations and a lot of NRE costs. The tools used to implement the designs are very powerful for CPLDS and FPGAS. However, some of the tools which are used to 18 program FPGAS are too complex for the average user. This complexity makes it harder for the user to take advantage of some of the features that the tool has to offer. CPLD tools on the other hand, are much Simpler to understand and easier to use. The use of both CPLDS and FPGAS continue to influence the VLSI market. As vendors continue to improve on these devices, the line which once divided them will no longer be very clear. Thus eventually, one device may seemingly evolve by combining some of the features of the CPLD and FPGA which will replace both devices. This device will have with it a design environment which will optimize all of its features from designing to programming which can only make this device even more appealing to designers. 2.4 WorkView Office 7.2 WorkView Office 7.2 is a PC-based electronic design automation (EDA) tool which was introduced by Viewlogic systems in 1994 [15]. This tool currently runs under the WindOWS NT and the Windows 95 operating systems. It provides a variety of graphical applications and DOS based applications to the user. A list of major components of this tool set can be seen in the Table l on the following page. WorkView Office is a versatile software solution for digital designers. The windows environment provides the user with an interface which is not only user—friendly but more than likely already familiar to the user. This tool also provides the user with online help Which a can easily accessed by the click of a button. WorkView Office has three versions Which are currently available. These versions are a student version, educauonal 1s tool is the f st~gale simula i0 tied into all built~in si ‘b Iy. (I) In re ulau 20 Table 1(cont’d): ViewSpice This tool is a circuit simulator that simulates P N N/A $6.000 and analyzes analog circuits. It can be used alone or in conjunction with Viewdraw. Operating Point This tool extracts operating point values P N Y $4.000 produced during analog Simulation and back annotates those values to the appropriate Viewdraw components. Viewsynthesis This tools is a fully interactive hierarchical E,P Y N/A N/A synthesis tool . MOTIVE This tool is a high performance static timing P N N/A 514.000 verifier. ViewPCB This tools allows you to export and import E,P Y N/A N/A design data from a third party PCB layout system. ViewGen This tool generates Viewdraw schematics E,P Y N/A N/A from the connectivity information found in the .wir files. Edif Interfaces These series of tools translate schematics and E,P Y N/A N/A other netlists to standard Edif 200 and can be used for analysis purposes. VCS This tool is the Verilog simulator. It can be P N Y $6.000 used in conjunction with Digital Fusion to simulate VHDL. digital. and Verilog designs. XTK This suite of tools can identify and resolve P N Y $19,000 complex signal integrity problems. version, and professional version. In Table 1, each version is represented by an S, E or P, respectively. Each tool is available in the version indicated against it. The student version which runs on the PC platform provides the student with a good sense of what the commercial tool is actually like [16]. Two restrictions do exist which make the Student version rather limited. The first restriction is that only 300 modules can be used in a complete design. This restriction limits the complexity of a 21 design, as well as, the amount of hierarchy that can be utilized within the design. The next restriction is one concerning number of designs and design names. The students who are using this software are limited to 10 designs which have already been named “design 1, design 2, etc.”. These predetemiined design names can cause problems for student trying to implement hierarchical designs by making the Student use up several design models to implement a complete project, if the project is rather involved. These restrictions, though very bothersome, do not negate the fact that Viewlogic has provided a very effective student version of their tool which is quite impressive to be the first student version. The educational and professional versions are differ in pricing and available tools. Tools which distinguish these two versions, like VCS, Motive, and XTK can be expensive for universities, especially if no useful purpose can be found for them within the curriculum. Overall, Viewlogic has provided a powerful PC-based EDA software solution for digital designers. Technical support for WorkView Office extends far beyond an 800 telephone number. Currently, Viewlogic has an e-mail address and a fax number which ensures that the customer can get a response to their technical questions. A news group is also provided via e—mail. This group is made aware of new products, problem fixes, and upcoming seminars pertaining to Viewlogic products. A list of how to access these services are provided in the Appendix A. WorkView Office, overall, has a wide range of support for even the most inexperienced user [15 ]. The ease of use, the different versions, and product line have made Viewlogic’s WorkView Office 7.2 one of the fastest growing EDA tools in the country. With their varied versions, the Student is able to get more than a glimpse at meaningful design 22 environment. This insight for the students can lead to practical application of their knowledge in the future. For the instructor, it provides flexibility in covering course material with a product that can easily be conformed to emphasize certain aspects of design. The professional engineer can have confidence in the integrity of the design due to the extra tools which WorkView Office provides. All of these issues make WorkView Office 7.2 by Viewlogic systems a leading EDA tool which is on the brink of cutting edge technology for digital circuit design. 2.5 Falcon Framework Falcon Framework by Mentor Graphics is a complete software solution for digital designers on a UNIX platform. Founded in 1981, Mentor Graphics presents a plethora of tools within the Falcon Framework environment to the digital designer. This relatively young company has set the tone for the EDA market. With its introduction of a software solution which automated the design, analysis, and documentation phases of electronic circuits, Mentor Graphics has proven to be a front—runner in leading edge technology for the EDA market [15]. Falcon Framework includes a lot of tools which extend beyond the needs of the traditional digital designer. These tools include analysis and simulation of DSP applications and analog circuitry. Thus, making it a powerful commercial, research, and educational tool. Table 2 ,on pages 26-28, lists the tools currently available at Michigan State University from Mentor Graphics. It currently runs on UNIX system with 23 Table 2: Falcon Framework Tools Tool Name Tool Description Available Optional AIK A library of files needed to build your own Y N/A (Analog Integrator Kit) version of an analog simulator Accusim This tool simulates analog design. Y N/A Cgen This tool generates C code for the Dataflow Y N/A description Language in Dsp Design DDSIM This tool is a DataDn'ven simulator within the Y N/A DSP Station DSPlab This tool is used to create a component model Y N/A for a DSP design and it can be used to perform either time and/or frequency simulations. DVE A downstream tool to view the source schematic Y N/A (Digital Viewpoint) as fully evaluated data. Editor A notepad for making notes. Y N/A FilLab This tool allows for the design [IR/FIR filters, as Y N/A well as, setting up bandwidth parameters for the filters. FastScan A comprehensive combinatorial automatic test Y N/A pattern generation system optimized for full scale designs. FlexTest IFlextest is a high performance sequential Y N/A automatic test pattern generation system that allows you to create a set of test paltems that achieves a highly accurately measured test coverage for cycle—based circuits FrameMaker A wordprocessor with many graphics Y N/A capabilities. gen_arch This tool creates VHDL Code from the EDDM Y N/A design. Mslab Mixed signal Simulator. Y N/A QHDL_Pro A complete digital simulation for designers Y N/A needing the ability to support the widest range of models in any digital simulation environment. QuickFault A high performance, timing—based deterministic Y N/A fault simulator. QuickGrade II A rapid and responsive fault grading tool which Y N/A uses probabilistic methods. QuickPath A static timing analyzer graphs worst case Y N/A scenarios for designs. Quicksim II The industry's fastest gate-level simulator. Y N/A 24 Table 2(cont’d): Quicksim II_FPGA A simulator which functions like QuickSim except that it verifies that the model instances are fpga models. N/A Registrar A graphical interface for registering data and tools for access from the design manager. N/A SimView A single Simulation interface for numerous Mentor Graphics and third party simulators. N/A WDFsyn (Wave Digital Filter) An interactive CAD tool for approximationand structure synthesis of monorate and multivirate Lattice Wave Digital Filters. N/A bold_adm This tool is used for making online libraries available (or unavailable) on the network by starting (or stopping) the bold server processes associated with the libraries. N/A bold_browser This tool is used for retrieving and displaying information contained in online libraries. N/A config_erc A compiler which compiles an ASCII file written in ERC(Electrical Rules Check) language to be invoked in DVE and used to make sure that the design meets specifications N/A config_nc A compiler which that compiles a file which contains the pin and net properties of a design. This file can also be invoked within the DVE and used to make sure the design meets the specifications which are included in the file. N/A design_arch A universal schematic editor for ASIC'S, lC's, boards, and MCM's. N/A dracnet A tool which reads Mentor Graphics design and creates a Dracula format netlist. N/A dss (Decision Support System) An environmental tool that features a control panel builder and a data integrator for EDA applications. N/A engr_view lElectfical class rules derive intelligent high- speed place and route tools. N/A enread An application which translates an EDIF file into a Mentor Graphics represented netlist that will allow for the design to be used with the tools that are available. N/A enwrite A tool which translates a Mentor Graphics‘ design (as seen through Design Viewpoint) into an EDIF file describing that design. N/A esyn .< N/A fablink K This tool generates manufacturing data and documentation for a PCB design. >< N/A 25 Table 2 (cont’d): hispeed_layout A module of layout that has been enhanced to Y N/A include features for design electrical rules in order to control the signal integrity of high speed nets in the design. hspicenet An application which generates a spice netlist Y N/A file by pulling out the information from the schematic or structural design of a circuit. int_layout Y N/A layout This tool places and routes components on a Y N/A board and routes the traces of the nets that connect the pins of these components. lcable A schematic Capture tool for wire and cable Y N/A design. libra A simulator for PCBs Y N/A linecalc Y N/A link 1 The tool which allows access to libraries which Y N/A are outside of standard libraries within Mentor Graphics. link 2 The tool which allows access to libraries which Y N/A are outside of standard libraries within Mentor Graphics. lsimnet An application which pulls out necessary Y N/A information , which sets the parameters to be used in Lsim, from the schematic or structural layout of the design. mds This application deals with design of RF Y N/A (Microwave Design Sheet) circuitry for Mentor Graphics. mfg_view Concurrent view-only database access by Y N/A engineers and manufacturing personnel. mixsp A simulator for PCBs Y N/A omnisys A simulator for PCBs Y N/A jomega A simulator for PCBs Y N/A pcb_data_editor This tools allows for the modification of the Y N/A PCB data after the design has been simulated. spicenet_1076 An application that access the VHDL design Y N/A and pulls out the necessary information to generate a Spice netlist. sys_1076 The VHDL library interface which allows the Y N/A designer to use components without creating his own version first. vhdlnet The tool which generates the netlist for the Y N/A VHDL code. vnet The tool which generates the netlist from Y N/A Verilog implementation of a design 26 X window capabilities. At this point, the UND{ version is the only one available for university use. Mentor Graphics is currently offering certain tools for the PC which were just released this year. However, these tools do not include a lot of those found in Falcon Framework and this version is only available to private industry. As mentioned before no PC-based tools are being marketed for widespread use, neither are there any student versions available for the Falcon Framework software tool. However, Mentor Graphics does provide a wealth of on-line manuals and tutorials. These resources give rather detailed information about the different capabilities of each tool. They are extensive and rather thorough at explaining different procedures. Moreover, like most companies, technical support is provided along with a website. Another good feature is the e-mail system used to receive customer request. This information can be found in Appendix A at the end of this paper. Mentor Graphics has provided the industry with a powerful tool in its Falcon Framework suite of tools. As it continues to explore ways to extend beyond the UNIX environment, it continues to be a world leader in the EDA industry. As EDA vendors like Mentor Graphics continue to offer such powerful tools, VLSI can only soar in the amount of advancements that could take place. 2.6 Comparison of Falcon Framework and WorkView Office 7.2 As EDA vendors have discovered, many designers within the US are doing more system-level, printed circuit board design, or embedded system design with programmable logic devices [18]. With this discovery, vendors have had to adjust their EDA tools to fit the growing needs of programmable logic technology. Some vendors 27 have migrated from a UNIX platform to a PC platform, while others offer powerful UNIX based tools. However, as technology dictates, the purpose of the vendor is to meet the needs of the consumer. Falcon Framework and WorkView Office 7.2 both offer solutions for the digital designer. In this section, a comparison will be made between these two software packages to get a clearer understanding of what both of these packages have to offer. The tools mentioned in the previous sections are both very powerful tools. Both products produce design solutions for the digital designer. Each of these tools provide components which are comparable to each other. A list of similar tools are provided in Table 3 , pages 30-31 of this document. As can be seen, these tools seem to have a lot in common. They present a significant number of tools which aid the designer in implementing, verifying and simulating a design. The tool vendors also provide a wealth of support for using these tools. Despite the common features between Falcon Framework and WorkView Office , there exists subtle differences which makes one design environment more appealing to a designer than another. In Tables 4 and 5, page 32-35, lists are provided which describe tools that are available in one software package but not in the other. Table 4 shows the tools which are in Falcon Framework but not in WorkView Office. The opposite is true for table 5. The difference in the tools offered has to do with the target audience. Mentor Graphics with Falcon Framework is targeting designers who are doing everything from PCB layouts to DSP applications. The offering of such tools allows them to appeal to a broader market which makes them a leader in the EDA industry. At the same time, 28 Table 3: Common Tools Between WorkView Office and Falcon Framework WorkView Falcon Office 7.2 . Framework Viemew This tool allows for the creation of symbol and Design_arch A universal schematic editor schematic designslt can be accessed for ASlC's, lC's, boards, and dynamically by other applications during the MCM‘s. design process. Digital Fusion This tool allows for the simulation of mixed QHDL_Pro A complete digital simulation VHDL. Verilog and gate-level digital designs. for designers needing the ability to support the widest range of models in any digital simulation environment. SpeedWave This tool is the simulation engine for the VHDL Quicksim II The industry's fastest gate-level design and gate level designs. simulator. ViewSim This tool is the fast—gate simulation engine Quicksim II The industry's fastest gate-level which is tied into all built-in simulation and simulator. schematic library. ViewTrace This tool is a waveform analyzer and editor that Quicksim II The industry's fastest gate-level graphically displays analog and/or digital simulator. simulations results. It can also be used for back annotating simulation. Analog Fusion This tool is used for mixed simulation of digital Mslab Mixed signal Simulator . and analog designs. It can be used with Digital Fusion if VHDL code is involved also. Wspice This tool creates a netlist for analog designs. Spicenet_lO76 An application that accesses This can be accessed by Analog Fusion and the VHDL design and pulls ViewSpice. out the necessary information to generate 3 Spice netlist. ViewSpice This tool is a circuit simulator that simulates Accusim This tool simulates analog and analyzes analog circuits. It can be used design. alone or in conjunction with ViewDraw. MOTIVE This tool is a high performance static timing QuickPath A static timing analyzer graphs verifier. worst case scenarios for designs. Edif Interfaces Thcsc series of tools translate schematics and Enrcad An application which translates other netlists to standard Edif 200 and can be an EDlF file into a Mentor used for analysis purposes. Graphics represented netlist that will allow for the design to he used with the tools that are available. Enwritc A tool which translates a Mentor Graphics' design (as seen through Design Viewpoint) into an EDIF file describing that design. 29 complex signal integrity problems. Table 3 (cont’d): VCS This tool is the Verilog simulator. It can be Quicksim II The industry‘s fastest gate-level used in conjunction with Digital Fusion to :simulator. simulate VHDL. digital. and Verilog designs. XTK This suite of tools can identify and resolve hispeed_layout A module of layout that has been enhanced to include features for design electrical rules in order to control the signal integrity of high speed nets in the design. Table 4: Falcon Framework Tools not Available in WorkView Office Tool Name Tool Description Available Optional AIK (Analog Integrater Kit) A library of files needed to build your own version of an analog simulator Y N/A Cgen This tool generates C code for the Dataflow description Language in DSP Design N/A DDSIM This tool is a DataDriven simulator within the DSP Station N/A DSPlab This tool is used to create a component model for a DSP design and it can be used to perform either time and/or ifrequency simulations. N/A DVE (Digital Viewpoint) A downstream tool to view the source schematic as fully evaluated data. N/A FilLab This tool allows for the design llR/FlR filters,as well as, setting up bandwidth parameters for the filters. N/A FastScan A comprehensive combinatorial automatic test pattern generation system optimized for full scale designs. N/A FlexTest Flextest is a high performance sequential automatic test pattern generation system that allows you to create a set of test patterns that achieves a highly accurately measured test coverage for cycle-based circuits N/A 30 Table 4 (cont’d): FrameMaker A wordprocessor with many graphics capabilities. N/A gen_arch This tool creates VHDL Code from the EDDM design. N/A QuickFault A high performance, timing-based deterministic fault simulator. N/A QuickGrade II A rapid and responsive fault grading tool which uses probalistic methods. N/A Quicksim II_FPGA A simulator which functions like QuickSim except that it verifies that the model instances are fpga models. N/A Registrar A graphical interface for registering data and tools for access from the design manager. N/A SimView A single simulation interface for numerous Mentor Graphics and third party simulators. N/A WDFsyn (Wave Digital Filter) An interactive CAD tool for approximation and structure synthesis of monovirate and multivirate Lattice Wave Digital Filters. N/A bold_adm This tool is used for making online libraries available (or unavailable) on the network by starting (or stopping) the bold server processes associated with the libraries. N/A bold_browser This tool is used for retrieving and displaying information contained in online libraries. N/A config_erc A compiler which compiles an ASCII file written in ERC(Electrical Rules Check) language to be invoked in DVE and used to make sure that the design meets specifications N/A config_nc A compiler which that compiles a file which contains the pin and net properties of a design. This file can also be invoked within the DVE and used to make sure the design meets the specifications which are included in the file. N/A Table 4 (cont’d): dracnet A tool which reads Mentor Graphics design Y N/A and creates a Dracula format netlist. dss An environmental tool that features a Y N/A (Decision Support System) control panel builder and a data integrator for EDA applications. engr_view lElectrical class rules derive intelligent high- Y N/A speed place and route tools. esyn Y N/A fablink This tool generates manufacturing data and Y N/A documentation for a PCB design. hispeed_layout A module of layout that has been enhanced Y N/A to include features for design electrical rules in order to control the signal integrity of high speed nets in the design. int_layout Y N/A layout This tool places and routes components on Y N/A a board and routes the traces of the nets that connect the pins of these components. lcable A schematic Capture tool for wire and cable Y N/A design. libra A simulator for PCBs Y N/A linecalc Y N/A link 1 The tool which allows access to libraries Y N/A which are outside of standard libraries within Mentor Graphics. link 2 The tool which allows access to libraries Y N/A which are outside of standard libraries within Mentor Graphics. lsimnet An application which pulls out necessary Y N/A iinformation . which sets the paramters to be used in Lsim, from the schematic or structural layout of the design. mds This application deals with design of RF Y N/A (Microwave Design Sheet) circuitry for Mentor Graphics. mfg_view Concurrent view-only database access by Y N/A engineers and manufacturing personnel. mixsp A simulator for PCBs Y N/A omnisys A simulator for PCBs Y N/A jomega A simulator for PCBs Y N/A 32 Table 4 (cont’d): pcb_data_editor This tools allows for the modification of the Y N/A PCB data after the design has been simulated. spicenet_1076 An application that access the VHDL Y N/A design and pulls out the necessary information to generate a Spice netlist. Table 5: WorkView Office Tools not Available in Falcon Framework [ Tool Name Tool Description Available Optional ProjectManager This tool is used to create and Y N/A edit WorkView Office files. It is linked to all tools. WOperating Point This tool extracts operating Y N/A point values produced during analog simulation and back .annotates those values to the appropriate Viewdraw components. Viewsynthesis This tools is a fully interactive Y N/A hierarchial synthesis tool . ViewPCB This tools allows you to export Y NM and import design data from a third party PCB layout system. ViewGen This tool generates Viewdraw Y N/A schematics from the connectivity information found in the .wir files. Viewlogic Systems with WorkView Office 7.2, is appealing to the digital designer who is using or is more comfortable in a PC/Windows environment. They do not focus on DSP or IC Layout capabilities like Falcon Framework. For ASIC designers they have provided a way for the transistor level design to use schematic entry to implement transistor level logic and send the designs to a company like MOSIS, to fabricate the chip without doing cell layouts. Because of the focus of the tools on different audiences, it is no wonder that Falcon Framework is seemingly more powerful than WorkView Office. 33 Table 6: Prices For Falcon Framework and Workview Office 7 .2 Available tools for PC for PC(Costs) Quantity Workstations Falcon Framework Personal Architect (schematic $2000-$7750 1-10 licenses $2,100/yr capture) QuickHDL-Lite, VHDL $4,995 11-20 licenses $4,100/yr Integra Station (PCB Layout) $25,000-$43,750 21-50 licenses $6,000/yr* (MSU) unlimited licenses $6,200/yr Workstations come with the products listed in Table 3 Available tools for lQuantity PC(Costs)each Workstations(each WorkView Office 7 .2 system system) Viewdraw 1-9 systems $1,500.00 $1,800.00 .Edif Graphics 1019 systems $1,000.00 $1,200.00 Viewsim 20+ systems $750.00 $900.00 SpeedWave Spice link Simbus and Pspice(unix only) ViewPLD View Synthesis ViewDatabook PCB interfaces Wirelisters All Viewlogic symbols and [simulation models ***75.00/system per year maintenance fee No more than $500/dept The price differences between these two tools are quite interesting. Table 6, on the following page, displays the pricing information for WorkView Office 7.2 and Falcon Framework. As can be seen from the table, the prices for the PC products for Falcon Framework are very high. These tools are only offered for commercial use and Mentor __ 1L; :— 34 Graphics has not decided on a price for educational purposes. WorkView Office 7.2, on the other hand, has prices which are comparable to that of Falcon Framework. The prices charged for these tools are a one-time fee. Unlike Falcon Framework which requires an annual renewal fee. At most for the WorkView Office 7.2, the user pays the yearly maintenance fee of no more than $500/dept. These prices for WorkView Office make it particularly attractive to those designers who are really looking for a complete software solution for digital design. The most important difference between Falcon Framework and WorkView Office 7.2 is the time it takes to learn the tool. With WorkView Office 7.2, Viewlogic has found a way to reach people with an EDA tool in an environment which is familiar to them, PC/Windows environment. WorkView Office 7.2 tools are relatively easy to use and with the ability of the user to have a student version within their own home, it becomes easier to learn. Falcon Framework does not come in a student version. For the most part if users do not have a software package like Linux or Solaris for their PC, they can not recreate the UNIX environment under which Falcon Framework runs. This forces the user to learn a new environment and then spend time figuring out how to access Falcon Framework tools. The presentation of different functions within Falcon Framework is rather confusing, and is not clearly defined within the on-line manual provided. Unlike the WorkView Office 7.2, which is using the Microsoft toolbar technology, Falcon Framework cannot provide the user with a clearly defined click and point format for carrying out particular functions. For example, to access the gates for schematic entry in WorkView Office 7.2, the user merely clicks on a gate like symbol on the toolbar. This 35 action allows immediate access to libraries which had been chosen by the user for the design. In Falcon Framework, the user must access the libraries via the pull-down menus or a side panel consisting of various pictures which are labeled. After the user gains access, and if they have a clear idea of what the libraries are in Falcon Framework, they can then obtain the gate for which they are looking. The libraries are all shown but the naming of these libraries is not very user friendly, thus requiring the user to find a gate by trial and error. This kind of approach is prevalent throughout the use of Falcon Framework which can be rather frustrating after prolonged usage. Overall, the type of environment to be used is dependent upon what the user is most comfortable with and the application for which he is using the tool. Despite this fact, WorkView Office 7.2 presents a design environment which is familiar and more user friendly than Falcon Framework. Falcon Framework could be an even more powerful tool if the implementation of basic functions are made more user friendly. Even so, both tools are leaders in the EDA market and that says a lot about both of them. 2.7 XACTstep V6.0.l XACT step v6.0.1, is the programming package use to program Xilinx FPGAS. This software package allows for the implementation of logic design for Xilinx programmable logic devices. By integrating a powerful design tool with a myriad of graphical user interfaces (GUI), Xilinx presents an environment which is easier to use and accelerates the learning curve[l9]. Table 7, on the following page, lists the different tools included within the software package which provides the designer with a more than adequate design solution for programming Xilinx programmable logic devices. 36 Table 7: XACTstep Tools Tool Name Tool Description Availabile Optional Design Manager This design manager is a graphical Itool that allows the user to manage his/her projects and provides access to other Xilinx tools for processing the design. N/A Flow Engine This tool enables the user to easily manage the processing of the design. Taking the translated design from the design manager, the user can optimize, map, place, and route the design and then generate a bitstream for programming the device. N/A Floor Planner This tool uses a graphical interface and two primary windows for distributing logic on an FPGA die. N/A Timing analyzer This tool takes a routed design and analyzes the circuit to see if it meets the specified timing requirements. N/A Prom Forrnatter This tool provides a graphical user interface that allows the user to format BIT files into a prom file compatible with Xilinx and third party vendors. It is also used to concatenate multiple bitstreams into a single PROM for daisy chain applications. N/A Hardware Debugger This tool allows the user to download a design to a device. verify the downloaded configuration. and display the internal states of the programmed device. N/A Xact-CPLD This tool deals with CPLD designs. N/A 37 The XACT step software comes in four different packages. These packages are called Base, Standard, and Stand-alone/extended packages. The Base package provide the user with a design environment for approximately 3000 gates from the Xilinx FPGA and CPLD collection. This package is sufficient to evaluate and target the best device to meet the needs of the user. This package is available on a PC/Window platform. The standard package is the one which includes an EDA tool of Xilinx’s choice. At one time this package included the ProCapture Series by Viewlogic systems. Since Xilinx has developed its own EDA tool, the standard package is now sold with the Xilinx’s EDA tool, Foundation. This package is available on the PC/Window and UNIX environment. The Stand-alone/Extended version, which is used here at Michigan State University, is the package which allows the user to attach whatever front end tool used for schematic entry. WorkView Office7.2, Aldec, Data I/O are just a few of these tools [ 20]. All of these packages combined make Xilinx a rather flexible design tool. Xilinx has now released a student version of its software package. Now students and new users can take advantage of the XACTstep performance tools in the comfort of their own home without using up all the memory in the computer. By providing this version Xilinx has allowed the new user to take advantage of fully understanding the design environment which is run at school or at the office without going off to a training course. With such a powerful tool, the amount of help available to the user must be easily accessible. Technical support for Xilinx is provided through an 800 number, an e-mail address, a fax number, a website, and a set of on-line tutorials. This information can be 38 found in Appendix A. As can be seen, Xilinx is a leader in the FPGAS not only with the devices but with software packages that it provides. 2.8 Summary FPGAS and CPLDS provide a variety of avenues for digital designers. All of these avenues can lead to the optimal design; yet, the path taken determines whether the designer reaches the optimal solution. A clear understanding of the intricacies of FPGAS and CPLDS is not only necessary but it is important to have a clear perception of what distinguishes the two devices, and how these differences will affect the application to be implemented. It is equally important to understand the EDA tools which are being suggested for use in the design environment . The software tools used to program FPGAS and CPLDS are just as important as the devices themselves. Understanding the different features of the tool is key to any designer to trying the optimal design. These tools should provide the means for the designer to obtain the level of training necessary to use their package effectively. This information can be provided in the form of on-line manuals , technical support, and/or Graphical user Interfaces (GUI) which are easy to understand,. Regardless of the vendor being used, the engineer must be familiar with the environment in which he is working. Knowing these things, by no means, suggests that a designer or anyone can build an environment for using these devices. Certain issues arise which must be addressed in order to put together an environment which will be a help and not a hindrance to the designer. In the following chapter, design flow will be discussed and certain key issues will be addressed concerning this process. Chapter 3: Design Flows Being able to use FPGAS or CPLDS effectively is heavily dependent upon the approach taken after the initial design phase. More often that not designers have taken a lackadaisical attitude when implementing designs on these devices [7 ]. This attitude, of course, leads to a design which requires several revisions. As discussed in the last chapter, for FPGAS, this attitude translates into NRE costs, and for CPLDS, new chips and system downtime. Since an in-depth knowledge about the device is not necessary but is helpful, it becomes very important to understand the EDA environment under which one is working. A knowledge of certain features within the EDA tool could improve the final design. The following sections deal with issues involved in learning different software packages. This discussion will be followed by a description of the design process using the current EDA environment for programming the Xilinx FPGA, along with some of the different problems which can be encountered. 3.1 Fundamental Learning Curves Each person has a different way of learning the same thing. Some people take step-by step approach making sure that every action has a reason which supports it. Others dive right into something and try to figure things out as they go along. Still, some people who are too impatient to try the first method and too cautious to try the second, seek guidance or formal training in the area they are trying to learn. Whatever way is taken, the theory would be that all people would arrive at the same place. Sometimes this happens and sometimes it does not. This scenario adequately describes the methods digital designers, new and old , use to learn new tools. Of course , everybody does learn 39 40 differently; thus, doing something a particular way may not work out for one person as opposed to another. However, if enough attention is paid to some of the pros and cons of each method, it may be that a slight modification in the learning could increase the productivity of the digital designer, especially, when these designers will be programming FPGAS. Figure 4, on the following page, illustrates three different paths to learning software, which were mentioned briefly in the previous paragraph. The first path which stems from tutorials is a methodical approach. The individual who travels this route spends hours, days, and sometimes weeks, depending upon their level of dedication, going through a slew of vendor provided tutorials. These tutorials present a step-by-step approach to using different tools which accompany the package. Tutorials provide the user with a step-by-step point of reference but do not account for some of the possible problems that the user may encounter. However, they serve as a quick reference for doing some of the basic functions within the tool. As the users continue to gain experience using this method, they broaden their knowledge by looking for outside sources to understand some of the things the tutorial may not explain in enough detail or answer some questions the tutorial does not address. These outside sources include but are not limited to on-line manuals, technical support, news groups etc. After becoming comfortable with the design environment, the user then implements a design. They may have to make some outside references to manuals but they at least have a course of action they can take, which could save time. This method of learning even though it can be time-consuming provides the user with a solid foundation on which to expand their knowledge of the tool, thus, becoming more productive. LEARNING CHART Workview Office 7.2 XACTstep CUPL MAGIC, etc i i Design (Brute force method) i Online manual Tutorials Training course (Methodical approach) (HyperSpeed method) On-line j j manuals Tech Online support manuals Tech Personal Designs Designs support references . . Better than Better than 133518115 Desrgns average average i ¢ understanding understanding Basic Basic understanding understanding i Tutorials f Tech Personal Support Reference Back to Back to original design original design i V Sufficient understanding Figure 4: Learning Chart Sufficient understandin 42 The next path which is to the far right in the figure is called the brute force method. This methodology stems from the “try it and see what happens” mentality discussed in the previous chapter. In this method, the individual dives right in by implementing a design , or at least making an honest attempt at one. However, due to their lack of knowledge about the software package they are using, they must spend a lot of time referencing manuals. If the manuals are difficult to understand then they must reference the tutorials, followed by technical support, etc. until they can obtain an answer they can understand and use. After all of these steps, if the individual has not decided to give up then they finally get back to the design, and start the process all over again. For all intents and purposes , this method is very frustrating. This method is like trying to ride a bike for the first time without training wheels. It requires several times of “falling down” before a sufficient understanding of the package is learned. Most people, at this point, if not required to, hardly ever get to a basic understanding. The frustration and time consuming nature of this methodology, especially for a novice, can be not only discouraging but stressful. Usually the individual winds up either giving up or deciding this is an area which they don’t want to work. An unfortunate conclusion that happens more often than necessary. The final method, which is more prevalent among employers than in universities is the hyperspeed method which is in the middle of the chart shown in the figure. In this method an individual is sent off to a training course. At this training course, the individual usually spends four to six hours of focused, guided, and hands on interaction with the software tool while getting equal hours of informative instruction. No outside distractions are incurred and the questions, usually asked by a novice, can be answered on 43 the same day. This intensive training can overwhelm an individual. A lot of information is given to the individual at one time. After each day, the person must make sure to makes notes about key points, in order to pass on the proper information. With this intensive training the individual has a different perspective about the package. This individual is aware of the different problems which could arise when using this tool with other packages. They also are aware of different problem fixes and different shortcuts to doing functions within the tool. Moreover, the individual establishes a contact which can be used later on if the need arises. This individual is a point of reference for the company or university they are representing. Most importantly, this individual can aid in setting up design environments. The way a person learns varies from individual to individual. One person can learn faster in one method than in the other method. However, the methods discussed are the most prevalent ways people learn. All of these methods have pros and cons. The one that really suits the digital designer is the one that will make him the most effective. 3.2 Design Process for FPGAS Figure 5, on the following page, is a chart which illustrates three routes for digital design. All of these design flows are methods which lead to implementation of a digital design either with programmable logic devices (FPGAS and CPLDS) or ASICS. As can be seen, this chart was tailored to the environment which has been setup at Michigan State University, however, only the names change in the design flow chart but not the final result. In this section, issues will be discussed concerning the 44 Design-Flow Options L Programmable Logic Devices IC Layout FPGAS CPLDS Digital mos designs Schematic capture Schematic capture Schematic capture VHDL CUPL ABEL ABEL Verilog SpeedWave Speedwave Analog Fusion Viewsim Viewsim Digital Fusion Digital Fusion CUPL Viewsynthesis Create Jedec Pspice Simulation (Microsim) XACTstep Chipmaster IC Layout 6000 (L-EDI'I‘) £32352“ Program MOSIS chip Chip fabrication Figure 5: Design-Flow Options 45 design process. More specifically, the design process for Xilinx FPGAS will be discussed. The design process for FPGAS actually is broken up into three phases. These phases are design entry, design implementation, and design verification. The following sections focus on these design phases because they involve optimizations required to improve the already optimized conceptualized design that will be implemented on the Xilinx FPGA. 3.2.1 Design Entry As technology changes the repertoire of components for the digital designer continues to expand [21]. These components for the designers can be used in their design or they can make modifications to make up their own components. Whatever the application, the designer must choose a method of design entry that will allow him to implement his design within the shortest amount of time but with a great amount of efficiency and accuracy. The common methods of design entry are schematic capture, hardware description languages (HDLs), and boolean entry. Schematic Capture and HDLs will be discussed mostly in this section because they are more commonly used among FPGA designers than boolean entry. Schematic Capture Schematic capture is the most widely used method for implementing designs for FPGAs[21]. It tends to be the method of choice among digital designers because it is the traditional method of design entry. In the past, few designers could use software packages which would take text written descriptions and formulate a schematic from 46 which to build components. Designers had to draw out the design after they figured out the idea, thus it became the focus of EDA vendors as these companies began to emerge. Schematic capture is a useful tool for the designer to visualize the conceptual design. This is the tool that deals with the logic inside the black box of many different electrical devices. It provides the designer with a much more tangible design short of the actual physical implementation. This realization of the conceptual design allows the designer to make modifications while actually seeing the changes. Thus, it is understandable why designers feel safer using this method of design entry [21]. Using schematic entry with WorkView Office 7.2 begins with the Project Manager. In this particular package the designer chooses the libraries that have components that they will need in their design. For Xilinx, the user can use the libraries provided by Xilinx or they can use the Xilinx libraries which come with WorkView Office 7.2. These libraries provide the user with the components necessary for basically whatever FPGA, the user is targeting. For this reason, the person should have at least an idea of what kind of device they want to use. Only the libraries specific to Xilinx components can be used . For example, a person cannot use regular libraries for a general schematic with components from vendor specific libraries such as Xilinx. Combining these libraries will cause problems in the simulation phase, which will be discussed later, of the design process. After the user chooses the libraries to be used he must save this setup as a *.vpj file. This file will contain all the information about the libraries that are to be used; moreover, as long as its the open project within project manager it will be linked to all of the other tools within WorkView Office 7.2. 47 Once the user has saved the setup in Project Manager, the user then opens the schematic capture tool called ViewDraw. It is here that the designer enters the schematic. Using the different project settings, the designer can tailor the design to his liking. Here the designer can implement the design using the libraries specified within the Project Manager, as well as, set up different attributes for the design. Things such as delays, reference designators, etc. are easy to enter just by clicking on the device and setting the value for the attribute. After the design has been entered, there are a few things that the designer must be sure of when working with Xilinx. The first thing is that all inputs must come from an Input Pad and be connected to an Ibuf. Doing this tells XACTstep that this is a user defined quantity and is provided external to the internal logic of the device. The next requirement is for outputs. If outputs are going to be seen external to the chip, i.e. connected to LEDs, then like the inputs they must go through Obufs and then to a Opad. Doing this alerts XACT step that this output needs to be assigned output pins from the device. These rules apply whether you are using single input, single output, a vector of inputs, or a vector of outputs. Finally, when naming nets the user must be aware that the signal must be named before and after an Ibuf or Obuf. Also naming the Ipads or the Opads would not hurt. Following these rules will eliminate some of the errors of a novice when saving and checking the design. Once an error free schematic has been created, then the user will use Viestm to generate the netlist(*.vsm) which will be needed by the XACTstep. Here the user should watch the window very carefully. If errors occur, the application will terminate and tell the user the error. Most of the time these errors are self explanatory but sometimes they 48 are not and the manuals or the on—line help which accompanies the WorkView Office 7.2 software package are rather ambiguous. When warnings occur, the user has the option of getting rid of them or ignoring them. For simulation purposes, that will be okay but for generating the Xilinx netlist (*.xnf), this could prove to be a very big problem. The problems occur because of the way the translation tool for Xilinx will read the warnings in the *.vsm file from the WorkView Office 7.2 tool. At this point, a good understanding of netlists would be helpful. Of course understanding the netlist is a little too much to ask of the beginner. However, for the more advanced user, a basic understanding of the two netlists could prove very helpful. Because of the warnings, the tool for Xilinx will make assumptions about what it believes the *.vsm tool meant for the schematic. These errors could range from something obvious like a failure in the translation of the design to something less obvious like a successful translation but a failed implementation. At this point, it becomes helpful to learn how to read the netlist. This error actually occurred in the demonstration project which will be discussed in the next chapter, and it will be discussed more thoroughly at that point. This issue is addressed here to stress the importance of having a schematic which is free of errors and warnings. ViewDraw is not a hard tool to get used to. It provides a wide range of functions which can be easily implemented. It can be rather difficult to setup Project manager and it can be more difficult to keep in mind all the rules which apply for the Xilinx libraries. Overall, after a few tries most of these things become pretty easy to remember. Despite being used traditionally, schematic capture is no longer a realistic option for the digital designer. Entering designs which number in the tens of thousands is not only time consuming but hard for the designer to visualize [21]. For these reasons, an 49 alternative approach must be utilized. One alternative would be the use of Hardware Description Languages (HDLs). These languages will be discussed in the following section. Hardware Description Languages (HDLS) Hardware Descriptive Languages(HDLs) such as VHDL and Verilog are not welcome tools to the traditional designer but as technology pushes the number of gates into the tens of thousands, it has become a necessary one. As stated in the previous section, designs with high gate counts are hard for the designer to visualize. With the need to increase productivity and still include every aspect of a design , HDLs permit the designer to reach these goals more than schematic entry [21]. HDLs allow the designer to be more flexible. This attribute of HDLs allows the design to be independent of the device and allows for functional testing to occur in a shorter amount of time than in the schematic entry method [19] . Earlier functional testing is a direct result of the ease of entering a design using these languages; moreover, if the functional simulation fails then it can be easily modified if it fails to meet expectations. Within the current EDA environment, the user would be have to use VHDL rather than Verilog for FPGA design. This reason for this is that the Verilog compiler and editor is not provided with the educational version but can be purchased. Therefore, the user would have to use VHSIC (Very High Speed Integrated Ciruits) Hardware Description Language, VHDL, in the tool called Speedwave. SpeedWave is the VHDL editor, compiler and simulator for WorkView Office 7.2. This tool is independent of the Project Manager . No libraries will have to be set up 50 like in the schematic entry or boolean (ABEL) entry of the design in Project Manager. In this tool the user would enter VHDL manager found under the heading “TOOLS”. Within this manager the user sets up the particular VHDL libraries, the user wants the compiler to use when compiling the design. These libraries include mathematical functions, certain signal names, function calls etc. Also, the user creates a working library. This library is where all the VHDL code should be located and where the compiled entities will be stored. The user must make sure that he specifies a working library. When setting up these libraries, like in Project Manager, the user must be aware of where they are storing information. If they are not careful, the user could inadvertently store their design in someone else’s project. Once the designer has setup the libraries, he could then proceed to enter the VHDL design using the editor within SpeedWave or any editor of his choosing so long as the file is saved as a text file. Once the design has been compiled, the user then looks under the tools pull down menu and selects Analyze VHDL, at this point the Vantage compiler compiles the design. The compiler will display any errors which may occur. After error-free code has been compiled, the user can then go to the file menu and load the VHDL design. Doing this will invoke the simulator, and the user can simulate the code. The user can also invoke Digital fusion. Either one will not make a difference since they both simulate the same type of designs. Using this particular tool from WorkView Office 7.2 is very easy, though it may sound “too good to be true”. However, this tool does not offer templates for VHDL code; a feature which would make those who are not used to encoding within VHDL more comfortable. Overall, this tool is rather user friendly. 51 Using HDLs, does come with its own set of problems. To use HDLs is very expensive. They become expensive because when these designs need to be synthesized the user has to invest in workstations since most synthesis tools are UNIX based. A few software packages like WorkView Office and Quicklogic, provide synthesis tools with their packages. As vendors begin to produce more PC based synthesis tools the cost will decline for the user. However, for a company there is still the issue of providing training to designers. Companies have to pay for special courses for those designers who have not been exposed to HDLs before. For universities, it requires the faculty to incorporate more uses of HDLs within the curriculum. As an issue of EDA today reported, fewer than 23% of the graduating engineering students ever used or had an effective working knowledge of VHDL or Verilog [18]. Beyond cost HDLs present a different problem which is called code transportability. VHDL ,especially, is dependent upon who the vendor is and how the vendor perceives the VHDL coding [21]. The IEEE standard code is not enough to solve this problem. Vendors need to come up with a solution which allows the code to be transported more easily. Verilog is used less often than VHDL but does not have VHDL’s problem of transportability problem. HDLs are essential alternatives to digital designing for FPGAS. Despite some of the issues which make HDLs costly, they are still necessary for high density designs. They do not guarantee the most optimal design but they can provide a faster functional model which leads to increased productivity. 52 3.2.2 Design Implementation After a design is entered, the design must then be implemented. Depending on the designer design implementation can be either broken down into two phases or left as just one phase. The first phase, which is simulation/functional verification, is sometimes not considered a phase but rather an intermediate step between design entry and design implementation [8]. The second phase, that of synthesis and optimization, is considered to be the actual place where the design is implemented. For this section design implementation is broken down into these two phases. Simulation IFunctional Verification Simulation/Functional Verification of a design is a key step for the digital designer. It is at this point where the improvements can be made more easily. It is also where the designer can look and see how the components of the design fit together. It is here that the designer is forced to review and renovate his design and if necessary recreate it [8]. In WorkView Office 7.2, there are at least three simulators which can be used. The first simulator is Viewsim. Viewsim is used to simulate gate-level designs only. Viewsim can be invoked from the ViewVSM, netlist tool, or it can be invoked by clicking on the button provided in the WorkView Office 7.2 toolbar. The second simulator is SpeedWave. SpeedWave as described before is the simulator for VHDL designs. This simulator can also simulate gate level designs. It can only be invoked from the toolbar. The third simulator is Digital Fusion. Digital fusion can simulate gate-level and VHDL designs. An interesting attribute which distinguishes Digital Fusion from the other two is that if Analog Fusion was available, Digital Fusion could simulate digital 53 designs that comprised analog, VHDL, and/or gate-levels implementations in one design. A nice thing about the interface between Viestm is that if one of models of the design is a module (underlying VHDL code) rather than a composite(underlying gate-level schematic), then it automatically invokes Digital Fusion rather than ViewSim. Back annotation is the key at this point for the designer. After the schematic for the design has been generated, the designer can then run either of these simulators to make sure the design is functional at each level of a hierarchical design or all points of a flattened design. Afterwards, the schematic is ready for use with the XACTstep tools. At this level, VHDL code must go through one more process than a schematic. This process is called synthesis. After VHDL is synthesized, a schematic is generated for it. This schematic then becomes like any other schematic in ViewDraw. It can be modified, if warnings or errors are showing up in the digital design. The important thing is once the VHDL code has generated the schematic, the designer can modify the schematic rather than his code. After the steps are taken to ensure that an error or warning free digital netlist is created, the functional simulation is done, and the design is ready for importing into the XACTstep tool. Synthesis and Optimization Synthesis is the transformation of a behavioral design description into a structural composition of known parts [8]. Optimization occurs in conjunction with the synthesis. This is where the tool takes advantage of certain rules which vary from vendor to vendor to improve the performance or minimize the area of a design. Synthesis tools can be sold with EDA vendor’s suite of tools or by some external vendors. Vendors like Quicklogic with its $3000 design suite, WorkView Office 7.2, and w ' u 54 the Foundation series provided by Xilinx, provide the synthesis tool within a windows environment. This targeting of the windows environment reduces the cost of synthesis tools significantly. At one time most synthesis tools could only be found on UNIX systems which forced companies to purchase workstations. As more EDA vendors target their tools to the windows environment, the price for synthesis tools will decline. Within the WorkView Office suite of tools, the tool for synthesis is Viewsynthesis. Once the designer has compiled and simulated the VHDL design within Speedwave the user then uses this tool to provide the equivalent gate level representation using Xilinx components. Before this can be done, the user must go into Project manager and setup a project which uses Xilinx libraries. If this is not done, the ViewSynthesis tool will tell the user to setup the project. Once the libraries have been setup, the user looks under the “Project” heading in the tool and adds the VHDL code (*.vhd file) to the project. If the design is a hierarchical design then all the code associated with it must be included. Once the designs are added the user then chooses the device to be targeted. Upon choosing the device, the user then chooses the optimization settings like one—hot encoding, optimize for area or speed, etc. Now the designer is ready to compile or synthesize the design. A problem which arises with the ViewSynthesis tool is the fact that it recompiles the VHDL code with a different compiler. Therefore, a design which may work in Speedwave may not be compiled within the synthesis tool. This situation arises from the fact that Speedwave does not interface with the synthesis tool. They do not communicate with each other. Furthermore, these tools use two different VHDL compilers. A classic example of the transportability problem with VHDL that was discussed in the previous 55 section. This problem may cause the designer to rewrite his code several times before the VHDL compiler within the synthesis tool will compile the design. A problem which wastes time and can prove to be frustrating since the designer must learn the rule for both compilers so that the synthesis tool will compile the design without requiring the designer to rewrite the code several times. When the design is finally compiled, the user can then invoke ViewGen from within the synthesis tool. ViewGen looks at the mappings from the synthesized code and generates a schematic for it. At this point the designer is done with the synthesis tool within WorkView Office 7.2. The user then generates a netlist for the schematic using Viestm. After making sure the schematic is free of errors and warnings, the design is then ready for use with XACTstep. Within XACTstep, the user is now ready to target a more specific device. The user enters Project manager and sets up the tool to use the schematic which needs to be translated. For a hierarchical design, the top level schematic is chosen. Once this is done, the part if not specified with the schematic is chosen and then translated. The translation process is usually pretty simple and straight forward. Any problem within this particular phase is not easy to figure out. One problem that the user should be aware of is using entity names beyond eight characters. If the names are too long, then XACTstep will have problems reading the files. Another problem which may arise is that the user forgot to generate a netlist for the synthesized schematic. For the most part the errors lie within those two areas; thus, making the translation process rather easy to figure out even if there are problems. 56 After the translation process, the designer is now ready to implement the design. Within this step, the user can do more optimizations to the code. These optimizations include improving for area, speed, removal of redundant signals, removing unconnect symbols etc. the importance of each of these designs is dependent upon your specifications and the applications. Once these optimizations are determined, the FLOW Engine tool then begins to work on the design. Here, the Xilinx tool automatically goes through each phase of preparing the design for use with the FPGA, without user intervention. This first step is the optimization stage, followed by place and route, and lastly the generation of the bitstream. Of course problems can occur in this phase but they vary depending upon the design. The tool generates reports for the design. If errors occur the designer can browse these reports and try and figure out the problem. Once the bitstream is generated, the design is ready to be downloaded and verified. The synthesis tool within the WorkView Office suite is a useful one. However, there is a need for a compiler which shares information with the Speedwave to improve its performance. For the most part, it is adequate for providing the information needed to generate the information needed to prepare the VHDL code for XACTstep. Within XACT step, the design is refined and targeted towards a particular device and more optimizations can take place. With this much optimization occurring, the designer can not help but obtain at least a very good design. 3.2.3 Design Verification 57 Verification, as described by Webster’s dictionary, is the proof that something is true by some evidence [22]. This evidence is provided in several steps for the digital designer. This evidence can be seen in the back annotation and simulation of the optimized design, the actual downloading of the design, and the in-circuit testing of the design. All of these steps lead the designer to the place where his conceptual design is reality. Once the FLOW Engine has finished with the design, the design can now be tested for simulation with the WorkView office 7.2 tool. The user can use the xsimmake command within the DOS window and generate the design file needed to simulate the design within WorkView Office. This process is basically the same as described for back annotating a design when using the simulators. If everything has proven satisfactory the designer prepares to download the design. A step which can occur here or after downloading the design is the use of the Tinting Analyzer. This tool within XACTstep is a static tinting analyzer. It produces reports about the longest path delay within the design. Furthermore, if tinting specifications were placed for certain paths within the design then it generates a report which informs the user of all the paths which failed to meet that time specification. These reports can prove useful because the designer can then determine if the critical path, path with longest delay, will be a key bottleneck within the design. Sometimes, the critical path may be the least used path within the design; thus, it would not be essential to the design to improve upon it. The Timing Analyzer within XACTstep is a powerful tool which if understood could aid in improving the overall performance of a system. Downloading the design happens in the Hardware Debugger tool. This process is rather easy but can be very frustrating. The designer first makes sure that the Xchecker 58 cable or whatever cable he is using is plugged into the computer. It does not matter what cable is being used but it must be setup in the Hardware Debugger tool. Since the Xchecker was used in the downloading the design, the process for using it will be discussed. Once the designer has setup the Xchecker cable within the tool, the designer then plugs it into the target device. Once this is done and the user has insured that all the proper connections have been made, the design is downloaded. This process seems easy enough but can be rather involved. Some of the issues which arise are discussed in the next chapter along with the demonstration projects. If everything is done correctly then the designer should be able to wire up the design and test it immediately. Once the design is downloaded then the user must make sure that power is not removed from it or the program will have to be downloaded again. Design verification is the final part of the design in the process. It is also very easy to test for because its just a matter of wiring the design up and seeing if it will work with the given test vectors. Here the designer realizes his idea. At this point, all the work has been done and a physical implementation of the design can be completed. 3.3 Linking an EDA tool(WorkView 7.2 ) and an FPGA vendor tool (XACTstep) A famous quote, author unknown, states “too many cooks in the kitchen spoil the soup”. This quote adequately describes the situation when trying to run a front-end EDA tool with an FPGA vendors package. More often than not, these tools supposedly independent of each other tend not to provide an easy transition into an environment in which they both must work together. Issues such as system requirements and platforms 59 can become serious bottlenecks if not carefully reviewed before purchasing a package. A simple issue like loading the software packages can prove to be complicated, if one is not careful. In the following paragraphs, a discussion of setting up WorkView Office 7.2 and XACT step will be presented. Running WorkView Office 7.2 and XACTstep on the same machine introduced not a lot but some very interesting issues. The first issue to be addressed was which software package was to be loaded first. XACTstep 6.0.1 has with it ProCapture Series software. The ProCapture series software is the predecessor to WorkView Office 7.2. For this reason, they shared some files which were the same. When WorkView Office was installed on the machine first, the files which were loaded with the XACTstep package modified the common files between the ProCapture series and the WorkView Office packages. This modification of the files caused WorkView Office not to work at all. A possible reason for this stems from the fact that the ProCapture series was not meant to run in the Windows95 Environment, the files that they had in common and that had been modified within WorkView caused the program not to work. Moreover, some of the basic configuration and setup files were modified. This issue was resolved by installing the XACT step software package followed by WorkView Office. After determining which package to load on the computer, the issue of which security key went on first became an issue. This issue, at the beginning, seemed like there was an error in the licensing for the product. Whenever the software package was invoked , a “Flex/LM” error would occur. This error indicated a licensing error but did not give much more information than that. At the time, no clear instructions had been issued as to which security key, XACTstep’s or WorkView Office‘s, should be on first. 60 While this seems trivial, it was actually not, as it resulted in a massive waste of time while different solutions were being tried. It was not until a few weeks later that it was discovered that the WorkView Office’s key has to come before any other key. The Xilinx key somehow blocks the WorkView Office key from the computer, therefore the key can not be accessed and WorkView Office would not run. Of course, after switching the keys around, the system began to work. Understanding the system requirements for each tool is a very important issue. At the beginning of this research, WorkView Office and XACTstep were both running under the Windows95 operating system. As long as they were the only two programs on the computer, XACT step and WorkView Office 7.2 did fine. As the tool environment was being expanded, WorkView Office began generating page faults right in the middle of the application. Moreover, the system just began to lock up. Windows95 which is in charge of handling the swap space, did not have enough RAM to run the program and thus the system crashed or was frozen. Windows95 was handling the swap space in this particular case very badly. According to a paper on the web [5], if left to its own devices Windows95 supposedly should grow and shrink this space as programs will allow. Sometimes this space does not “grow” big enough to run certain programs thus the system crashes. The way to handle this problem would be to modify how much swap is allocated within the windows program or move the program. The latter approach was taken because running them on the same machine was not working but also if Windows95 is having such a problem with swap space why run it on the same platforms and eventually have it happen again. After further research into the possibility of running them on different platforms, it was 61 discovered that the WorkView Office suite of tools run better under the Windows NT environment. The Windows NT environment has proven invaluable. There is no problem in the interaction of the files which are ported over from the WorkView Office tool to the XACT step tool. Moreover, Windows NT warns the individual when the virtual memory will run out. This feature at least gives one the user one more chance to prevent the program from failing. Another issue which arose was that of disk space. WorkView Office and Xilinx are huge programs. Combined, they can take up 90% of the space on a 1.2 Gig hard drive. This particular issue was addressed by expanding the hard drive space. Moreover, WorkView Office is going to be networked which will actually allow things to run more smoothly, than strictly off a stand alone PC. Some problems that arose independent of the software packages themselves were business issues. Licensing was a major issue when setting up these two environments. Because the first release of WorkView Office 7.2 was licensed through Xilinx, a lot of time was spent trying to lift the restriction. Finally , a copy of WorkView Office was bought which ran independent of the Xilinx tool. This way the user could have access to more tools and libraries which are provided by WorkView Office, and still be able to work with the Xilinx tools. Thus, it becomes necessary to buy tools directly from the vendor of the product. 62 3.4 Summary Setting up the design flow for a new design environment can be rather involved. Understanding how people learn is essential to knowing how the training in such an environment will take place. Whether a corporation, training employees or a professor at a university, finding the least expensive and most effective way to do this is the most important thing. The design process for the design environment can then be formulated in a detailed fashion. It should not be a broad overview which can be found in basically any text book, nor should it be a quick overview. The design process should provide the necessary tools to ensure that the novice user is able to take advantage of the design environment and to use those features which would make the design experience a welcome ally rather than a charging bull. Of course, it is important to make sure that the software tools being utilized work well together. By setting up the environment from start to finish , it will be possible to figure out different solutions to early problems within this design environment. These issues that were addressed allowed for a larger environment to be implemented with some guidelines rather than going on a trial and error mission. All of these issues highlighted in this chapter were realized by setting up demonstration projects. These projects will be described in the following chapter. The design process was figured out by doing implementations of a few designs. These designs will in no way turn the world upside down, but they do provide an even more detailed discussion of the steps taken leading up to the implementation of design on the Xilinx FPGA. Chapter 4: Demonstration Projects The “try it and see what happens” approach when used properly does prove to be an effective way to evaluate different aspects of a design environment. This technique allows the user to understand some of the limitations to a tool as well as some of the advantages in using a particular function. Furthermore, it allows the user to obtain the prOper supplementary tools, if necessary, in order to make the design environment more complete. Within this research, three demonstration projects were undertaken. These projects served as evaluation tools of not just the present facilities for FPGA/CPLD but also as a measurement of the skills needed and the software packages being considered. These three designs consisted of two regular structure designs, combinatorial and sequential, and a project of irregular structure. These designs were chosen to test different aspects of the tools involving different areas of digital logic design. A combinatorial design was chosen in order to test the asynchronous behavior of the FPGA. Asynchronous designs provide a greater degree of flexibility, such that various aspects of digital logic design can be explored. On the other hand, a state machine, also of regular structure, provides the same flexibility with synchronous behaviour. Both the designs implemented would be familiar to most digital designers. The irregular structured design was used to test the capability of the software environment and the tools for handling designs not within the constraints of normal digital design. All of these projects were implemented using either schematic capture, VHDL, or a ntixed design, using the WorkViewOffice 7.2 and XACT 6.0.1 versions of the software 63 64 packages. Each one of these projects will be discussed at length along with the problems encountered and possible solutions to these problems. 4.1 Combinatorial: Multiplier design Multipliers are designs which are simple and can be easily used to provide a variety of ways to test different aspects of digital logic design [8]. This design was the first one implemented using Work View Office. It was utilized not only to explore issues dealing with a design using VHDL code but it was also to see some basic performance attributes in implementing a combinatorial design on an FPGA. 4.1.1 Design specifications The multiplier design in this particular project was designed with the following criteria in mind: 1) Design entry method must be in VHDL 2) Multiplier must be for two inputs that are unsigned and eight bits wide, with an output which is 18 bits wide, consisting of a 16 bit product, a carry out and an overflow 3) Try to make the worst case delay of the multiplier to be at the most 100ns The design entry method was chosen to explore the issues involving encoding in VHDL to implementation. The inputs were chosen to be each 8 bits wide with an output which provides a 16 bit product, a carry out and an overflow flag to alert the user when a carry out or overflow occurs. A less than 100ns delay was chosen due to the basic structure of the design. The design went through four levels of carry—save adders which would cause the delay to be rather large. Thus, choosing a delay less than 100ns forces the XACT tool to give better results when it is optimized for speed. 65 4.1.2 Design process The list provided below describe the steps of the design process for implementing the design on the FPGA. For more details, please refer to the previous chapter. WorkView Office 7 .2 (Windows NT) 1) SpeedWave (W orkview Office)was used to enter, edit and compile the VHDL code. 2) Functional testing of the design was then done by doing a simulation with the SpeedWave tool. 3) Once the code had been properly edited to insure that the design functioned, as described in the code, ViewSynthesis was invoked. 4) ViewSynthesis then recompiled the VHDL code and mapped it to a model in the form of a schematic (*.1 file). 5) This file was then viewed in ViewDraw and a digital netlist (*.vsm file) was created. 6) The WIR(contained the netlists) and the SCH(contained the schematics) were then transferred to the PC upon which XACTstep was on. XACTstep (Windows 95) 7) Design manager was invoked within the XACTstep tool and the project was created. The design was then translated from a *.vsm file to a *.xnf file (Xilinx netlist). 8) After the design was translated, Flow Engine then optimized, placed, routed, and created the bitstream for the design. 66 9) The Timing Analyzer was then used to check for time specifications, delay paths, and modifications were made if necessary. 10) Hardware Debugger along with the Xchecker cable was then used to download the design to the XC4010. 11) The design was then physically tested for functionality. 4.1.3 Results The multiplier design for this project was downloaded to the XC4010 which was set up in the manner illustrated on the following page. When the hardware implementation was tested, there were no problems in the functionality of the multiplier. The project however did fail to meet the tinting specification. The longest delay path of the design was l32ns before delays were assigned to the different components within the design schematic. This path was improved by assigning an overall input delay of 70ns for the complete multiplier design. Even though this particular specification was not met, the design was rerouted and improved the longest path delay to be 118ns. This particular delay was the best time to be achieved without completely designing a completely different multiplier. 4.1.4 Problems encountered The first problem which occurred is listed in number 7 of the design process. Viestm which created the digital netlist for the synthesized schematic in Workview Office generated warnings. At first these warnings were ignored. Therefore, the design failed when it was taken to the Flow Engine tool. Of course a significant amount of time 67 was spent trying to figure out the problem. These warnings caused the translator for XACT step to misinterpret the design and thus generate a netlist which had a design error in it. This error was the assigning of an input to drive an output pin. To better illustrate, it is like putting a switch to the output of a gate. The circuit is shorted. Within the Flow Engine, the design was caused to fail for that reason. However, this problem was discovered only after looking at the netlists that were generated by each tool. Thus, it is better to have a schematic free of warnings before allowing XACTstep to translate it into a *.xnf file. Number 10 dealt with the downloading of the design to the target system. After the bitstream was created, the Hardware Debugger tool along with the Xchecker cable was then used to download the design. When the design is downloaded the FPGA, sends a signal which indicates that the design was downloaded successfully, this did not happen. So the board with the FPGA was rewired and the Xchecker cable was replaced with another one, but this did not resolve the issue. The FPGA was then placed in the demonstration board provided by Xilinx to ensure that the FPGA was not faulty. This fact was verified because when the cable was connected to the demonstration board the design downloaded successfully. After further investigation, it was determined that the target system had too much noise on the line for the baud rate of 9600, at which the Xchecker cable was downloading the bitstream. The baud rate was increased to 19200 and the design downloaded successfully. This issue involving noise on the line especially when using a protoboard could have also been resolved by using decoupling capacitors . This issue can occur more often than any other in the design process for FPGA implementation of a design. 68 4.2 Sequential Design : Counter This first project to be implemented was that of a simple 4-bit counter. This particular project is a good example of synchronous behavior via a state machine. It makes use of the flip-flops which are in abundance when using FPGAS. It serves as a good example of a small test design to become familiar with the behavior of a synchronous design using an FPGA. 4.2.1 Design Specifications This particular counter was designed with the following specifications. (1) 4-bit binary counter (2) Use of schematic capture (3) Clock enable, clock, clear (4) Clock enable out (cascade capability) The design was chosen to be four-bit using four toggle flip-flops. The flip-flops were cascaded using proper logic to obtain a four—bit counter which is capable of counting from 0 to 15. The counter output transitions occur on the rising edge of the clock and when the clock enable is high. If the clear signal is active, then the counter is cleared to 0. Once clear becomes inactive, and if clock enable is high, then the counter counts from 1 to 15 and reaches 0 only upon clearing it. The clock enable out is provided to make the cascading of the counter easier to implement a larger counter. 4.2.2 Design Process The list provided below describes the steps of the design process for implementing the design on the FPGA. For more details, please refer to the previous chapter. 69 WorkView Office 7.2 (Windows NT) 1) Viewdraw (W orkview Office) was used to enter the design schematic. 2) A digital netlist (*.vsm file) was created and ViewSim was used to simulate the design. 3) The WIR(contained the netlists) and the SCH(contained the schematics) were then transferred to the PC with XACTstep. XACTstep (Windows 95) 4) Design manager was invoked within the XACTstep tool and the project was created. The design was then translated from a *.vsm file to a *.xnf file (Xilinx netlist). 5) After the design was translated, Flow Engine then optimized, placed, routed, and created the bitstream for the design. 6) The Timing Analyzer was then used to check for time specifications, delay paths, and modifications were made if necessary. 7) Hardware Debugger along with the Xchecker cable was then used to downloaded the design to the XC4010. 8) The design was then physically tested for functionality. 4.2.3 Results The schematic for the counter design was successfully simulated within the Workview office software package. It was downloaded using the 19200 baud rate. A baud rate of 9600 was also used and was successful. However, it is still recommended 70 that the 19200 baud rate is better because, it consistently compensates for the noise caused on a protoboard for downloading a design. The counter design was implemented using a switch register box and run on a 2H2 clock. The clock was chosen because it is easy to read the number at a comfortable rate. The schematic, simulation results, pinout, and timing report is provided in the appendix. No problems were encountered for this particular design. 4.3 Processing unit 4.3.1 Design specifications The processing unit was designed to meet the following specifications. (1) 8-bit instruction word (2) 3- bit opcode (3) a register file of with 16 addresses The design was chosen to implement instructions which consist of 8-bits. This 8-bit instruction includes three bits which dictate the function, a 4-bit address code, and a l-bit code used especially for loading the accumulator. The 3-bit code was chosen to implement the 8 basic instructions which usually accompany a processing unit. 4.3.2 Design Process The list provided below describes the steps of the design process for implementing the design on the FPGA. For more details, please refer to the previous chapter. WorkView Office 7.2 (Windows NT) 1) Viewdraw (Workview Office) was used to enter the design schematic. 2) A digital netlist (*.vsm file) was created and ViewSim was used to simulate the 71 design. 3) The WIR(contained the netlists) and the SCH(contained the schematics) were then transferred to the PC with XACTstep. XACTstep (Windows 95) 4) Design manager was invoked within the XACTstep tool and the project was created. The design was then translated from a *.vsm file to a *.xnf file (Xilinx netlist). 5) After the design was translated, Flow Engine then optimized, placed, routed, and created the bitstream for the design. 6) The Timing Analyzer was then used to check for time specifications, delay paths, and modifications were made if necessary. 7) Hardware Debugger along with the Xchecker cable was then used to downloaded the design to the XC4010. 8) The design was then physically tested for functionality. 4.3.3 Results The schematic for the processing unit is provided in Appendix C. .The ALU performs all the operations between an accumulator and a register file. The register file can be loaded with certain values using a basic LOAD command and loading the number into accumulator and then storing the command for the data register. All the values processed by the ALU are from the data register and the accumulator. They are routed to the ALU and then placed back in the accumulator. The dedicated input ‘ul’ is used and can be used to load the accumulator with external values. 72 Appendix B contains a table of the possible opcodes and the functions that the processing unit generates. The unit is run by an on-board 8 MHz clock. This clock was chosen because of the delay in some of the internal structures required a very slow clock. These instructions were chosen because they were simpler to handle and could be used to test the functionality of the FPGA with a design which was not so complex in the sense that it is easy for the user to comprehend. All instructions were being implemented, as shown from the ViewSim simulation results. Making the data synchronous presented an extra challenge. Unfortunately, inconsistencies showed up in the simulation results which made the design more of a challenge. These inconsistencies were proven not to be completely related to the way the design was done but rather by the limitations of the software package. Some of these inconsistencies will be discussed in the next chapter. In the appendix, the test program is provided which was used to test the processing unit, along with the schematic for the processing unit, pin layout, (XACT 6.0.1) and the timing analysis report. A series of simple instructions which were loaded into the processing unit doing simulation to output a particular function, has been included. 4.3.4 Problems encountered and their resolution In addition to the problems with the simulator, a problem which was noticed with the design is that of asynchronous components. Though the processing unit included registers, the design which was implemented incorporated components which exhibited 73 asynchronous behavior. These components caused additional delays which contributed to synchronization problems as seen in the simulation results provided in the appendix. According to Chan [23], the difference lies in the differential in the propagation delay in the design. The difference caused the design to simulate with delays in the outputs which caused the results to be lagging in the simulation. These delays could probably have been adjusted if the amount of delay was equal to that of the registers at different stages. Another possible resolution to the problem is to make more of the asynchronous logic synchronous. This additional logic will increase the area but eventually may help synchronize the design. The use of the processing unit illustrated key points about implementing synchronous designs. One important point to be considered is the use of the same clock within the design. In an effort to make the design more synchronous, a different clock was placed on an internal component which forced the design to run at two different speeds. The extra clock was added to compensate for some of the delay on the other components as previously discussed. Another important thing for synchronous design with FPGAS, is to partition the design and handle synchronization problems earlier on during the design. If possible simulate the design at different stages of the design. Doing this could possibly cut down on synchronization problems. Despite the inconsistencies during exhaustive simulation, and design implementation, XACTstep was used to map the design to the FPGA. The processor design utilized approximately 45% of the FPGA and from the timing report could be run at 18MHz. 74 4.4 FIR filter This design is not normally implemented on FPGAS. It is meant to explore issues involving the implementation of such a design and to evaluate whether using VHDL code, schematic entry, or a mixture of the two is required. 4.4.1 Design Specifications The design was set up to meet the following specifications. 1) Sampling frequency of at least 15 kHz (used for speech processing) 2) Data input 8 bits wide and data out 8 bits wide 3) 3rd order FIR filter The frequency was chosen because this is a little more than the frequency at which speech processing is done. The data bits were chosen due to the limitations of the A/D and the D/A converters that could be utilized with the filter design . 4.4.2 Design Process The list provided below describes the steps of the design process for implementing the design on the FPGA. For more details, please refer to the previous chapter. WorkView Office 7.2 (Windows NT) 1) Viewdraw (Workview Office) was used to enter the design schematic. 2) A digital netlist (*.vsm file) was created and ViewSim was used to simulate the design. 75 3) The WIR(contained the netlists) and the SCH(contained the schematics) were then transferred to the PC with XACT step. XACTstep (Windows 95) 4) Design manager was invoked within the XACTstep tool and the project was created. The design was then translated from a *.vsm file to a *.xnf file (Xilinx netlist). 5) After the design was translated, Flow Engine used then optimized, placed, routed, and created the bitstream for the design. 6) The Timing Analyzer was then used to check for time specifications, delay paths, and modifications were made if necessary. 7) Hardware Debugger along with the Xchecker cable was then used to download the design to the XC4010. 8) The design was then physically tested for functionality. 4.4.3 Results The implementation of the filter design on the FPGA was successfully prepared. The design itself had to go through several iterations because it initially exceeded the capacity of the FPGA that was being used. From the timing reports generated by the Timing Analyzer , the filter could be operated at a maximum frequency of 12.9 KHZ which was well within the allowable range specified in the previous paragraph. This 3 design, however, introduced some software limitations which can result in a loss in 76 design time if the user is not careful. These limitations will be discussed in the following paragraph- 4.4.4 Problems Encountered This design proved the most difficult one during the implementation stage. The first problem that arose involved the use of dedicated carry logic. The dedicated carry logic, is a special feature provided by Xilinx [12]. This produced a design which was composed of 34000 digital modules. The amount of CLBs needed, 468, exceeded the amount available on the chip,400. Thus the design had to be completely revised. As stated earlier in the paper, designs should be independent of the FPGA one is using. However, after implementing this filter design, the FPGA being used should become a consideration. The filter design required at least 8 flip-flops per register which included about 4 CLBs. The adder took up at least 32 CLBS. After adding up all the components and figuring out the CLBs, an appropriate number of utilized CLBS was determined. However as discussed in the previous paragraph, the amount of CLBs exceeded those available on the FPGA. From this particular design, or any exceptionally large design, after functional simulation, the design should be taken to XACT to determine the number of CLBS needed so that the design can either be changed or the proper equipment obtained. The FIR filter design had to be revised by replacing the carry logic with a regular full adder. This reduced the design in area and it was mapped to an FPGA. 77 The flow engine tool kept using a trim command even after the function was disabled. This trimming produced errors and warnings. Unfortunately, trimming is done whether the user wants it or not which can become rather annoying when implementing designs. This use of trimming also causes the delay data generated by the Timing analyzer tool to possibly be inaccurate. Fortunately, the Xilinx tool gives the user warnings about the removal of such logic. Another problem which occurred earlier in the design process involved the ViewSynthesis tool. The design of the filter was first implemented in VHDL code. It simulated just fine within Speedwave but when it was time to be synthesized the VHDL code produced warnings and errors. This design is an example of the transportability problem which was introduced in the previous section. This problem is particularly interesting since it occurs within the vendor provided tools. After several iterations of trying to resolve this issue, the design was done in schematic entry format. This design, though not physically tested, provided insight into the importance of partitioning a design, and the importance of being aware of the resources available to an individual on the chip. It demonstrates that early up in the design process, if an FPGA has already been chosen , the user should remain focused on the design but remember what device they are going to use. Another important lesson is to make use of any vendor-provided Special functions. These functions could prove to enhance the design. The demonstration projects for this thesis provided different aspects about the implementation of code and the limitations of the system when implementing designs which were rather dense. It also illustrated how VHDL code must be able to be transported , especially within the tools of a given vendor. Overall these projects 78 introduced problems that seemed simple enough to fix but really required quite a bit of time. Moreover, key issues were able to be addressed which allowed for a quick fix for the current environment. Chapter 5: Summary and Conclusions FPGAS and CPLDS, by next year, are reported to be at least a two billion dollar market [8], an almost staggering revelation but not really a surprising one. Their development over the recent years has been astronomical. The EDA tools used to develop designs are still somewhat lagging; yet they have provided still powerful design environments for the digital designer. As FPGAS/CPLDS continue to revolutionize areas like telecommunications, cable, medical device development, and many others, it will become necessary for those currently doing digital design or VLSI design as well as future Electrical Engineers to become familiar with these devices and their uses, as well as the tools that are used to develop designs to be implemented on them. 5.1 Problem Restatement This thesis project addresses some contemporary issues involved when PLDS (FPGAS and CPLDS) are being considered for incorporation into digital designs. This project is also intended to discover some of the underlying issues which need to be addressed by both FPGA vendors and EDA software deve10pers. Furthermore, it is meant to serve as a tool to raise the level of awareness about developing an environment for designing with PLDs (FPGAS and CPLDS) at Michigan State University. 5.2 Contributions This thesis provides valuable insight into programmable logic devices and the software environment under which these designs are developed. By setting up the current design environment using WorkView Office 7.2[9] and XACTstep[5], guidelines were 79 80 established for integrating certain software packages. With the help of the demonstration projects, a design methodology specific to the current environment is presented. Moreover, guidelines for choosing devices have been established. This research also provides a list of problem fixes/suggestions for the current design environment. The different contributions of this thesis project are provided in the following sections. 5.2.1 Checklists for the implementation of designs on PLDS Throughout this thesis project, the goal has been to develop strategies to obtain a better understanding of PLDs (FPGAS and CPLDS). This understanding is two- fold, in the sense, the individual must first understand the methods of design entry for the design environment in which they are working. Second, the designer must also be able to choose the device which will best fit the end-application. In the previous chapter, different designs which covered a variety of issues concerning the implementation of digital logic design were discussed. As a result of this research and the demonstration projects, the following lists were developed. Some things addressed are specific to the design environment but, for the most part, these lists can apply to basically any design environment being utilized by a designer. 5.2.1.1 Design methodologies The lists provided, on the following page, are actually summaries of implementing designs on the current design environment. The entries in these tables were actually discussed in chapters three and four. They are simply meant to serve as guidelines to using the current design environment and to provide helpful hints to help make sure that 81 the design process for PLDs (Xilinx FPGAS and CPLDs) is an easier one, as well as, an effective one. Table 8: Design process for FPGAS WorkView Office 7.2 WorkView Office 7.2 Schematic Capture VHDL 1 Setup Library search order in Project Manager 1 Setup Library search order in Project Manager and VHDL manager in Speedwave 2 Use ViewDraw to enter the design 2 Using Speedwave editor or any text editor enter design 3 Use ViewSim to simulate the design 3 Use SpeedWave to simulate the design 4 Use ViewTrace to verify functionality, (if it did 4 Use ViewTrace to verify not work. then back to step 2) functionality, (if it did not work, then back to step 2) 5 Create digital netlist using Viestm or invoke 5 Use ViewSynthesis to generate from within ViewDraw (is it error and warning structural model for design (if VHDL free, if not back to step 2) compiler here, go back to step2) 6 Choose the device to target 6 Invoke ViewDraw on the generated schematic and follow the steps described for schematic capture. 7 XACTstep v6.0.1 7 XACTstep v6.0.1 (Same for each Design method) (Same for each Design method) 8 Setup project in Design Manager and choose 8 Setup project in Design Manager and part to target choose part to target 9 Use Flow Engine to Optimize the design 9 Use Flow Engine to Optimize the (if it does not work, view reports. correct and design (if it does not work, view redo step). reports. correct and redo step). 10 Use Timing Analyzer for performance analysis 10 Use Timing Analyzer for (optional), if failed back to step 2 performance analysis (optional), if failed back to step 2 1 1 Use Hardware Debugger to download design 1 1 Use Hardware Debugger to download ‘ design 12 Generate test vectors and verify physical 12 Generate test vectors and verify implementation physical implementation 5.2.1.2 Checklist for choosing PLDS (FPGAS and CPLDS) The most interesting aspect about designing for FPGAS and CPLDS is the fact that these designs are completely independent of the device of the device they are targeting. These devices, no matter what, can be “shaped” into fitting the design 82 considerations. Sometimes I/O count for the design may exceed the amount provided by the device or the area of a design may require the use of a different device later on but these issues are not significant enough at the beginning of the design process. The designer is free to conceptualize, visualize (schematic capture or VHDL code via synthesis tool), and verify the functionality of the design process free from the constraints of the physical device. Yet, it is still important, after the design has been prepared to be targeted to a device, to understand or at least be aware of some questions which could not only save time but money when choosing these devices. The list below are questions which should be considered by the designer when choosing a device. 1) What is the end application? 2) Does the device have special features which can improve the design? 3) Does the device satisfy the input and output requirements of the design? 4) Can the device handle the density of the design? 5) How flexible is the device to changes? Is it an ISP device? 6) What are the power considerations? 7) Is the device erased when power is removed? 8) How should the device be mounted into the target system? 9) How is the device to be programmed? Are the proper tools available? 10) What is the cost? 83 11) How is the technical support for the device? 12) What does the maintenance contract entail? All of these issues if addressed can cut down on the time and money when choosing a device. Of course, some of these questions can be dealt with beforehand, however, they are not meant to serve as design restrictions. 5.2.1.3 Checklist for developing EDA environments The EDA tool environment is a very important part of designing for PLDS. It is here that key optimizations and mappings occur to produce a design which is even better than the original design. The EDA environment that is available for programming PLDS should exploit the architecture of these devices, especially FPGAS. The speed and the true capacity for the FPGA is truly dependent upon the tool environment in which designs are implemented for it. This requirement is essential for the following reason. Most designers do not understand the architecture of these devices and do not have time to learn; thus, the tool environment in which they work must compensate for this lack of knowledge by handling some of the responsibilities of understanding the device so the best design can be produced. Thus, understanding certain aspects about the tool or tools could aid the users in obtaining all the information necessary to put together the correct and most efficient design environment possible. The following questions could prove helpful when determining what tool to use in a particular environment. 1) What are the requirements of the EDA environment? 84 2) How user friendly is the tool? 3 On what platform is the tool is the package most effective? V 4 If running different platforms, will the file be portable from one platform from V the other? 5 V What are the system requirements to run the package(s)? 6 What are the prices and the maintenance fees for the tool? V 7 v What is the cost of training? How does the tool(s) fit into the current curriculum? 8 V What supplementary tools, if any, are necessary? 9) How efficient is the technical support staff? 10) Does the tool provide versions for home use? If so how extensive is this tool? 11) Does this environment have all the capabilities required? The first and last questions are essentially the same. However, the first question is used to determine the focus of the environment to be developed. The second question is to make sure that the environment that was setup has provided all the things that were decided upon when answering first question. 5.2.3 Problems that could be encountered and their resolutions. When dealing with any new environment, problems can arise which take a long time to resolve but have the possibility of recurring again. The list below, addresses certain problems encountered while doing this thesis project. It is intended to provide 85 information and helpful hints to certain software problems and design debugging for the current environment. 1. Problem: Windows 95 Page Fault Solution: A: Exit Workview Office completely and restart computer B: Zip files and Move to Window NT machine 2. Problem: WorkView Office: Licensing Error Solution: A: No license for the tool being accessed. B: If all programs are doing this, make sure that the license key is installed on the back of the machine C: If running a system which requires multiple security keys, make sure the WorkView Office key is first. 3. Problem: Windows NT: Warning about virtual memory Solution: Close the applications that are not immediately being used. 4. Problem: Windows NT: Viewdraw.exe error Solution: A: Restart not necessary, just re-open Viewdraw window B: If backannotating a design, then minimize the schematic window until it is ready to be viewed. 5. Problem: WorkView Office 7.2 and XACTstep are on the same machine: Workview Office runs incorrectly Solution: A: Make sure that Xactstep was installed first on the machine. B: Make sure that the WorkView's security key is first. 6. Problem: XACTstep: cannot generate wir file Solution: Problem: Solution: Problem: Solution: 86 A: If porting from Windows NT, make sure the WIR, SYM, and SCH were ported for the design. B: If using a user-defined component from a different project, make sure a copy of the netlist is generated in the current working directory. C: Check the name of the design. Cannot be longer that eight characters. D: Make sure that the *.vsm was free of warnings and errors. Rerun Viestm on the design. E: Check the translatelog file, may need to change the device that is targeted. F: Call technical support XACTstep: Flow Engine fails A: Review the reports generated and go back to original schematic XACTstep: Downloading fails A: Make sure Xchecker cable is connected correctly. B: Double check the wiring of the whole design C: Check the power supply to the target system. Make sure that it’s on. D: Increase the baud rate of the design E: Decouple the power supply with .1 or .01 pF capacitor 87 5.2.4 Raised level of awareness concerning PLDs and EDA environments The most important contribution is the setting up the design environment here at Michigan State University. With the aid of some of the research done in this thesis the Electrical Engineering department has implemented a design environment within the labs and curriculum which will aid in producing future engineers who will be prepared to face the challenges of the constantly changing digital design and VLSI technologies. Moreover, with the guidelines established within the thesis, the transition for students will hopefully be a smoother one. 5.3 Future work This thesis project has established the foundation for future work which can be done here at Michigan State University. Hopefully, as the use of these tools become more familiar to the students, more advanced projects canbe undertaken within the classroom settings. The use of PLDs can be extended in to classes such as digital signal processing, control systems, etc. Integrated circuits which encompass these devices can be developed. Research concerning EDA tools can be developed to address some of the issues established in this project such as Synthesis tool development, user friendly GUIs (Graphical User Interfaces), algorithms for development of lower powered ISP devices, etC- The amount of future work depends on Michigan State University, but as this teChnology continues to advance, the possibilities are almost limitless. PLDS are devices which have extended their usefulness into almost every aspect 0f tcChnology. As the designs become more complex and dense, the vendors of these dCVices continue to improve upon the architectures; thus, extending their capabilities. 88 These advancements with the devices must also include advancements with the EDA tools. Without a simultaneous growth of the device architectures with the EDA tools, the capabilities and the usefulness will remain unexplored. This thesis project dealt with some of the issues involving PLDS, specifically, Xilinx FPGAS. Hopefully, it will serve as a catalyst for even more extensive study into the area of EDA tool development and PLD development here at Michigan State University. Most importantly, it is believed that this project can serve as a valuable resource in setting up future design environments and preparing future engineers for a world that is quickly becoming influenced by digital technology in almost every area of life. APPENDIX A: LIST OF FPGA/CPLD AND EDA SOFTWARE VENDORS 89 APPENDIX A LIST OF FPGA/CPLD AND EDA SOFTWARE VENDORS Current Vendors used by MSU X'l' Internet: www.xilinx.com Tech support: Help line 1-800—255-7778 email: hotline@xilinx.com Viewlogic Internet: www.viewlogic.com Tech support: Help line 1-800-CAE-VIEW email: pc_support@viewlogic.com Other Vendors Low Density PLDS or CPLDS Vendor name Lattice AMD PAL(vantis) Cypress High Density PLDs or CPLDS Wine Logical Devices Lattice Actel Altera AMD Mach AT&T (Lucent technologies) Xilinx Internet www.1atticesemi.com www.vantis.com www.cypress.com Internet www.10gicaldevices.com www.1atticesemi.com www.actel.com www.altera.com www.vantis.com www.1ucent.com/nticro/fpga www.xilinx.com (student version) EDA Vendors Vendor naLme Data I/O (Windows) Cadence (Windows) Mentor Graphics(Unix) (Will support PC in future) Vendor name ORCad (Windows) Synopsis Viewlogic (Unix + Windows) FPGA Vendors Vendor name Xilinx Altera Orcad 90 Internet www.synario.com www.cadence.com www.mentorg.com Internet www.0rcad.com www.synopsis.com www.viewlogic.com (student version) Software XACT Step 6.0.1 (Foundation Series) Max and Pluss # software Multiplier VHDL Code APPENDIX B DEMONSTRATION PROJECTS Simulation waveform - synthesized design Pin I/O Ofilinx report) Tinting Analysis Data Counter Schematic Simulation Data Pin I/O (Xilinx report) Timing Analysis Data Processor Schematic Simulation Data Pin I/O (Xilinx report) Tinting Analysis Data Opcode table FIR Filter VHDL Code Schematic Pi.“ I/o (Xilinx report) Tuning Analysis data 91 92 Appendix B VHDL Code for Multiplier Entity mult80 is p011(X,Y: in bit_vector(7 downto 0); productzout bit_vector(15 downto 0)); end mult8c; architecture struct of mult8c is component atree port (m0,m1,m2,m3,m4,m5,m6,m7: in bit_vector(7 downto 0); outputzout bit_vector(18 downto 0)); end component; component and2 port (a,b: in bit; c: out bit); end component; signal p0,p1,p2,p3,p4,p5,p6,p7:bit_vector(7 downto 0); signal final: bit_vector(l8 downto 0); For Ulzatree use entity work.atree(struct); begin p0(0) <= X(O) and Y(O); p0(1) <= X(O) and Y(l); p0(2) <= X(O) and Y(2); p0(3) <= X(O) and Y(3); 90(4) <= X(O) and Y(4); 130(5) <= X(O) and Y(5); p0(6) <= X(O) and Y(6); 130(7) <= X(O) and Y(7); P1(0) <= X(1) and Y(0); 131(1) <= X(1) and Y(1); p1(2) <= X(1) and Y(2); p1(3) <= X(1) and Y(3); 131(4) <= X(1) and Y(4); p1(5)<= X(1) and Y(5); pl(6) <= X(1) and Y(6); pl(7) <= X(1) and Y(7); p2(0) <= X(2) and Y(O); p2(1) <= X(2) and Y(l); p2(2) <= X(2) and Y(2); p2(3) <= X(2) and Y(3); p2(4) <= X(2) and Y(4); p2(5) <= X(2) and Y(5); p2(6) <= X(2) and Y(6); p2(7) <= X(2) and Y(7); p3(0) <= X(3) and Y(O); p3(1) <= X(3) and Y(l); p3(2) <= X(3) and Y(2); p3(3) <= X(3) and Y(3); p3(4) <= X(3) and Y(4); p3(5) <= X(3) and Y(5); P3(6) <= X(3) and Y(6); p3(7) <= X(3) and Y(7); p4(0) <= X(4) and Y(O); 134(1) <= X(4) and Y(l); p4(2) <= X(4) and Y(2); p4(3) <= X(4) and Y(3); p4(4) <= X(4) and Y(4); p4(5) <= X(4) and Y(5); p4(6) <= X(4) and Y(6); p40) <= X(4) and Y(7); p5(0) <= X(5) and Y(O); p5(1)<= X(5) and Y(l); p5(2) <= X(5) and Y(2); p5(3) <= X(5) and Y(3); 95(4) <= X(5) and Y(4); p5(5) <= X(5) and Y(5); P5(6) <= X(5) and Y(6); P5(7) <= X(5) and Y(7); 136(0) <= X(6) and Y(O); P6(1)<= X(6) and Y(l); p6(2) <= X(6) and Y(2); 136(3) <= X(6) and Y(3); 136(4) <= X(6) and Y(4); 93 94 p6(5) <= X(6) and Y(5); p6(6) <= X(6) and Y(6); p6(7) <= X(6) and Y(7); p7(0) <= X(7) and Y(0); p7(l) <= X(7) and Y(l); p7(2) <= X(7) and Y(2); p7(3) <= X(7) and Y(3); p7(4) <= X(7) and Y(4); p7(5) <= X(7) and Y(5); p7(6) <= X(7) and Y(6); p7(7) <= X(7) and Y(7); U1: atree port map(p0,p1,p2,p3,p4,p5,p6.p7.final); product<=final( 15 downto 0); end struct; Entity atree is port (m0,m1,m2,m3,m4,m5,m6,m7: in bit_vector(7 downto 0); outputzout bit_vector(18 downto 0)); end atree; architecture struct of atree is component CSA15 port ( X, Y, Z: in BIT_VECTOR( 14 downto 0); U: out BIT_VECTOR (14 downto 0); V: out BIT_VECTOR (15 downto 0)); end component; Component CSA16 port ( X, Y, Z: in BIT_VECTOR( 15 downto 0); U: out BIT_VECTOR (15 downto 0); V: out BIT_VECTOR (l6 downto 0)); end component; Component CSA17 Port ( X, Y, Z: in BIT_VECTOR( 16 downto 0); U: out BIT_VECTOR (l6 downto 0); V: out BIT_VECTOR (17 downto 0)); end component; 95 component CSA 1 8 port ( X, Y, Z: in BIT_VECTOR( 17 downto 0); U: out BIT _VECTOR (17 downto 0); V: out BIT_VECTOR (18 downto 0)); end component; component CLA19 port(a,b:in bit_vector(l8 downto 0); czout bit_vector(18 downto 0)); end component; signal n0,n1,n2,n3,n4,n5,n6,n7,nn4,C1,C3:bit_vector(l4 downto 0); signal F1 ,F2,F3,C2,CC l :bit_vector( 15 downto 0); signal sl,s2,s3,c4:bit_vector(16 downto 0); signal t1,t2,t3,C5:bit_vector(17 downto 0); signal Q4,Q5:bit_vector(18 downto 0); signal ohboy:bit_vector(18 downto 0); For U0,U1,U3: CSA15 use entity work.CSA15(behavorial); For U2 :CSA16 use entity work.CSAl6(behavorial); For U4: CSA17 use entity work.CSA17(behavorial); For US: CSA18 use entity work.CSA18 (behavorial); For U6: clal9 use entity work.cla19(behavior); Begin n0<="0000000" & m0; n1<="000000" & m1 &"0"; n2<="00000" & m2 & "00"; n3<="0000" & m3 & "000"; n4<="000" & m4 & "0000"; n5<="00" & m5 & "00000"; n6<="0" & m6 & "000000"; n7<= m7 & "0000000"; F1<="0" & C1; 81 <= "0"&C2; S3<="00"&C3; t1<="00" & CCl; t2<="0" & C4; Q4<="0" & C5; U02CSA15 port map(n0,n1,n2, C1,F2); U1:CSA15 port map(n3,n4,n5, nn4,F3); 96 U2:CSA16 port map(Fl,F2,F3, C2,S2); U3:CSA15 port map(nn4,n6,n7,C3,CCl); U4:CSA17 port map(sl,32,s3, C4,t3); U5:CSA18 port map(tl,t2,t3,C5,Q5); U6:clal9 port map(Q4,Q5,output); end struct; 97 1 1'11 1&1! 12 1 1 1 1‘9 I 1 1 1 1 I 1 12 2 1 l 1 “ 1000 1m: Tine (seconds) 1110‘ 124 1 t 1 1 1 1 r rt. 1 1 1 1 F 1:5 1 1 1C 1 1 111125 501'! 144 T 1.27 143 Figure 6: Simulation data for Multiplier 1.1.1 98 Appendix B IO PIN ASSIGNMENT RESULTS FOR DESIGN MULTSC From PPR Version 5.2.1 1997/06/24 16:20:44 Xilinx, Inc. (c) Copyright 1997. All Rights Reserved. Chip Pinout Description This chapter describes where your design's pins were placed in terms of the package pins. Generally there are four sections for this chapter. The first section is a list showing signal name and the package pin location, sorted by the signal name. The second section is a list showing the package pin names and signal names sorted by the package pin names. Next section appears only if your design uses special pads. This will a table showing the special pad names and the signal names, sorted by special pad name. The last section is a series of CST file statements, which if copied into a text file, can be used as constraints for a subsequent ppr run for locking 105 at their current locations. Sorted by Signal Names: Pin Name Package Pin Location CO_pad : P65 OF_pad : P19 PRODUCTO_pad : P58 PRODUCTl_pad : P27 PRODUCT2_pad : P67 PRODUCT3_pad : P18 PRODUCT4_pad : P20 PRODUCT5_pad : P24 PRODUCT6_pad : P60 PRODUCT7_pad : P59 PRODUCT8_pad : P25 PRODUCT9_pad : P26 PRODUCT10_pad : P57 PRODUCTl l__pad : P28 PRODUCT12_pad : P61 99 PRODUCT13_pad : P56 PRODUCT14_pad : P8 PRODUCT15_pad : P10 X0_pad : P29 Xl_pad : P45 X2_pad : P39 X3_pad : P40 X4_pad : P41 X5_pad : P44 X6_pad : P38 X7_pad : P37 Y0_pad : P36 Y1_pad : P35 Y2_pad : P9 Y3_pad : P68 Y4_pad : P17 Y5_pad : P66 Y6_pad : P62 Y7_pad : P23 Sorted by Package Pin Locations: Package Pin Location Pin Name P8 : PRODUCT14_pad P9 : Y2_pad P10 : PRODUCT15_pad P17 : Y4_pad P18 : PRODUCT3_pad P19 : OF_pad P20 : PRODUCT4_pad P23 : Y7_pad P24 : PRODUCT5_pad P25 : PRODUCT8_pad P26 : PRODUCT9_pad P27 : PRODUCT1_pad P28 : PRODUCT11_pad P29 : X0_pad P35 : Y1_pad P36 : Y0_pad P37 : X7_pad P38 : X6_pad P39 : X2_pad P40 : X3_pad P41 : X4_pad P44 : X5_pad 100 P45 : X1_pad P56 : PRODUCT13_pad P57 : PRODUCT10_pad P58 : PRODUCTO_pad P59 : PRODUCT7_pad P60 : PRODUCT6_pad P61 : PRODUCT12_pad P62 : Y6_pad P65 : CO_pad P66 : Y5_pad P67 : PRODUCT2_pad P68 : Y3_pad CST File Format (location constraints file): place instance CO_pad : P65 ; place instance OF_pad : P19 ; place instance PRODUCTO_pad : P58 ; place instance PRODUCT1_pad : P27 ; place instance PRODUCT2_pad : P67 ; place instance PRODUCT3_pad : P18 ; place instance PRODUCT4_pad : P20 ; place instance PRODUCT5_pad : P24 ; place instance PRODUCT6_pad : P60 ; place instance PRODUCT7_pad : P59 ; place instance PRODUCT8_pad : P25 ; place instance PRODUCT9_pad : P26 ; place instance PRODUCT10_pad : P57 ; place instance PRODUCTl 1_pad : P28 ; place instance PRODUCT12_pad : P61 ; place instance PRODUCT13_pad : P56 ; place instance PRODUCT14 _pad : P8 ; place instance PRODUCT15_pad ' .PlO ; place instance X0 _pad . ';P29 place instance X1_pad : P45 , place instance X2_pad : P39 ; place instance X3_pad : P40 ; place instance X4_pad : P41 ; place instance X5_pad : P44 ; place instance X6_pad : P38 ; place instance X7_pad : P37 ; place instance Y0_pad : P36 ; place instance Y1_pad 2 P35 ; place instance Y2_pad : P9 ; place instance Y3_pad : P68 ; 101 place instance Y4_pad : P17 ; place instance Y5_pad : P66 ; place instance Y6_pad : P62 ; place instance Y7_pad : P23 ; End of Report ----====== 102 Appendix B Timing Analysis Data Xdelay Report File: Design: mult8c.lca (4010PC84-5) Program: XDELAY 5.2.1 Speedsfile: File 4010.spd, Version 4000.1, Revision 4010.15 Xdelay tinting analysis options: From all. To all. Worst case Pad to Pad path delay : 118 ns (17 block levels) Pad "Y2" (P9) to Pad "IOB2" (P65.0) 103 V“ FTCE ‘ no r“. F T C E i—-— 01 p. T: a . 1/Uaur O 1 FTCE I u 0———————-cr 07—" Ctn 1 1‘1]? CLENABLE EN F T C E . ‘—1]T 01 ctncx 428”; CE _4” P CLK 1\. c | I AD I Pinup 9‘ , a C” . 1_2" 2 A IBUF ' CLEAR CLEAR -~ Figure 7: Schematic for Counter UUIPUII3rOJ D 104 crust CLK - 1 - - r 11- 1111. _J H 111 a e _U Q3 02 01 00 T(CL Figure 8: Simulation Data for Counter 105 Appendix B 10 PIN ASSIGNMENT RESULTS FOR DESIGN COUNT From PPR Version 5.2.1 1997/06/24 21:04:54 Xilinx, Inc. (c) Copyright 1997. All Rights Reserved. Chip Pinout Description This chapter describes where your design's pins were placed in terms of the package pins. Generally there are four sections for this chapter. The first section is a list showing signal name and the package pin location, sorted by the signal name. The second section is a list showing the package pin names and signal names sorted by the package pin names. Next section appears only if your design uses special pads. This will a table showing the special pad names and the signal names, sorted by special pad name. The last section is a series of CST file statements, which if copied into a text file, can be used as constraints for a subsequent ppr run for locking 103 at their current locations. Sorted by Signal Names: Pin Name Package Pin Location CLEAR_pad : P29 CLK_pad : P28 EN_pad : P35 ‘ QA_pad : P36 QB_pad : P57 QC_pad : P9 QD_pad : P56 Sorted by Package Pin Locations: 106 Package Pin Location Pin Name P9 : QC_pad P28 : CLK_pad P29 : CLEAR_pad P35 : EN_pad P36 : QA_pad P56 : QD_pad P57 : QB_pad CST File Format (location constraints file): place instance CLEAR_pad : P29 ; place instance CLK_pad : P28 ; place instance EN_pad : P35 ; place instance QA_pad : P36 ; place instance QB_pad : P57 ; place instance QC_pad : P9 ; place instance QD_pad : P56 ; =----- End of Report ========== 107 Appendix B Timing Analyzer Report File Design: c:\1_users\tracie\demo4\xproj ect\v l_1\rev 1\count.lca (4010PC84-5) Program: TIMING ANALYZER 5.2.0 Speedsfile: File 4010.spd, Version 4000.1, Revision 4010.15 Xdelay tinting analysis options: From all. To all. Clock net "C" path delays: Pad to Setup : 10.9ns (0 block levels) (Includes an external input margin of 0.0ns.) Pad "CLEAR" (P29) to FF Setup (SR) at "Q0.C2" Target FFX drives output net "Q0" Clock to Pad : 17.1ns (0 block levels) (Includes an external output margin of 0.0ns.) Clock to Q, net "Q2" to Pad "IOB3" (P57.0) Clock to Setup (same edge) : 10.9ns (0 block levels) (Includes 1.3ns clock skew compensation.) Clock to Q, net "Q0" to FF Setup (D) at "CEO.G3" Target FFX drives output net "Q3" Minimum Clock Period : l7.1ns Estimated Maximum Clock Speed : 58.5Mhz 108 ur.ttu At-nuvtr-II . n. _.ni:)_._._._,__.__....It ._......_ ' ’lll' lllllr-ll tutti-Cl :'. Ill: jrcrsrrp m ril- rlIrlIrrtI-tt-Il Figure 9: Schematic for Processor 109 ; E~@@@@@@f@@@@@@@ ————_— If (our —‘ 1 INT 1 ACCOUTI S.Su Se - - _.-....__- , ---..M -..-.-.-....--.-..--.D.H1,-.-- m u ._., .. -- 1.1 u - - a 1 r1 , u - no. 1.- u m J - -- - .1,- i r w _m.---.-» m u -- _. .- - u - m.- - u c z -11 . u u c -- .M n u - 1E.-- 11. -1..-1 T U - w; -1 111 r_ u 1. a. - .. 1 w JHM i “H.1HHHHHHHHW1111 r4 r4 Se 4. OATAI ULl CLK T(INT) Tine (seconds) data for Processor ICH1 Simulat Figure 10 110 Appendix B IO PIN ASSIGNMENT RESULTS FOR DESIGN LPROC2 From PPR Version 5.2.1 1997/06/13 02:38:51 Xilinx, Inc. (c) Copyright 1997. All Rights Reserved. Chip Pinout Description This chapter describes where your design's pins were placed in terms of the package pins. Generally there are four sections for this chapter. The first section is a list showing signal name and the package pin location, sorted by the signal name. The second section is a list showing the package pin names and signal names sorted by the package pin names. Next section appears only if your design uses special pads. This will a table showing the special pad names and the signal names, sorted by special pad name. The last section is a series of CST file statements, which if copied into a text file, can be used as constraints for a subsequent ppr run for locking 103 at their current locations. Sorted by Signal Names: Pin Name Package Pin Location CL2_pad : P3 CL_pad : P39 CLEN__pad : P10 CLR_pad : P9 CO_pad : P45 INTO_pad : P84 INT1_pad : P68 INT2_pad : P66 INT3_pad : P4 lNT4_pad : P27 111 INT5_pad : P40 INT 6_pad : P44 INT7_pad : P5 OUTPUTO_pad : P61 OUTPUT1_pad : P25 OUTPUT2_pad : P41 OUTPUT3_pad : P20 OUTPUT4_pad : P19 OUTPUT5_pad : P24 OUTPUT6_pad : P23 OUTPUT7_pad : P38 S_pad : P5 9 ULl_pad : P83 V_pad : P60 Z_pad : P69 Sorted by Package Pin Locations: Package Pin Location Pin Name P3 : CL2_pad P4 : INT 3_pad P5 : INT7_pad P9 : CLR_pad P10 : CLEN_pad P19 : OUTPUT4_pad P20 : OUTPUT3_pad P23 : OUTPUT6_pad P24 : OUTPUT5_pad P25 : OUTPUT1_pad P27 : INT4_pad P38 : OUTPUT7_pad P39 : CL_pad P40 : INT5_pad P41 : OUTPUT2_pad P44 : INT6_pad P45 : CO_pad P59 : S_pad P60 : V_pad P61 : OUTPUTO_pad P66 : IN T2_pad P68 : INT1_pad P69 : Z_pad P83 : ULl_pad P84 : INTO_pad 112 CST File Format (location constraints file): place instance CL2_pad : P3 ; place instance CL_pad : P39 ; place instance CLEN_pad : P10 ; place instance CLR_pad : P9 ; place instance CO_pad : P45 ; place instance INT O_pad : P84 ; place instance INT1_pad : P68 ; place instance INT2_pad : P66 ; place instance INT 3_pad : P4 ; place instance INT 4__pad : P27 ; place instance INT5_pad : P40 ; place instance IN T6_pad : P44 ; place instance INT7_pad : P5 ; place instance OUTPUTO_pad : P61 ; place instance OUTPUT1_pad : P25 ; place instance OUTPUT2_pad : P41 ; place instance OUTPUT3_pad : P20 ; place instance OUTPUT4_pad : P19 ; place instance OUTPUT5_pad : P24 ; place instance OUTPUT6_pad : P23 ; place instance OUTPUT7_pad : P38 ; place instance S_pad : P59 ; place instance ULl_pad : P83 ; place instance V_pad : P60 ; place instance Z_pad : P69 ; ========= End of Report 113 Appendix B Timing Analysis Data Warning: Combinational logic loop(s) have been detected. These may cause subtle design problems, and may yield some inaccurate path delays. For a detailed enumeration of these loops, use the "DRC -Inform" command from within XDE/EditLCA. Warning: There are unrouted pins. Timing results may be incomplete. Xdelay Report File: Design: lproc2.lca (4010PC84-5) Program: XDELAY 5.2.1 Speedsfile: File 4010.spd, Version 4000.1, Revision 4010. 15 Xdelay timing analysis options: From all. To all. Combinational logic loops broken at net(s): "$1177/CLEAR" "$11177/$1159/D5" "$11177/$1159/D6" "$11177/$1I59/D7" "$11177/$1159/D8" Worst case Pad to Pad path delay : 34.2ns (1 block level) Pad "CLR" (P9) to Pad "IOBl" (P45.0) Clock net "$1N299_1" path delays: Pad to Setup : 39.6ns (1 block level) (Includes an external input margin of 0.0ns.) Pad "CLR" (P9) to FF Setup (D) at "INS.F4" Target FFY drives output net "IN 5" 114 Clock to Setup (same edge) : 19.1ns (0 block levels) (Includes 2.7ns clock skew compensation.) Clock to Q, net "INSTRUCTIONS" to FF Setup (D) at "INS.F2" Target FFY drives output net "INS" Clock to Setup (to other clock net) : 46.2ns (4 block levels) Clock to Q, net "INSTRUCTION 1 " to FF Setup (D) at "$1136/D01 12.F2" Target FFY drives output net "$1136/D0112" Clock to Setup (to other setup type) : 64.6ns (5 block levels) Clock to Q, net "INSTRUCTIONS" to FF Setup (via H') at "DATAIN4.G3" Target FFX drives output net "DATAIN4_2" Minimum Clock Period : 64.6ns Estimated Maximum Clock Speed : 15.5Mhz Clock net "$1N299_2" path delays: Pad to Setup : 87.4ns (6 block levels) (Includes an external input margin of 0.0ns.) Pad "CLR" (P9) to FF Setup (via H') at "DATAIN4.G3" Target FFX drives output net "DATAIN4_2" Clock to Setup (same edge) : 65 .9ns (5 block levels) (Includes 2.6ns clock skew compensation.) Clock to Q, net "INSTRUCTION6" to FF Setup (via H') at "DATAIN5.Gl " Target FFX drives output net "DATAIN 5" Clock to Setup (to other clock net) : 43.6ns (3 block levels) Clock to Q, net "INSTRUCTION 3" to FF Setup (D) at "$1136/D056.F4" Target FFX drives output net "$1136/D056" Clock to Setup (to other setup type) : 36.7ns (5 block levels) Clock to Q, net "1N2" to FF Setup (via H') at "ALUOUT6.G2" Target FFX drives output net "ALUOUT6" Minimum Clock Period : 87.4ns Estimated Maximum Clock Speed : 11.4Mhz Clock net "CLACC" path delays: Pad to Setup : 57.4ns (3 block levels) 115 (Includes an external input margin of 0.0ns.) Pad "CLR" (P9) to FF Setup (EC) at "$1I77/SUM6.C2" Target FFX drives output net "$1N190" Target FFY drives output net "$lIl77/$lIS9/Q8" Clock to Pad : 27.4ns (1 block level) (Includes an external output margin of 0.0ns.) Clock to Q, net "ACCOUT5_2" to Pad "OUTPUTS" (P240) Clock to Setup (same edge) : 16.6ns (0 block levels) (Includes 1.0ns clock skew compensation.) Clock to Q, net "ALUOUT7" to FF Setup (D) at "$1Il32/D7.F2" Target FFX drives output net "$11132/D7" Clock to Setup (to other clock net) : 38.1ns (2 block levels) Clock to Q, net "ACCOUT6" to FF Setup (D) at "$1136/$1N55.G1" Target FFX drives output net "$1136/D0126" Minimum Clock Period : 57.4ns Estimated Maximum Clock Speed : 17.4Mhz Clock net ”CLK" path delays: Pad to Setup : 78.0ns (6 block levels) (Includes an external input margin of 0.0ns.) Pad "CLR" (P9) to FF Setup (D) at "$1136/D0112.F2" Target FFY drives output net "$1136/D0112" Clock to Setup (same edge) : 17.8ns (0 block levels) (Includes 6.3ns clock skew compensation.) Clock to Q, net "$1136/C1_1" to FF Setup (D) at "$11132/RLCE.F2" Target FFX drives output net "$1136/C2" Clock to Setup (falling to rising edge) : 48.2ns (4 block levels) Clock to Q, net "$1136/C1_l" to FF Setup (D) at "$1136/D0112.F2" Target FFY drives output net "$1136/D0112" Clock to Setup (to other setup type) : 54.5ns (4 block levels) Clock to Q, net "$1136/C0" to FF Setup (via H') at "DATAIN4.G3" Target FFX drives output net "DATAIN4_2" Minimum Clock Period : 78.0ns 116 Minimum Clock Low pulse width : 48.2ns Estimated Maximum Clock Speed : 12.8Mhz 117 Appendix B Opcode table /_, Addresses lllllllll \.,Opcodes General purpose processing unit > flfl—‘OOOO -~—oo---—oc> a I: A4 Instr 0 LD 1 ST 0 ADD 1 SUB 0 AND 1 OR 0 XOR l 118 Appendix B VHDL Code for FIR filter Entity fir8 is port(clock,enable: in bit; X: in integer; Y: out integer); end fir8; architecture behavior of fir8 is Begin update: process variable result: integer; subtype coefficient is integer range 0 to 1023; type integer_array is range 0 to 7; type fil_coef is array (0 to 3) of coefficient; constant h:fil__coef:=( 1 ,2,4,8); type 11 is array (0 to 7)of coefficient; variable w: u; Begin wait on clock until clock=' 1'; If enable=' 1' then --update elements Fori in 7 downto 1 loop w(i):=w(i-l); endloop; w(O):= x; --filter operations result:=0; For i in O to 3 loop result:=result+h(i)*(w(i)+ W(7-i)); 119 endloop; --- output result Y<=result; Else Y<=O; end if; end process update; end behavior; I BHU F 8 "My . , . I /~"‘ *» . . . IPADBI , " x74 17..-, .-.., _ 1(7.01\ "I 1: Es . .“l ”(7:01 :‘1 ‘l I: :1 - l I ”I 1 "I I ‘ ‘ ' I: “7'01 AZ[7:U] rural ' M . 07 i:::::::: INEQIUFBUUIMIétggla \W", : _J_L.Iutrta.a) I IPADB IBUFB rural/an"; A1[7'01 B[7x01 IPADB IB_\UF‘B;.01 ”7:01 Aot7val / D‘r - - z: w - l’Iaur ; . u i ‘l | flu l 7l=====::: ' 1_4-1 iEfl-IKULHE-fil II D fi‘ij ”D ‘- 1—II n 1 3.1 \Ujfin. ........ ........ TE7~01 Figure 11: Schematic for FIR filter 121 Appendix B IO PIN ASSIGNMENT RESULTS FOR DESIGN FIRl From PPR Version 5.2.1 1997/06/ 12 00:48:27 Xilinx, Inc. (c) Copyright 1997. All Rights Reserved. Chip Pinout Description This chapter describes where your design's pins were placed in terms of the package pins. Generally there are four sections for this chapter. The first section is a list showing signal name and the package pin location, sorted by the signal name. The second section is a list showing the package pin names and signal names sorted by the package pin names. Next section appears only if your design uses special pads. This will a table showing the special pad names and the signal names, sorted by special pad name. The last section is a series of CST file statements, which if copied into a text file, can be used as constraints for a subsequent ppr run for locking 103 at their current locations. Sorted by Signal Names: Pin Name Package Pin Location $11386/$11275/CIN_pad : P28 $1N484_pad : P10 $1N619_pad : P61 A00_pad : P50 A01_pad : P79 A02_pad : P77 A03_pad : P47 A04_pad : P72 A05_pad : P78 A06_pad : P48 122 A07_pad : P81 A10_pad : P71 A1 1_pad : P70 A12_pad : P49 A13_pad : P80 Al4_pad : P46 A15_pad : P67 A16_pad : P69 A17_pad : P68 A20_pad : P39 A21_pad : P7 A22_pad : P37 A23_pad : P38 A24_pad : P44 A25_pad : P40 A26_pad : P45 A27_pad : P23 A30_pad : P9 A31_pad : P15 A32_pad : P16 A33_pad : P17 A34_pad : P18 A35_pad : P8 A36_pad : P14 A37_pad : P19 IN 0__pad : P84 IN 1_pad : P82 IN2_pad : P83 IN 3_pad : P41 IN4_pad : P4 INS_pad : P3 1N6_pad : P5 IN 7_pad : P6 OUTO_pad : P20 OUT1_pad : P24 OUT Z_pad : P25 OUT3_pad : P26 OUT4_pad : P29 OUT5_pad : P27 OUT6_pad : P35 OUT7_pad : P36 Sorted by Package Pin Locations: Package Pin Location Pin Name P18 P19 P20 P23 P24 P25 P26 P27 P28 P29 P35 P36 P37 P38 P39 P40 P41 P44 P45 P46 P47 P48 P49 P50 P61 P67 P68 P69 P70 P7 1 P72 P77 : A30_pad : $1N484_pad : A36_pad : A3l_pad : A32_pad : A33_pad : A34_pad : A37_pad : OUTO_pad : A27_pad : OUT1_pad : OUT2_pad : OUT3_pad : OUT5_pad : $11386/$11275/CII\I_pad : OUT4_pad : OUT6_pad : OUT7_pad : A22_pad : A23_pad : A20_pad : A25_pad : IN3_pad : A24_pad : A26_pad : Al4_pad : A03_pad : A06_pad : A12_pad : A00_pad : $1N619_pad : A15_pad : A17_pad : Al6_pad : A1 1_pad : A10__pad : A04_pad : A02_pad 123 124 P78 : A05_pad P79 : A01_pad P80 : A13_pad P81 : A07_pad P82 : IN1_pad P83 : INZ_pad P84 : INO_pad CST File Format (location constraints file): place instance $11386/$11275/CIN_pad : P28 ; place instance $1N484_pad : P10 ; place instance $1N619_pad : P61 ; place instance A00_pad : P50 ; place instance A01_pad : P79 ; place instance A02_pad : P77 ; place instance A03_pad : P47 ; place instance A04_pad : P72 ; place instance A05_pad : P78 ; place instance A06_pad : P48 ; place instance A07_pad : P81 ; place instance A10_pad : P71 ; place instance A11_pad : P70 ; place instance A12_pad : P49 ; place instance A13_pad : P80 ; place instance Al4_pad : P46 ; place instance A15_pad : P67 ; place instance Al6_pad : P69 ; place instance A17_pad : P68 ; place instance A20_pad : P39 ; place instance A21_pad : P7 ; place instance A22_pad : P37 ; place instance A23_pad : P38 ; place instance A24_pad : P44 ; place instance A25_pad : P40 ; place instance A26_pad : P45 ; place instance A27_pad : P23 ; place instance A30_pad : P9 ; place instance A31_pad : P15 ; place instance A32_pad : P16 ; place instance A33_pad : P17 ; place instance A34_pad : P18 ; place instance A35_pad : P8 ; place instance A36_pad : P14 ; 125 place instance A37_pad : P19 ; place instance INO_pad : P84 ; place instance IN1_pad : P82 ; place instance IN2_pad : P83 ; place instance IN3_pad : P41 ; place instance IN4_pad : P4 ; place instance INS_pad : P3 ; place instance IN 6_pad : P5 ; place instance IN7_pad : P6 ; place instance OUTO_pad : P20 ; place instance OUT1_pad : P24 ; place instance OUT2_pad : P25 ; place instance OUT3_pad : P26 ; place instance OUT4_pad : P29 ; place instance OUT5_pad : P27 ; place instance OUT6_pad : P35 ; place instance OUT7_pad : P36 ; 126 Appendix B Timing Analysis Data Warning: There are unrouted pins. Timing results may be incomplete. Xdelay Report File: Design: fir1.lca (4010PC84-5) Program: XDELAY 5.2.1 Speedsfile: File 4010.spd, Version 4000.1, Revision 4010.15 Xdelay timing analysis options: From all. To all. Combinational logic loops broken at net(s): "$11386/$11275/$1N78" "$11386/$11275/$1N84" "$1I386/$11275/$1N85" "$1N334" "$1N344" "$1N731" "$1N789" ”A0" "A1" "A2" "A3" "A4" "A5" "A6" "A7" "B0" "B1" "132.. "B3" "B4" "B5" "B6" "B7" "TAPl/$1I78/$ 1163/A" "TAP1/$lI78/$1I1 l9/A" "TAP1/$II78/$11126/A" "TAP1/$lI78/$11146/A" "TAP1/$1178/$1I153/A" "TAP1/$lI78/$1I339/A" "TAP1/$1I78/$11367/A” "TAP1/$1178/$1I414/A" "TAP1/$1I78/$ll468/A" "TAP1/$II78/$11523/CI" "TAPl/$lI78/$11558/A" "TAPl/$1I78/$1N64" "TAP1/$1I78/$1N66" "TAP1/$II78/$1N68" "TAPl/$1178/$1N70" "TAPl/$II78/$1N72" "TAPl/$1I78/$1N105" "TAPl/$II78/$1N109" "TAPl/$II78/$1N120" "TAPl/$II78/$1N122" "TAPl/$1178/$1N151" "TAP1/$II78/$1N154" "TAP1/$II78/$1N161" "TAP1/$lI78/$1N186" "TAP1/$II78/$1N188" "TAP1/$II78/$1N310" "TAPl/$1178/$1N318" "TAP1/$ll78/$1N322" "TAP1/$II78/$1N323" "TAP1/$II78/$1N326" "TAP1/$II78/$1N359" "TAP1/$II78/$1N374" "TAP1/$II78/$1N378" "TAP1/$1178/$1N397" "TAPl/$1I78/$1N399" "TAP1/$ lI78/$1N403" "TAP1/$ 1178/$1N4OS" "TAP1/$lI78/$1N417" "TAPl/$1I78/$1N4l9" "TAP1/$ 1178/$1N450" "TAP1/$1I78/$1N453" "TAP1/$1I78/$1N455" "TAP1/$II78/$1N457" 127 "TAPl/$1178/$1N460" "TAPl/$lI78/$1N476" "TAP1/$II78/$1N533" "TAP1/$1I78/$1N535" "TAP1/$1178/$1N543" "TAP1/$1I78/$1N54S" "TAP1/$II78/$1N553" "TAP1/$1I78/$1N562" "TAP1/$1I78/$1N567" "TAP1/$1178/$1N571" "TAP1/$II78/$1N584" "TAPl/$1I78/$ 1N586" "TAPl/$1I78/$1N600" "TAPl/$1178/$1N604" "TAPl/$lI78/$1N613" "TAPl/$II78/$1N615" "TAPl/$1I78/$1N616" "TAPl/$II78/$1N618" "TAPl/$1I78/$ 1N624" "TAPl/$1I78/$1N626" "TAP1/$lI78/$1N628" "TAP1/$1I78/$1N82 1 ” "TAP1/$1I78/$1N827" "TAPl/$ lI78/—G" "TAP2/$II78/$ll63/A" "TAP2/$II78/$11119/A" "TAP2/$II78/$11126/A" "TAP2/$lI78/$11146/A" "TAP2/$lI78/$11153/A" "TAP2/$lI78/$11339/A" "TAP2/$II78/$1I367/A" "TAP2/$lI78/$1I414/A" "TAP2/$II78/$11468/A" "TAP2/$lI78/$11523/CI" "TAP2/$1178/$11558/A" "TAP2/$1178/$1N64" "TAP2/$ lI78/$1N66" "TAP2/$II78/$1N68" "TAP2/$1178/$1N70" "TAP2/$II78/$1N72" "TAP2/$1178/$1N105" "TAP2/$1178/$ 1N109" "TAP2/$1178/$1N120" "TAP2/$lI78/$1N122" "TAP2/$lI78/$1N151" 128 "TAP2/$1178/$1N154" "TAP2/$lI78/$1N16l " "TAP2/$lI78/$1N186" "TAP2/$1I78/$1N188" "TAP2/$1I78/$1N3 10" "TAP2/$1178/$1N318" "TAP2/$lI78/$1N322" "TAP2/$1178/$1N323" "TAP2/$II78/$1N326" "TAP2/$II78/$1N359" "TAP2/$II78/$1N374" "TAP2/$lI78/$1N378" "TAP2/$lI78/$1N397” "TAP2/$1178/$1N399" "TAP2/$1I78/$1N403" "TAP2/$1I78/$1N405" "TAP2/$ lI78/$1N417" "TAP2/$1178/$1N4l9" "TAP2/$1178/$1N450" "TAP2/$1I78/$1N453" "TAP2/$1178/$1N455" "TAP2/$lI78/$1N457" "TAP2/$II78/$1N460" "TAP2/$1178/$1N476" "TAP2/$1178/$ 1N533" "TAP2/$ 1178/$ 1N535" "TAP2/$1178/$1N543" "TAP2/$1I78/$1N545" "TAP2/$ lI78/$1N553" "TAP2/$II78/$1N562" "TAP2/$1I78/$1N567" "TAP2/$1I78/$1N571" "TAP2/$1I78/$1N584" "TAP2/$1178/$1N586" "TAP2/$II78/$1N600" "TAP2/$lI78/$1N604" "TAP2/$1178/$1N613" "TAP2/$1178/$1N615" "TAP2/$lI78/$1N616" "TAP2/$1178/$1N618" "TAP2/$II78/$1N624" "TAP2/$lI78/$1N626" "TAP2/$II78/$1N628" "TAP2/$lI78/$1N821" "TAP2/$ lI78/$1N827" 129 "TAP2/$1I78/—G" "TAP3/$1I78/$lIl26/A" "TAP3/$ lI78/$lI339/A" "TAP3/$II78/$lI4l4/A" "TAP3/$lI78/$11468/A" "TAP3/$1I78/$11523/CI" "TAP3/$1178/$1I558/A" "TAP3/$II78/$1N64" "TAP3/$1178/$1N66" "TAP3/$1178/$1N68" "TAP3/$1I78/$1N70" "TAP3/$1178/$1N72" "TAP3/$II78/$1N105" "TAP3/$1I78/$1N109" "TAP3/$1I78/$1N120" "TAP3/$lI78/$1N122" "TAP3/$lI78/$1N151" "TAP3/$1I78/$1N154" "TAP3/$lI78/$1N161" ”TAP3/$lI78/$1N186" "TAP3/$1178/$1N188" "TAP3/$1178/$1N310" "TAP3/$1178/$1N318" "TAP3/$1I78/$1N322" "TAP3/$lI78/$1N323" "TAP3/$II78/$1N326" "TAP3/$1I78/$1N359" "TAP3/$lI78/$1N374" "TAP3/$1178/$1N378" "TAP3/$II78/$1N397" "TAP3/$ lI78/$1N399" "TAP3/$1I78/$ lN403" "TAP3/$1178/$1N405" "TAP3/$lI78/$1N417" "TAP3/$ll78/$1N4l9" "TAP3/$1178/$1N450" "TAP3/$1I78/$1N453" "TAP3/$lI78/$1N455" "TAP3/$lI78/$1N457" "TAP3/$lI78/$1N460" "TAP3/$1178/$1N476" "TAP3/$1I78/$1N533" "TAP3/$lI78/$1N535" "TAP3/$lI78/$1N543" "TAP3/$II78/$1N545" 130 "TAP3/$II78/$1N553" "TAP3/$1178/$1N562" "TAP3/$lI78/$1N567" "TAP3/$1178/$1N57l" "TAP3/$1178/$1N584" "TAP3/$1I78/$1N586" "TAP3/$lI78/$1N600" "TAP3/$1178/$1N604" "TAP3/$II78/$1N613" "TAP3/$II78/$1N615" "TAP3/$1178/$1N616" "TAP3/$II78/$1N618" "TAP3/$II78/$1N624" "TAP3/$1I78/$1N626" "TAP3/$1178/$1N628" "TAP3/$1178/$1N821 " "TAP3/$ lI78/$1N827" "TAP3/$II78/~G" "TAP4/$lI78/$ 11468/A" "TAP4/$1178/$11523/CI" "TAP4/$1178/$11558/A" "TAP4/$1I78/$1N64" "TAP4/$1178/$1N66" "TAP4/$1I78/$1N68" "TAP4/$1178/$1N70" "TAP4/$II78/$1N72" "TAP4/$lI78/$1N105" "TAP4/$1I78/$1N109" "TAP4/$1I78/$1N120" "TAP4/$II78/$1N122" "TAP4/$1178/$1N151" "TAP4/$1I78/$1N154" "TAP4/$1178/$1N161" "TAP4/$1178/$1N186" "TAP4/$lI78/$1N188" "TAP4/$1178/$1N310" "TAP4/$1178/$1N318" "TAP4/$1178/$1N322" "TAP4/$ lI78/$1N323" "TAP4/$1I78/$1N326" "TAP4/$1178/$1N359" "TAP4/$lI78/$1N374" "TAP4/$lI78/$1N378" "TAP4/$1I78/$1N397" "TAP4/$lI78/$1N399" 131 132 "TAP4/$lI78/$1N403" "TAP4/$lI78/$1N405" "TAP4/$1178/$1N417" "TAP4/$1178/$1N419" "TAP4/$1I78/$1N450" "TAP4/$1178/$1N453" "TAP4/$1I78/$1N455" "TAP4/$1I78/$1N457" "TAP4/$1178/$1N460" "TAP4/$ lI78/$1N476" "TAP4/$II78/$1N533" "TAP4/$1178/$1N535" "TAP4/$1178/$1N543" "TAP4/$lI78/$1N545" "TAP4/$1178/$1N553" "TAP4/$1178/$1N562" "TAP4/$1I78/$1N567" "TAP4/$1178/$1N571" "TAP4/$1178/$1N584" "TAP4/$1I78/$1N586" "TAP4/$1I78/$1N600" "TAP4/$1I78/$1N604" "TAP4/$1178/$1N613" "TAP4/$1178/$1N615" "TAP4/$1I78/$1N616" "TAP4/$1I78/$1N618" "TAP4/$1I78/$1N624" "TAP4/$1178/$1N626" ”TAP4/$II78/$1N628" "TAP4/$1I78/$1N821" "TAP4/$1I78/$1N827" "TAP4/$lI78/—G" Clock net "$1N630_1" path delays: Pad to Setup : 22.9ns (1 block level) (Includes an external input margin of 0.0ns.) Pad "$1N619" (P61) to FF Setup (EC) at "TAP4/$lI78/$1152/S.C4" Target FFY drives output net "TAP4/A7" Clock to Setup (same edge) : 12.6ns (0 block levels) (Includes 1.4ns clock skew compensation.) Clock to Q, net "W1" to FF Setup (D) at "TAP3/$ll78/$1N824.C2" Target FFX drives output net "WB3" Clock to Setup (to other clock net) : 77.5ns (11 block levels) 133 Clock to Q, net "TAPl/A6" to FF Setup (D) at "Y4.F3" Target FFX drives output net "Y4" Minimum Clock Period : 77.5ns Estimated Maximum Clock Speed : 12.9Mhz Clock net "$1N630_2" path delays: Pad to Setup : 78.2ns (11 block levels) (Includes an external input margin of 0.0ns.) Pad "1N6" (P5) to FF Setup (D) at "Y4.F3" Target FFX drives output net "Y4" Clock to Pad 15.8ns (0 block levels) (Includes an external output margin of 0.0ns.) Clock to Q, net "YO" to Pad "OUTO" (P200) Clock to Setup (rising to falling edge) : 72.9ns (11 block levels) Clock to Q, net "WC1_1" to FF Setup (D) at "Y4.F3" Target FFX drives output net "Y4" Minimum Clock Period : 78.2ns Minimum Clock High pulse width : 72.9ns Estimated Maximum Clock Speed : 12.8Mhz LIST OF REFERENCES [1] [2] [31 [4] [5] [6] [7] [8] [91 [10] [11] [12] [131 [14] [15] [161 134 LIST OF REFERENCES Weiss, Ray, “Embeddeds advance in auto, communications, office, industry, and consumer markets”, Computer Design, September 1996, pp. 58-64. Weiss, Ray, “Embedded Systems, They’re headed everywhere”, Computer Design, September 1996,p.97. Weiss, Ray, “Going for the gold-ASICS go mainstream”, Computer Design, September 1996, pp.79-80. Website: www.viewlogic.com Website: www.xilinx.com Mayer, John H. “Programmable Logic Knows no bounds”, Computer Design, February 1997, PP. 3-4. Trimberger, Stephen M., Field Programmable Gate Arrays Technology, Kluer Academic Publishers, Netherlands, 1994, pp. 2—13. Oldfield, John V., F ield-programmable gate arrays: reconfigurable logic for rapid prototyping and implementation of digital systems, Wiley, 01995, pp. XD(- XXV. Website: www.xilinx.com/xup/downld.htm Xilinx, The Programmable Logic Data Book, 1994, pp.2-9-2- 16. Mayer, John H. “CPLDS push performance density limits”, Computer Design, February 1997,1313. 22-23. Xilinx, The Programmable Logic Data Book, 1994, pp.3-4 - 3-18. Website: www.reconfig.com/gloss.htm Beachler, Robert K., “True PLD vs.gate-array costs”, Computer Design, February 1997 , p. 30. Viewlogic, “Getting Started with WorkView Office”, 1995, p. Duckworth, R. James, Workview Ofi‘ice Student Edition, Schematic Entry and Digital Analysis, Prentice hall, New Jersey, 1997, pp. 1-13 [17] [18] [19] [20] [211 [22] [23] 135 Website: www.mentorg.com/corp-info/corp.bg.htm Website: www.edat.com/96pubs/7-96_DAC.htm Website: www.xilinx.com/products/software/software.htm. Website: www.xilinx.com/products/software/xact_pkg.htm Beikner, John, “Migrating to HDLs is a multi step process,” Computer Design, February 1997, pp. 32-34 Newfeldt, Victoria, Webster’s New World Dictionary, Simon and Schuster, Inc., Ohio, p. 656 Chan, Pak K., Digital Design Using Field Programmable Gate Arrays Prentice Hall, 1994, pp. 170-172 MICHIGAN STRTE UNIV. LIBRARIES lllllHlHlWlllHllHHHINIllHHHllHWIIHHIWIHHll 31293015630944