A

REPORT ON

45 DAYS SUMMER TRAINING PROGRAMME

TAKEN AT BIRLA INSTITUTE OF SCIENTIFIC RESEARCH JAIPUR 2012

BANSAL SCHOOL OF ENGINEERING AND TECHNOLOGY JAIPUR

SUBMITTED TO DEPARTMENT OF ELECTRONICS BIRLA INSTITUTE OF SCIENTIFIC RESEARCH JAIPUR

SUBMITTED BY

Sagar Bhargava
B.S.E.T JAIPUR

CERTIFICATE

This is to certify that Mr. Sagar Bhargava (Electronics & Communication) has successfully completed his Summer Training during May-July 2012. The project was undertaken by him at Birla Institute of Scientific Research titled 8 bit ALU & Processor using VHDL. The project on evaluation fulfills all the stated criteria and the student's findings are his original work. I hereby certify her work excellent to the best of my knowledge.

Dated: 10.07.2012

Mr. P. S. Rathore Training In charge... BISR- Jaipur.........

PREFACE

The concept of Industrial Training intends to increase the knowledge and skills of the student, to make him capable of doing a particular job efficiently. The purpose of training is to bring a gap between job requirement and job competence. Training is aimed at improving the behavior and performance of a person. During Training at Birla Institute of Scientific Research, Jaipur I got the knowledge of the essential elements required for the completion of electronic based projects. Hence I have made this report on the basis of knowledge I got during my Training period.

ACKNOWLEDGEMENT

I am highly indebted to the Director of Birla Institute of Scientific Research, Jaipur for allowing me to do my Summer Training as well as for his guidance and constant supervision. I am thankful to Prof. J. B. Gupta, Prof. P.S. Rathore (training in charge), Mrs. Jyoti Sharma, Mr. Jitendra Gupta & Mr. Uma Shankar for their kind and active support and valuable guidance during the training. I have taken efforts in the project. However, it would not have been possible without the kind support and many individuals and organizations. I would like to extend my sincere thanks to each and every member related to Birla Institute of Scientific Research.

Place: Jaipur Date: 10.07.2012

(SAGAR BHARGAVA) B.S.E.T. Jaipur

Contents

INTRODUCTION TO VLSI DESIGN

1.1 1.2 1.3 1.4 INTRODUCTION VLSI DESIGN 1.3.1 1.4.1 1.4.2 1.4.3 1.4.4 1.4.5 1.4.6 1.4.7 1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CONVENTIONAL APPROACH TO DIGITAL DESIGN

4
4 4 6 7 7 9 9 9 11 11 12 12 12

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Abstraction Model . . . . . . . . . . . . . . . . . . . . . . Design Description . . . . . . . . . . . . . . . . . . . . . . Optimization Simulation Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ASIC DESIGN FLOW . . . . . . . . . . . . . . . . . . . . . . . .

Physical Design . . . . . . . . . . . . . . . . . . . . . . . . Post Layout Simulation Critical Subsystems . . . . . . . . . . . . . . . . . . . . .

ROLE OF HDL . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Architecture of FPGAs and CPLDs

2.1 2.2 2.3 2.4 2.5 Introduction to High-Capacity FPDs . . . . . . . . . . . . . . . . 2.1.1 Denitions of Relevant Terminology . . . . . . . . . . . . Evolution of Programmable Logic Devices . . . . . . . . . . . . . User-Programmable Switch Technologies . . . . . . . . . . . . . . Computer Aided Design (CAD) Flow for FPDs . . . . . . . . . . Applications of CPLDs . . . . . . . . . . . . . . . . . . . . . . . .

13
13 14 15 17 19 21

VHDL
3.1 3.2 3.3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A standard language . . . . . . . . . . . . . . . . . . . . . . . . . Entities and Architectures . . . . . . . . . . . . . . . . . . . . . . 3.3.1 3.3.2 3.4 3.4.1 3.4.2 3.4.3 3.4.4 Entity declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture declaration and body Entities

22
22 23 23 23 24 24 24 25 25 27

Design Units

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Architectures . . . . . . . . . . . . . . . . . . . . . . . . . Packages and package bodies Congurations . . . . . . . . . . . . . . . . . . . . . . . .

Projects
4.1 ALU 8 Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 4.1.2 4.2 4.2.1 4.2.2 *.vhd Code . . . . . . . . . . . . . . . . . . . . . . . . . . Test Bench Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *.vhd Code

28
28 28 29 30 30 36

Processor

Test Bench Code . . . . . . . . . . . . . . . . . . . . . . .

Xilinx ISE and Spartan-3

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 5.1.2 Part 1: Starting a new Project . . . . . . . . . . . . . . . Part 2: Generating a PROM File . . . . . . . . . . . . . .

39
39 39 48

List of Figures
1.1 1.2 1.3 1.4 1.5 2.1 2.2 2.3 2.4 4.1 4.2 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 A simple digital circuit. . . . . . . . . . . . . . . . . . . . . . . . 5 6 8 8 10 16 18 19 20 30 38 40 41 42 43 44 45 46 47 49 49 50 51 52 53 54 55 56 57 58 58 59

Sequence of steps in conventional electronic circuit design. . . . . Design domain and levels of abstraction. . . . . . . . . . . . . . . Major activities in ASIC design. . . . . . . . . . . . . . . . . . . ASIC design and development ow. . . . . . . . . . . . . . . . . . Structure of a PAL. . . . . . . . . . . . . . . . . . . . . . . . . .

Structure of an FPGA. . . . . . . . . . . . . . . . . . . . . . . . . FPD Categories by Logic Capacity. . . . . . . . . . . . . . . . . . CAD Design Flow for SPLDs. . . . . . . . . . . . . . . . . . . . . ALU Simulation in Xilinx ISE . . . . . . . . . . . . . . . . . . . . Processor Simulation in Xilinx ISE . . . . . . . . . . . . . . . . . Xilinx Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

New Project Window . . . . . . . . . . . . . . . . . . . . . . . . . Project Source Properties Window Module Nomenclature Window Summary . . . . . . . . . . . . . . . . . . .

Source Dening Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project Navigator Window

Code Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FPGA Pins Denation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.10 Prompt

5.11 Xilinx Pace

5.12 PROM Conguration Files

5.13 Prepare PROM Files . . . . . . . . . . . . . . . . . . . . . . . . . 5.14 Congure Xilinx PROM Device . . . . . . . . . . . . . . . . . . . 5.15 Summary Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.16 Add Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.17 Adding Source Bit Files 5.18 Adding Device 5.19 PROM File Generation 5.20 Final Output Window

5.21 Save Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 1
INTRODUCTION TO VLSI DESIGN
1.1 INTRODUCTION

The word digital has made a dramatic impact on our society. More signicant is a continuous trend towards digital solutions in all areas  from electronic instrumentation, control, data manipulation, signals processing, telecommunications etc., to consumer electronics. Development of such solutions has been possible due to good digital system design and modeling techniques.

1.2

CONVENTIONAL APPROACH TO DIGITAL DESIGN

Digital ICs of SSI and MSI types have become universally standardized and have beenaccepted for use. Whenever a designer has to realize a digital function, he uses a standard set of ICs along with a minimal set of additional discrete circuitry. Consider a simple example of realizing a function as

