As we have seen, hockey and recovery from damages gave us the chance to move a little bit forward
in trying to understand why we may be interested
in looking into runtime reconfiguration.
As in the hockey case, we may be interested in having a system able to adapt itself
after the chip has been fabbed to deal with faults, to try to take advantage of the reconfiguration
to recover from damages.
Within this context, as an example, reconfiguration can be used to bring the system back
to a known and safe state whenever a fault is going to be detected.
Under a different prospective, we may be interested in looking intro structural modifications.
Interfaces are going to remain the same, but the internal implementation of our system
can be different.
It can evolve to better respond to runtime needs.
The more the system is going to be executed, the better it can answer to specific needs.
Let’s consider an example from the mobile context.
External factors, like the surrounding temperature, may have huge impacts on our system.
Being too hot or too cold can impact the way in which our mobile is running out of battery
Having a system capable to adapt the underlying computing infrastructure to implement
the same functionality in a different way can provide us a better energy saving.
This obviously may come to a cost: maybe this new implementation is not going to perform
with the same quality of the previous one, but if the only other solution
was not to have a working device, well, I think it can be a reasonable cost to be paid.
Finally, but the list can be longer, and I don’t want to spoil future discoveries
that we are going to have through other classes, we may be interested in having a system able
to adapt its behaviour because of the surrounding environment in which it is used.
And believe me, I know exactly what I’m talking about!
According to the surrounding conditions, a system may be interested
in behaving in different ways.
Let’s go back to our mobile context, but this time do not consider only mobile phone,
let’s take into consideration a vehicle, a van, a motorbike, what about a car?
Ok, let’s go for it.
Nowadays we are used to driver cars that are enriching our driving experience
with a lot of information gather by the car itself.
We may have information about the pedestrians, and this is definitely an important information!
Now, driving the care to work at 6.30am is definitely characterised by different scenarios
from the one that we may have by driving at 8am,
just right in the middle of the rush hours.
Because of this, our pedestrians identification system may behave differently.
One thing is being able to detect just few sporadic pedestrians,
who may also being moving slowly because of the time, remember, it is 6.30am,
and another one is being able to detect them at 8am when there moving like crazy
because they are getting late to go to work and, because of this,
they are rapidly changing the way in which they are moving.
The amount of data that has to be processed is different,
but the response time it is not.
The latency in being able to collect information and in providing useful feedbacks to the driver
is not changing just because the context is getting more complex
and the system has to be able to adapt its behaviour to deal with it.
Because of all these needs we have to create a recofigurable-friendly ecosystem.
Keeping it simple, reconfigurable logic is a special kind of hardware circuit
that can be reconfigured, after fabrication, into whatever logic the user desires.
The reconfiguration process is often simply programming some kind of configuration memory.
There are already mobile phones on the market
that have reconfigurable logic embedded into the system.
However, consumer products have not yet all followed on this trend,
which has however swept the scientific large-scale computing world.
And this is bringing us back to our starting assumption:
a recofigurable-friendly ecosystem is needed.
Reconfigurable computing is breaking down the barrier between hardware
and software design technologies.
The segregation between the two has become more and more fuzzy because both are programmable now.
Reconfigurable computing can also be viewed as a trade-off between general-purpose computing
and application specific design.
Given the architecture and the design flexibility, reconfigurable computing has catalyzed
the progress in hardware-software codesign technology and in a vast number of application areas
such as scientific computing, biological computing, artificial intelligence, signal processing,
security computing, control oriented design, to name a few.
It is not guarantee that in these applicative domains we are going to have
the presence of an hardware design expert: this means that we have to work towards the definition
of a reconfigurable-friendly ecosystem that will make these technologies open to everybody
who is going to find benefits in using them!
It has been a pleasure staying with your for this introductory class!
We’ll talk soon again to explore more this fantastic world of reconfigurable computing systems!