1

INTRODUCTION TO VHDL
VHDL is an acronym for VHSlC Hardware Description Language (VHSIC is an acronym for Very High Speed Integrated Circuits). It is a hardware description language that can be used to model a digital system at many levels of abstraction ranging from the algorithmic level to the gate level. The complexity of the digital system being modeled could vary from that of a simple gate to a complete digital electronic system, or anything in between. The digital system can also be described hierarchically. Timing can also be explicitly modeled in the same description. The VHDL language can be regarded as an integrated amalgamation of the following languages: sequential language, concurrent language, net-list language, timing specifications, waveform generation language. Therefore, the language has constructs that enable you to express the concurrent or sequential behavior of a digital system with or without timing. It also allows you to model the system as an interconnection of components. Test waveforms can also be generated using the same constructs. All the above constructs may be combined to provide a comprehensive description of the system in a single model. The language not only defines the syntax but also defines very clear simulation semantics for each language construct. Therefore, models written in this language can be verified using a VHDL simulator. It is a strongly typed language and is often verbose to write. It inherits many of its features, especially the sequential language part, from the Ada programming language. Because VHDL provides an extensive range of modeling capabilities, it is often difficult to understand. Fortunately, it is possible to quickly assimilate a core subset of the language that is both easy and simple to understand without learning the more complex features. This subset is usually sufficient to model most applications. The complete language, however, has sufficient power to capture the descriptions of the most complex chips to a complete electronic system. (Ada is a registered trademark of the U.S. Government, Ada Joint Program Office).

HISTORY OF VHDL
1981 1983.85 initiated by US DoD to address hardware life-cycle crisis development of baseline language by Intermetrics, IBM and TI

1986

All rights transferred to IEEE

1987 Mil Std 454 requires comprehensive VHDL descriptions to be delivered with ASICs 1994 2000 2002 Revised standard (named VHDL 1076-1993) Revised standard (named VHDL 1076 2000, Edition) Revised standard (named VHDL 1076-2002)

2007 VHDL Procedural Language Application Interface standard (VHDL 1075c-2007) 2009 Revised Standard (named VHDL 1076-2008)

CAPABILITIES OF VHDL
The following are the major capabilities that the language provides along with the features that differentiate it from other hardware description languages. The language can be used as an exchange medium between chip vendors and CAD tool users. Different chip vendors can provide VHDL descriptions of their components to system designers. CAD tool users can use it to capture the behavior of the design at a high level of abstraction for functional simulation. The language can also be used as a communication medium between different CAD and CAE tools, for example, a schematic capture program may be used to generate a VHDL description for the design which can be used as an input to a simulation program. The language supports hierarchy, that is, a digital system can be modeled as a set of interconnected components; each component, in turn, can be modeled as a set of interconnected subcomponents. The language supportsflexible design methodologies: top-down, bottom-up, or mixed.

The language is not technology-specific, but is capable of supporting technology-specific features. It can also support various hardware technologies, for example, you may define new logic types and new components, you may also specify technology-specific attributes. By being technology independent, the same behavior model can. be synthesized into different vendor libraries. It supports both synchronous and asynchronous timing models. Various digital modeling techniques such as finite-state machine descriptions, algorithmic descriptions, and boolean equations can be modeled using the language. The language is publicly available, human readable, machine readable, and above all, it is not proprietary. It is an IEEE and ANSI standard, and therefore, models described using this language are portable. The government also has a strong interest in maintaining this as a standard so that re-procurement and second-sourcing may become easier. The language supports three basic different description styles: structural, dataflow, and behavioral. A design may also be expressed in any combination of these three descriptive styles. It supports a wide range, of abstraction levels ranging from abstract behavioral descriptions to very precise gate-level descriptions. It does not, however, support modeling at or below the transistor level. It allows a design to be captured at a mixed level using a single coherent language. Arbitrarily large designs can be. modeled using the language and there are no limitations that are imposed by the language on the size of a design. The language has elements that make large scale design modeling easier, for example, components, functions, procedures, and packages. There is no need to learn a different language for simulation control. Test benches can be written using the same language to test other VHDL models.

Nominal propagation delays, min-max delays, setup and hold timing, timing constraints, and spike detection can all be described very naturally in this language. The use of generics and attributes in the models facilitate back-annotation of static information such as timing or placement information. Generics and attributes are also useful in describing parameterized designs. A model can not only describe the functionality of a design, but can also contain information about the design itself 'in terms of user-defined attributes, for example, total area and speed. A common language can be used to describe library components from different vendors. Tools that understand VHDL models will have no difficulty in reading models from a variety of vendors since the language is a standard. Models written in this language can be verified by simulation since precise simulation semantics are defined for each language construct. Behavioral models that conform to a certain synthesis description style are capable of being synthesized to gate-level descriptions. The capability of defining new data types provides the power to describe and simulate a new design technique at a very high level of abstraction without any concern about the implementation details.