Qn+1 = Qn + (AB )
Here Qn, A, and B are Boolean variables, with Q n being the value of Q at the nth time step. Here A B signies the logical AND of A and B; the `+' symbol signies the logical OR of the logic variables on either side. A circuit to realize the function is shown in Figure 1.1. The circuit can be realized in terms of two ICs  an A-O-I gate and a ip-op. It can be directly wired up, tested, and used. With comparatively larger circuits, the task mostly reduces to one of identifying the set of ICs necessary for the job and interconnecting; rarely does one have to resort to a microlevel design [Wakerly]. The accepted approach to digital design here is a mix of the top-down and bottom-up approaches as follows

Figure 1.1: A simple digital circuit.

Decide the requirements at the system level and translate them to circuit requirements. Identify the major functional blocks required like timer, DMA unit, registerle etc., say as in the design of a processor. Whenever a function can be realized using a standard IC, use the same for example programmable counter, mux, demux, etc. Whenever the above is not possible, form the circuit to carry out the block functions using standard SSI  for example gates, ip-ops, etc. Use additional components like transistor, diode, resistor, capacitor, etc., wherever essential.

Once the above steps are gone through, a paper design is ready. Starting with the paper design, one has to do a circuit layout. The physical location of all the components is tentatively decided; they are interconnected and the `circuitonpaper' is made ready. Once a paper design is done, a layout is carried out and a net-list prepared. Based on this, the PCB is fabricated, and populated and all the populated cards tested and debugged. The procedure is shown as a process owchart in Figure 1.2 At the debugging stage one may encounter three types of problems:

Functional mismatch: The realized and expected functions are dierent. One may have to go through the relevant functional block carefully and locate any error logically. Finally the necessary correction has to be carried out in hardware.

Timing mismatch:

The problem can manifest in dierent forms.

One

possibility is due to the signal going through dierent propagation delays in two paths and arriving at a point with a timing mismatch. This can cause faulty operation. Another possibility is a race condition in a circuit involving asynchronous feedback. This kind of problem may call for elaborate debugging. The preferred practice is to do debugging at smaller

Figure 1.2: Sequence of steps in conventional electronic circuit design.

module stages and ensuring that feedback through larger loops is avoided: It becomes essential to check for the existence of long asynchronous loops.

Overload:

Some signals may be overloaded to such an extent that the

signal transition may be unduly delayed or even suppressed. The problem manifests as reections and erratic behavior in some cases (The signal has to be suitably buered here.). timing mismatches. The above have to be carried out after completion of the prototype PCB manufacturing; it involves cost, time, and also a redesigning process to develop a bugfree design. In fact, overload on a signal can lead to

1.3

VLSI DESIGN
Design automation is the order of the day.

The complexity of VLSIs being designed and used today makes the manual approach to design impractical. With the rapid technological developments in the last two decades, the status of VLSI technology is characterized by the following [Wai-kai, Gopalan]: steady increase in the size and hence the functionality of the ICs.

A steady reduction in feature size and hence increase in the speed of operation as well as gate or transistor density.

A steady improvement in the predictability of circuit behavior. A steady increase in the variety and size of software tools for VLSI design.

The above developments have resulted in a proliferation of approaches to VLSI design. We briey describe the procedure of automated design ow [Rabaey, Smith MJ]. The aim is more to bring out the role of a Hardware Description Language (HDL) in the design process. An abstraction based model is the basis of the automated design.

1.3.1 Abstraction Model

The model divides the whole design cycle into various domains (see Figure 1.3). With such an abstraction through a division process the design is carried out in dierent layers. The designer at one layer can function without bothering The thick horizontal lines separating the As an example, let us about the layers above or below.

layers in the gure signify the compartmentalization.

consider design at the gate level. The circuit to be designed would be described in terms of truth tables and state tables. With these as available inputs, he has to express them as Boolean logic equations and realize them in terms of gates and ip-ops. In turn, these form the inputs to the layer immediately below. Compartmentalization of the approach to design in the manner described here is the essence of abstraction; it is the basis for development and use of CAD tools in VLSI design at various levels. The design methods at dierent levels use the respective aids such as Boolean equations, truth tables, state transition table, etc. But the aids play only a small role in the process. To complete a design, one may have to switch from one tool to another, raising the issues of tool compatibility and learning new environments.

1.4

ASIC DESIGN FLOW

As with any other technical activity, development of an ASIC starts with an idea and takes tangible shape through the stages of development as shown in Figure 1.4 and shown in detail in Figure 1.5. The rst step in the process is to expand the idea in terms of behavior of the target circuit. Through stages of programming, the same is fully developed into a design description  in terms of well dened standard constructs and conventions. The design is tested through a simulation process; it is to check, verify, and ensure that what is wanted is what is described. Simulation is carried out through dedicated tools. With every simulation run, the simulation results are studied to identify errors in the design description. The errors are corrected and another simulation run carried out. Simulation and changes to design description together form a cyclic iterative process, repeated until an error-free design is evolved.

Figure 1.3: Design domain and levels of abstraction.

Figure 1.4: Major activities in ASIC design.

Design description is an activity independent of the target technology or manufacturer. It results in a description of the digital circuit. To translate it into a tangible circuit, one goes through the physical design process. The same constitutes a set of activities closely linked to the manufacturer and the target technology.

1.4.1 Design Description

The design is carried out in stages. The process of transforming the idea into a detailed circuit description in terms of the elementary circuit components constitutes design description. The nal circuit of such an IC can have up to a billion such components; it is arrived at in a step-by-step manner. The rst step in evolving the design description is to describe the circuit in terms of its behavior. The description looks like a program in a high level language like C. Once the behavioral level design description is ready, it is tested extensively with the help of a simulation tool; it checks and conrms that all the expected functions are carried out satisfactorily. If necessary, this behavioral Finally, one level routine is edited, modied, and rerun  all done manually.

has a design for the expected system  described at the behavioral level. The behavioral design forms the input to the synthesis tools, for circuit synthesis. The behavioral constructs not supported by the synthesis tools are replaced by data ow and gate level constructs. synthesizable codes for his design. The design at the behavioral level is to be elaborated in terms of known and acknowledged functional blocks. It forms the next detailed level of design description. Once again the design is to be tested through simulation and iteratively corrected for errors. The elaboration can be continued one or two steps further. It leads to a detailed design description in terms of logic gates and transistor switches. To surmise, the designer has to develop

1.4.2 Optimization
The circuit at the gate level  in terms of the gates and ip-ops  can be redundant in nature. The same can be minimized with the help of minimization tools. The step is not shown separately in the gure. The minimized logical design is converted to a circuit in terms of the switch level cells from standard libraries provided by the foundries. The cell based design generated by the tool is the last step in the logical design process; it forms the input to the rst level of physical design [Micheli].

1.4.3 Simulation
The design descriptions are tested for their functionality at every level  behavioral, data ow, and gate. One has to check here whether all the functions are carried out as expected and rectify them. All such activities are carried out by the simulation tool. The tool also has an editor to carry out any corrections

Figure 1.5: ASIC design and development ow.

10

to the source code. Simulation involves testing the design for all its functions, functional sequences, timing constraints, and specications. Normally testing and simulation at all the levels  behavioral to switch level  are carried out by a single tool; the same is identied as  scope of simulation tool in Figure 1.5.

1.4.4 Synthesis
With the availability of design at the gate (switch) level, the logical design is complete. The corresponding circuit hardware realization is carried out by a synthesis tool. Two common approaches are as follows:

