A Hardware Engineer’s Guide toVHDL

(1)

A Hardware Engineer’s Guide to VHDL

This page and its accompanying links address the needs of those users who are new to VHDL. This VHDL tutorial assumes no prior knowledge of HDLs. The pre-requisites are hardware design

experience, more than a passing acquaintance with programming languages and a willingness to learn.

VHDL is a programming language. However, throughout this tutorial we aim to map code snippets directly onto the equivalent hardware. In addition, we will encourage you to “think code” so that at the end of the tutorial you are as comfortable with VHDL code fragments as you are with schematics.

Note that we are building this tutorial incrementally with monthly releases of new topics which can be accessed from this page. This corner of the Web is split into two sections, the first providing you with a VHDL overview, the second gives you some real examples of VHDL code use. In the VHDL

Backgrounder, we aim to provide you with a general appreciation of what VHDL is, and how it is used in the design process. In the Designing Hardware using VHDL section, we’re going to

familiarise you with the main features of VHDL, particularly design entities. This will let you see how to design simple circuit elements in VHDL.

If you want to go beyond the material we present here, call Doulos for a free copy of VHDL PaceMaker Entry Edition, surf the rest of our Web site and book yourself onto a Doulos training course. It’s the best way to learn and it’s also the most enjoyable way to learn VHDL - learn VHDL from the VHDL experts!

VHDL Backgrounder What is VHDL?

●

A Brief History of VHDL

●

Levels of Abstraction

●

Scope of VHDL

●

Design Flow using VHDL

●

Benefits of using VHDL

●

Designing Hardware using VHDL An Example Design Entity

●

Internal Signals

●

Components and Port Maps

●

Plugging Chips into Sockets

●

Configurations: Part 1

●

Configurations: Part 2

●

Order of Analysis

●

Vectored Ports and Signals

●

Test Benches: Part One

●

Test Benches: Part Two

●

Doulos VHDL Training Verilog Training : A Hardware Engineer’s Guide to VHDL

http://www.doulos.co.uk/hegv/index.htm (1 of 2) [12/12/2000 13:05:06]

(2)

Summary, so far...

●

Comparing Components with Processes

●

Processes

●

RTL Coding

●

If statement

●

Synthesizing Latches

●

VHDL FAQ

Doulos Training Courses

Doulos Home Page

This page was last updated 2^nd June 1999

We welcome your e-mail comments. Please contact us at: webmaster@doulos.co.uk

Doulos VHDL Training Verilog Training : A Hardware Engineer’s Guide to VHDL

http://www.doulos.co.uk/hegv/index.htm (2 of 2) [12/12/2000 13:05:06]

(3)

What is VHDL?

VHDL is the VHSIC Hardware Description Language. VHSIC is an abbreviation for Very High Speed Integrated Circuit. It can describe the behaviour and structure of electronic systems, but is particularly suited as a language to describe the structure and behaviour of digital electronic hardware designs, such as ASICs and FPGAs as well as conventional digital circuits.

VHDL is a notation, and is precisely and completely defined by the Language Reference Manual ( LRM ). This sets VHDL apart from other hardware description languages, which are to some extent defined in an ad hoc way by the behaviour of tools that use them. VHDL is an international standard, regulated by the IEEE. The definition of the language is non-proprietary.

VHDL is not an information model, a database schema, a simulator, a toolset or a methodology!

However, a methodology and a toolset are essential for the effective use of VHDL.

Simulation and synthesis are the two main kinds of tools which operate on the VHDL language. The Language Reference Manual does not define a simulator, but unambiguously defines what each simulator must do with each part of the language.

VHDL does not constrain the user to one style of description. VHDL allows designs to be described using any methodology — top down, bottom up or middle out! VHDL can be used to describe

hardware at the gate level or in a more abstract way. Successful high level design requires a language, a tool set and a suitable methodology. VHDL is the language, you choose the tools, and the

methodology... well, I guess that’s where Doulos come in to the equation!

Doulos VHDL Training : What is VHDL?

http://www.doulos.co.uk/hegv/whatis.htm (1 of 2) [12/12/2000 13:05:25]

(4)

VHDL FAQ

Return to Hardware Engineer’s Guide Contents

Doulos Home Page

This page was last updated 15^th January 1999

Doulos VHDL Training : What is VHDL?

http://www.doulos.co.uk/hegv/whatis.htm (2 of 2) [12/12/2000 13:05:25]

(5)

A Brief History of VHDL

The Requirement

The development of VHDL was initiated in 1981 by the United States Department of Defence to address the hardware life cycle crisis. The cost of reprocuring electronic hardware as technologies became obsolete was reaching crisis point, because the function of the parts was not adequately

documented, and the various components making up a system were individually verified using a wide range of different and incompatible simulation languages and tools. The requirement was for a

language with a wide range of descriptive capability that would work the same on any simulator and was independent of technology or design methodology.

Standardization

The standardization process for VHDL was unique in that the participation and feedback from

industry was sought at an early stage. A baseline language (version 7.2) was published 2 years before the standard so that tool development could begin in earnest in advance of the standard. All rights to the language definition were given away by the DoD to the IEEE in order to encourage industry acceptance and investment.

ASIC Mandate

DoD Mil Std 454 mandates the supply of a comprehensive VHDL description with every ASIC delivered to the DoD. The best way to provide the required level of description is to use VHDL throughout the design process.

VHDL '93

As an IEEE standard, VHDL must undergo a review process every 5 years (or sooner) to ensure its ongoing relevance to the industry. The first such revision was completed in September 1993, and tools conforming to VHDL '93 are now available. VHDL’98? Hmmm...

Summary: History of VHDL

