UPGRADE YOUR BROWSER
We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!
11-09-2018 02:46 PM
I am trying to understand the nuance between Project vs Non-Project Mode as it relates to Partial Reconfiguration.
After reading over UG909 and doing some testing with a working Project Mode core, it seems like Project mode requires you to have all of your Reconfigurable Modules combined into one project so that you can create a config and a child run for each combination. Where as Non-Project mode allows you to build your static code, lock the implementation, and then separately import this checkpoint and build the reconfigurable module bitstream by itself. i.e. each RM project could be given a locked static checkpoint and generate its own RM bitstream
Under a scenario where company A creates the static section, company B creates reconfigurable module 1, and company C creates reconfigurable module 2 is it recommended to use the Non-Project mode? Is the Project mode even possible in this scenario? If so, how would Project mode be used to allow company B and C to create their own RM bitstreams without needing to communicate with one another?
11-16-2018 09:26 AM
A few follow-up answers:
1. There is no difference in the back-end place and route tools whether you are running in project or non-project mode. You have the same sources and same constraints and are running the same steps (opt_design, place_design, etc.). What would affect results would be which RM is present during that first run when static is first implemented. After that, static is locked and cannot change.
2. There are many improvements on the horizon, but I can't really comment on specifics here, as plans can and will change, and this item is not at the top of the list. But we do have use cases, especially with multi-user platform designs, where this could be quite useful.
3. Yes. Any licensed IP in the design will need to find that license, even if the IP is in static and does not need to be reimplemented. The existence of that IP triggers a license check, even to open the static checkpoint. We do have strategies in place to avoid this requirement in multi-user use cases -- this feature is committed and will appear next spring.
4. Yes, archive project is the best way -- it basically zips the project up into a compact (relatively speaking) bundle. Make sure remote sources are included in the archive.
thanks,
david.
11-12-2018 10:28 AM
These two modes are simply different tool flow paths to get to the same fundamental result -- full and partial bitstreams. Project mode takes care of some of the critical details such as checkpoint dependencies, locking static results, pr verify, etc.; you are responsible for these details in non-project mode, but that gives you more flexibility in how the sources are managed.
Either methodology can be used for your use case here. The main question is what environment companies B and C prefer to work in. Company A will need to supply the locked static design result for both B and C to work with, and this could just be a static checkpoint, or it could be the full project with the parent run completed. Companies B and C will add their modules in their respective partitions and compile that part of the design. They can run pr_verify against the locked static design and generate partial bitstreams independent of each other. They can share these bitstreams and RM checkpoints back with Company A.
As B and C work on their own, they don't need to have any information from each other. Partition C can be a grey box or contain dummy logic while Company B implements their design, and vice versa. As long as the static remains locked and consistent for B and C, you're good to go. Any issue or concerns for what information is shared from A to either B or C?
Where is the hardware in this scenario, and who is in control of device programming? Ultimately that is the key question. The owner of the hardware needs to manage bitstream delivery and ensure that the static image stays in sync with all partials.
thanks,
david.
11-12-2018 12:43 PM - edited 11-12-2018 01:22 PM
Thanks for the reply.
Delving deeper into doing this with project mode.
Company A would be providing the locked static section to Companies B and C in the form of a "toolkit". B and C each have their own hardware that they can use independently.
In project mode, Company A can implement their locked static section using a greybox for the RM. But UG909 mentions implementing your most complicated RM first. Will this be an issue for B or C if their designs are complicated? Furthermore, what is the deliverable from A to B&C for the locked static design. Is there a .dcp that encompasses everything that B|C would need, or will the entire project need to be delivered in the form of a tarball? How does one go about locking the static section in project mode? I also didn't see a way to "import" a locked static implementation.
I'm encouraged to hear that Project-mode would work for this conop, as we are already using Project mode. I'm just not seeing the big picture yet.
Thanks again,
Jae
11-12-2018 02:04 PM
Okay, so Companies B and C (and so on) are completely independent of each other, they are each just filling in an empty space within the base design provided by Company A. No problem.
The "most complicated" strategy is just a recommendation to achieve the highest possible quality static design based on the Reconfigurable Modules (RM) currently available. In a case like this, Company A will want to optimize their static design to 1) leave as much room in the Reconfigurable Partition (RP) as possible, as they don't know what RMs will be coming in later, and 2) optimize the boundaries for timing closure, leaving as much slack as possible. The former is a matter of packing the static design as compactly as possible, and the latter can be achieved with a dummy module with appropriate timing constraints and perhaps some location constraints to guide dataflow. Hopefully you would have some representative module designs to test any static that is created before releasing it to these other Companies.
Yes, the routed, locked static-only checkpoint is the minimum Company B or C would need to implement their module, but with just that one file they're working in non-project mode. In order to get the automation of project mode, they would need to receive the full project -- we don't support importing a routed checkpoint as a starting point. So it's a question of what you (I'm assuming you're Company A here) want to share to guide them, knowing they'd have access to anything you share. Locking a static checkpoint is just a matter of running "lock_design -level routing" after removing anything from the RP using "update_design -black_box" and this is done automatically in project mode. With this checkpoint anyone could use that as a starting point for inserting a post-synthesis module netlist for implementation in that context.
So to sum up, you have two options. If you start in project mode and build PR design with just a Parent configuration, you can implement and lock the static design. You have two ways to share this with your customers for filling in their Reconfigurable Modules:
1. Send them the complete project and say "your stuff goes here" while pointing at the RM for the first child configuration and beyond.
2. Copy the <design>_routed_bb.dcp file from the <project>.runs/impl_1 directory and share that. You'd want to create and share a non-project run script for them that implements a child configuration from that starting point.
Either way you'll want to provide detailed instructions and/or guidance for things like the instantiation template and connectivity, design behavior before, during and after PR, and remind them not to unlock the static results.
thanks,
david.
11-14-2018 10:29 AM
Thanks for the thorough explanation! Things are becoming clearer for sure.
A few follow-up questions:
Thanks for your continued support on this issue.
-Jae
11-16-2018 09:26 AM
A few follow-up answers:
1. There is no difference in the back-end place and route tools whether you are running in project or non-project mode. You have the same sources and same constraints and are running the same steps (opt_design, place_design, etc.). What would affect results would be which RM is present during that first run when static is first implemented. After that, static is locked and cannot change.
2. There are many improvements on the horizon, but I can't really comment on specifics here, as plans can and will change, and this item is not at the top of the list. But we do have use cases, especially with multi-user platform designs, where this could be quite useful.
3. Yes. Any licensed IP in the design will need to find that license, even if the IP is in static and does not need to be reimplemented. The existence of that IP triggers a license check, even to open the static checkpoint. We do have strategies in place to avoid this requirement in multi-user use cases -- this feature is committed and will appear next spring.
4. Yes, archive project is the best way -- it basically zips the project up into a compact (relatively speaking) bundle. Make sure remote sources are included in the archive.
thanks,
david.
11-16-2018 12:39 PM
Thanks again for all the help.
I look forward to seeing what comes in the future with Partial Reconfig, particularly on the license requirement.
I have marked this question as solved.
-Jae
09-09-2019 03:26 AM - edited 09-09-2019 03:31 AM
This post is much more informative than ug909.
* Any news regarding #3 (license)?
To use the (encrypted) static routed checkpoint as a starting poing: only the non-project mode is available.
I understand the project mode needs the entire project and not only the checkpoint file.
Do you see any problem encrypting the static checkpoint file to hide the company A's logic to company B and C? And vice versa?
* Would they be able to change anything from the static locked routed logic? The codes of all three companies need to be hidden.
* What would be the workflow with a single encrypted static checkpoint?
* What if the company B and C need FPGA pins not exposed in the interface/RM? I am really struggling finding information regarding that case.
09-09-2019 01:58 PM
Regarding #3, this has been tabled until next year, as we have prioritiezed Versal tasks for the short term.
In terms of netlist encryption, take a look at UG1118. When encrypting a netlist, you can control what is exposed or available, such as modification of the encrypted design to creation of RTL netlists or bitstreams. Look at table 6-2 for the details.
So this would hide company A's information from B or C, but I don't see a vice versa need. Companies B and C, if I understand the example correctly, would generate their own bitstreams from the locked static checkpoint they've been given, so Company A would never get anything back from B or C.
If B or C are going to add external pins to the design, A would have to define them and put that IO bank in the reconfigurable region. B or C would then select which ones they want to use (all, some, none), but the port list is defined at the top-level design.
I'll review UG909 to see what further clarifications I can add. At the very least a reference to UG1118 is in order.
thanks,
david.
09-10-2019 06:35 PM
@davidd Thank you for your reply.
I have different requirements than @jsammy.
Regarding the encryption: I mean the routed locked static checkpoint/DCP file encryption not the netlist as defined in ug835-TCL commands with the write_checkpoint command using -encrypt option. I would like to avoid Company B&C being able to unlock the static logic. Hopefully the encryption is enough to invalid any unlock functions.
Regarding the external pins, that's well understood, we expose all the PINs and we include them in the pBlock.
Thanks,