Lecture 4.2 (2outof2): Introduction to VHDL - Lexicon, syntax and structure

Loading...

来自 Universitat Autònoma de Barcelona 的课程

Digital Systems: From Logic Gates to Processors

196 个评分

Universitat Autònoma de Barcelona

Digital Systems: From Logic Gates to Processors

196 个评分

This course gives you a complete insight into the modern design of digital systems fundamentals from an eminently practical point of view. Unlike other more "classic" digital circuits courses, our interest focuses more on the system than on the electronics that support it. This approach will allow us to lay the foundation for the design of complex digital systems. You will learn a set of design methodologies and will use a set of (educational-oriented) computer-aided-design tools (CAD) that will allow you not only to design small and medium size circuits, but also to access to higher level courses covering so exciting topics as application specific integrated circuits (ASICs) design or computer architecture, to give just two examples. Course topics are complemented with the design of a simple processor, introduced as a transversal example of a complex digital system. This example will let you understand and feel comfortable with some fundamental computer architecture terms as the instruction set, microprograms and microinstructions. After completing this course you will be able to: * Design medium complexity digital systems. * Understand the description of digital systems using high-level languages such as VHDL. * Understand how computers operate at their most basic level (machine language).

从本节课中

Arithmetic components + Introduction to VHDL

<b><font size=4 color=#B22222><b>Click on "v More" to read the purpose of this module</b></font> </b><br/><br/>Arithmetic circuits are an essential part of many digital circuits and thus deserve a particular treatment. <ul><li> The first part of this module presents some implementations of the basic arithmetic operations. Only operations with naturals (non-negative integers) are considered. </li><li>The second part of this module introduces the basics of VHDL with the goal of providing enough knowledge to understand its usage throughout this course and start developing basic hardware models.</li></ul>

Lecture 4.2 (1outof2): Introduction to VHDL - Lexicon, syntax and structure8:58

Lecture 4.2 (2outof2): Introduction to VHDL - Lexicon, syntax and structure12:27

Lecture 4.3 (1outof2): Introduction to VHDL - Sequential sentences10:37

Lecture 4.3 (2outof2): Introduction to VHDL - Sequential sentences12:59

Lecture 4.4 (1outof2): Introduction to VHDL - Concurrent sentences12:18

Lecture 4.4 (2outof2): Introduction to VHDL - Concurrent sentences8:55

L4.2 Short introduction to VHDL I (OLD VERSION)22:07

L4.3 Short introduction to VHDL II (OLD VERSION)18:30

L4.4 Short introduction VHDL III (OLD VERSION)32:36

与讲师见面

Elena Valderrama
Professor
Departamento de Microelectrónica y Sistemas Electrónicos. UAB.
Jean-Pierre Deschamps
Professor
Lluis Terés
Professor
Centro Nacional de Microelectrónica del CSIC
Merce Rullan
ProfesoraTitular
Departamento de Microelectrónica y Sistemas Electrónicos. UAB.
Joaquín Saiz Alcaine
Ingeniero Informático
Departamento de Microelectrónica y Sistemas Electrónicos. UAB.
David Bañeres
Profesor Agregado
Estudios de Informática, Multimedia y Telecomunicación. UOC.
Juan Antonio Martínez
Collaborator
APSI - UAB

We need do go one step farther.

We have seen objects and data types, but what should we do now?

Keep in mind, now, we are trying to model a digital system.

To go farther, we'll introduce design units.

There are five design units which are the entity,

the architecture, the package declaration, the package body and configuration.

In this brief introduction, we will only talk on three of them

which will be the entity, the architecture, and the package.

Although it's not a precise definition,

we can say the entity would be the you're trying to simulate or implement.

The architecture will be the description of how it works.

Let me remark, this is not a formal definition.

But I think it kind of hard for you to understand the language.

The entity identifies a module.

It defines its name, its in and outports but

with no information of their functionality.

The architecture will always be linked to an entity.

It has access to the to the in and

output ports of this entity, and it describes or models the functionality.

For a single entity, we can provide more than one architecture but

all of them will share the same block of in and out ports declared in the entity.

Anyhow, in most of the examples we will use in this course,

there will be only one architecture for each entity.

But sometimes, it can be useful describing different architectural solutions for

the same entity.

We have seen entity and architecture.

And now we'll briefly see the package, which contains declarations and

definitions of data types.

Objects and functions to ease their shared use in different BATL codes.

Package contains a declarative part and a body.

For our purposes, we will barely use the package body, because we will be able to

declare and define everything we mean in the package declaration.

But that will come later in the course.

Let's get deeper into the design units.

We have seen the entity is like a black box,

which only defines the interfaces of each module, both in and out.

It doesn't provide any information on it's behavior or functionality.

In this slide, we can see an example of an entity definition.

I'd like to focus on the entity name, or identifier and in the ports.

In this example, we name an entity MUX21.

We attach three imports, A, B, and Ctrl, and provide one output.

As you see,

the definition does not provide any idea of what this block is doing inside.

That will be the work for the architecture.

How does the entity behave or how is it structured?

And that's what the architecture will tell us.

As we can see here, there's an identifier, with the architecture's name and

the reference to the entity.

We'll have also a plot for declarations.

I'd like to focus on the lines between beginning and end.

That's where the behavior or

the structure of the circuits you are designing will be described.

In this slide we have two architectures for two similar entities.