1981 - Initiated by US DoD to address hardware life-cycle crisis

1983-85 - Development of baseline language by Intermetrics, IBM and TI 1986 - All rights transferred to IEEE

1987 - Publication of IEEE Standard

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

Doulos VHDL Training : A Brief History of VHDL

http://www.doulos.co.uk/hegv/history.htm (1 of 2) [12/12/2000 13:05:42]

(6)

Doulos Home Page

Doulos VHDL Training : A Brief History of VHDL

http://www.doulos.co.uk/hegv/history.htm (2 of 2) [12/12/2000 13:05:42]

(7)

Levels of Abstraction

VHDL can be used to describe electronic hardware at many different levels of abstraction. When considering the application of VHDL to FPGA/ASIC design, it is helpful to identify and understand the three levels of abstraction shown opposite - algorithm, register transfer level (RTL), and gate level. Algorithms are unsynthesizable, RTL is the input to synthesis, gate level is the output from synthesis. The difference between these levels of abstraction can be understood in terms of timing.

Levels of abstraction in the context of their time domain

Algorithm

A pure algorithm consists of a set of instructions that are executed in sequence to perform some task.

A pure algorithm has neither a clock nor detailed delays. Some aspects of timing can be inferred from the partial ordering of operations within the algorithm. Some synthesis tools (behavioural synthesis) are available that can take algorithmic VHDL code as input. However, even in the case of such tools, the VHDL input may have to be constrained in some artificial way, perhaps through the presence of an ‘algorithm’ clock — operations in the VHDL code can then be synchronized to this clock.

RTL

An RTL description has an explicit clock. All operations are scheduled to occur in specific clock cycles, but there are no detailed delays below the cycle level. Commercially available synthesis tools do allow some freedom in this respect. A single global clock is not required but may be preferred. In addition, retiming is a feature that allows operations to be re-scheduled across clock cycles, though not to the degree permitted in behavioural synthesis tools.

Doulos VHDL Training : Levels of Abstraction

http://www.doulos.co.uk/hegv/levels_abstraction.htm (1 of 2) [12/12/2000 13:06:02]

(8)

Gates

A gate level description consists of a network of gates and registers instanced from a technology library, which contains technology-specific delay information for each gate.

Writing VHDL for Synthesis

In the diagram above, the RTL level of abstraction is highlighted. This is the ideal level of abstraction at which to design hardware given the state of the art of today’s synthesis tools. The gate level is too low a level for describing hardware - remember we’re trying to move away from the implementation concerns of hardware design, we want to abstract to the specification level - what the hardware does, not how it does it. Conversely, the algorithmic level is too high a level, most commercially available synthesis tools cannot produce hardware from a description at this level.

In the future, as synthesis technology progresses, we will one day view the RTL level of abstraction as the “dirty” way of writing VHDL for hardware and writing algorithmic (often called behavioural) VHDL will be the norm.

Until then, VHDL coding at RTL for input to a synthesis tool will give the best results. Getting the best results from your synthesizable RTL VHDL is a key topic of the Doulos Comprehensive VHDL and Advanced VHDL Techniques training courses. The latter also covers behavioural synthesis techniques.

Doulos Home Page

Doulos VHDL Training : Levels of Abstraction

http://www.doulos.co.uk/hegv/levels_abstraction.htm (2 of 2) [12/12/2000 13:06:02]

(9)

Scope of VHDL

VHDL is suited to the specification, design and description of digital electronic hardware.

System level

VHDL is not ideally suited for abstract system-level simulation, prior to the hardware-software split.

Simulation at this level is usually stochastic, and is concerned with modelling performance, throughput, queueing and statistical distributions. VHDL has been used in this area with some success, but is best suited to functional and not stochastic simulation.

Digital

VHDL is suitable for use today in the digital hardware design process, from specification through high-level functional simulation, manual design and logic synthesis down to gate-level simulation.

VHDL tools usually provide an integrated design environment in this area.

VHDL is not suited for specialized implementation-level design verification tools such as analog simulation, switch level simulation and worst case timing simulation. VHDL can be used to simulate gate level fanout loading effects providing coding styles are adhered to and delay calculation tools are available. The standardization effort named VITAL (VHDL Initiative Toward ASIC Libraries) is active in this area, and is now bearing fruit in that simulation vendors have built-in VITAL support.

More importantly, many ASIC vendors have VITAL-compliant libraries, though not all are allowing VITAL-based sign-off — not yet anyway.

Analogue

Because of VHDL's flexibility as a programming language, it has been stretched to handle analog and switch level simulation in limited cases. However, look out for future standards in the area of analog VHDL. Check out our Model of the Month from April 1996 for an example of analogue modeling in VHDL.

Design process

The diagram below shows a very simplified view of the electronic system design process

incorporating VHDL. The central portion of the diagram shows the parts of the design process which are most impacted by VHDL.

Doulos VHDL Training : Scope of VHDL

http://www.doulos.co.uk/hegv/scopevhd.htm (1 of 2) [12/12/2000 13:06:39]

(10)

VHDL FAQ

Doulos Home Page

Doulos VHDL Training : Scope of VHDL

http://www.doulos.co.uk/hegv/scopevhd.htm (2 of 2) [12/12/2000 13:06:39]

(11)

Design Flow using VHDL

The diagram below summarizes the high level design flow for an ASIC (ie. gate array, standard cell) or FPGA. In a practical design situation, each step described in the following sections may be split into several smaller steps, and parts of the design flow will be iterated as errors are uncovered.

System-level Verification

As a first step, VHDL may be used to model and simulate aspects of the complete system containing one or more devices. This may be a fully functional description of the system allowing the