ADVANTAGES
The key advantage of VHDL, when used for systems design, is that it allows the behavior of the required system to be described (modeled) and verified (simulated) before synthesis tools translate the design into real hardware (gates and wires). Another benefit is that VHDL allows the description of a concurrent system. VHDL is a dataflow language, unlike procedural computing languages such as BASIC, C, and assembly code, which all run sequentially, one instruction at a time.

VHDL project is multipurpose. Being created once, a calculation block can be used in many other projects. However, many formational and functional block parameters can be tuned (capacity parameters, memory size, element base, block composition and interconnection structure). VHDL project is portable. Being created for one element base, a computing device project can be ported on another element base, for example VLSI with various technologies.

HARDWARE ABSTRACTION
VHDL is used to describe a model for a digital hardware device. This model specifies the external view of the device and one or more internal views. The internal view of the device specifies the functionality or structure, while the external view specifies the interface of the device through which it communicates with the other models in its environment. The device to device model mapping is strictly a one to many. That is, a hardware device may have many device models. For example, a device modeled at a high level of abstraction may not have a clock as one of its inputs, since the clock may not have been used in the description. Also the data transfer at the interface may be treated in terms of say, integer values, instead of logical values. In VHDL, each device model is treated as a distinct representation of a unique device, called an entity in this text. The entity is thus a hardware abstraction of the actual hardware device. Each entity is described using one model that contains one external view and one or more internal views. At the same time, a hardware device may be represented by one or more entities.

SOME OF THE VHDL TERMS

Before we start with, here are some of the basic terms used in VHDL Entity All designs are expressed in terms of entities. An entity is the most basic building block in a design. The uppermost level of the design is the

top-level entity. If the design is hierarchical, then the top-level description will have lower-level descriptions contained in it. These lower-level descriptions will be lower-level entities contained in the top-level entity description. Architecture All entities that can be simulated have an architecture description. The architecture describes the behavior of the entity. A single entity can have multiple architectures. One architecture might be behavioral while another might be a structural description of the design. Configuration A configuration statement is used to bind a component instance to an entity-architecture pair. A configuration can be considered like a parts list for a design. It describes which behavior to use for each entity, much like a parts list describes which part to use for each part in the design. Package - A package is a collection of commonly used data types and subprograms used in a design. Think of a package as a toolbox that contains tools used to build designs. Driver - This is a source on a signal. If a signal is driven by two sources, then when both sources are active, the signal will have two drivers. Bus - The term bus usually brings to mind a group of signals or a particular method of communication used in the design of hardware. In VHDL, a bus is a special kind of signal that may have its drivers turned off. Attribute - An attribute is data that are attached to VHDL objects or predefined data about VHDL objects. Examples are the current drive capability of a buffer or the maximum operating temperature of the device. Generic - A generic is VHDLs term for a parameter that passes information to an entity. For instance, if an entity is a gate level model with a rise and a fall delay, values for the rise and fall delays could be passed into the entity with generics. Process - A process is the basic unit of execution in VHDL. All operations that are performed in a simulation of a VHDL description are broken into single or multiple processes.

VHDL IS LIKE A PROGRAMMING LANGUAGE

The behavior of a module may be described in programming language form. If you are familiar with the Ada programming language, you will notice the similarity with that language. This is both a convenience and a nuisance. The convenience is that you dont have much to learn to use these VHDL facilities. The problem is that the facilities are not as comprehensive as those of Ada, though they are certainly adequate for most modeling purposes.

DESCRIBING STRUCTURE
A digital electronic system can be described as a module with inputs and/or outputs. The electrical values on the outputs are some function of the values on the inputs. A module F has two inputs, A and B, and an output Y. Using VHDL terminology, we call the module F a design entity, and the inputs and outputs are called ports. One way of describing the function of a module is to describe how it is composed of sub-modules. Each of the sub-modules is an instance of some entity, and the ports of the instances are connected using signals. This kind of description is called a structural description.

DESCRIBING BEHAVIOR
In many cases, it is not appropriate to describe a module structurally. One such case is a module which is at the bottom of the hierarchy of some other structural description. For example, if you are designing a system using IC packages bought from an IC shop, you do not need to describe the internal structure of an IC. In such cases, a description of the function performed by the module is required, without reference to its actual internal structure. Such a description is called a functional or behavioral description. DISCRETE EVENT TIME MODEL Once the structure and behavior of a module have been specified, it is possible to simulate the module by executing its behavioral description. This is done by simulating the passage of time in discrete steps. At some simulation time, a module input may be stimulated by changing the value on an input port. The module reacts by running the code of its behavioral description and scheduling new values to be placed on the signals connected to its output ports at some later simulated time. This is called scheduling a transaction on that signal. If the new value is different from the previous

