Hi! What I'm going to show you today in this class are the differences in between the moudle based and the partial configuration design flow to design an FPGA based SOC with dynamic reconfiguration capabilities. Now, starting with the overall system we can have, as we know, a configurable functional unit one, reconfigurable functional unit two and a set of logic that are going to be included in this static logic which is basically in charge of taking care of their configuration as an example. Now, in order to be able to connect all these modules together we need to design the proper communication infrastructure. This is great! This is just an overall ideal representation of our flow. Now, let's try to see how we can have a kind of a logic view of this system. So, what we're going to design now is the logic view and what we are going to have next is the physical view. So, basically the idea is that in the logic view we are going to have the idea of our system while in the physical view we are going to see how to move from the idea to the physical implementation. Now, within this context we know that we are working with the SOC so we're going to have just one FPGA which is going to be used to implement our system. We have static logic that in the module base has to be constrained so here we're gonna have our static logic. Now, the kind of interesting thing here is that we have the communication infrastructure that was also in here: this green one was the communication infrastructure. With respect to the logic view in a model based system what we're going to have is that the logic infrastructure has to remain consistent no matter what and no matter how many reconfigurable units we are going to have. So, because of this we're going to consider the communication infrastructure as part of the static logic. Then we may have also fix the logic that is going to be used to take care of the other configuration. So, in the fixed logic we're going to have a soft core as an example where we're going to run the software that is going to take care of the runtime support for the partial reconfiguration or we can just have the reconfigurable manager or a configurable core if you want. Now, what is missing here is how we are going to consider this remaining part. Well, this remaining part is going to be used to implement the reconfigurable functional unit, so we're going to have the reconfigurable function unit two, we're going to have the reconfigurable function unit one and the way in which we are going to do this is basically by saying a configurable function unit one, reconfigurable functional unit two and no matter what even if you're going to have more reconfigurable functional unit here so let's say generic and reconfigurable functional unit and we're going to have it implemented in here reconfigurable functional unit n. Now, because of these we are going to have also the communication infrastructure that is going to move to connect also to this element. That's great! But this is just a high view of our system, this is not enough. What we have to do is to try to see how this logic view can be finally implemented in the real FPGA and we're going to do this by using both the moudle based and the partial reconfiguration flow. With the module base flow what we are going to do is basically this: we're going to have again our FPGA and now we have to implement the static logic. The static logic in the module base has to be constrained, which means that we have to go through the initial budgeting phase, as we know, and by doing this we are going to have a kind of an idea of the number of resources that we're going to use in order to implement the communication infrastructure the fixed logic and the let's say overall static logic and by doing this we can say that this amount of area in the FPGA is going to be used to implement the static logic. Now, how many reconfigurable regions are we going to implement in our FPGA? For sake of simplicity what we're going to say is that in order to be able to have a mapping in between this set of reconfigurable functional units from one to n we're going to need a kind of an organization that is going to allow us to say: two reconfigurable regions, reconfigurable region one and reconfigurable region two are going to be instantiated and used in order to be able to implement those reconfigurable functional units at runtime Obviously, as we know, this is not something that is in the module base and this is exactly where the university effort is coming into play to complete somehow the work done by excellence as an example in designing the module based and the universities are basically working on providing you solutions to see how to map those reconfigurable functional units on the reconfigurable region in order to allow you to implement your system on the actual FPGA. So, this is a reconfigurable region one and this is a reconfigurable region two. Now, because of this we know that at runtime we want to have a reconfigurable functional unit one and maybe reconfigurable functional unit two implemented in here while we're going to have a reconfigurable functional unit three and reconfigurable functional unit n implemented in here That's great! That means that we need someone that is going to be able at runtime to try to swap in and out of these reconfigurable functional unit from this reconfigurable region and this is going to be done by the element in the static logic. But we need something more and the thing which is missing is the communication infrastructure. So, basically what is going to be needed is a set of hardware macros that are going to be instantiated at the edge of the reconfigurable region and the static one in order to allow us to guarantee the communication infrastructure in between all these elements to allow the input and output of data once that a reconfigurable functional unit is going to be implemented By doing this we are going to have a kind of extra fixed route in logic: let's say that this one is going to connect this data logic with the function unit implementing the reconfigurable region one and this is something that is going to be connected here and as we can see this one can go here and here. So, that means that we need something that is going to allow us to cross the boundaries of reconfigurable region one to go from the static logic to the reconfigurable region two. This one can also be used to do something like this, as an example. So, that's great. This is exactly what is constraining and defining our moudle based: we need reconfigurable region information in order to be able to guarantee that each reconfigurable functional unit is going to have a proper area and set of resources at runtime; We're gonna have the static logic that is going to be used to take care of the reconfiguration of the remaining reconfigurableregion area and also the communication infrastructure that has to be guaranteed in order to be able to move the data from the static logic to the reconfigurable region, whatever is going to be, or may be even between the reconfigurable region itself, so it can be also the case in which we are going to have a streaming application where the static logic has to communicate with the reconfigurable region one and maybe the reconfigurable region one has to communicate with the reconfigurable region two. So, that is the reason why we have this here and from a logic perspective what is happening is basically that what we may have is something like this. So, a direct communication between a component that is going to be placed in the reconfigurable region one with something that is going to be placed in the reconfigurable region two, in this case a reconfigurable functional unit with the reconfigurable function unit two. This is great and this is taking all the advantage of a modular based design but at the same time we can see that there is some sort of overconstraining: this region is spending the entire rate of the FPGA; we are going to replicate a lot of the communication infrastructure in order to guarantee the persistency in the static routing; and we have a static logic which is constrained in a specific area. This was good. This was the way in which we were use of doing things, but this is also the reason why we moved from the moudle based to the partial reconfigurable flow. What we are going to do now is to see how the same logic view is going to be implemented in a physical view by using the PRI design flow. So, the pure flow has been introduced since the Vertex 4 went to the market and the reason is quite simple: the Vertex 4 were the first FPGA provided by Xilins that were allowing a bidimensional floor planning. So, with respect to this let's design our FPGA: we have our chip and we want to implement the static logic within this chip. That can be done but one of the ideas is that the way in which we are going to do this is going to be completely different from the previous one and a way in which we are going to do this is by just simply synthesizing the static logic and placing and routing it on the FPGA by letting the fixed static logic to be aware of the fact that we're going to have a set of reconfigurable functional units. So, we are going to do this is by simply identifying the reconfigurable region where we are going to map the reconfigurable function unit one to n and just to keep it consistent with the previous example we are going to have just two reconfigurable regions: so let's draw one here (reconfigurable region one) and one here (reconfigurable region two) Just to keep it simple here I'm not really paying too much attention on the way in which I'm going to design the two reconfigurable regions but obviously we have a constraint that has to be respect like: the column width and CLB and the fact that the height has to be multiple of the frame. Now, by doing this we are providing information to the static logic that there are two reconfigurable regions, so wherever we are going to map the fixed logic and the communication infrastructure we're going to try to minimize the overlap, the crossing in between the study logic and this element. We may have some of these because of some routing constraint that we may have, so we're going to have our static logic spending here, here, generally speaking, I'm not really drawing it but we may host some lines crossing this component because of routing purposes: maybe connection with the i/o block and so and so forth. That's good, but that is only because of the static part. Now, what we are going to do is to guarantee that the communication infrastructure in between the static and the reconfigurable functional units that are going to be implemented in each reconfigurable region is going to be guaranteed. That means that we're going to fix the interfaces in between the reconfigurable regions and the remaining logic. By doing this what we are going to do is basically also continuing the routing of the element to guarantee this: there are very simple things here. That's great! Now, how each reconfigurable function unit is going to be implemented in the reconfigurable region is quite simple. We know from the previous example that reconfigurable region two was used to host reconfigurable function unit one and the reconfigurable function unit two while the reconfigurable region one will be used to host the reconfigurable function unit 3 to reconfigurable functional unit n. Now, what is going to happen in the implementation of the partial reconfigurable module using the Xilinx terminology of our reconfigurable function unit one on the reconfigurable region two is quite simple: whenever we are going to have the place and route of this reconfigurable functional unit in this area we are going to provide information on the static routing that was belonging to the routing and mapping of the static logic. By doing this the place and route for the reconfigurable functional unit is not going to use this set of resources that has to be guaranteed to implement the static routing of other elements. And this is the physical view if we want physical view of our system. Now, one thing that is quite important to notice is that the idea was quite simple: the physical view is not much different from this one but has some very important differentiations. The first one is that in here we are just providing the set of all the reconfigurable functional units that are basically the module that we are going to have whenever defining our system, while in the physical view we are packing together this set of reconfigurable functional units over the reconfigurable region. And this is something that neither the moudle based or the partial reconfiguration one was doing. That is exactly where as an example the university effort is coming to play. The other one is that we have the communication infrastructure here - that is just a bunch of lines - while here it's extremely important because we need to prevent that routing information are going to be deleted in switching between one reconfigurable functional unit to another one. The other one is that we have a kind of a fixed logic here, which is one of the modules, that is taking care of the reconfiguration. Here is going to be spread somewhere in the static area, as an example, by designing a soft core maybe a microblaze that is going to take care of the reconfiguration, but again when to swap in between the reconfigurable function unit one and the reconfigurable function unit two is something that has to be decided at design time in order to properly design the necessary differences that are going to be loaded because of the microblaze into the region in order to swap in between the reconfigurable function unit one and the reconfigurable function unity two. How to do it and when to do it? this is something that is going to be taken care of by a runtime controller which is something again which is not in here, so that is something where Universities have been done a lot of work to be able to design this runtime controller. So, that's it with respect to the logic view with respect to the physical view starting from the system design. Just to wrap up everything together: we have the system; in the system we are listining all the reconfigurable function units, that are basically modules in this view; and the static logic. Then we're going to have a logic view of this system where we're going to group things together in something that is going to be more or also communication oriented with respect to the previous one. Then we have to move from the logic view to the physical view and by doing this we are going to use moudle based , difference based or partial configuration design flow that are the two, the moudle based and a partial configuration design flow, that I showed you today, but also taking into consideration that these are the really important things, constraints, that are specific for the design flow that we are going to use
