Hi!
Welcome back to our example where we have been able to configure our FPGA with a given design!
Even if you are not familiar with it, well, this is not a big issue, the basic idea is
that we went through the entire design process and we have been able to create the proper
configuration bitstream.
This is great, we have a working FPGA, and this is what we are here for!
But wait…
What?
Wait a second Something is happening…
While we were executing our design we just realised that something has to be changed…
It is not a big thing, we just have to modify the configuration of one CLB.
Umh… not a big thing?
Are you sure?
Well, you are right, it is not a big thing… it is HUGE! GIGANTIC!
We don’t know how to do it!
This means that even if the update is small, even if it is not involving the other elements
we do have to start from scratch the entire design process.
Wow… that seems to be insane!
It’s ok with us, we are just using a super simple FPGA, but what if we are going to work with a real one?
Well, this can be HUGE! and this is exactly the rationale behind
the PARTIAL RECONFIGURATION!
We do need to work towards the creation of a RECONFIGURABLE-FRIENDLY ECOSYSTEM!
RECONFIGURABLE SYSTEMS are gathering an increasing interest
from both the scientific and the industrial world.
The need of a comprehensive framework which can guide designers
through the whole implementation process is becoming stronger.
It is quite hard to have just in one framework support to:
. define which IP-Core has to become a reconfigurable core
. perform the actual swap of reconfigurable cores and the FPGA reconfiguration
. define interconnections among reconfigurable cores
. identify from an high-level or RT-Level specification how to define reconfigurable cores
And these are just few examples, I can provide you more.
Because of this scenario we can find many examples of tools/initiatives to try to cope with it.
One of the earliest examples in trying to provide a tool
to design partial configuration bitstream has been done by Xilinx.
They have been working on a design flow for partially reconfigurable architectures
which was characterised by a set of subsequent phases to implement the architecture
where PARTIALLY RECONFIGURABLE REQUIREMENTS were explicitly exposed.
In having a look to the history of Xilinx efforts in providing tools to support
partial reconfiguration we can identify three official design flows:
. DIFFERENCE BASED, also known as SMALLBIT MANIPULATION
. MODULE BASED
. PR, that was the shorten version of PARTIAL RECONFIGURATION
And nowadays, PR is fully integrated into Xilinx tool flows.
Xilinx has been always interested in innovating and in trying to provide to the designers
tools capable to answer to theirs needs.
Over the last two decades they’ve been able to reinvent their tools quite well.
They started with ISE and was basically a framework to create configuration bitstream
starting from a VHDL/Verilog description.
Xilinx realised that designers were looking for something more, something different.
They saw an opportunity in opening the FPGA world to people not fully trained in VHDL
and Verilog… and that is when EDK and SDK arrived on the market.
These tools were providing building blocks to the designer to allow him/her to assemble them
to create a working system.
One of the interesting part was that, if you were able to design your own IP in VHLD/Verilog
you were still having the opportunity of integrating it into a design that was created in a much easier way.
This means that, even if you were a skilled IP designer, you were gaining in productivity
because Xilinx was providing you a tool to design the overall system
where to embed/add your IP without having to worry of the entire system design by yourself.
The next bit step was the introduction of the support to the High Level Synthesis.
And this was done with Vivado HLS but this was not enough.
Xilinx was looking for more.
They were looking for tools to allow both an embedded system designer and an HPC one
to have the same design experience, or at least to gain the same benefits
in terms of productivity… and this is where we are now, with SDSoC and SDAccel.
Obviously there are other tools, I just named few examples to give you an idea
on how things have changed and companies were not the only one in following this race.