The circuit is realized through an FPGA [Oldeld]. The gate level design description is the starting point for the synthesis here. The FPGA vendors provide an interface to the synthesis tool. Through the interface the gate level design is realized as a nal circuit. With many synthesis tools, one can directly use the design description at the data ow level itself to realize the nal circuit through an FPGA. The FPGA route is attractive for limited volume production or a fast development cycle.

The circuit is realized as an ASIC. A typical ASIC vendor will have his own library of basic components like elementary gates and ip-ops. Eventually the circuit is to be realized by selecting such components and interconnecting them conforming to the required design. This constitutes the physical design. Being an elaborate and costly process, a physical design may call for an intermediate functional verication through the FPGA route. The circuit realized through the FPGA is tested as a prototype. It provides another opportunity for testing the design closer to the nal circuit.

1.4.5 Physical Design

A fully tested and error-free design at the switch level can be the starting point for a physical design [Baker & Boyce, Wolf]. It is to be realized as the nal The circuit using (typically) a million components in the foundry's library. step-by-step activities in the process are described briey as follows:

System partitioning: The design is partitioned into convenient compartments or functional blocks. Often it would have been done at an earlier stage itself and the software design prepared in terms of such blocks. Interconnection of the blocks is part of the partition process.

Floor planning: The positions of the partitioned blocks are planned and the blocks are arranged accordingly. The procedure is analogous to the planning and arrangement of domestic furniture in a residence. Blocks with I/O pins are kept close to the periphery; those which interact frequently or through a large number of interconnections are kept close together, and so on. Partitioning and oor planning may have to be carried out and rened iteratively to yield best results.

11

Placement: The selected components from the ASIC library are placed in position on the  Silicon oor. It is done with each of the blocks above. Routing: The components placed as described above are to be interconnected to the rest of the block: It is done with each of the blocks by suitably routing the interconnects. Once the routing is complete, the physical design cam is taken as complete. The nal mask for the design can be made at this stage and the ASIC manufactured in the foundry.

1.4.6 Post Layout Simulation

Once the placement and routing are completed, the performance specications like silicon area, power consumed, path delays, etc., can be computed. Equivalent circuit can be extracted at the component level and performance analysis carried out. This constitutes the nal stage called  verication. One may have to go through the placement and routing activity once again to improve performance.

1.4.7 Critical Subsystems

The design may have critical subsystems. Their performance may be crucial to the overall performance; in other words, to improve the system performance substantially, one may have to design such subsystems afresh. The design here may imply redenition of the basic feature size of the component, component design, placement of components, or routing done separately and specically for the subsystem. A set of masks used in the foundry may have to be done afresh for the purpose.

1.5

ROLE OF HDL

An HDL provides the framework for the complete logical design of the ASIC. All the activities coming under the purview of an HDL are shown enclosed in bold dotted lines in Figure 1.4. Verilog and VHDL are the two most commonly used HDLs today. Both have constructs with which the design can be fully described at all the levels. There are additional constructs available to facilitate setting up of the test bench, spelling out test vectors for them and  observing the outputs from the designed unit. IEEE has brought out Standards for the HDLs, and the software tools conform to them. Verilog as an HDL was introduced by Cadence Design Systems; they placed it into the public domain in 1990. It was established as a formal IEEE Standard in 1995. version of the standard. The revised version has been brought out in 2001. However, most of the simulation tools available today conform only to the 1995

12

Chapter 2
Architecture of FPGAs and CPLDs
2.1 Introduction to High-Capacity FPDs

Prompted by the development of new types of sophisticated eld-programmable devices (FPDs), the process of designing digital hardware has changed dramatically over the past few years. Unlike previous generations of technology, in which board-level designs included large numbers of SSI chips containing basic gates, virtually every digital design produced today consists mostly of high-density devices. This applies not only to custom devices like processors and memory, but also for logic circuits such as state machine controllers, counters, registers, and decoders. When such circuits are destined for high-volume systems they have been integrated into high-density gate arrays. However, gate array NRE costs often are too expensive and gate arrays take too long to manufacture to be viable for prototyping or other low-volume scenarios. For these reasons, most prototypes, and also many production designs are now built using FPDs. The most compelling advantages of FPDs are instant manufacturing turnaround, low start-up costs, low nancial risk and (since programming is done by the end user) ease of design changes. The market for FPDs has grown dramatically over the past decade to the point where there is now a wide assortment of devices to choose from. A designer today faces a daunting task to research the dierent types of chips, understand what they can best be used for, choose a particular manufacturers's product, learn the intricacies of vendor-specic software and then design the hardware. Confusion for designers is exacerbated by not only the sheer number of FPDs available, but also by the complexity of the more sophisticated devices. The purpose of this paper is to provide an overview of the architecture of the various types of FPDs. The emphasis is on devices with relatively high logic capacity; all of the most important commercial products are discussed. Before proceeding, we provide denitions of the terminology in this eld.

13

This is necessary because the technical jargon has become somewhat inconsistent over the past few years as companies have attempted to compare and contrast their products in literature.

2.1.1 Denitions of Relevant Terminology

The most important terminology used in this report are dened below:

Field-Programmable Device (FPD)  a general term that refers to any type of integrated circuit used for implementing digital hardware, where the chip can be congured by the end user to realize dierent designs. Programming of such a device often involves placing the chip into a special programming unit, but some chips can also be congured  in-system . Another name for FPDs is programmable logic devices (PLDs); although PLDs encompass the same types of chips as FPDs, we prefer the term FPD because historically the word PLD has referred to relatively simple types of devices.

PLA  a Programmable Logic Array (PLA) is a relatively small FPD that contains two levels of logic, an AND-plane and an OR-plane, where both levels are programmable (note: although PLA structures are sometimes embedded into full-custom chips, we refer here only to those PLAs that are provided as separate integrated circuits and are user-programmable).

CPLD  a more Complex PLD that consists of an arrangement of multiple SPLD-like blocks on a single chip. Alternative names (that will not be used in this paper) sometimes adopted for this style of chip are Enhanced PLD (EPLD), Super PAL, Mega PAL, and others.

FPGA  a Field-Programmable Gate Array is an FPD featuring a general structure that allows very high logic capacity. Whereas CPLDs feature logic resources with a wide number of inputs (AND planes), FPGAs oer more narrow logic resources. FPGAs also oer a higher ratio of ip-ops to logic resources than do CPLDs.

HCPLDs  high-capacity PLDs: CPLDs and FPGAs.

a single acronym that refers to both

This term has been coined in trade literature for

providing an easy way to refer to both types of devices.

Interconnect  the wiring resources in an FPD. Programmable Switch  a user-programmable switch that can connect a logic element to an interconnect wire, or one interconnect wire to another. Logic Block  a relatively small circuit block that is replicated in an array in an FPD. When a circuit is implemented in an FPD, it is rst decomposed into smaller sub-circuits that can each be mapped into a logic block. The term logic block is mostly used in the context of FPGAs, but it could also refer to a block of circuitry in a CPLD.

14

Logic Capacity  the amount of digital logic that can be mapped into a single FPD. This is usually measured in units of  equivalent number of gates in a traditional gate array . In other words, the capacity of an FPD is measured by the size of gate array that it is comparable to. In simpler terms, logic capacity can be thought of as  number of 2-input NAND gates .

Logic Densitythe amount of logic per unit area in an FPD. Speed-Performance  measures the maximum operable speed of a circuit when implemented in an FPD. For combinational circuits, it is set by the longest delay through any path, and for sequential circuits it is the maximum clock frequency for which the circuit functions properly.