value on the signal, an event occurs, and other modules with input ports connected to the signal may be activated. The simulation starts with an initialization phase, and then proceeds by repeating a two-stage simulation cycle. In the initialization phase, all signals are given initial values, the simulation time is set to zero, and each modules behavior program is executed. This usually results in transactions being scheduled on output signals for some later time. In the first stage of a simulation cycle, the simulated time is advanced to the earliest time at which a transaction has been scheduled. All transactions scheduled for that time are executed, and this may cause events to occur on some signals. In the second stage, all modules which react to events occurring in the first stage have their behavior program executed. These programs will usually schedule further transactions on their output signals. When all of the behavior programs have finished executing, the simulation cycle repeats. If there are no more scheduled transactions, the whole simulation is completed. The purpose of the simulation is to gather information about the changes in system state over time. This can be done by running the simulation under the control of a simulation monitor. The monitor allows signals and other state information to be viewed or stored in a trace file for later analysis. It may also allow interactive stepping of the simulation process, much like an interactive program debugger.

DECLARATIONS OF VHDL
There are various types of declarations done in VHDL. The VHDL programming is basically done by entity declaration, architecture declaration, component declaration, signal declaration, etc. these declarations are described below:

ENTITY DECLARATION
A digital system is usually designed as a hierarchical collection of modules. Each module has a set of ports which constitute its interface to the outside

world. In VHDL, an entity is such a module which may be used as a component in a design, or which may be the top level module of the design. The syntax for declaring an entity is: entity_declaration ::= entity identifier is entity_header entity_declarative_part [ begin entity_statement_part ] end [ entity_simple_name ] ; entity_header ::= [ formal_generic_clause ] [ formal_port_clause ] generic_clause ::= generic ( generic_list ) ; generic_list ::= generic_interface_list port_clause ::= port ( port_list ) ; port_list ::= port_interface_list The entity declarative part may be used to declare items which are to be used in the implementation of the entity. Usually such declarations will be included in the implementation itself, so they are only mentioned here for completeness. Also, the optional statements in the entity declaration may be used to define some special behavior for monitoring operation of the entity. The entity header is the most important part of the entity declaration. It may include specification of generic constants, which can be used to control the structure and behaviour of the entity, and ports, which channel information into and out of the entity. The actual value for each generic constant is passed in when the entity is used as a component in a design. The entity ports are also specified using an interface list, but the items in the list must all be of class signal. This is a new kind of interface item not previously discussed. The syntax is: interface_signal_declaration ::= [ signal ] identifier_list : [ mode ] subtype_indication [ bus ] [ := static_expression ]

ARCHITECTURE DECLARATION
Once an entity has had its interface specified in an entity declaration, one or more implementations of the entity can be described in architecturebodies. Each architecture body can describe a different view of the entity. An architecture body is declared using the syntax:

10

architecture_body ::= architecture identifier of entity_name is architecture_declarative_part begin architecture_statement_part end [ architecture_simple_name ] ; architecture_declarative_part ::= { block_declarative_item } architecture_statement_part ::= { concurrent_statement } block_declarative_item ::= subprogram_declaration | subprogram_body | type_declaration | subtype_declaration | constant_declaration | signal_declaration | alias_declaration | component_declaration | configuration_specification | use_clause concurrent_statement ::= block_statement | component_instantiation_statement The declarations in the architecture body define items that will be used to construct the design description. In particular, signals and components may be declared here and used to construct a structural description in terms of component instances.

SIGNAL DECLARATION
Signals are used to connect submodules in a design. They are declared using the syntax: signal_declaration ::= signal identifier_list : subtype_indication [ signal_kind ] [ := expression ] ; signal_kind ::= register | bus

COMPONENT DECLARATION
An architecture body can also make use of other entities described separately and placed in design libraries. In order to do this, the architecture must declare a component, which can be thought of as a template defining a virtual

11

design entity, to be instantiated within the architecture. Later, a configuration specification can be used to specify a matching library entity to use. The syntax of a component declaration is: component_declaration ::= component identifier [ local_generic_clause ] [ local_port_clause ] end component ; Some examples of component declarations: component nand3 generic (Tpd : Time := 1 ns); port (a, b, c : in logic_level; y : out logic_level); end component; component read_only_memory generic (data_bits, addr_bits : positive); port (en : in bit; addr : in bit_vector(depth1 downto 0); data : out bit_vector(width1 downto 0) ); end component;

COMPONENT INSTANTIATION
A component defined in an architecture may be instantiated using the syntax: component_instantiation_statement ::= instantiation_label : component_name [ generic_map_aspect ] [ port_map_aspect ] ; This indicates that the architecture contains an instance of the named component, with actual values specified for generic constants, and with the component ports connected to actual signals or entity ports.

12

DESIGN DESCRIPTION BEHAVIOUR

There are basically three different styles of modeling in VHDL. They are as follows: STRUCTURAL STYLE: In the structural style of modeling, an entity is described as a set of interconnected components. Here one whole project is divided into different modules as components which make the complex program easy. Eg. Architecture ha of ha is component XOR2 port (X, Y: in BIT; Z: out BIT); end component; component AND2 port (L, M: in BIT; N: out BIT);

13

