Partial Reconfig Project vs Non-Project Mode

[jsammy]

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?

[davidd]

@jsammy,

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.

[jsammy]

@davidd,

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

[davidd]

@jsammy,

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.

[jsammy]

@davidd

Thanks for the thorough explanation!  Things are becoming clearer for sure.

A few follow-up questions:

1. Is there any advantage in the quality of the static results by using project mode and co-locating all of the RMs into sub-configs within one project (versus distributing a locked static design that was generated with a stand-in RM)?  Put another way, does the sub-config implementation do some sort of joint solution of the static region or is the static design locked after the initial implementation for all subsequent sub-configs?  I gather from your previous response that the latter is true, but I just wanted to make sure.
2. "we don't support importing a routed checkpoint as a starting point" - Is there any plan to support this on the current roadmap?
3. As far as distributing the complete project, are there any license implications that I need to be cognizant of if the static section includes licensed IP?
4. What is the recommended way to distribute a complete project?  I found the File > Archive Project menu option which seems to be a good candidate.

Thanks for your continued support on this issue.

-Jae

[davidd · Accepted solution]

@jsammy,

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.

[jsammy]

@davidd

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

[Anonymous]

@davidd 

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.

[davidd]

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.

[Anonymous]

@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,