In the remainder of this section, to provide insight into FPD development the evolution of FPDs over the past two decades is described. the manufacture of FPDs. Additional background information is also included on the semiconductor technologies used in

2.2

Evolution of Programmable Logic Devices

The rst type of user-programmable chip that could implement logic circuits was the Programmable Read-Only Memory (PROM), in which address lines can be used as logic circuit inputs and data lines as outputs. Logic functions, however, rarely require more than a few product terms, and a PROM contains a full decoder for its address inputs. PROMS are thus an inecient architecture for realizing logic circuits, and so are rarely used in practice for that purpose. The rst device developed later specically for implementing logic circuits was the Field-Programmable Logic Array (FPLA), or simply PLA for short. A PLA consists of two levels of logic gates: a programmable  wired AND-plane followed by a programmable  wired OR-plane. A PLA is structured so that any of its inputs (or their complements) can be AND'ed together in the AND-plane; each AND-plane output can thus correspond to any product term of the inputs. Similarly, each ORplane output can be congured to produce the logical sum of any of the AND-plane outputs. With this structure, PLAs are well-suited for implementing logic functions in sum-of-products form. They are also quite versatile, since both the AND terms and OR terms can have many inputs (this feature is often referred to as wide AND and OR gates). When PLAs were introduced in the early 1970s, by Philips, their main drawbacks were that they were expensive to manufacture and oered somewhat poor speed-performance. Both disadvantages were due to the two levels of congurable logic, because programmable logic planes were dicult to manufacture and introduced signicant propagation delays. To overcome these weaknesses, Programmable Array Logic (PAL) devices were developed. As Figure 1 illustrates, PALs feature only a single level of programmability, consisting of a programmable  wired ANDplane that feeds xed OR-gates. To compensate for

15

Figure 2.1: Structure of a PAL.

lack of generality incurred because the OR-plane is xed, several variants of PALs are produced, with dierent numbers of inputs and outputs, and various sizes of OR-gates. PALs usually contain ip-ops connected to the OR-gate outputs so that sequential circuits can be realized. PAL devices are important because when introduced they had a profound eect on digital hardware design, and also they are the basis for some of the newer, more sophisticated architectures that will be described shortly. Variants of the basic PAL architecture are featured in several other products known by dierent acronyms. All small PLDs, including PLAs, PALs, and PAL-like devices are grouped into a single category called Simple PLDs (SPLDs), whose most important characteristics are low cost and very high pin-to-pin speed-performance. As technology has advanced, it has become possible to produce devices with higher capacity than SPLDs. The diculty with increasing capacity of a strict SPLD architecture is that the structure of the programmable logic-planes grow too quickly in size as the number of inputs is increased. The only feasible way to provide large capacity devices based on SPLD architectures is then to integrate multiple SPLDs onto a single chip and provide interconnect to programmably connect the SPLD blocks together. Many commercial FPD products exist on the market today with this basic structure, and are collectively referred to as Complex PLDs (CPLDs). CPLDs were pioneered by Altera, rst in their family of chips called Classic EPLDs, and then in three additional series, called MAX 5000, MAX 7000 and

16

MAX 9000. Because of a rapidly growing market for large FPDs, other manufacturers developed devices in the CPLD category and there are now many choices available. All of the most important commercial products will be described CPLDs provide logic capacity up to the equivalent of about 50 To build FPDs with very high logic capacity, a dierent in Section 2.

typical SPLD devices, but it is somewhat dicult to extend these architectures to higher densities. approach is needed. The highest capacity general purpose logic chips available today are the traditional gate arrays sometimes referred to as Mask-Programmable Gate Arrays (MPGAs). MPGAs consist of an array of pre-fabricated transistors that can be customized into the user's logic circuit by connecting the transistors with custom wires. Customization is performed during chip fabrication by specifying the metal interconnect, and this means that in order for a user to employ an MPGA a large setup cost is involved and manufacturing time is long. Although MPGAs are clearly not FPDs, they are mentioned here because they motivated the design of the user-programmable equivalent: Field- Programmable Gate Arrays (FPGAs). Like MPGAs, FPGAs comprise an array of uncommitted circuit elements, called logic blocks, and interconnect resources, but FPGA conguration is performed through programming by the end user. An illustration of a typical FPGA architecture appears in Figure 2.2. As the only type of FPD that supports very high logic capacity, FPGAs have been responsible for a major shift in the way digital circuits are designed. Figure 2.3 summarizes the categories of FPDs by listing the logic capacities available in each of the three categories. In the gure,  equivalent gates refers loosely to  number of 2-input NAND gates . The chart serves as a guide for selecting a specic device for a given application, depending on the logic capacity needed. However, as we will discuss shortly, each type of FPD is inherently better suited for some applications than for others. It should also be mentioned that there exist other special-purpose devices optimized for specic applications (e.g. state machines, analog gate arrays, large interconnection problems). However, since use of such devices is limited they will not be described here. The next sub-section discusses the methods used to implement the user-programmable switches that are the key to the user-customization of FPDs.

2.3

User-Programmable Switch Technologies

The rst type of user-programmable switch developed was the fuse used in PLAs. Although fuses are still used in some smaller devices, we will not discuss them here because they are quickly being replaced by newer technology. For higher density devices, where CMOS dominates the IC industry, dierent approaches to implementing programmable switches have been developed. For CPLDs the main switch technologies (in commercial products) are oating gate transistors like those used in EPROM and EEPROM, and for FPGAs they are SRAM and antifuse. Each of these is briey discussed below. An EEPROM or EPROM transistor is used as a programmable switch for

17

Figure 2.2: Structure of an FPGA.

18

Figure 2.3: FPD Categories by Logic Capacity.

