We are facing a design issue. Given the system requirements, we are unfortunately working with an underlaying platform which cannot provide us the necessary amount of resources required to implement our solution. In other words, we are done... The device is not big enough to provide us the necessary amount of resources! At this point, the easiest solution is obviously the one where we are going to by a new device that is going to guarantee us the necessary amount of resources. This is totally reasonable, but what if we are working in a dynamic context in which we need to adapt our system quite often to new requirements, to support new standards, or, as also already mentioned, to the addition of new features? We cannot continue to buy new devices, we cannot continue to update all the systems we have already deployed. This is not going to scale and it won’t be sustainable! We need something different! We are working with a reconfigurable technology because we were interested in being able to adapt our system to changes... we are now just facing one! We need to look at this problem from a different prospective. What we are really looking for is nothing more than a bigger device. Now, what if we are going to fake one? What if we are going to design a system that is going to use more resources than the one available? In other words, what we are looking for is a VIRTUAL DEVICE that will allow us to implement our system. Now, the real question at this point is: how to extend the area, A_d, of our physical device to be this new area, A_vd, for the required virtual device? That is exactly where the reconfiguration is coming to play. One way in which we can extend the area is by reusing it over time to implement a different set of resources! That is great! That is exactly what we need! Now this is defining a new challenge! We are now asked if it is possible, by using the reconfiguration, partial or complete, of the underlying FPGA to design a system that will meet the performance requirements! This means that we are looking for a design where the amount of resource that are going to be reconfigured will add a reconfiguration time, to implement them, that will be added to the execution time of our system by not exceeding the required execution time. What it has been just presented, is exactly the rationale behind the definition of new research challenges! The reconfiguration has been proven to be really effective in different scenarios, but it is introducing an overhead to the overall execution time. Furthermore, by doing this it heavily impacts on the final solution’s latency. Identifying a design that is meeting the performance requirement by effectively using the reconfiguration, is exactly one of the research objective when using FPGA-based solution to implement the desired system This is bringing us back to one of the key observation that we already made: the runtime and the design time are two phases that are close together as never before. We need tools that are going to be aware of such a scenario. We cannot just simply adapt design techniques, even if well known and effective, to this new scenario. We are facing new requirements and challenges, we do need to define, design, implement and share a RECONFIGURABLE-AWARE ECOSYSTEM. Furthermore, it is quite important to make a final observation on what it has been presented. In our previous graphical representation, I was saying that a certain amount of resources can be used to implement a system with a certain expected theoretical performance. That is true, but we have to keep in mind one thing. Whenever working with an FPGA, the resources we are referring to are not computational elements implemented on our device, but we are working with LUT, Slices, BRAM blocks, etc. So, within this context it is up to us, the system designers to decide how to use our FPGA resources to implement the computational elements that will be used to design our system. We do not necessary have pre-fab computational resources, addition and multiplications units, just to give you an example, that will provide us a certain latency/execution time. We may be interested in designing a specific computational element to have certain performance, therefore, that means that the available area on the FPGA has to be carefully used to implement what we are really looking for. It is not just implementing an application on a given architecture, it is more like designing the best architecture to implement the desired application while looking for the required performance.
