In previous units,

we talked about how Boolean functions can be realized using logic gates.

And in this unit, we are going to talk about how we can actually build and

implement the logic gates using a formalism

called Hardware Description Language or HDL.

Once you build a logic gate in HDL, you can actually simulate it, test it.

And finally, build it in hardware as we now turn to describe.

All right.

So let's begin this journey from obstruction to implementation.

The first thing that you have to do as a gate architect is demand a full and

complete description of the desired gate's behavior.

And in this case, what we need is some sort of a truth table.

In the case of Xor, it's a very simple truth table.

And the truth table along with a gate diagram, gives you everything

that you need in order to understand what this chip is supposed to do.

And what we see here is also sometimes called the chip's interface.

And indeed, using this information, you can start writing an HDL file

that will look something like this example here.

So we start the HDL program or the HDL file with some documentation,

free-form, you know, you can write whatever you want there,

which describes what the gate is supposed to do.

And then we specify the name of the chip.

The names of the inputs of the chips and the names of chip's output.

And all this information, by the way, the name of the chip and

the names of its inputs and outputs is typically given to you.

You know, it's not something that you decide.

It's something which is part of the chip's contract, if you will.

So you simply write it up using this syntax and then you write the magic

word parts, which describes that here begins the segment of your

program in which you're going to describe how this chip is actually designed.

Now when you use such a chip, such Xor chip,

what we've seen so far is called a gate interface.

And notice that this is everything that I need in order to use Xor gate.

However, if I have to build this gate, well, that's a different story.

Now, I have to open up the black box and actually design it.

So when we use chips, we always wear two different hats.

There's the hat of the programmer who uses the chip, the chip part and

for this, all we need to know is the chip interface.

And there is the other hat of the chips builder,

which is what we're going to do now.

So moving alone, let's discuss how we actually build this chip from scratch.

All right.

So, actually we are not going to build it from scratch, we can if we,

if we need if we need to we can build it from a NAND gates only.

However, let us assume that we, we've already built

an and gate an or gate and, and not gate.

Well, if we built these gates or if someone gave us

these gates that we can freely use.

Here's what we can do.

We can inspect the truth table and figure out from the truth

table that the Xor functionality can be described as follows.

I mean, look at Xor, look at the truth table.

The gate outputs one in two cases only.

If if a and not b or if b and not a.

That is if a is true and b is false or if b is true and and a is false.

This sort of comes out, jumps out from the truth table.

You can either see it on your own or as Noam described in one of the previous

units, you can synthesize this this insight or

this, Boolean function from the table itself.

So, once you come up with this insight,

the next thing that you do is you think about it for a little while and

you come up with a gate logic diagram that describes how we can build this

Boolean function using basic logic gates that we already have to our disposal.

Now developing such diagrams is a matter of experience and the only way to,

to gain this expertise is to see many, many examples like, like this one.

So let's take this example and and explain it in in detail.

So the first thing that we can do is draw the boundary of

the chip diagram or the or the gate diagram.

So we use this dash to outline for this purpose and

what remains outside the boundary is the user's view of this gate.

In other word, the, the gate interface.

All the users knows is that he or she has a gate that has two inputs,

a and b, an output called out and altogether.

They somehow, this chip as if by magic, delivers Xor functionality.

So we draw this diagram and and this interface and

now we can delve more into the into the inner architecture.

So notice how the a signal is being copied and

sent simultaneously into two different destinations.

One of them is the and gate and the other one is and not gate.

This is perfectly okay in chip diagram.

And we see that the b signal undergoes the same the same treatment.

And in general, when you write HDL code, you are allowed to take any signal.

And distribute as many copies as you want of this signal

into as many destinations as you want.

This this wiring or these dispatching is done simultaneously.

So to use formal language HDL has unlimited thin out.

You can, you can thin out any given signal to as many destinations as you want.

And we do it we always do it when we write HDL code.

All right.

Moving along, notice that we're using some off the shelf gates and not and or.

Now whenever you use an off, off the shelf gate,

you are bound to use the names of the gate's input and

output as advertised, so to speak.

In other words, when you take the gate, gate off the shelf, the gate comes

along with what can be called the gate's signature or the gate's API.

So we have no degrees of freedom here.

We have to use the official names of the the inputs and

outputs of, of every one of our chip parts.

Now the next thing that we do is let's focus on the red

connections that we see here.

These are the connections that we draw in order to connect the different

chip parts together.

Now the rule is that every one of these connections has to be named and

it's our responsibility to come up with sensible names, so that's what we do.

We can call this particular connection not a,

which is a sensible name, I think a self-descriptive name.

We'll do the same thing with the not b.

We call this one a and not b.

We can call this one not b not a and b and, and that's it.

We, we, we have named all the internal connections in our architecture.

And we can actually now move on to describe this diagram in HDL.

So now we can actually move on and implement this diagram using HDL.

So we return to the HDL stub file that we had before.

And I use the term stub file to describe a partial HDL implementation,

so to speak that actually describes only the chip's interface.

And typically, it comes with the statement implementation missing or

put your code here and so on and so forth.

So this is the contract that we actually have to implement.

And now, indeed, we are going to focus on the implementation section of this file.