FPGA/ASIC specification to be validated prior to commencing detailed design. Alternatively, this may be a partial description that abstracts certain properties of the system, such as a performance model to detect system performance bottle-necks.

RTL design and testbench creation

Once the overall system architecture and partitioning is stable, the detailed design of each

FPGA/ASIC can commence. This starts by capturing the design in VHDL at the register transfer level, and capturing a set of test cases in VHDL. These two tasks are complementary, and are

sometimes performed by different design teams in isolation to ensure that the specification is correctly interpreted. The RTL VHDL should be synthesizable if automatic logic synthesis is to be used. Test case generation is a major task that requires a disciplined approach and much engineering ingenuity:

the quality of the final FPGA/ASIC depends on the coverage of these test cases.

RTL verification

The RTL VHDL is then simulated to validate the functionality against the specification. RTL

simulation is usually one or two orders of magnitude faster than gate level simulation, and experience has shown that this speed-up is best exploited by doing more simulation, not spending less time on simulation.

In practice it is common to spend 70-80% of the design cycle writing and simulating VHDL at and above the register transfer level, and 20-30% of the time synthesizing and verifying the gates.

Look-ahead Synthesis

Although some exploratory synthesis will be done early on in the design process, to provide accurate speed and area data to aid in the evaluation of architectural decisions and to check the engineer's understanding of how the VHDL will be synthesized, the main synthesis production run is deferred until functional simulation is complete. It is pointless to invest a lot of time and effort in synthesis until the functionality of the design is validated.

70% of design time at RTL!

Doulos VHDL Training : Design Flow

http://www.doulos.co.uk/hegv/design_flow.htm (1 of 2) [12/12/2000 13:08:00]

(12)

VHDL FAQ

Doulos Home Page

Doulos VHDL Training : Design Flow

http://www.doulos.co.uk/hegv/design_flow.htm (2 of 2) [12/12/2000 13:08:00]

(13)

Benefits of using VHDL

Executable specification

It is often reported that a large number of ASIC designs meet their specifications first time, but fail to work when plugged into a system. VHDL allows this issue to be addressed in two ways: A VHDL specification can be executed in order to achieve a high level of confidence in its correctness before commencing design, and may simulate one to two orders of magnitude faster than a gate level description. A VHDL specification for a part can form the basis for a simulation model to verify the operation of the part in the wider system context (eg. printed circuit board simulation). This depends on how accurately the specification handles aspects such as timing and initialization.

Behavioural simulation can reduce design time by allowing design problems to be detected early on, avoiding the need to rework designs at gate level. Behavioural simulation also permits design

optimization by exploring alternative architectures, resulting in better designs.

Tools

VHDL descriptions of hardware design and test benches are portable between design tools, and

portable between design centres and project partners. You can safely invest in VHDL modelling effort and training, knowing that you will not be tied in to a single tool vendor, but will be free to preserve your investment across tools and platforms. Also, the design automation tool vendors are themselves making a large investment in VHDL, ensuring a continuing supply of state-of-the-art VHDL tools.

Technology

VHDL permits technology independent design through support for top down design and logic

synthesis. To move a design to a new technology you need not start from scratch or reverse-engineer a specification - instead you go back up the design tree to a behavioural VHDL description, then

implement that in the new technology knowing that the correct functionality will be preserved.

Benefits

Executable specification

●

Validate spec in system context Subcontract

❍

●

Functionality separated from implementation

●

Simulate early and fast Manage complexity

❍

●

Explore design alternatives

●

Get feedback

Produce better designs

❍

●

Automatic synthesis and test generation (ATPG for ASICs)

●

Increase productivity

Shorten time-to-market

❍

●

Doulos VHDL Training : The Benefits of VHDL

http://www.doulos.co.uk/hegv/benefits.htm (1 of 2) [12/12/2000 13:08:57]

(14)

Technology and tool independence (though FPGA features may be unexploited)

●

Portable design data Protect investment

❍

●

VHDL FAQ

Doulos Home Page

Doulos VHDL Training : The Benefits of VHDL

http://www.doulos.co.uk/hegv/benefits.htm (2 of 2) [12/12/2000 13:08:57]

(15)

An Example Design Entity

A design is described in VHDL using the concept of a design entity. A design entity is split into two parts, each of which is called a design unit in VHDL jargon. The entity declaration represents the external interface to the design entity. The architecture body represents the internal description of the design entity - its behaviour, its structure, or a mixture of both. Let’s imagine we want to describe an and-or-invert ( AOI ) gate in VHDL. If we consider the AOI gate as a single chip package, it will have four input pins and one output pin; we need not concern ourselves with power and ground pins in modelling our AOI design.

VHDL: an AOI gate design entity

-- VHDL code for AND-OR-INVERT gate library IEEE;

use IEEE.STD_LOGIC_1164.all;

entity AOI is port (

A, B, C, D: in STD_LOGIC;

F : out STD_LOGIC );

end AOI;

architecture V1 of AOI is begin

F <= not ((A and B) or (C and D));

end V1;

-- end of VHDL code

OK, that’s the code. Let’s dissect it line by line...

-- VHDL code for AND-OR-INVERT gate

Similar to many programming languages, VHDL supports comments. Comments are not part of the VHDL design, but allow the user to make notes referring to the VHDL code, usually as an aid to understanding it. Here the comment is a “header” that tells us that the VHDL describes an AOI gate. It

Doulos VHDL Training : A Design Entity

http://www.doulos.co.uk/hegv/aoi_design.htm (1 of 3) [12/12/2000 13:09:49]

(16)

is no more than an aide de memoire in this case. A VHDL compiler will ignore this line of VHDL.

