cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ali_flt
Contributor
Contributor
334 Views
Registered: ‎08-10-2020

partitioning and sharing MPSoC resources between users

Jump to solution

Hi,
I want to create a platform on top of a zynq Ultrascale+ MPSoC device where the resources are shared between several users (students). 
Let's say there is a university lab where students need no more than 50-60K of LUT for their simple designs so up to 4 students can share the resources of a single MPSoC Chip. 


My question is that is there any way to generate bitstream for just a specific partition of the FPGA and program just that part without changing the rest of design? For example, when 3/4 of the fpga layout is already in use, the 4th student generates his own bitstream and programs the last 1/4 without any interference with the rest of the design. 

I've thought of partial reconfiguration (Dynamic Function exChange), but the problem is  that we don't have the design of all users at the time of creating the vivado project and programming the FPGA and I don't know if it's possible to reconfigure a part of design after the generation of the bitstream of the whole design.

P.S.: I believe the concept I described above is already being used in FPGA-based cloud services so it can be done.

Many Thanks,
Ali

0 Kudos
1 Solution

Accepted Solutions
marcb
Moderator
Moderator
151 Views
Registered: ‎05-08-2012

Hi @ali_flt 

It sounds like Dynamic Function eXchange (DFX) would work here. There can be multiple Reconfigurable Partitions (RPs), where each RP can swap between several different versions (Reconfigurable Modules RMs). The main criteria would be the static part of the design remain the same for each user. The full initial bitstream could be loaded, and then each individual RP could be updated.

Each RP would need to have unchanging boundary connections, but not all RP boundary connections would need to be used at the same time. 

For the same project-mode design, each user could submit a set of RTL sources to add to the project.

Alternatively, in non-project design, users could synthesize and implement their portion with an out of context (OOC) synthesis, and then linking in the static that is shared by every user.

The one problematic portion would be that you would want the most robust RMs for your initial configuration, or the first time through the implementation. Some users might not be ready, and having a grey box implementation (mostly empty module) could lead to implementation failures. More information can be found from UG909. 

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug909-vivado-partial-reconfiguration.pdf

 

---------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
2 Replies
marcb
Moderator
Moderator
152 Views
Registered: ‎05-08-2012

Hi @ali_flt 

It sounds like Dynamic Function eXchange (DFX) would work here. There can be multiple Reconfigurable Partitions (RPs), where each RP can swap between several different versions (Reconfigurable Modules RMs). The main criteria would be the static part of the design remain the same for each user. The full initial bitstream could be loaded, and then each individual RP could be updated.

Each RP would need to have unchanging boundary connections, but not all RP boundary connections would need to be used at the same time. 

For the same project-mode design, each user could submit a set of RTL sources to add to the project.

Alternatively, in non-project design, users could synthesize and implement their portion with an out of context (OOC) synthesis, and then linking in the static that is shared by every user.

The one problematic portion would be that you would want the most robust RMs for your initial configuration, or the first time through the implementation. Some users might not be ready, and having a grey box implementation (mostly empty module) could lead to implementation failures. More information can be found from UG909. 

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug909-vivado-partial-reconfiguration.pdf

 

---------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
ali_flt
Contributor
Contributor
114 Views
Registered: ‎08-10-2020

Hi @marcb ,

Thanks for your answer. After researching about PR and FPGA virtualization now I have an overview of the subject. But two things are a challenging me at the moment:
1) Is there a standard automatic way to split the PL resources between four parts (except the part for the shell) or do I have to draw the Pblocks manually?
2) Do I need to implement NoCs on the PL for better wiring and implementation results or are AXI4 buses sufficient? If NoC is needed are there any sources for NoC implementation on Xilinx MPSoCs?
I would really appreciate it if anyone shares their information towards these questions.
Regards,
Ali 

0 Kudos