What we have seen so far was great, but it has a sort of limitations. We were constrained by having everything implemented in a single chip, everything was implemented in the context of an SoC and we now that, even if it is a reasonable assumption, unless we are working in the embedded system domains, systems can be much more complex. Therefore, what we are going to do now is to remove the single chip assumption and in moving to a SYSTEM implemented ON MULTIPLE CHIP, or SoMC. This scenario will be quite interesting and it will show how the reconfiguration taxonomy that we are already familiar with: EMBEDDED vs EXTERNAL COMPLETE vs PARTIAL DYNAMIC vs STATIC even if it is going yet to be valid, will need some careful “adjustments”/observations. Let us first familiarise ourselves with this new System-on-Multiple Chip. As it is shown in the figure, we are now working with a board that can host more than one FPGA. And and overall system which is composed by one host, but this is a simplification that can be removed moving to a scenario with multiple hosts, connected to, at least one board or, considering the context, one card, hosting more than one FPGA. Within this context, it is reasonable to consider an EMBEDDED RECONFIGURATION a scenario in which the element in charge of the reconfiguration management, the WHO, is placed onto one of the FPGAs. But, what if the WHO is going to move to the host. What if the reconfiguration will be managed by a software component executed on the “external” host processor. Well, on one hand we can consider this as a case for the EXTERNAL RECONFIGURATION. This is totally reasonable considering that the WHO is located outside the FPGAs, but what if we are going to move to a system level? Within this context, it is correct in saying that the reconfiguration is managed externally with respect to the reconfigurable elements, but it is still embedded in the system. Things can get even more complicated quite fast! Let us move to the COMPLETE VS PARTIAL RECONFIGURATION scenario. Now, what if we are in this scenario? We have three FPGAs and just a portion of one of them, the one in green, is going to be reconfigured. Which one is going to be your answer if I’m going to ask you to describe the scenario depicted in this figure? Is it a COMPLETE or a PARTIAL RECONFIGURATION scenario? As we can expect, this is a clear example of a PARTIAL RECONFIGURATION. Easy, no? Well, move from this view to the system view. As we can see now, we are in the scenario in which one of the FPGA is going to be completely reconfigured. And there we go… is it now a partial or a complete reconfiguration? On one hand, it is a complete reconfiguration because the FPGA under reconfiguration is completely reconfigured but, on the other hand, with respect to the resources available on the board, it is a partial reconfiguration, just one of the three FPGAs has been reconfigured. Starting from this scenario we can now try to compare the STATIC vs the DYNAMIC RECONFIGURATION. In this example, we are observing a complete reconfiguration of one of the three FPGAs while the computation on the other twos will be halted. As we can imagine this is a case for a STATIC reconfiguration. But what if one of the other two FPGAs won’t stop its computation? Well this situation is highlighting an interesting context. They did stop, in the previous case, but was the stop related to the reconfiguration process or not? If the answer is YES, the previous one was a STATIC reconfiguration scenario, but if the answer is NO, we are going to move to the same scenario we have here. They stopped, maybe because they were waiting for new data to be processed, now that they have it, well at least one of them, they can continue their computation. Now, the point here is quite simple. We do need definitions! But the reasons why we need them is not for a pure theoretical exercise, but to be able to present our work to other researchers and to have an understanding of the difficulties and runtime conditions we have to deal with while designing our system. For the sake of completeness, let us move to a third scenario in which we are going to have one FPGA that will be reconfigured while all the other two devices will continue their computation. What about now, is this an example of DYNAMIC RECONFIGURATION or STATIC RECONFIGURATION? Is it the case of a PARTIAL RECONFIGURATION or a COMPLETE RECONFIGURATION? We can say, to keep it simple, that to be able to properly define the kind of reconfiguration we have first to clearly identify the edge, the border of our system. Therefore, going back to our example, if we are going to identify with the system the set of the three FPGAs we can now easily say that this is a PARTIAL DYNAMIC RECONFIGURATION case, but this seems a way to provide a definition that is not really capable to capture the real needs of the system designer. As I was previously saying, this is not just pure theory, the definitions that we are using have to be useful at least in capturing the difficulties, the issues that we have to keep in mind while designing, implementing our system. Therefore, given this observation, rather than basing a definition of a reconfigurable scenario on the definition of the system, I would prefer, and it is worthy to stress that this is my personal view, to bind it to the intimate characteristics of our FPGA. Given the previous example, what was happening to the chip that was involved in the reconfiguration process? It was entirely configured, therefore this is not partial or even dynamic! We may think that the previous examples were all the scenarios we can come up with. Well, this is not true, we may have, at least, one more case. And pay attention to the fact that we haven’t taken into consideration the interaction with the host but in the case in which we were evaluating internal vs external reconfigurations. Now, in the scenario depicted in this figure we are observing a partial reconfiguration of one of the three FPGA. The reconfiguration, with respect to the single FPGA is PARTIAL and STATIC, since the rest of the elements on the chip are not making any progress in their computation, but with respect to the board it is DYNAMIC, the partial reconfiguration of the FPGA is happening while the other two devices are working. Again, we can make these scenarios as complex as we want, but the point here was just to highlight the importance of knowing what we are doing! FPGAs are examples of extremely powerful devices but we do have to have a clear understating on what we are going to need them for and of the rationale behind the needs of using them. Every decisions will be payed at design time, in implementing the system and, or maybe or, at runtime in properly managing the execution of our system. Nothing is going to come for free, but the advantages in using such devices can be huge! Within this context, to try to make some light on these definitions, I would like to suggest you always to refer to the reconfiguration which is going to be used per device, keeping in mind that, no matter what, a complex system is not going to be composed only by a pure or a 100% hardware implementation, but we are going to have a mix of hardware and software. That the hardware part may be implemented by using multiple devices. That data flowing into those devices may have to be properly partitioned. That this may lead to a runtime scenario where, even if the configuration per device is going to be complete, which means “simple” from an FPGA reconfiguration perspective, the management of this system is going to be all… but simple. This is definitely widening our spectrum of possibilities. These observations are helping us in understanding that working with an FPGA-based system is going to be much more than pure hardware design. This scenario is finally opening the door to the terrific world of FPGA-based systems design.