Two hyphens mark the start of a comment, which is ignored by the VHDL compiler. A comment can be on a separate line or at the end of a line of VHDL code, but in any case stops at the end of the line.

library IEEE;

use IEEE.STD_LOGIC_1164.all;

Above the entity declaration is a library clause ( library IEEE; ) and a use clause ( use IEEE.STD_LOGIC_1164.all; ). This gives the entity AOI access to all the names declared within package STD_LOGIC_1164 in the library IEEE, and to data type STD_LOGIC in particular.

Internal signals

Shown below is a second architecture V2 of AOI (remember that the architecture name V2 is

completely arbitrary - this architecture is called V2 to distinguish it from the earlier architecture V1).

Architecture V2 describes the AOI function by breaking it down into the constituent boolean

operations. Each operation is described within a separate concurrent signal assignment. In hardware terms we can think of each assignment as a die in a hybrid package or a multi-chip module. The signals are the bonding wires or substrate traces between each die.

Signals

The architecture contains three signals AB, CD and O, used internally within the architecture. A signal is declared before the begin of an architecture, and has its own data type (eg. STD_LOGIC).

Technically, ports are signals, so signals and ports are read and assigned in the same way.

Assignments

The assignments within the architecture are concurrent signal assignments. Such assignments execute whenever a signal on the right hand side of the assignment changes value. Because of this, the order in which concurrent assignments are written has no effect on their execution.The assignments are

concurrent because potentially two assignments could execute at the same time (if two inputs changed simultaneously). The style of description that uses only concurrent assignments is sometimes termed dataflow.

Delays

Each of the concurrent signal assignments has a delay. The expression on the right hand side is

evaluated whenever a signal on the right hand side changes value, and the signal on the left hand side of the assignment is updated with the new value after the given delay. In this case, a change on the port A would propagate through the AOI entity to the port F with a total delay of 5 NS.

VHDL: Internal signals of an AOI gate

library IEEE;

entity AOI is

port (A, B, C, D: in STD_LOGIC;

F : out STD_LOGIC);

end AOI;

Doulos VHDL Training : Internal Signals

http://www.doulos.co.uk/hegv/internal.htm (1 of 2) [12/12/2000 13:10:19]

(19)

architecture V2 of AOI is

signal AB, CD, O: STD_LOGIC;

begin

AB <= A and B after 2 NS;

CD <= C and D after 2 NS;

O <= AB or CD after 2 NS;

F <= not O after 1 NS;

end V2;

Doulos Home Page

This page was last updated 15^th June 1998

Doulos VHDL Training : Internal Signals

http://www.doulos.co.uk/hegv/internal.htm (2 of 2) [12/12/2000 13:10:19]

(20)

Components and Port Maps

The example above shows the previously defined design entity AOI being used as a component within another, higher level design entity MUX2, to create a design hierarchy with two levels. The design entity MUX2 also contains a second component, named INV. In order to write the VHDL for this circuit, we need to cover two new concepts: component instantiation (placing the INV and AOI inside another higher-level design, MUX2) and port mapping (connecting up the two components to each other and to the primary ports of MUX2). In VHDL, this is how we can model PCBs assembled from individual chips, for example.

Components

The two component declarations (for INV and AOI) must match the corresponding entity declarations exactly with respect to the names, order and types of the ports. We’ve already seen enough of the AOI gate, let’s see how closely the component and entity declarations match for the INV design entity.

Entity Component

entity INV is

port (A: in STD_LOGIC;

F: out STD_LOGIC);

end INV;

component INV

F: out STD_LOGIC);

end component;

The two component declarations (for INV and AOI) appear in the architecture declarative part (that’s a VHDL technical term that means that the component declarations are coded before the begin).

library IEEE;

entity MUX2 is

port (SEL, A, B: in STD_LOGIC;

F : out STD_LOGIC);

end;

architecture STRUCTURE of MUX2 is

Doulos VHDL Training : Components and Port Maps

http://www.doulos.co.uk/hegv/components.htm (1 of 3) [12/12/2000 13:10:59]

(21)

component INV

F: out STD_LOGIC);

end component;

component AOI

port (A, B, C, D: in STD_LOGIC;

F : out STD_LOGIC);

end component;

signal SELB: STD_LOGIC;

begin

G1: INV port map (SEL, SELB);

G2: AOI port map (SEL, A, SELB, B, F);

end;

Instantiation

The architecture STRUCTURE of MUX2 makes instances of INV and AOI through the component instantiations at the bottom of the architecture (labelled G1 and G2). The component names (INV and AOI) are references to design entities defined elsewhere. The instance labels (G1 and G2) identify two specific instances of the components, and are mandatory.

Port Maps

The ports in a component declaration must usually match the ports in the entity declaration

one-for-one. The component declaration defines the names, order, mode and types of the ports to be used when the component is instanced in the architecture body. Instancing a component implies making a local copy of the corresponding design entity - a component is declared once within any architecture, but may be instanced any number of times. In this example, there is just one instance of the components AOI and INV.

Association

Signals in an architecture are associated with ports on a component using a port map. In effect, a port map makes an electrical connection between “pieces of wire” in an architecture (signals) and pins on a component (ports). The same signal may be associated with several ports - this is the way to define interconnections between components.

In our MUX2 example, the signal SELB is associated with the F port of the INV instance and the C port of the AOI instance.

(22)

Doulos Home Page

This page was last updated 3^rd July 1998

(23)

Plugging Chips into Sockets

On the page “Components and Port Maps”, we looked at the VHDL used to describe the instantiation of components in an architecture. Instantiating components in VHDL enables us to create a design hierarchy, it’s just like plugging chips into a PCB. In our case, the MUX2 is the PCB, the AOI gate and the inverter (INV) are two chips. But what about the sockets? Let’s look into instantiating components in a little more detail.