end component; begin X1: XOR2 port map (A, B, SUM); A1: AND2 port map (A, B, CARRY); end ha; DATAFLOW STYLE: In this modeling style, the flow of data through the entity is expressed by using concurrent signal assignment statements. The structure of the entity is not explicitly specified in this modeling style, but it can be implicitly deduced. Eg. architecture ha of ha is begin sum <= a xor b; carry <= a and b; end ha; BEHAVIOURAL STYLE: The behavioral style of modeling specifies the behavior of an entity as a set of statements that are executed sequentially in the specified order. This set of sequential statements, that are specified inside a process statement, do not explicitly specify the structure of the entity but merely specifies its functionality. A process statement is a concurrent statement that can appear within an architecture body. Eg. architecture demux4 of demux4 is begin p0 : process (din,sel) begin if (sel="00") then dout <= (din & "000"); elsif (sel="01") then dout <= ('0' & din & "00"); elsif (sel="10") then dout <=("00" & din & '0'); else dout <= ("000" & din); end if; end process; end demux4;

14

FPGA
A field-programmable gate array (FPGA) is an integrated circuit designed to be configured by the customer or designer after manufacturinghence "field-programmable". The FPGA configuration is generally specified using a hardware description language (HDL), similar to that used for an application-specific integrated circuit (ASIC) (circuit diagrams were previously used to specify the configuration, as they were for ASICs, but this is increasingly rare). FPGAs can be used to implement any logical function that an ASIC could perform. The ability to update the functionality after shipping, partial re-configuration of the portion of the design[1] and the low non-recurring engineering costs relative to an ASIC design (notwithstanding the generally higher unit cost), offer advantages for many applications. FPGAs contain programmable logic components called "logic blocks", and a hierarchy of reconfigurable interconnects that allow the blocks to be "wired together"somewhat like many (changeable) logic gates that can be interwired in (many) different configurations. Logic blocks can be configured to

15

perform complex combinational functions, or merely simple logic gates like AND and XOR. In most FPGAs, the logic blocks also include memory elements, which may be simple flip-flops or more complete blocks of memory. FPGAs can be characterized by the following items: High production cost Low design density - Programmable fabric adds significant overhead No NRE and Re-Spin cost Low development effort - Low dead-time - simplified timing - No test vectors - Relaxed verification - Physical design is hands-off

FPGA TECHNOLOGY IN DETAIL

FPGAs are chips, which are programmed by the customer to perform the desired functionality. The chips may be programmed either Once: Antifuse technology, e.g. devices manufactured by Quick logic Several times: Flash based e.g. Devices manufactures by Actel Dynamically: SRAM based e.g. Devices manufactured by Actel, Altera, Atmel, Cypress, Lucent, Xilinx Each technology has its own advantages, which shall be discussed only very briefly: Antifuse FPGAs: - Devices are configured by burning a set of fuses. Once the chip is configured, it can- not be altered any more. - Bug fixes and updates possible for new PCBs, but hardly for already manufactured boards. - ASIC replacement for small volumes. Flash FPGAs

16

- Devices may be re-programmed several thousand times and are nonvolatile, i.e. keep their configuration after power-off - With marginal additional effort, the chips may be updated in the field - Expensive - Re-configuration takes several seconds The CLBs form the central logic structure with easy access to all support and routing structures. The IOBs are located around all the logic and memory elements for easy and quick routing of signals on and off the chip. SRAM FPGAs - Currently the dominating technology - Unlimited re-programming - Additional circuitry is required to load the configuration into the FPGA after power- on - Re-configuration is very fast, some devices allow even partial reconfiguration during operation. - Allows new approaches and applications

GENERAL OVERVIEW
There are several families of FPGAs available from different semiconductor companies. These device families slightly differ in their architecture and feature set, however most of them follow a common approach: A regular, flexible, programmable architecture of Configurable Logic Blocks (CLBs), surrounded by a perimeter of program. Values stored in static memory cells control all the configurable logic elements and interconnect resources. These values load into the memory cells on power-up, and can reload if necessary to change the function of the device.

CONFIGURABLE LOGIC BLOCKS

The basic building block of the CLBs is the logic cell (LC). An LC includes a 4-input function generator carry logic, and a storage element. The output from the function generator in each LC drives both the CLB output and the D input of the flip-flop. Each CLB contains four LCs, organized in two similar slices; a single slice is shown in figure below.

17

In addition to the four basic LCs, the CLBs contain logic that combines function generators to provide functions of five or six inputs. Consequently, when estimating the number of system gates provided by a given device, each CLB counts as 4.5

STORAGE ELEMENTS
The storage elements in the Spartan-II slice can be configured either as edgetriggered D-type flip-flops or as level-sensitive latches. The D in- puts can be driven either by the function generators within the slice or directly from slice inputs, bypassing the function generators

18

Slice Configuration In addition to Clock and Clock Enable signals, each slice has synchronous set and reset signals (SR and BY). SR forces a storage element into the initialization state specified for it in the configuration by forcing it into the opposite state. Alternatively, these signals may be configured to operate asynchronously. All of the control signals are independently invertible, and are shared by the two flip-flops within the slice.