And basically, what we do is we begin to describe

the gate diagram one chip part at a time.

And for each one of the chip parts that we have, we write a single

HDL statement that describes the chip along with all its connections.

So we have two we happen to have two not chip parts.

So we describe them.

The first not has n equals a.

This is the input.

You know, the, the n input of the chip receives the a signal.

And the out, output of of the chip goes into not a.

We do similar with the, with the other not chip.

Then we described the two and chips.

And finally, we described the other or chip.

Notice by the way that they use the words gate and

chip interchangeably and that's perfectly okay.

A gate for me is simply a simple chip.

All right.

So this HDL diagram is nothing more than

a textural description of the gate diagram.

Did I say, HDL diagram, I, I meant the HDL file is a textural description of,

of the gate diagram that we see at the top of the slide.

Now, I'd like to to notice that once again, we have interface,

we have implementation.

And also note that the interface of the chip is unique, you know?

There's only one way to describe this chip and this is typically given to

us by whoever, you know, commissioned us to implement this chip.

At the same time, the implementation is not unique and

the same interface can be implemented in typically in many, many different ways.

For example, in the case of Xor,

we can implement the Xor chip using three logic gates only.

So and it doesn't really matter how exactly we do it.

We can, you can think about it on your own if you want.

But in general, there may be different implementations and

some of them will be less expensive.

They will contain less chip box, less connections.

Consume less energy and so on and so forth.

So the interface is unique and implementation varies.

Now, I'd like to use this opportunity to

make some general observations about, about HDL.

And for ease of reference I have placed in front of you

what we saw earlier in this unit.

The the gate diagram on the right-hand, hand side and

its HDL description on the left.

So what, what can we say about, about HDL?

First of all, we see that there are certain issues in HDL,

which are very similar to what we normally do in other programming languages.

We have to worry about good documentation of our HDL program,

just like we do when we write the program in Java or Python.

We have to come up with good descriptive names.

Both to the chips that we use and to the connections that

we that we create within the architecture.

So readability is terribly important.

You know, we have to make sure that our HDL code is self-descriptive and readable.

And in order to do it, we also use indentation.

You know and and make the code look real nice.

So, all of these things are expected from you when you write your own HDL programs.

In addition, there are certain things which are really unique to HDL.

First of all, HDL is a functional or declarative language.

There is no procedure going on.

There's no program execution going on.

It is nothing more than a static description of the gate diagram.

At the same time, you know, we assume that at some point this

descriptive code will go into some interpreter.

You know, it will go into, in our case into harder simulator that,

that can actually take this description and

start to sort of pipe values from the bottom all the way to the end.

So we assume there is some agent that will turn this

implementation into something that, that is actually working.

But this procedural part is not part of the HDL code,

you know, it's external to the HDL code.

So because HDL is a functional language,

we can actually write those HDL statements in any order that we wish.

You know, it doesn't matter if you begin to describe the not gate or the or gate,

it's completely up to you.

But it is typically it's customary to begin to describe

your diagram from left to right and this also makes the code more readable.

Also, note that each time we use an off the shelf gate, we commit

ourself to using the gate interface, that is the names of the input and

outputs that come along with the gate documentation.

Now, in the HEC computer that we're going to build in this course.

We decided as a matter of convention to almost always use the letters and

b for a two input chip and out for a single output chip.

And therefore, we are going to have

many chip connections that look like a equals a and out equals out.

Now, at the beginning, you know,

this formalism these conventions will look a little bit strange.

You know, what does it mean, a equals a, out equals out?

If you think about it a little bit and if you go back to consult these diagrams,

you will see that these connections make a lot of sense.

And actually, they are very convenient from a programming perspective.

You will realize that once you get your hands dirty and

write some HDL code of your own.

So, I'd like to end with some some comments about

hardware description languages in general.

There are many of them out there and yet, the two most popular

HDLs that at least I know of are VHDL are Veri, Verilog.

These are the languages which are used,

I think in 90% of hardware design projects.

But there are many other HDLs that are out there that can be used, as well.

Our own HDL is very similar in its spirit to the industrial

strength HDLs that I mentioned earlier, VHDL and Verilog.

And yet, it is a very minimal and simple version of these HDLs.

And for this reason, you can master it in something like one hour of

reading a tutorial and and beginning to write some HDL code of of your own.

And most importantly, our HDL along with our hardware simulator gives you

everything that you need in order to build the computer described in this course.

And actually, any other computer that you may want to build

using the knowledge that you will gain in the Nand2Tetris course.

So if you want read more about HDL and, and you should,.

Take a look at a Appendix A in the textbook and also read

the HDL Survival Guide in our Nand2Tetris website.

Both are, are actually available in, in the website.

And you may want to also take the hardware simulator tutorial and,

and learn how to actually read HDL descriptions and, and

execute the underlying logic of these HDL using simulation.

So this has been the unit in which we gave you a primer of HDL.

And in the next unit, we'll describe, once again,

how you can take your HDL designs and

bring them to life within the context of the hardware simulator.

Unit 1.4: Hardware Description Language

Build a Modern Computer from First Principles: From Nand to Tetris (Project-Centered Course)

Meet the Instructors