Component Declarations

Remember that the two component declarations (for INV and AOI) must match the corresponding entity declarations exactly with respect to the names, order and types of the ports. This is important because, as a hardware analogy, the component declaration is essentially a chip socket for the chip represented by the design entity — the entity declaration defines the pins of the chip.

Component Instantiation

So, instantiation is essentially a VHDL term for soldering a chip socket into a PCB. Instantiation also assumes that the socket contains the chip referenced by the same name as it is plugged into the PCB.

However, for our purposes, we can think of component instantiation as plugging a chip into a PCB, ignoring whether it’s socketed or not.

Component Declaration Component Instantiation

Doulos VHDL Training : Plugging Components into Sockets

http://www.doulos.co.uk/hegv/sockets.htm (1 of 3) [12/12/2000 13:11:15]

(24)

component INV

F: out STD_LOGIC);

end component;

G1: INV

port map (SEL, SELB

);

Port Mapping

The concept of port mapping is little more than soldering the chip socket pins into the holes of the PCB. Thus in the case of our inverter, the F output pin of the INV chip is plugged into the F pin of the INV socket. The F pin of the INV socket is soldered to a PCB trace called SELB.

Similarly, instantiation of the AOI gate can be thought of as soldering the AOI socket into the MUX2 PCB. In this case, as an example, the SELB trace is soldered to the C pin of the AOI socket. By default, the AOI socket is assumed to be carrying an AOI chip.

architecture STRUCTURE of MUX2 is ...

component AOI

port (A, B, C, D: in STD_LOGIC; -- 3rd item in list is C F : out STD_LOGIC);

end component;

signal SELB: STD_LOGIC;

begin ...

G2: AOI port map (SEL, A, SELB, B, F); -- 3rd item in list is SELB end;

Default binding

Our current view of component instantiation assumes default binding. In default binding, the chip socket (component declaration) carries a chip (design entity) of the same name (say, AOI) as we’ve already seen. Now in the hardware world, there’s no such limitation, sockets aren’t chip specific.

VHDL allows the designer the same freedom. The chip socket and the chip do not have to have the same name, but to implement this facility requires a configuration to bind the appropriate design entity to the component instantiation. We’ll look at configurations shortly.

(25)

Doulos Home Page

This page was last updated 4^th August 1998

(26)

Configurations: Part 1

On the page “Plugging Chips into Sockets” it was suggested (in the default binding section) that an instantiation of a design entity need not have a component declaration of the same name to be legal VHDL, providing we use a configuration to change the default binding. In the case of Plugging Chips into Sockets, the emphasis was on establishing the relationships between component declaration, design entity (particularly its entity declaration) and component instantiation.

Remember that the design entity (chip package) consists of both an entity declaration (chip pins) and architecture body (chip die). In Part 1 of Configurations, we will look at selecting one architecture from many architectures of one design entity for instantiation (essentially specifying which die goes in the package of the chip that will be plugged into the PCB to maintain our analogy) and in Part 2, we will look at choosing from amongst different design entities for instantiation (essentially specifying which chip to plug into the socket).

Configuration

A VHDL description may consist of many design entites, each with several architectures, and organized into a design hierarchy. The configuration does the job of specifying the exact set of entities and architectures used in a particular simulation or synthesis run.

A configuration does two things. Firstly, a configuration specifies the design entity used in place of each component instance (i.e., it plugs the chip into the chip socket and then the socket-chip assembly into the PCB). Secondly, a configuration specifies the architecture to be used for each design entity (i.e., which die).

Default configuration

Shown below is a minimal configuration for the top level entity MUX2. This configuration selects the architecture to be used (there is only one, STRUCTURE). By default, all components inside the

architecture will be configured to use a design entity of the same name as the component (i.e., AOI), and the most recently analyzed architecture of each design entity.

We’ll tackle the concept of the most recently analyzed architecture in the next but one article in this series. Suffice to say that in this example we will take v2 to be the most recently analyzed, by virtue of the fact that we compiled the v1 version of AOI first and then compiled the v2 version of our AOI design entity a few minutes later (let’s say).

Configuration declaration

The configuration declaration is yet another one of those VHDL design units. Remember the entity declaration is a design unit as is the architecture body. In the configuration declaration, for the architecture that we want to configure, we can specify exactly which components make up the final design entity. In the example below, for the G2 instance inside our STRUCTURE architecture, we use the V1 architecture of the AOI gate. There will be absolutely no doubt as to which architecture has been chosen for simulation because we have specified v1 in the configuration. In the

MUX2_default_CFG configuration, we could change the AOI architecture for simulation by simply re-compiling v1 after v2 — hardly a robust mechanism for design description! Note, that you only

Doulos VHDL Training : Configurations: Part 1

http://www.doulos.co.uk/hegv/configurations.htm (1 of 3) [12/12/2000 13:11:28]

(27)

need to be concerned with configurations of multiple architectures when you have more than one architecture per design entity in the first place.

Default configuration of MUX2

use WORK.all;

configuration MUX2_default_CFG of MUX2 is for STRUCTURE

-- Components inside STRUCTURE configured by default -- let’s say v2 architecture for AOI

end for;

end MUX2_default_CFG;

Specified configuration of MUX2

use WORK.all;

configuration MUX2_specified_CFG of MUX2 is for STRUCTURE

for G2 : AOI

use entity work.AOI(v1);

-- architecture v1 specified for AOI design entity end for;

end for;

end MUX2_specified_CFG;

Once again, let’s break the VHDL code down fragment by fragment, using the specified