ELECTRONIC DESIGN WITH FPGAs

In most digital designs, the circuitry can be classified by the following categories:

19

STANDARD PRODUCTS - These products provide a functionality which is not associated with a specific application area but common to a broad range of devices. Typical parts in this category are processors and memories. APPLICATION SPECIFIC STANDARD PRODUCTS or ASSPs These products provide functionality which is not associated with a specific implementation, but common to an application area. Typical parts in this category are MPEG decoders. CUSTOM LOGIC - This logic is associated with a specific application and is the essence of what distincts one product from another. Often this is glue logic, connecting standard products or ASSPs with each other. There are several options on how to implement custom logic, FPGAs being one amongst them.

Introduction to Xilinx

20

Xilinx is a Synthesis Tool which converts Schematic/HDL Design Entry into functionally equivalent logic gates on Xilinx FPGA, with optimized speed & area. So, after specifying behavioral description for HDL, the designer merely has to select the Library and specify Optimization Criteria; and Xilinx Synthesis Tool determines the net list to meet the specification; which is then converted into Bit-File to be loaded onto FPGA PROM . Also, Xilinx Tool generates Post-Process Simulation Model after every Implementation Step, which is used to functionally verify generated net list after processes, like Map, Place & Route. Some more Features of Xilinx: Allows Mixed Mode HDL Design Entry Xilinx ISE allows integration with other Synthesis Engine from Mentor Graphics/Exemplar, Synopsys and Simplicity. (XST is proprietary Synthesis Tool of Xilinx.)

Xilinx flow overview

21

1). Add HDL/Schematic Design Entry to ISE Project, targeted for a particular Xilinx Product Family. 2). Design Synthesis: Converts HDL into equivalent boolean equations; according to which logic gates are then correspondingly packed into Logic Cells, LUTs & FFs from Xilinx UNISIM Library 3). Design Implementation: I. Translate: Translate step checks the design and ensures that netlist is consistent with chosen architecture. Translate also checks Userdefined Constraint file, for any inconsistencies. II. Map: Calculates & Allocates Physical Combinational Logic Blocks (CLB) & Input Output Block (IOB) Components in Targeted Device, to Logic Element symbols in Netlist that is generated during Translation Process. III. Place & Route (PAR): Places CLBs into logical position and utilizes the routing resources on target device, to connect logic cells on Xilinx Product such that desired Timing Specification are met. 4). Bit-File Generation: Creates Bit-Stream file containing Configuration Data for Target FPGA Device

Creating a new ise project in Xilinx

22

1. From Project Navigator, select File > New Project. (Specify the Project Name, Project Location; and select Top Level Source Type as HDL) 2. Click Next & describe Device Properties in New Project Wizard. (Based on the Selection Design Consideration mentioned earlier, select Xilinx Product Family/ Device Type/ Package Type & Speed Grade) 3. Click Next & then click Add Source tab in New Project Wizard, to browse and add existing HDL source files to current ISE Project

Synthesizing design

23

During synthesis, HDL files are translated into gates and optimized for the target architecture. Thus, XST Synthesis tool uses designs HDL code and generates a supported net list type (NGC) for Xilinx implementation tools, by performing following general steps : Analyze / Check Syntax of the Source Code. Compile: Translates and optimizes the HDL code into a set of components that the synthesis tool can recognize. Map: Translates the components from the compile stage into the target technologys primitive components from UNISIM Library. Steps to Synthesize HDL Design : Select top-level HDL design in the Sources window. To set Synthesis options, right-click Synthesize - XST in the Processes window; select Properties to display the Process Properties dialog box. With the top-level source file selected, right-click Synthesize - XST in the Processes window & select Run option. Synthesis Report file is stored with extension <project_name>.syr in ISE Project Directory.

Synthesis options

24

Synthesis options enables designer to modify the behavior of the synthesis tool, to make optimizations according to the needs of design. Optimization Effort: constraint allows choosing synthesis optimization level as Normal or High optimization. Optimization Goal: constraint allows choosing synthesis optimization strategy as Speed or Area. For e.g. In Shift Add Multiplier implementation, when Optimization Goal is selected as Area, though Number of Slices and LUTs utilized reduces by 1%, but the maximum frequency for the design also reduces by 8MHz, in comparison to Synthesis done with default Optimization Goal (i.e. Speed). Use Synthesis Constraint File: option allows including (or) excluding .xcf Constraint File, during synthesis process. Keep Hierarchy: is a synthesis and implementation constraint. If hierarchy is maintained during Synthesis, the Implementation tools will use this constraint to preserve the hierarchy throughout the implementation process and allow a simulation net list to be created with the desired hierarchy. Though preserving the hierarchy gives the advantage of fast processing; but, merging the hierarchy blocks improves the fitting results (i.e. fewer device macro cells & better frequency). Global Optimization Goal: allows optimizing speed in different regions (register to register, in pad to register, register to out pad, and in pad to out pad) of the design. Write Timing Constraints: enables or disables propagation of timing constraints to the NGC file, which will be used during place and route, as well as synthesis optimization. Slice Utilization Ratio: defines the area size in absolute number or percent of total number of slices that XST must not exceed, during timing optimization.

