米兰理工大学

FPGA computing systems: Background knowledge and introductory materials

评分

This course is for anyone passionate in learning how a hardware component can be adapted at runtime to better respond to users/environment needs. This adaptation can be provided by the designers, or it can be an embedded characteristic of the system itself. These runtime adaptable systems will be implemented by using FPGA technologies. Within this course we are going to provide a basic understanding on how the FPGAs are working and of the rationale behind the choice of them to implement a desired system. This course aims to teach everyone the basics of FPGA-based reconfigurable computing systems. We cover the basics of how to decide whether or not to use an FPGA and, if this technology will be proven to be the right choice, how to program it. This is an introductory course meant to guide you through the FPGA world to make you more conscious on the reasons why you may be willing to work with them and in trying to provide you the sense of the work you have to do to be able to gain the advantages you are looking for by using these technologies. The course has no prerequisites and avoids all but the simplest mathematics and it presents technical topics by using analogizes to help also a student without a technical background to get at least a basic understanding on how an FPGA works. One of the main objectives of this course is to try to democratize the understanding and the access to FPGAs technologies. FPGAs are a terrific example of a powerful technologies that can be used in different domains. Being able to bring this technologies to domain experts and showing them how they can improve their research because of FPGAs, can be seen as the ultimate objective of this course. Once a student completes this course, they will be ready to take more advanced FPGA courses.

从本节课中

An Introduction to Reconfigurations

Before continuing in this terrific journey in the reconfigurable computing area, it can be useful to define a common language. Obviously, some of these terms have been already used but it is now time to better understand them and to make some order before continuing with more advanced concepts. Furthermore, as we know, FPGA configuration capabilities allow a great flexibility in hardware design and, as a consequence, they make it possible to create a vast number of different reconfigurable systems. These can vary from systems composed of custom boards with FPGAs, often connected to a standard PC or workstation, to standalone systems including reconfigurable logic and General Purpose Processors, to System-on-Chip's, completely implemented within a single FPGA mounted on a board, with only few physical components for I/O interfacing. There are different models of reconfiguration, and a scheme to classify them is presented in this module. We can consider this module as a transitional/turning point module. We have been exposed to some terminology and concepts and we are now ready to move forward. To do this, we need to combine all the pieces of the puzzles together and to invest a bit at looking at the overall picture, and this is exactly what this module has been designed for.

A Common Vocabulary4:48

与讲师见面

Marco Domenico Santambrogio
Associate Professor
DEIB - Dept. of Electronics, Information and Bioengineering

Before continuing in this terrific journey in the reconfigurable computing area, it can be useful

to set a common language that will be used from now on.

Obviously, we had already encountered several new therms, field programmable gate array,

was one of them, bitstream, was a second one, but we do need something more.

First of all, I’m going to introduce you the term OBJECT CODE.

With Object Code I’m going to refer to the executable active physical implementation,

either hardware or software, of a given functionality.

Think of an executable file, in the software context.

This file is nothing more than a sequence of zeros and ones, as it is a bitstream file

used to configure a certain system or just a functionally on an FPGA.

The object code is something more, it can be seen as a bitstream under execution.

To have an object code, we need to design, or implement, if you prefer, a CORE.

A core is a specific representation of a functionality.

It is possible, as an example, to have a core described in VHDL, in C

or in an intermediate representation, as an example, via a data flow graph.

Once that a core has been defined, we need to integrate it into a system.

This means that the pure functionality is not sufficient.

We need something more.

We need to bind it with the proper communication infrastructure

because we need to send its data in order to have it properly working

and, at the same time, we need to collect back the produced data.

A core capable of computing great functionalities is completely useless if we cannot provide it with data

and read back its results.

From now on, a core described using a hardware description language

combined with its communication infrastructure, a bus interface, a point-to-point connection,

a network-on-chip, just to provide some examples, will be called IP-CORE.

As we know we are working with FPGAs.

And one of the unique characteristics of these devices is their ability of being reconfigured.

Within this context, an IP-Core that can be plugged and/or unplugged at runtime

in an already working architecture is going to be called RECONFIGURABLE FUNCTIONAL UNIT.

Now, we need one more definition which obviously related to the one that we have just seen.

We know that we can work with IP-core that can be swapped in and out a running system.

We know that these elements are called reconfigurable functional unit,

but one thing which is missing is the definition of where these units will be placed

and that is exactly what a RECONFIGURABLE REGION is.

A reconfigurable region is a portion of the device area used to implement

a reconfigurable functional unit.

Finally, we can define the configuration bitstream as the sequence of bit,

that is where the name belongs to, used to configure a reconfigurable region

by being properly stored into the configuration memory.

With this set of definitions in mind, we can now go back to the configuration process.

Imagine and see how these definitions are going to clarify and extend this scenario.

We are going to see what new challenges we are going to face from now on!

In the figure we have an FPGA which is configured by storing the desired configuration bitstreams

into the configuration memory via a configuration interface.

But now we know that a reconfiguration bitstream is the sequence of bit

to configure a reconfigurable region.

Which means that the FPGA cannot be seen any longer as a monolithic component.

Furthermore, we know that these reconfigurable regions are used to host a certain reconfigurable functional unit.

What is now missing is exactly this.

How can we identify this reconfigurable functional units?

What does it imply to have several reconfigurable regions defined on an FPGA?

Are we going always to work with several reconfigurable regions or not?

Those answers, those challenges are the ones that we are willing to explore, to find an answer to!