configuration. Leaving aside the use clause for now, the first line specifies what we are configuring, configuration is a VHDL keyword and is followed by the name we wish to give the configuration.

After the of keyword we specify the design entity we are configuring; is is also a keyword. Bracketed with this first line is the last end configuration_name line. Hence,

configuration MUX2_specified_CFG of MUX2 is -- block configuration

end MUX2_specified_CFG;

Configurations usually consist of nested configuration items, bracketed with end for; statements. The first item is the architecture specification,

for architecture_name -- thus, for STRUCTURE the second is the instance specification,

for instance_label : component_name -- thus, for G2 : AOI

and finally the binding indication,

use entity library_name.entity_name(architecture_name) -- thus, use entity work.AOI(v1);

Now, what about that use clause? Let’s say the AOI design entity is compiled into the working library WORK by default. Thus in order for the component_name to be visible we need a use clause, hence use WORK.all; is required.

(28)

Doulos Home Page

This page was last updated 14^th August 1998

(29)

Configurations: Part 2

Let’s review default binding before we go any further. In default binding, the chip socket (component declaration) carries a chip (design entity) of the same name (say, AOI) as we’ve already seen. The chip is inserted into the socket courtesy of a component instantiation and a configuration declaration.

If we omit the configuration or if we use a default configuration, the socket and chip must have the same name.

If we want to choose a particular die (architecture) for our chip, we must specify the architecture in the configuration.

Now. Suppose we want to create a general-purpose socket and at some later time, we want to specify which chip will be plugged into the socket. To do this requires a late-binding configuration

declaration.

Late binding

The syntax is really no different than before except that we choose a different chip name for the bound design entity, it does not have to be the same as the component declaration. Let us suppose that a spec.

change (happens too often, doesn’t it?) is required. The spec change requires a 3-input AND gate rather than a 2-input multiplexer. One way to tackle this requirement is to use late binding. This requires no change to the MUX2 at all except in the configuration. So, in a hardware sense, we’re extracting the AOI gate from its socket and inserting a 4-input AND gate.

Late-binding configuration of MUX2

use WORK.all;

configuration AND3_CFG of MUX2 is for STRUCTURE

for G2 : AOI

use entity work.AND4(quick_fix);

-- architecture quick_fix of AND4 specified for AOI component end for;

end for;

end AND3_CFG;

Doulos Home Page

http://www.doulos.co.uk/hegv/late_binding.htm (1 of 2) [12/12/2000 13:11:37]

(30)

This page was last updated 27^th September 1998

http://www.doulos.co.uk/hegv/late_binding.htm (2 of 2) [12/12/2000 13:11:37]

(31)

Order of Analysis

This is one of those topics that doesn’t really relate to hardware design. However, you can’t ignore this topic as it is so fundamental to simulating (and to a lesser extent, synthesizing) your VHDL designs. Anyhow, let's see how hardware-y we can make it!

Remember design units? So far we have used three of the five VHDL design units. An entity declaration is a primary design unit, as is a configuration declaration. An architecture body is a secondary design unit. An architecture is a secondary design unit of the corresponding entity declaration primary design unit. Hence,

architecture architecture_name of entity_name is -- secondary primary

To simulate a piece of VHDL code, you need a design environment consisting of an entity declaration and an architecture body and you also need a testbench. The testbench contains an instance of the design plus some VHDL code to apply stimuli to the design that is being simulated. In VHDL terms, the testbench is just another design entity.

OK. On to order of analysis, following on from the hardware analogy we used in the Configuration pages. In the VHDL design world, you have to create the chip package first before you can glue in the die. So, create the chip package (and put it into stores), then create the chip die (and put that in to stores, too). Someone in stores will check to see that a package for the die exists, if not they’ll give it back. Once you have done that, you can check the assembled chip out of stores any time you like.

We’ll look at checking items out of stores later on. In VHDL, checking items into stores is called analysis. In VHDL, stores is called a library (yes, in VHDL you can have lots of storerooms, hence a library not the library). So, this requires that before you analyze any architecture into a library, you must first analyze the corresponding entity declaration into the same library.

In the real world, you can goof up and put an empty chip package in to stores. You can do the same in VHDL, too. Analyzing an entity declaration into a library is OK. Conversely, a VHDL architecture body must not exist alone (the VHDL storeman will lose that tiny die!); an architecture won't be put into a library unless there's already an entity declaration in the library.

To summarise, VHDL design units are analyzed into VHDL libraries. One default library is provided for you, it is called WORK. Once you have have analyzed all of the design units you need for a simulation run into a VHDL library, you can run the simulation...

Simulating the MUX2

Let's suppose we have a rudimentary Unix or Windows’95 DOS Box command line interface for our VHDL simulator. The analyze comand allows you to specify a VHDL library name and a filename in order to analyze the VHDL source code. We'll assume that each VHDL design unit has it's own file. To analyze the VHDL in the correct order for simulation, we would enter the following

commands, one after the other,

analyze -library WORK -file aoi.entity

analyze -library WORK -file aoi.v1.architecture analyze -library WORK -file mux2.entity

Doulos VHDL Training : Order of Analysis

http://www.doulos.co.uk/hegv/analysis.htm (1 of 2) [12/12/2000 13:11:51]

(32)

analyze -library WORK -file mux2.v1.architecture analyze -library WORK -file mux2test.entity

analyze -library WORK -file mux2test.v1.architecture analyze -library WORK -file mux2test.v1.configuration on the command line.

Doulos Home Page

This page was last updated 20^th October 1998

Doulos VHDL Training : Order of Analysis

http://www.doulos.co.uk/hegv/analysis.htm (2 of 2) [12/12/2000 13:11:51]

(33)