Specifying user constraints

Need for Setting Constraints:

25

For Design to meet desired Area/Frequency Specification on FPGA, it is required to tell the Implementation Tool for what performance it should optimize the design implementation processes like Map, Place & Route. Thus, User Defined Constraints allows specifying desired Clock period/ Pad to Setup/Clock to Pad delay & assign areas to hierarchical blocks of logic. Physical User Constraint also allows allocating HDL designs I/O signals to specific package pins. Adding Constraints to Design: User can specify Constraints for ISE Design Project , either through GUI by double-clicking on following options available within User Constraints label in Processes Window:(i) Create Timing Constraints (ii) Assign Package Pins (iii) Create Area Constraints (or) the User can specify constraints in .ucf file, through any text editor. While opening Constraint Editor Window, Translate step runs automatically because implementation stage must see the net list before it can offer the user the chance to constraint sections of design.

TIMING CONSTRAINTS

26

The Global Clock Domain and Input/Output Ports tab of Create Timing Constraints window automatically displays all clock nets in the design, and enables designer to define the associated Period, Pad to Setup, and Clock to Pad values.

Clock Period: constraint ensures that the internal paths starting and ending at synchronous points (Flip-Flops /RAM / Latches ) have logic delay less than Maximum Delay allowed in the design specification. Pad to Setup: is the path starting at Input Port of the design and ending at an input to a flip-flop/latch/RAMwherever there is a setup time against a control signal. Clock to Pad: is the path starting at the Q output of a flip-flop or latch and ending at Output Port of the design. It includes the Clock-to-Q delay of the flip-flop and path delay from that flip-flop to FPGA output. The clock-to-pad path time is the maximum time required for the data to leave the source flip-flop, travel through logic and routing, and leave the chip. Pad to Pad: constraint constrains combinatorial asynchronous paths having started and endpoints as Pads of the design.

ASSIGNING PACKAGE PINS

27

Package Pins can be assigned to Designs Input/Output Ports through LOC constraint in .ucf file or through Assign Package Pin GUI Window.

TRANSLATING DESIGN

28

During translation, the NGD Build program performs the following functions: Converts input design net lists and writes results to a single merged NGD net list. The merged net list describes the logic in the design as well as any location and timing constraints. Performs timing specification and logical design rule checks. Adds constraints from the User Constraints File (UCF) to the merged net list.

Steps to Translate the Design: Translate Process gets automatically executed while opening Constraint Editor GUI Window (or) User can right-click Translate option in Processes Window and select Run option. To set Translate Properties, right-click Translate in the Processes window; select Properties to display the Process Properties dialog box. Synthesis Report file is stored with extension <project_name>.bld in ISE Project Directory. Translate Process File Types: Translate Process uses following files as input:

29

NGC net list file from Synthesis Process. UCF constraint files containing timing and layout constraints.

Translate Process creates following files as output: NGD file, containing logical description of the design, expressed in terms of lower level Xilinx Primitives, with constraint applied to design. BLD Report file shows following error in design or UCF file: Missing or untranslatable hierarchical blocks Invalid or incomplete timing constraints Output contention, load less output, and source less inputs.

MAPPING THE DESIGN

30

MAP Process Functionality: Allocates CLB and IOB resources for all basic logic elements in the design. Processes all location and timing constraints, performs target device optimizations, and runs a design rule check on the resulting mapped net list.

Steps to Map the Design: To set Map Process Properties, right-click Map in the Processes window; select Properties to display the Process Properties dialog box. Right-click Map label in Processes Window and select Run option. Synthesis Report file is stored with extension <project_name>.mrp in ISE Project Directory.

Map Process File Types: MAP Process uses NGD file, created during Translate Process, as Input file. MAP Process creates following files as output:

31

NCD (Native Circuit Description) file containing physical description of design in terms of the components in the target Xilinx device. PCF (Physical Constraints File) contains constraints specified during design entry expressed in terms of physical elements. MRP (MAP Report File) confirms the resources used within the device; and describes trimmed and merged logic. Detailed Report also describes exactly where each portion of the design is located in the device.

PLACING AND ROUTING

Place and Route Process Functionality:

32

During placement, PAR places components into sites based on factors such as constraints, the length of connections, and the available routing resources. After placing the design, the router performs a converging procedure for a solution that routes the design to completion and meets timing constraints.

Steps to Place and Route the Design: To execute PAR in the Processes tab, right-click Place & Route under the Implement Design process group, and select Run option. To set Place and Route Properties, right-click Place & Route in the Processes window; select Properties to display the Process Properties dialog box.