CPLDs (and also for many SPLDs) by placing the transistor between two wires in a way that facilitates implementation of wired-AND functions. This is illustrated in Figure 4, which shows EPROM transistors as they might be connected in an AND-plane of a CPLD. An input to the AND-plane can drive a product wire to logic level `0' through an EPROM transistor, if that input is part of the corresponding product term. For inputs that are not involved for a product term, the appropriate EPROM transistors are programmed to be permanently turned o. A diagram for an EEPROMbased device would look similar.

2.4

Computer Aided Design (CAD) Flow for FPDs

Such software tools are discussed

When designing circuits for implementation in FPDs, it is essential to employ Computer-Aided Design (CAD) programs. briey in this section to provide a feel for the design process involved. CAD tools are important not only for complex devices like CPLDs and FPGAs, but also for SPLDs. A typical CAD system for SPLDs would include software for the following tasks: initial design entry, logic optimization, device tting, simulation, and conguration. This design ow is illustrated in Figure 2.4, which also indicates how some stages feed back to others. Design entry may be done either by creating a schematic diagram with a graphical CAD tool, by using a textbased system to describe a design in a simple hardware

19

Figure 2.4: CAD Design Flow for SPLDs.

description language, or with a mixture of design entry methods. Since initial logic entry is not usually in an optimized form, algorithms are employed to optimize the circuits, after which additional algorithms analyse the resulting logic equations and  t them into the SPLD. Simulation is used to verify correct operation, and the user would return to the design entry step to x errors. When a design simulates correctly it can be loaded into a programming unit and used to congure an SPLD. One nal detail to note about Figure 2.4 is that while the original design entry step is performed manually by the designer, all other steps are carried out automatically by most CAD systems. The steps involved for implementing circuits in CPLDs are similar to those for SPLDs, but the tools themselves are more sophisticated. Because the devices are complex and can accommodate large designs, it is more common to use a mixture of design entry methods for dierent modules of a complete circuit. For instance, some modules might be designed with a small hardware description language like ABEL, others drawn using a symbolic schematic capture tool, and still others described via a full-featured hardware description language such as VHDL. Also, for CPLDs the process of  tting a design may require steps similar to those described below for FPGAs, depending on how sophisticated the CPLD is. The necessary software for these tasks is supplied either by the CPLD manufacturer or a third party. The design process for FPGAs is similar to that for CPLDs, but additional tools are needed to support the increased complexity of the chips. The major dierence is in the  device tter step that comes after logic optimization and before simulation, where FPGAs require at least three steps: a technology mapper to map from basic logic gates into the FPGA's logic blocks, placement to choose which specic logic blocks to use in the FPGA, and a router to allocate the wire segments in the FPGA to interconnect the logic blocks. With this added complexity, the CAD tools might require a fairly long period of time

20

(often more than an hour or even several hours) to complete their tasks.

2.5

Applications of CPLDs

We will now briey examine the types of applications which best suit CPLD architectures. Because they oer high speeds and a range of capacities, CPLDs are useful for a very wide assortment of applications, from implementing random glue logic to prototyping small gate arrays. One of the most common uses in industry at this time, and a strong reason for the large growth of the CPLD market, is the conversion of designs that consist of multiple SPLDs into a smaller number of CPLDs. CPLDs can realize reasonably complex designs, such as graphics controller, LAN controllers, UARTs, cache control, and many others. As a general rule-ofthumb, circuits that can exploit wide AND/OR gates, and do not need a very large number of ip-ops are good candidates for implementation in CPLDs. A signicant advantage of CPLDs is that they provide simple design changes through re-programming (all commercial CPLD products are re-programmable). With insystem programmable CPLDs it is even possible to re-congure hardware (an example might be to change a protocol for a communications circuit) without power-down. Designs often partition naturally into the SPLD-like blocks in a CPLD. The result is more predictable speed-performance than would be the case if a design were split into many small pieces and then those pieces were mapped into different areas of the chip. Predictability of circuit implementation is one of the strongest advantages of CPLD architectures.

21

Chapter 3
VHDL
3.1 Introduction

VHDL is a programming language that has been designed and optimized for describing the behavior of digital systems. VHDL has many features appropriate for describing the behavior of electronic components ranging from simple logic gates to complete microprocessors and custom chips. Features of VHDL allow electrical aspects of circuit behavior (such as rise and fall times of signals, delays through gates, and functional operation) to be precisely described. The resulting VHDL simulation models can then be used as building blocks in larger circuits (using schematics, block diagrams or system-level VHDL descriptions) for the purpose of simulation. VHDL is also a general-purpose programming language: just as high-level programming languages allow complex design concepts to be expressed as computer programs, VHDL allows the behavior of complex electronic circuits to be captured into a design system for automatic circuit synthesis or for system simulation. Like Pascal, C and C++, VHDL includes features useful for structured design techniques, and oers a rich set of control and data representation features. Unlike these other programming languages, VHDL provides features allowing concurrent events to be described. This is important because the hardware described using VHDL is inherently concurrent in its operation. One of the most important applications of VHDL is to capture the performance specication for a circuit, in the form of what is commonly referred to as a test bench. Test benches are VHDL descriptions of circuit stimuli and corresponding expected outputs that verify the behavior of a circuit over time. Test benches should be an integral part of any VHDL project and should be created in tandem with other descriptions of the circuit.

22

3.2

A standard language

One of the most compelling reasons for you to become experienced with and knowledgeable in VHDL is its adoption as a standard in the electronic design community. Using a standard language such as VHDL virtually guarantees that you will not have to throw away and recapture design concepts simply because the design entry method you have chosen is not supported in a newer generation of design tools. Using a standard language also means that you are more likely to be able to take advantage of the most up-to-date design tools and that you will have access to a knowledge base of thousands of other engineers, many of whom are solving problems similar to your own.

3.3

Entities and Architectures

Every VHDL design description consists of at least one entity/architecture pair. (In VHDL jargon, this combination of an entity and its corresponding architecture is sometimes referred to as a design entity.) In a large design, you will typically write many entity/architecture pairs and connect them together to form a complete circuit. An entity declaration describes the circuit as it appears from the  outside - from the perspective of its input and output interfaces. If you are familiar with schematics, you might think of the entity declaration as being analogous to a block symbol on a schematic. The second part of a minimal VHDL design description is the architecture declaration. Before simulation or synthesis can proceed, every referenced entity in a VHDL design description must be bound with a corresponding architecture. The architecture describes the actual function  or contents  of the entity to which it is bound. Using the schematic as a metaphor, you can think of the architecture as being roughly analogous to a lower-level schematic referenced by the higher-level functional block symbol.

3.3.1 Entity declaration

An entity declaration provides the complete interface for a circuit. Using the information provided in an entity declaration (the names, data types and direction of each port), you have all the information you need to connect that portion of a circuit into other, higher-level circuits, or to develop input stimuli (in the form of a test bench) for verication purposes. The actual operation of the circuit, however, is not included in the entity declaration. Let's take a closer look at the entity declaration for this simple design description: entity compare is port( A, B: in bit_vector(0 to 7); EQ: out bit); end compare;

23

The entity declaration includes a name, compare, and a port statement dening all the inputs and outputs of the entity. The port list includes denitions of three ports: A, B, and EQ. Each of these three ports is given a direction (either in, out or inout), and a type (in this case either bit_vector(0 to 7), which species an 8-bit array, or bit, which represents a single-bit value). There are many dierent data types available in VHDL. To simplify things in this introductory circuit, we're going to stick with the simplest data types in VHDL, which are bit and bit_vector.

3.3.2 Architecture declaration and body

The second part of a minimal VHDL source le is the architecture declaration. Every entity declaration you reference in your design must be accompanied by at least one corresponding architecture (we'll discuss why you might have more than one architecture in a moment). Here's the architecture declaration for the comparator circuit: architecture compare1 of compare is begin EQ <= '1' when (A = B) else '0'; end compare1; The architecture declaration begins with a unique name, compare1, followed by the name of the entity to which the architecture is bound, in this case compare. Within the architecture declaration (between the begin and end keywords) is found the actual functional description of the comparator. There are many ways to describe combinational logic functions in VHDL; the method used in this simple design description is a type of concurrent statement known as a conditional assignment. This assignment species that the value of the output (EQ) will be assigned a value of '1' when A and B are equal, and a value of '0' when they dier.

3.4

Design Units

One concept unique to VHDL (when compared to software programming languages and to its main rival, Verilog) is the concept of a design unit. Design units in VHDL (which may also be referred to as library units) are segments of VHDL code that can be compiled separately and stored in a library. There are actually ve types of design units in VHDL; entities, architectures, packages, package bodies, and congurations. Entities and architectures are the only two design units that you must have in any VHDL design description. Packages and congurations are optional.

3.4.1 Entities
A VHDL entity is a statement (indicated by the entity keyword) that denes the external specication of a circuit or sub-circuit. The minimum VHDL design

24

description must include at least one entity and one corresponding architecture. When you write an entity declaration, you must provide a unique name for that entity and a port list dening the input and output ports of the circuit. Each port in the port list must be given a name, direction (or mode, in VHDL jargon) and a type. Optionally, you may also include a special type of parameter list (called a generic list) that allows you to pass additional information into an entity. An example of an entity declaration is given below: entity fulladder is port (X: in bit; Y: in bit; Cin: in bit; Cout: out bit; Sum: out bit); end fulladder;

3.4.2 Architectures
A VHDL architecture declaration is a statement (beginning with the architecture keyword) that describes the underlying function and/or structure of a circuit. Each architecture in your design must be associated (or bound) by name with one entity in the design. VHDL allows you to create more than one alternate architecture for each entity. This feature is particularly useful for simulation and for project team environments in which the design of the system interfaces (expressed as entities) is performed by a dierent engineer than the lower-level architectural description of each component circuit, or when you simply want to experiment with dierent methods of description. An architecture declaration consists of zero or more declarations (of items such as intermediate signals, components that will be referenced in the architecture, local functions and procedures, and constants) followed by a begin statement, a series of concurrent statements, and an end statement, as illustrated by the following example: architecture concurrent of fulladder is begin Sum <= X xor Y xor Cin; Cout <= (X and Y) or (X and Cin) or (Y and Cin); end concurrent;

3.4.3 Packages and package bodies

A VHDL package declaration is identied by the package keyword, and is used to collect commonlyused declarations for use globally among dierent design units. You can think of a package as a common storage area, one used to store such things as type declarations, constants, and global subprograms. Items dened within a package can be made visible to any other design unit in the complete VHDL design, and they can be compiled into libraries for later re-use.

25

A package can consist of two basic parts: statements:

a package declaration and an

optional package body. Package declarations can contain the following types of

Type and subtype declarations Constant declarations Global signal declarations Function and procedure declarations Attribute specications File declarations Component declarations Alias declarations Disconnect specications Use clauses

Items appearing within a package declaration can be made visible to other design units through the use of a use statement. If the package contains declarations of subprograms (functions or procedures) or denes one or more deferred constants (constants whose value is not immediately given), then a package body is required in addition to the package declaration. A package body (which is specied using the package body keyword combination) must have the same name as its corresponding package declaration, but it can be located anywhere in the design, in the same or a dierent source le. An example of a package is given below: package conversion is function to_vector (size: integer; num: integer) return std_logic_vector; end conversion; package body conversion is function to_vector(size: integer; num: integer) return std_logic_vector is variable ret: std_logic_vector (1 to size); variable a: integer; begin a := num; for i in size downto 1 loop if ((a mod 2) = 1) then ret(i) := '1'; else ret(i) := '0'; end if; a := a / 2;

26

end loop; return ret; end to_vector; end conversion;

3.4.4 Congurations
The nal type of design unit available in VHDL is called a conguration declaration. You can think of a conguration declaration as being roughly analogous to a parts list for your design. A conguration declaration (identied with the conguration keyword) species which architectures are to be bound to which entities, and it allows you to change how components are connected in your design description at the time of simulation. (Congurations are not generally used for synthesis, and may not be supported in the synthesis tool that you will use.) Conguration declarations are always optional, no matter how complex a design description you create. In the absence of a conguration declaration, the VHDL standard species a set of rules that provide you with a default conguration. For example, in the case where you have provided more than one architecture for an entity, the last architecture compiled will take precedence and will be bound to the entity. A simple example of a conguration is given below: conguration this_build of rcomp is for structure for COMP1: compare use entity work.compare(compare1); for ROT1: rotate use entity work.rotate(rotate1); end for; end this_build;

27

Chapter 4
Projects
4.1 ALU 8 Bit

4.1.1 *.vhd Code

library IEEE; use IEEE.STD_LOGIC_1164.ALL; use ieee.std_logic_unsigned.all; use ieee.std_logic_arith.all; use IEEE.NUMERIC_STD.ALL; library UNISIM; use UNISIM.VComponents.all; entity sagALU is port( a, b : in std_logic_vector(7 downto 0); op : in std_logic_vector(2 downto 0); zero : out std_logic; f : out std_logic_vector(7 downto 0)); end sagALU; architecture Behavioral of sagALU is begin process(op,a,b) variable nf: std_logic_vector(7 downto 0); begin case op is when "000" => nf := a and b; when "100" => nf := a or b; when "001" => nf := a xor b; when "101" => nf := a xnor b; when "010" => nf := a + b; when "110" =>

28

nf := a - b; when "111" => if a < b then nf := "11111111"; end if; when others => nf := "00000000"; end case; if nf="00000000" then zero <= '1'; else zero <= '0'; end if; f <= nf; end process; end Behavioral;

4.1.2 Test Bench Code

LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sagalutb IS END sagalutb; ARCHITECTURE behavior OF sagalutb IS COMPONENT sagALU PORT( a : IN std_logic_vector(7 downto 0); b : IN std_logic_vector(7 downto 0); op : IN std_logic_vector(2 downto 0); zero : OUT std_logic; f : OUT std_logic_vector(7 downto 0) ); END COMPONENT; Inputs signal a : std_logic_vector(7 downto 0) := (others => '0'); signal b : std_logic_vector(7 downto 0) := (others => '0'); signal op : std_logic_vector(2 downto 0) := (others => '0'); Outputs signal zero : std_logic; signal f : std_logic_vector(7 downto 0); BEGIN  Instantiate the Unit Under Test (UUT) uut: sagALU PORT MAP ( a => a, b => b, op => op, zero => zero, f => f );  Stimulus process

29

Figure 4.1: ALU Simulation in Xilinx ISE

stim_proc: process begin  hold reset state for 100 ns. wait for 100 ns;  insert stimulus here wait; end process; END;

4.2

Processor

4.2.1 *.vhd Code

- CPU is a four register, 8 bit data/instruction, load/store machine. LIBRARY ieee; USE ieee.std_logic_1164.all; - standard logic USE ieee.std_logic_unsigned.all; - arithmetic stu ENTITY sagproc2 IS PORT( clk: IN std_logic; - 50% duty cycle clock rd: inout std_logic; - mem read cntl wr: inout std_logic; - mem write cntl

30

addr: inout std_logic_vector(15 downto 0);- the address bus data: INOUT std_logic_vector(7 downto 0); - the data bus sevseg: OUT std_logic_vector(6 downto 0); - segven segment display din : IN std_logic_vector(15 DOWNTO 0); - shell data in dout : OUT std_logic_vector(7 DOWNTO 0); - shell data out dsel : IN std_logic_vector(1 DOWNTO 0) - shell data out select ); END sagproc2; ARCHITECTURE one OF sagproc2 IS - reset signal SIGNAL reset: std_logic; - cpu state SIGNAL fetch, exec: std_logic; -opcodes SIGNAL ld, st, addi, add, inand, isll, inot: std_logic; SIGNAL clr, jal, skipn, skipz, br: std_logic; - IR, PC SIGNAL ir: std_logic_vector(7 downto 0); -instruction register SIGNAL pc: std_logic_vector(7 downto 0); -program counter SIGNAL PCinSel: std_logic; -selects PC load source 0=PC_incrementer 1=Aout SIGNAL PCload: std_logic; -gates the PC load SIGNAL PCaddSel: std_logic_vector(1 downto 0); -selects PC increment 0=1 1=2 3=displacement SIGNAL PCinc: std_logic_vector(7 downto 0); -increment value SIGNAL PCin: std_logic_vector(7 downto 0); -PC update SIGNAL PCnew: std_logic_vector(7 downto 0); -incrmented PC - DATA from IR SIGNAL DataImm: std_logic_vector(7 downto 0); - 4 bits from IR extended SIGNAL disp: std_logic_vector(2 downto 0); -oset for reg indirect data addr from IR so addr<= disp+Bout SIGNAL displacement: std_logic_vector(7 downto 0); -oset for PC jump from IR so PC <= PC+displacement - MEMORY interface SIGNAL MASel: std_logic; -memory address select: 0=PC, 1=disp+(B) SIGNAL dataAddr: std_logic_vector(7 downto 0); -memory data address 1=disp+(B) SIGNAL AtoBus: std_logic; -gates the A bus output onto the memory data bus

31

- DATA registers SIGNAL r0, r1, r2, r3: std_logic_vector(7 downto 0); SIGNAL rdata: std_logic_vector(7 downto 0); - register outputs SIGNAL Aout, Bout: std_logic_vector(7 downto 0); -register input bus SIGNAL RegDSel: std_logic_vector(1 downto 0); -data source for rdata reg write: 0=0 1=PC 2=ALUout 3=data SIGNAL ALUBSel: std_logic_vector(1 downto 0); -data source for ALU b input: 0=Bout 1=0 2=1 3=DataImm SIGNAL ASel: std_logic_vector(1 downto 0); -selects A register output SIGNAL BSel: std_logic_vector(1 downto 0); -selects B register output SIGNAL we: std_logic; -enables a register load - ALU SIGNAL Bin: std_logic_vector(7 downto 0); SIGNAL ALUop: std_logic_vector(1 downto 0); -selects ALU function SIGNAL ALUout: std_logic_vector(7 downto 0); -ALU result SIGNAL zne: std_logic; -gates the Z and N register loads SIGNAL z, n: std_logic; -the Z and N registers BEGIN - *********************************** -debugger shell interface reset <= din(0); WITH dsel SELECT dout <= addr(7 downto 0) WHEN "00" , data WHEN "01", pc WHEN "10", ir WHEN "11" , "11111111" WHEN OTHERS ; - *********************************** - 7-seg decoder WITH r3(3 downto 0) SELECT sevseg <= "0111111" WHEN "0000", "0000110" WHEN "0001", "1011011" WHEN "0010", "1001111" WHEN "0011", "1100110" WHEN "0100", "1101101" WHEN "0101", "1111101" WHEN "0110",

32

"0000111" WHEN "0111", "1111111" WHEN "1000", "1101111" WHEN "1001", "1110111" WHEN "1010", "1111100" WHEN "1011", "0111001" WHEN "1100", "1011110" WHEN "1101", "1111001" WHEN "1110", "1110001" WHEN OTHERS; - *********************************** - OPcode decoder ld <= '1' WHEN ir(7 downto 6)="00" ELSE '0'; - load st <= '1' WHEN ir(7 downto 6)="01" ELSE '0'; -store addi <= '1' WHEN ir(7 downto 6)="10" ELSE '0'; -add immediate add <= '1' WHEN (ir(7 downto 6)="11" AND ir(1 downto 0)="00") ELSE '0'; -add inand <= '1' WHEN (ir(7 downto 6)="11" AND ir(1 downto 0)="01") ELSE '0'; - nand isll <= '1' WHEN (ir(7 downto 6)="11" AND ir(3 downto 0)="0010") ELSE '0'; - shift left inot <= '1' WHEN (ir(7 downto 6)="11" AND ir(3 downto 0)="0110") ELSE '0'; - not clr <= '1' WHEN (ir(7 downto 6)="11" AND ir(3 downto 0)="1010") ELSE '0'; - clear reg jal <= '1' WHEN ir(7 downto 0)="11011110" ELSE '0';  jump and link skipn <= '1' WHEN ir(7 downto 0)="11101110" ELSE '0'; -skip on neg skipz <= '1' WHEN ir(7 downto 0)="11111110" ELSE '0'; - skip on zero br <= '1' WHEN (ir(7 downto 6)="11" AND ir(1 downto 0)="11") ELSE '0'; - branch - *********************************** - compute memory address disp <= ir(2 downto 0); dataAddr <= "00000"&disp + Bout; MASel <= '1' WHEN exec='1' ELSE '0'; WITH MASel SELECT addr <= "00000000" & pc WHEN '0', - during fetch phase "00000000" & dataAddr WHEN '1', - during exec phase "00000000" & pc WHEN OTHERS; - *********************************** - memory read/write control rd <= '0' WHEN (ld='1' AND exec='1' AND clk='0' ) - load data OR (fetch='1' AND clk='0') - fetch inst ELSE '1'; wr <= '0' WHEN (st='1' AND exec='1' AND clk='0') - store data ELSE '1'; - A bus to memory

33

data <= Aout WHEN wr='0' ELSE "ZZZZZZZZ";  oats the bus - *********************************** - Program Counter control PCaddSel <= '0'&n WHEN skipn='1' ELSE - add 2 '0'&z WHEN skipz='1' ELSE - add 2 "10" WHEN br='1' ELSE - add displacment "00"; - increment when not a branch or skip - sign extend the displacement eld displacement <= ir(5) & ir(5) & ir(5) & ir(5) & ir(5 downto 2); WITH PCaddSel SELECT PCinc <= "00000001" WHEN "00", "00000010" WHEN "01", displacement WHEN "10", "00000001" WHEN OTHERS; PCnew <= pc + PCinc; - the updated verion of the PC PCinSel <= '1' WHEN jal='1' ELSE '0'; WITH PCinSel SELECT PCin <= PCnew WHEN '0', Aout WHEN '1', Aout WHEN OTHERS; - *********************************** - register controls - set up register data select RegDSel <= "11" WHEN ld='1' ELSE "01" WHEN jal='1' ELSE "00" WHEN clr='1' ELSE "10" ; - feedback from alu - route the input data WITH RegDSel SELECT rdata <= "00000000" WHEN "00", pcnew WHEN "01", ALUout WHEN "10", data WHEN "11", "00000000" WHEN OTHERS; - choose a register for output A, jal always loads r2 ASel <= "10" WHEN jal='1' ELSE ir(5 downto 4) ; - choose a register for output B, r2 or r3 used for ld/st disp BSel <= '1'&ir(3) WHEN (ld='1' OR st='1') ELSE ir(3 downto 2) ; - write enable for registers disable for 4 opcodes we <= '0' WHEN st='1' OR br='1' OR skipn='1' OR skipz='1' ELSE '1' ; - A output WITH ASel SELECT Aout <= r0 WHEN "00", r1 WHEN "01", r2 WHEN "10",

34

r3 WHEN OTHERS; - B output WITH BSel SELECT Bout <= r0 WHEN "00", r1 WHEN "01", r2 WHEN "10", r3 WHEN OTHERS; - *********************************** - ALU controls - control the B input to the ALU ALUbSel <= "11" WHEN addi='1' ELSE - DataImm "10" WHEN inot='1' ELSE - const=1 "00" ; -Bout DataImm <= "0000"&ir(3 downto 0); - ALU B input WITH ALUbSel SELECT Bin <= Bout WHEN "00", "00000000" WHEN "01", "11111111" WHEN "10", DataImm WHEN OTHERS; - ALU function control ALUop <= "00" WHEN addi='1' OR add='1' ELSE "01" WHEN inand='1' OR inot='1' ELSE "10" ;- shift left - ALU WITH ALUop SELECT ALUout <= Aout + Bin WHEN "00", - add and addi NOT (Aout AND Bin) WHEN "01", - nand and not Aout(6 downto 0)&'0' WHEN OTHERS; -shift - zero and neg ag control zne <= '1' WHEN addi='1' OR add='1' OR inand='1' OR isll='1' OR inot='1' ELSE '0' ; - *********************************** - Timing, reset, and register updates PROCESS (clk, reset) BEGIN IF reset='1' THEN pc <= "00000000"; - reset to address zero ir <= "00000000"; - inst is equiv to clear reg 0 r3 <= "11111111"; - for testing fetch <= '1'; exec <= '0'; ELSIF (clk='1' AND clk'event) THEN IF fetch='1' THEN ir <= data; fetch <= '0';

35

exec <= '1'; ELSE pc <= PCin; fetch <= '1'; exec <= '0'; IF we='1' THEN CASE ASel IS WHEN "00" => r0 <= rdata; WHEN "01" => r1 <= rdata; WHEN "10" => r2 <= rdata; WHEN "11" => r3 <= rdata; WHEN OTHERS => NULL; END CASE; END IF; IF zne='1' THEN n <= aluout(7); IF aluout=0 THEN z <= '1'; ELSE z <= '0'; END IF; END IF; END IF; END IF; END PROCESS; END one;

4.2.2 Test Bench Code

LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sagproc2tb IS END sagproc2tb; ARCHITECTURE behavior OF sagproc2tb IS COMPONENT sagproc2 PORT( clk : IN std_logic; rd : INOUT std_logic; wr : INOUT std_logic; addr : INOUT std_logic_vector(15 downto 0); data : INOUT std_logic_vector(7 downto 0); sevseg : OUT std_logic_vector(6 downto 0); din : IN std_logic_vector(15 downto 0); dout : OUT std_logic_vector(7 downto 0); dsel : IN std_logic_vector(1 downto 0) ); END COMPONENT; Inputs

36

signal clk : std_logic := '0'; signal din : std_logic_vector(15 downto 0) := (others => '0'); signal dsel : std_logic_vector(1 downto 0) := (others => '0'); BiDirs signal rd : std_logic; signal wr : std_logic; signal addr : std_logic_vector(15 downto 0); signal data : std_logic_vector(7 downto 0); Outputs signal sevseg : std_logic_vector(6 downto 0); signal dout : std_logic_vector(7 downto 0);  Clock period denitions constant clk_period : time := 10 ns; BEGIN  Instantiate the Unit Under Test (UUT) uut: sagproc2 PORT MAP ( clk => clk, rd => rd, wr => wr, addr => addr, data => data, sevseg => sevseg, din => din, dout => dout, dsel => dsel );  Clock process denitions clk_process :process begin clk <= '0'; wait for clk_period/2; clk <= '1'; wait for clk_period/2; end process;  Stimulus process stim_proc: process begin  hold reset state for 100 ns. wait for 100 ns; wait for clk_period*10;  insert stimulus here wait; end process; END;

37

Figure 4.2: Processor Simulation in Xilinx ISE

38

Chapter 5
Xilinx ISE and Spartan-3
5.1 Introduction

In this we will discuss how to create a simple Xilinx ISE project based on the Spartan-3 Board. We will be implementing a simple decoder circuit that uses the switches on the board as inputs and the eight LEDs as outputs. There are several parts to this tutorial. Part 1 shows the basics of creating a project in Xilinx ISE. Part 2 shows how to create a PROM le that can be written to the non-volatile memory on the Spartan-3 board (because the FPGA's conguration is lost when power is turned o ). Part 3 shows how to then program the board.

5.1.1 Part 1: Starting a new Project

Start the Xilinx ISE 7.1i Project Navigator: Click Next. Select the device family, device, package, and speed grade, as shown here: Click Click Next. Click New Source. Select VHDL Module and enter  decoder as the le name: Click Next. You can now specify the inputs and outputs for the decoder. These will be inserted into an automatically generated template for the VHDL le. We have one 3-bit input ( sel ) and one 8- bit output ( y ): Click Next. You will be shown a summary window: Click Finish. Project Navigator now shows you a summary of the project: Click on the  decoder.vhd tab below the summary window, or double-click on  decoderbehaviorial in the top left  Sources pane. You will need to describe the behavior of the decoder using statements in the architecture body. In this example we will use a conditional signal assignment statement:

39

Figure 5.1: Xilinx Window

40

Figure 5.2: New Project Window

41

Figure 5.3: Project Source Properties Window

42

Figure 5.4: Module Nomenclature Window

43

Figure 5.5: Source Dening Window

44

Figure 5.6: Summary

45

Figure 5.7: Project Navigator Window

46

Figure 5.8: Code Window

47

Before we can synthesize this design we need to specify what pins on the FPGA the inputs and outputs are connected to. Double-Click on  Assign Package Pins in the  Processes pane in the left of the window. Note: You may be asked to save the VHDL le, and your design will be checked for syntax errors (these will need to be xed before you can proceed). The tools will prompt you to create a UCF le: Click Yes. The PACE editor will load: Click File Save followed by File Exit.

5.1.2 Part 2: Generating a PROM File

In this part of the chapter, we will see how to generate a PROM le that can be written to the Platform Flash on the Spartan-3 board, so that your FPGA's conguration is saved even when the board is powered down. If you do not want to generate a PROM le, you can skip directly to Part 3. However, in the interest of this tutorial we recommend you complete this part as well. We assume you are continuing from Part 1 above and are still in Project Navigator: Double-click on  Generate PROM, ACE, or JTAG File in the  Processes pane. You will notice that Project Navigator will execute the steps listed above  Generate Programming File (Synthesis and Implement Design) and mark them with a green checkmark as they complete. The iMPACT tool will open and a wizard to create a new conguration will open. Select PROM File: Click Next. Enter the PROM File Name (for example,  decoder_prom ): Click Next. Select the appropriate PROM (which is  xcf  /  xcf02s for this board) from the dropdown menus and click Add: Click Next. You will be shown a summary: Click Next. Click Add File. Select the  decoder.bit le and click Open. You can now click Finish. iMPACT will ask: Select Yes. You should then see iMPACT report successful le generation: Before you close iMPACT, select File Save Project As. . . Save the conguration under a lename such as  decoder_prom.ipf  , but do not use the default lename of  decoder.ipf  (if you follow Part 2a below, remember this lename).

48

Figure 5.9: FPGA Pins Denation

Figure 5.10: Prompt

49

Figure 5.11: Xilinx Pace

50

Figure 5.12: PROM Conguration Files

51

Figure 5.13: Prepare PROM Files

52

Figure 5.14: Congure Xilinx PROM Device

53

Figure 5.15: Summary Wizard

54

Figure 5.16: Add Files

55

Figure 5.17: Adding Source Bit Files

56

Figure 5.18: Adding Device

57

Figure 5.19: PROM File Generation

Figure 5.20: Final Output Window

58

Figure 5.21: Save Project

59

You can now close iMPACT.

60

Bibliography
[1] Fundamentals of Logic Design with VHDL- Stephen Brown & Zvonko Vranesic [2] Fundamentals of Logic Design with Verilog- Stephen Brown & Zvonko Vranesic [3] VHDL Programming by Examples- Douglas L. Perry [4] Verilog Digital System Design- Zinalabedin Navabi [5] FPGA Prototyping by VHDL Examples - Xilinx Spartan-3 Version

61