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!