PAR Process File Types: PAR Process uses Mapped Design (NCD) File and Physical Constraint (PCF) file created during MAP Process, as Input File.

33

PAR Process creates following files as output: - Placed and Routed NCD Design File - PAR Report File, including summary information of all placements and routing iterations.

GENERATING Bitmap PROGRAMMING FILE

Purpose of Generating Programming File:

34

After design has been routed, it is required to generate the binary data which can be used to program the physical device. The Programming BIT File for FPGA Device should contain all the configuration information, defining the internal logic and interconnections of the FPGA, plus device-specific information from other files associated with the target device. The binary data in the BIT file can then be downloaded into the FPGA's memory cells or it can be used to create a PROM file. Step to Generate Programming File: To create Bitmap file, right-click Generate Programming File label in Processes window & click Run option.

BitGen Process File Types: Xilinx uses BitGen process for generating Bitstream program. BitGen takes a fully routed NCD file, generated during PAR process as its input, and produces a configuration bitstream - a binary file with a .bit extension.

PROJECT
AIM

35

The aim of the project is to design the internal architecture of the metro train using VHDL and implement the same in the FPGA kit.

THEORY
When we travel in a metro train in any of the metro cities, we usually notice the changes in the LED lights while the metro changes from one station to another. So, the main aim of this project is to make this internal architecture of the metro. In this project, I used an FPGA kit for designing purpose and the programming was done on Xilinx software. FIELD-PROGRAMMABLE GATE ARRAY (FPGA) is an integrated circuit designed to be configured by the customer or designer after manufacturinghence "field-programmable". The FPGA configuration is generally specified using a hardware description language (HDL), similar to that used for an application-specific integrated circuit (ASIC) (circuit diagrams were previously used to specify the configuration, as they were for ASICs, but this is increasingly rare). FPGAs can be used to implement any logical function that an ASIC could perform. The ability to update the functionality after shipping, partial re-configuration of the portion of the design[1] and the low non-recurring engineering costs relative to an ASIC design (notwithstanding the generally higher unit cost), offer advantages for many applications. XILINX is a supplier of programmable logic devices. It is known for inventing the field programmable gate array (FPGA) and as the first semiconductor company with a fabless manufacturing model.[1][2][3] Founded in Silicon Valley in 1984, the company is headquartered in San Jose, California, U.S.A.; Dublin, Ireland; Singapore; and Tokyo, Japan. The company has corporate offices throughout North America, Asia and Europe

DESIGN
Our task is to implement the internal architecture of the metro train. In order to implement the design for the metro train project and write the programs for the same, we have to divide our work in 8 parts: STATION PACKAGE

36

First of all we will define a package in which all the stations will be mentioned. Suppose we take 8 stations namely: Noida, Delhi, Faridabad, Palwal, Mathura, Agra, Gwalior, and Jhansi. PROGRAM
library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; package station is type station_name is (noida,delhi,faridabad,palwal,mathura,agra,gwalior,jhansi,station_not_available,train_is_ru nning); end station;

COUNTER The second step is to give the direction. So, we will design a controller which will control the direction of the train. PROGRAM
library IEEE; use IEEE.STD_LOGIC_1164.all;

37 use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; entity count is generic (length :integer); port( start : in STD_LOGIC; clk : in STD_LOGIC; direction : out std_logic ; station_value : out integer range 0 to length-1); end count; architecture count_arc of count is begin p0 : process (start,clk) variable m : integer range 0 to length-1 := 0; variable dir : std_logic := '0'; begin if (m=0) then dir :='1'; elsif (m=length-1) then dir := '0'; end if; if (start='1') then if (dir ='1') then if (rising_edge(clk)) then m := m + 1; end if; elsif (dir='0') then if (rising_edge(clk)) then m := m - 1; end if; end if; end if; station_value <= m; direction <= dir; end process; end count_arc;

OUTPUT PORT MODULE The third step for our design will be to assign the current station name and the next station name to each point of the direction, i.e. we will decide the location by giving the current station name and the next station name. PROGRAM
library IEEE;

38 use IEEE.STD_LOGIC_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; use work.station.all; entity output is generic (length :integer ); port( location : in integer range 0 to length; direction : in std_logic ; current_station : out station_name; next_station : out station_name); end output; architecture output_arc of output is begin p0 : process (location,direction) variable cs,ns : station_name; begin case location is when 0 => cs := noida; ns := delhi; when 1 => cs := delhi; if (direction='1') then ns := faridabad; else ns := noida; end if; when 2 => cs := faridabad; if (direction='1') then ns := palwal; else ns := delhi; end if; when 3 => cs := palwal; if (direction ='1') then ns := mathura; else ns := faridabad; end if; when 4 => cs := mathura; if (direction ='1') then ns := agra; else ns := palwal; end if; when 5 => cs := agra; if (direction ='1') then ns := gwalior; else ns := mathura; end if; when 6 => cs := gwalior;