They have been put together for comparison as they have just sent

between the begin and end is where the architecture is from.

In this case there is a unique process which uses A, B, Ctrl and

Z signals which are defined as in our entity.

In side the process there is a simple if-then-else construction.

If the Ctrl signal equals to 0 then Z take the value of A.

And if it doesn't equal to 0, Zed will take the b.

This behavior belongs to the one of a multi flexor controlled by control

with two data entrances a and b.

And the Zed data exit, which is what we have sketched in the slide.

On the right side, We analyze the other entity we have defined.

It's similar, but this is a generic parameter, 1n.

This extension permits the user from associated architecture for

a generic multi-plexor.

As you see this architecture is exactly identical to the architecture in

the first case.

So we have also defined a multiplex server now and the ins and

outs are not one beat signals but of n beats.

The architecture of the previous example as a functional definition.

It tells us how the entity behaves.

But if you are thinking in a multiplex are created from logic gates

BADL allows us to make a description based on this approach.

In this case the architecture is a spaced logic gate.

On logic gates, which we define as components in the alley,

as components in this architecture's declaration part.

After that, we make the appropriate instances for

these components and we connect them in their in and

out to the signals that have also been defined.

So we have seen two architectures of the same entity with

very different structural levels.

Functional unstructural.

Both of them behave as expected.

And as you probably have noticed,

there are other possible intermediate descriptions such as the one

which answers to the figure in the upper part of the slide.

Where we can see different logic functions in a graph which answers to the data flow.

It resides through it's primary entrances.

This architecture could be describe as we see here.

In our architecture, we have fold data flow of the same to what.

Inside which, we have defined its internal signals.

Inside the architectural description zone, we set four concurrent

designations as they model the logic functions In the graphic we have seen.

As important aspect which sometimes can lead to confusion,

to confusion, is that this designations are concurrent sentences.

So the order in which they appear is irrelevant.

To summarize, we have seen that one entity can have many different architectures.

And with different abstraction levels.

They all have their primary in and out ports in common defined in the entity.

Once entity and

architecture have been let's talk on the last design unit we will see, package.

Package is a way to let me define as a name to genus.

Package definitions of data types, objects, functions and processes

to easily [INAUDIBLE] or reuse this functions in different [INAUDIBLE] codes.

In this slide, you can see there are two different units.

The package declaration and the package body.

It block with its own syntax.

To use package contents inside a certain code,

we will use the use sentence which you can see in the bottom of the slide.

You'll be able to use your own packages and

at the same time use some standard which inside the default

packages, which in fact are the most usable ones.

STANDARD and TEXTIO are the default packages inside BXCL where we can

find really a whole set of values functions and

really useful standard logic and arithmetical operations.

Based on these packages the designer can define his own packages

which will help him to simply the BHCLs modeling words,

under reuse of the code to allow the project's collaborative development.

You will find the reference to this package in

almost any code you read or create.

Just as an example,

you can review this slide where you see, there were farmings to that.

Logic arith and logic 1164 package, commented.

And also, in this slide the definition of our user refine package,

for reutilization.

I would encourage you to read the code presented in this slide as

you will see there is also the definition of constant assuming,

of constant data types and values to discuss them.

Let me finish this short introduction to the packages with a comment regarding

some of the IEEE standard packages.

Here we have the standard package 1164 which

defines a multivalued logic with up to nine different logic values.

Not only a zero and one as maybe you may expect.

It has a value of U, as non initialized,

X for unknown, 0 for strong drive, logic zero, 1 for logic one,

Z for height impedance or disconnected Double W for weak noun.

L for week or h for height.

Finally the hyphen which is redundant or indistinct term.

Which means the position of this hyphen can be taken by

any other value in the standard.

So we mark all the values in this multi-valuated logic are necessary

be able to calculate and simulate the digital circuits with bigger partition.

Farther than pure binary 0 and 1, and so be able to manage the different

situations in which we confine a digital signal inside a simulation.

This package also has some simple subtypes.

It has some logical arithmetic operations you find

against this kind of beta and it also contains some data

conversion functions from inter to multivalulated logic and vise versa.

We have also another important standard package which is the arithmetic standard,

which defines more complex operations and functions then the one's we have just seen

and also are a bit more elaborative operations and functions.

There are other packages, such as standard logic, signed and unsigned.

In which the functions are defined to ease the work with numbers,

with signs and numbers without signs.

All these define and summarize baggage by weight.

IEEE are recognized and used in a optimal way by the modeling simulation and

synthesis tool which is, which eases the corresponding processes on the models.

We are going to treat, use this package.

So I would highly recommend you to make use of this standard practice.

As a summary of this first BATL session we have interviews,

the concept, and the main objectives of the hardware description.

But watch this remember they are modeling simulation.

We have introduced BADL Lexicon and

syntax through the language of this constants, variables, and signals.

Data types and language operators expressions.

We have also seen how the language structure and designs.

Entity, architecture, and package.

And all this has been illustrated with small samples of code.

Anyhow, the best to get interviews would be by reading and

writing your own VHDL code.

And that's all for today.

Hope to see you soon in our next lesson.

探索我们的目录

免费加入并获得个性化推荐、更新和优惠。

Coursera 致力于普及全世界最好的教育，它与全球一流大学和机构合作提供在线课程。

© 2019 Coursera Inc. 保留所有权利。

通过 App Store 下载

通过 Google Play 获取