Politecnico di Milano

FPGA computing systems: Background knowledge and introductory materials

notes

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.

À partir de la leçon

Design Flows

After presenting different solutions proposed to design and implement dynamic reconfigurable systems, this module will describe a general and complete design methodology that can be followed as a guideline for designing reconfigurable computing systems. To design and implement a reconfigurable computing system, designers need Computer-Aided Design (CAD) tools for system design and implementation, such as a design analysis tool for architecture design, a synthesis tool for hardware construction, a simulator for hardware behavior simulation, and a placement and routing tool for circuit layout. We may build these tools ourselves or we can also use commercial tools and platforms for reconfigurable system design. The first choice implies a considerable investment in terms of both time and effort to build a specific and optimized solution for the given problem, while the second one allows the re-use of knowledge, cores, and software to reach a good solution to the same problem more rapidly. This module is guiding the students through an historical view on how CAD frameworks evolved through the years. This is done to show how fast the technology is evolving and the rationale behind the choice made to improve the users experience when working with an FPGA-based system. Not only commercial tools are described, but also the personal journey done by the course instructor and his research team, starting from his early days as a PhD up to the research challenges they are nowadays working on.

Partial Reconfiguration Design Flows4:58

Xilinx Difference Based Partial Reconfiguration5:23

Xilinx Module Based Partial Reconfiguration5:02

Xilinx Partial Reconfiguration (PR) Flow5:33

Moudle Based vs Partial Reconfiguration Design Flows17:14

Rencontrer les enseignants

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

With the MODULE-BASED implementation of partial reconfiguration

we are gaining all the advantages of the widely used modular design approach.

It is a design approach that allows several designers to cooperatively work

on the same project simultaneously.

This approach implies that the team of designers needs to have a leader in charge of organising

the system into modules.

By doing this him or her has to estimate the amount of resources that will be used

by each module, defines the placement locations for the modules on the device

and lets the single parts to be developed by the other designers independently.

Within this context, we can see that this approach is basically recalling

the structural VHDL/verilog design of a system.

By embracing this design methodology we are allowing, per module, a parallel and independent:

. Design entry and synthesis . Design implementation

. Design verification

but, at the same time, we have to be very careful, at the system level to take care

of the following design constraints:

. Module definition

. Module height and width . Inter-module communication

Now, as we can understand this approach is definitely interesting to implement

a partial reconfigurable system.

We can use the modules to define our reconfigurable functional units

and the module placement constraints to identify a Reconfigurable Region.

The reconfiguration is going to happen because we may have two or more modules

implemented in the same area.

This solution has specific limitations/constraints:

. Reconfigurable Regions have strict shape requirements

which basically means that we can not assign height and width

in a completely arbitrary way to our Reconfigurable Regions.

. Bus-macro replication

we need to guarantee the correct crossing of modules boundaries by using a set of macros

that have to be instantiated in our design

. The identification and definition of the area constrains also for the part of the design

and won’t be affected by the reconfiguration of other elements

We can see this as the “static side” of our system.

It is quite typical, in the case of designing a partial dynamic reconfigurable system

in using the static side to implement the reconfiguration controller or manager.

The Module-based design flow is organised in four main steps:

. HDL description and synthesis . Initial Budgeting Phase

. Active Module Phase . Final Assembly Phase

During the HDL DESCRIPTION AND SYNTHESIS step the designers in the team,

developed their own modules using a hardware description language

and synthesised them by using synthesis tools.

During this phase the team leader has the role of designing the top-level design entry

and synthesises it before moving to the initial budgeting phase.

It is important to notice that, at the top level:

. all global logic has to be included . all the modules are instantiated as black boxes

with only the information on their interfaces

. all the signals connecting all the modules must be defined

During the INITIAL BUDGETING PHASE we are defining design constraints.

As an example: during this phase we are going to identify the area constraints for each area

used to implement a module.

This is what we are used to refer to as the FLOORPLANNING phase.

The ACTIVE MODULE PHASE is where each component is going to be implemented.

Thanks to the constraints identified during the initial budgeting phase,

we can independently implement each module composing our design.

Just to be clear, by implementing I am referring to the TECHNOLOGY MAPPING

and to the PLACE AND ROUTE phases.

The results of the Active Module phase can be seen in this picture.

What we are observing is the design of three different modules.

Two of them, the smallest ones, are used to configure two modules that are used to realise

two Reconfigurable Functional Units.

I did also highlight the Reconfigurable Regions with a rectangular box surrounding the RFU.

While the third one is the module used to implement the static element of our system.

Once we have all the modules implementations, we are ready to go

through the FINAL ASSEMBLY PHASE which is used to assemble individual modules together

to create all the necessary configurations used to generate all the necessary partial bistreams.

In our examples we have created an initial configuration bitstream

with only the static side and two partial reconfiguration bitstreams,

one per Reconfigurable Functional Unit.

And in this figure we can see a possible configuration of our system where we can see both

the Reconfigurable Functional Units simultaneously implemented on our system.