39 if (direction ='1') then ns := jhansi; else ns := agra; end if; when 7 => cs := jhansi; ns := gwalior; when others => cs := station_not_available; end case; current_station <= cs; next_station <=ns; end process; end output_arc;

TRAVELLING TIME OF METRO The fourth step will assign time duration for each station. That means we will assign delay after each current station. PROGRAM
library IEEE; use IEEE.STD_LOGIC_1164.all; use ieee.std_logic_arith.all;

40 use ieee.std_logic_unsigned.all; use ieee.numeric_std.all; entity traverltime is generic (length : integer ); port( direction : in STD_LOGIC; svalue : in integer range 0 to length-1; dout : out integer); end traverltime; architecture time_arc of traverltime is begin p0 : process (direction,svalue) begin if (direction='1') then case svalue is when 0 => dout <= 20; when 1 => dout <= 25; when 2 => dout <= 30; when 3 => dout <= 40; when 4 => dout <= 18; when 5 => dout <= 30; when 6 => dout <= 15; when others => dout <= 15; end case; else case svalue is when 7 => dout <= 15; when 6 => dout <= 30; when 5 => dout <= 18; when 4 => dout <= 40; when 3 => dout <= 30; when 2 => dout <= 25; when 1 => dout <= 20; when others => dout <= 20; end case; end if; end process; end time_arc;

CLOCK SIGNAL FOR COUNTER Now we will call the travel time component that was made in the previous step. This is done in order to make the clock signal which will run in the final step. PROGRAM
library IEEE; use IEEE.STD_LOGIC_1164.all;

41 use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; use ieee.numeric_std.all; entity counterclk is generic (length : integer ); port( clkin : in STD_LOGIC; direction : in std_logic ; svalue : in integer range 0 to length ; motor_drive : out std_logic ; tpout : out integer; clkout : out STD_LOGIC); end counterclk; architecture counterclk_arc of counterclk is signal tp : integer; component traverltime is generic (length : integer ); port( direction : in STD_LOGIC; svalue : in integer range 0 to length; dout : out integer); end component ; begin p0 : traverltime generic map (length=>length) port map (direction=>direction,svalue=>svalue,dout=>tp); tpout <= tp; p1 : process (clkin,tp) variable m : integer := 0; variable mdrive : std_logic := '1'; variable countclk : std_logic; begin motor_drive <= mdrive; clkout <= countclk; if (rising_edge(clkin)) then m := m + 1; end if; if (m=tp) then m := 0; end if; if (m=0) then countclk := '1'; end if; if (m=tp/2) then countclk :='0'; end if; if (m=4) then mdrive := '0';

42 elsif (m=0) then mdrive := '1'; end if; end process; end counterclk_arc;

TEST ASSEMBLER Now we will call all the components that are already made in the above steps. All the parts are assembled in order to run the internal architecture of the metro train. PROGRAM
library IEEE; use IEEE.STD_LOGIC_1164.all; use ieee.std_logic_arith.all;

43 use ieee.std_logic_unsigned.all; use ieee.numeric_std.all; use work.station.all; entity testassembly is generic (length : integer := 8); port( clkin : in STD_LOGIC; m_drive : out std_logic ; cstation : out station_name ; nstation : out station_name); end testassembly; architecture testassembly_arc of testassembly is component count is generic (length :integer ); port( start : in STD_LOGIC; clk : in STD_LOGIC; direction : out std_logic ; station_value : out integer range 0 to length-1); end component ; component output is generic (length :integer); port( location : in integer range 0 to length; direction : in std_logic ; current_station : out station_name; next_station : out station_name); end component ; component counterclk is generic (length : integer); port( clkin : in STD_LOGIC; direction : in std_logic ; svalue : in integer range 0 to length ; motor_drive : out std_logic ; tpout : out integer; clkout : out STD_LOGIC); end component ; signal direction,countclk : std_logic ; signal svalue : integer range 0 to length; signal motor_drive : std_logic ; signal current_station_display : station_name; signal tp : integer; begin p0 : counterclk generic map (length => length) port map (tpout=>tp,clkin=>clkin,direction=>direction,svalue=>svalue,motor_drive=>motor_ drive,clkout=>countclk);

44 p1 : output generic map (length => length) port map (location=>svalue,direction=>direction,current_station=>current_station_display,ne xt_station=>nstation); p2 : count generic map (length => length) port map (start=>'1',clk=>countclk,direction=>direction,station_value=>svalue); m_drive <= not motor_drive; p4 : process (motor_drive,current_station_display) begin if (motor_drive='1') then cstation <= current_station_display; else cstation <= train_is_running; end if; end process; end testassembly_arc;

IMPLEMENTING ON THE FPGA

After the programming was done, the final step was to implement the program on the FPGA kit. The program was translated, mapped, placed and routed using the Xilinx software. And then the internal architecture of the metro train was done.

45

BIBLIOGRAPHY www. google.com

VHDL programming by Douglas Perry

46

A VHDL Primer by Jayaram Bhaasker Circuit Design with VHDL by Volnei A. Pedroni