Vectored Ports and Signals

Back to Components this month.

Ports can represent busses or vectors as well as single bits. In the example above, the port SEL is a 2-bit bus, with msb numbered 1 and lsb numbered 0. The type of the port is STD_LOGIC_VECTOR, which is also defined in package STD_LOGIC_1164 on library IEEE. Objects of type

STD_LOGIC_VECTOR are simply an array of STD_LOGIC objects.

Vectors used in a MUX4 design

library IEEE;

entity MUX4 is

port (SEL : in STD_LOGIC_VECTOR(1 downto 0);

A, B, C, D: in STD_LOGIC;

F : out STD_LOGIC);

end MUX4;

In the previous example, an array type was used to allow the description in VHDL of a vectored port.

Array types can be used for internal signals as well as ports. This can be seen in the MUX4 testbench code below:

entity TEST_MUX4 is ...

architecture BENCH of TEST_MUX4 is ...

signal SEL: STD_LOGIC_VECTOR(1 downto 0);

...

begin

SEL <= "00",

"01" after 30 NS,

Doulos VHDL Training : Vectored Ports and Signals

http://www.doulos.co.uk/hegv/vectors.htm (1 of 2) [12/12/2000 13:12:02]

(34)

"10" after 60 NS, "11" after 90 NS, "XX" after 120 NS, "00" after 130 NS;

...

M: MUX4 port map (SEL, A, B, C, D, F);

end BENCH;

The stimulus for the SEL signal is shown as a waveform, made up of individual waveform elements.

A waveform element consists of an expression followed by a time specification for when the signal is driven by the value of the expression. In this particular case, the expression is a

STD_LOGIC_VECTOR literal. STD_LOGIC_VECTOR values can be written as bit string literals.

For example both bits are set to '0 at time 0, while at time 30 ns, SEL(1) is set to '0' and SEL(0) is set to '1'.

Doulos Home Page

This page was last updated 14^th November 1998

Doulos VHDL Training : Vectored Ports and Signals

http://www.doulos.co.uk/hegv/vectors.htm (2 of 2) [12/12/2000 13:12:02]

(35)

Test Benches : Part One

So we have a design. But it’s unproven. In this tutorial we look at designing a simple testbench in VHDL.

With VHDL, it is possible to model not only the hardware or system design, but also a test bench to apply stimulus to the design and to analyze the results, or compare the results of two simulations. In effect, VHDL can be used as a stimulus definition language as well as a hardware description

language.

One consequence of using VHDL to model a test bench is that the test bench is portable between VHDL tools from different vendors.

Test Bench for MUX4

The entity declaration for a test bench (entity TEST_MUX4 is ... end;) is usually empty.

This is because the test bench itself does not have any inputs or outputs. Test vectors are generated and applied to the unit under test within the test bench. Note that it is illegal to have an architecture body without an entity declaration.

Components

Doulos VHDL Training : Test Benches

http://www.doulos.co.uk/hegv/test_bench.htm (1 of 3) [12/12/2000 13:12:20]

(36)

A component declaration is needed (component MUX4 ... end component;) in order to pull the MUX4 entity into the test bench. Think of a component declaration as a chip socket. It allows a VHDL structural description to be written in a top-down manner, because the VHDL compiler can check the consistency of the design unit that uses the component before the corresponding design entity has been written.

In order that the VHDL simulator can bind (more VHDL jargon) the design entity MUX4 to the component MUX4, the names and types of the ports must match between the entity and the component.

entity TEST_MUX4 is end;

library IEEE;

architecture BENCH of TEST_MUX4 is component MUX4

...

end component;

-- signals begin

-- signal assignments to create stimulus M: MUX4 port map (...);

end BENCH;

VHDL FAQ

Doulos Home Page

This page was last updated 7^th February 1998

(37)

(38)

Test Benches : Part Two

This month, we look at writing the VHDL code to realise the testbench based on last month’s template.

Concurrent Assignment

The 5 concurrent signal assignment statements within the test bench define the input test vectors (eg.

A <= 'X', '0' after 10 NS, '1' after 20 NS;). The delays in these assignments are relative to the time when the assignments execute (ie. time 0), not to each other (eg. Signal A will change to '1' at 20 NS, not at 30 NS).

entity TEST_MUX4 is end;

library IEEE;

architecture BENCH of TEST_MUX4 is component MUX4

port (SEL :in STD_LOGIC_VECTOR(1 downto 0);

A, B, C, D:in STD_LOGIC;

F :out STD_LOGIC);

end component;

signal SEL: STD_LOGIC_VECTOR(1 downto 0);

signal A, B, C, D, F: STD_LOGIC;

begin

SEL <= "00", "01" after 30 NS, "10" after 60 NS, "11" after 90 NS, "XX" after 120 NS,

"00" after 130 NS;

A <= 'X', '0' after 10 NS, '1' after 20 NS;

B <= 'X', '0' after 40 NS, '1' after 50 NS;

C <= 'X', '0' after 70 NS, '1' after 80 NS;

D <= 'X', '0' after 100 NS, '1' after 110 NS;

M: MUX4 port map (SEL, A, B, C, D, F);

end BENCH;

The waveforms generated for the SEL, A, B and C signals are shown below.

Doulos VHDL Training : Test Benches : Part Two

http://www.doulos.co.uk/hegv/testbench_2.htm (1 of 2) [12/12/2000 13:12:33]

(39)

VHDL FAQ

Doulos Home Page

This page was last updated 27^th February 1998

Doulos VHDL Training : Test Benches : Part Two

http://www.doulos.co.uk/hegv/testbench_2.htm (2 of 2) [12/12/2000 13:12:33]

(40)

Summary, so far...

Before we go any further let’s summarise where we have got to...

We know how to create a component in VHDL

●

We know how to join components together

●

Bottom-up design

Joining components together is one method of design using VHDL. It’s the bottom-up approach.

There’s nothing wrong with joining components together to create a design hierarchy, but using it as your design approach exclusively can restrict your productivity even though it is possible to create any design you could wish for using VHDL in this manner. Let’s step back a moment and consider how the design of something as simple as a MUX_2 is being implemented; not at a hardware level but at a conceptual level. We’ll change the MUX_2 so that it has an inverting data path:

signal SELB, FB: STD_LOGIC;

begin

G2: AOI port map (SEL, A, SELB, B, FB);

G3: INV port map (FB, F);

Well, that’s three components. The largest port list has only 5 elements. There’s only two levels of hierarchy. The target technology has to have cells called AOI and INV. Suppose the widths of the A, B inputs have to be changed?

What about a 100k gate ASIC? With multiple levels of hierarchy. Suppose it has to be technology independent, too. Creating large designs in this manner is very time-consuming. It is error-prone (it’s just too easy to connect the wrong signal to a port). It is awkward to make changes to the design as a whole (change all the busses in a design by 1 bit, for example to add parity). This approach to creating functionality is often referred to as a structural coding style.

Adopting a structural design approach, we first have to decide what we want to do (switch between two inputs) and secondly how to implement it (using components). So, while joining components together has its place, we really ought to move on to a better low-level design approach. Instead of determing the functionality and then implementing it, we’re going to describe the functionality and leave it at that. We’re not going to worry about implementation. Well, ultimately we will concern ourselves with implementation but from a coding point of view, let’s get the functionality or behaviour out of the way first.

Coding behaviour

At a conceptual level we can specify what we want the design to do using a behavioural coding style.

Using the structural approach, we have to describe explicitly how the design is to be implemented.

Thus a structural approach implies an extra step in the design process.

So, how do we implement (smile) a behavioural coding style? Well, this can be achieved by writing VHDL code as though we were writing software rather than describing hardware. We can take our

Doulos VHDL Training : HEGV : Summary

http://www.doulos.co.uk/hegv/summary.htm (1 of 2) [12/12/2000 13:12:49]

(41)

VHDL coding capabilities closer to VHDL programming, closer to writing software rather than describing hardware. By writing software rather than describing hardware, we can concentrate on what a design does rather than how it does it. We can concern ourselves with functionality rather than implementation. In the same way that mathematicians look to abstract a concept to make a problem easier to solve and provide more flexible solutions, we can abstract our designs from VHDL hardware descriptions to VHDL software functions. However, a software function will still at some point

become a hardware description. We can bridge the gap from software function to hardware description using synthesis.

With the behavioural approach to design, we still have to decide what we want to do, but that’s it. We can use synthesis tools to decide how to implement the functionality we have (behaviourally)

specified. There are still two steps in creating a netlist that meets our design goals, it’s just that with a behavioural approach we use design automation to complete the second (implementation) step.

Hopefully, this can save us time because we as engineers only have to do one job instead of two.

Using a software-oriented design approach we can reduce the number of design steps.

Next month, we’ll look at how to code up the MUX_2 circuit in a software-oriented manner using VHDL processes.

Doulos Home Page

This page was last updated 28^th October 1998

Doulos VHDL Training : HEGV : Summary

http://www.doulos.co.uk/hegv/summary.htm (2 of 2) [12/12/2000 13:12:49]

(42)

Components vs. Processes

Last month, it was suggested that designs could be created using a more software-oriented behavioural style of VHDL coding rather than the explicit structural coding style used to create the MUX_2 design. Before we look at how to describe a MUX_2 using a behavioural coding approach, let’s deal with how VHDL designs operate — the MUX_2 will serve as our example.

signal SELB, FB: STD_LOGIC;

begin

G2: AOI port map (SEL, A, SELB, B, FB);

G3: INV port map (FB, F);

Sequential, parallel or concurrent?

Conceptually, the AOI and INV components operate concurrently. They do not operate in parallel. Sorry for being pedantic but this subtlety is important. Parallel means operate simultaneously, usually without communication between the parallel elements (“never touching” in my dictionary). Concurrency means cooperating, taking place at the same time or location.

In VHDL, we usually speak of elements executing rather than operating (or cooperating), so in VHDL elements can execute concurrently, in parallel or in sequence. We can see that the AOI and INV components execute concurrently — they communicate via the internal signals. You might think that they execute in sequence.

(Almost!) If SEL changes and A,B have the same value then the G1 instance of INV executes in parallel with AOI.

As FB does not change value the G3 instance of INV does not execute. This simple scenario shows the absence of parallel execution (G3 doesn’t execute whilst G1 and G2 are executing) and sequential execution (G3 doesn’t execute after G2); this leaves us with concurrency.

We often say to ourselves that the AOI and INV are connected. We now know that being connected means concurrent execution. In our example, the functionality of the MUX_2 is implemented via components executing concurrently.

Processes

To create software-style VHDL, we first have to deal with processes. We can think of a VHDL process as a blob of hardware. Instead of instantiating a component in an architecture, we can instantiate a process.

For our MUX_2 example, let’s dispense with concurrency altogether. Let’s use a single process. Processes enable you to code up a design by describing the design’s functionality using statements executing in sequence. This is different from the way in which components create functionality. Components create functionality by executing concurrently with respect to each other.

STRUCTURE BEHAVIOUR

Doulos VHDL Training : HEGV : Components vs. Processes

http://www.doulos.co.uk/hegv/comps_vs_procs.htm (1 of 3) [12/12/2000 13:13:04]