cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
4,047 Views
Registered: ‎08-10-2009

Running SLR Builds in Parallel for same device

Jump to solution

This is a methodology question for handling devices with multiple SLRs. The typical build flow is to confine modules to their respective SLRs via pblock constraints, handle the SLR crossings with proper pipelining/Laguna cells with appropriate constraints, and let the tool rip through the entire design. This is a sound approach, and theoretically, once it is set up, the user just has to push the button and let the tools do the work.

 

As an alternative approach (I'll explain the motivations below), is there a methodology that would allow the design's partitions over respective SLRs to be synthesized/implemented in parallel, and then allow the tool to quickly integrate everything up at the final stage?

 

There are three motivations to this suggestion.

 

1) Dividing the design up into SLR partitions and taking advantage of multiple cores in a workstation's typical microprocessor or to farm out jobs to other machines would presumably speed up the time to synthesize/implement a large complex design by at least Nx, where N is the number of SLRs in the target device. This is not to be confused with Vivado's ability to take advantage of multi-core threading.

 

2) Any timing issues related to SLR crossings would inherently be isolated to the final integration stage of this multi-stage flow.

 

3) Perhaps this is a debatable item, but confining the tool to focus on a single SLR design would give it more flexibility and less complexity in meeting the fit/timing closure restrictions, than if it had to handle a large design with its multiple SLRs in a single run.

 

Perhaps this methodology requires some "faux" wrappers on each of the independent SLR designs so that the multi-SLR device can still be targeted in all cases. For instance, the run with the SLR0-based design would contain a wrapper that instantiated the SLR0-only design with placeholder SLR-crossing logic (termination flops/pins) for the other SLRs.

 

Certainly, it's easier to push the button and let the tools rip on the entire design. But let's suppose you were embarking on a 3-6 month project targeting a large UltraScale device with multiple SLRs. Maybe it's worth it to do some legwork at the front end to build each SLR partition in parallel, which would presumably reduce synthesis/implementation flows from say 8 hours down to 3, a hefty savings for the many iterations that could be run over the course of the project.

 

If Xilinx came back and said, "Vivado already does this in effect when it builds multi-SLR designs," I suppose there would be no reason to spend the extra effort to force it to run the separate SLR designs using explicitly separate runs. But I'm not sure that is the case.  

 

Thanks for any thoughts on this idea.

0 Kudos
1 Solution

Accepted Solutions
Observer
Observer
7,189 Views
Registered: ‎08-10-2009

Re: Running SLR Builds in Parallel for same device

Jump to solution

Thanks for your thoughts. I'm thinking along the same lines. Very powerful, solid benefits, but maybe some homework needs to be done to get one's 'project' in shape to take advantage.

View solution in original post

0 Kudos
5 Replies
Highlighted
Guide
Guide
4,040 Views
Registered: ‎01-23-2009

Re: Running SLR Builds in Parallel for same device

Jump to solution

This can already be accomplished with the Hierachical Design Flow.

 

Using this flow, you can identify modules to synthesize, place and route "out of context (OOC)" with each other. If you have your design split up so that the top level module/entity is just an instantiation of the N modules/entities that form the logic in the N SLRs, then you can implement all N modules OOC.

 

The Hierarchical Design Flow flow is defined in UG905. Note that this flow requires the use of Non-Project Batch mode within Vivado - it is currently not supported in project mode...

 

Avrum

Highlighted
Observer
Observer
4,033 Views
Registered: ‎08-10-2009

Re: Running SLR Builds in Parallel for same device

Jump to solution

Nice! I will study this and see how this could be adaptable to what we are doing...

Regards,

John

0 Kudos
Highlighted
Observer
Observer
4,023 Views
Registered: ‎08-10-2009

Re: Running SLR Builds in Parallel for same device

Jump to solution

I understand some of the logistics for using this methodology. It certainly provides advantages in terms of turnaround time for builds, etc. Just wondering how often developers are willing to take the leap to employ this flow as opposed to sticking with an overall project-based flow. Do Vivado users find this to be a proven, reliable flow? 

Thank you.

0 Kudos
Highlighted
Guide
Guide
3,972 Views
Registered: ‎01-23-2009

Re: Running SLR Builds in Parallel for same device

Jump to solution

I have done a lot of investigation into the flow, and have done some "test" stuff with it, but have never really implemented an FPGA with it. I think you will find that it is not commonly used (which is a bit surprising, since it is incredibly powerful).

 

As a result, it is probably not the "smoothest" flow - I have had some problems with constraints (for the most part, things that can be worked around) and some other bugs (which have since been fixed).

 

But if you commit to this flow, you probably need to realize that you are going into pretty rarely used territory (at least I think so - others can correct me if I am wrong), and that there may still be some "gotcha's" out there, and working through them is likely to be slow and difficult... (Sorry).

 

Avrum

0 Kudos
Observer
Observer
7,190 Views
Registered: ‎08-10-2009

Re: Running SLR Builds in Parallel for same device

Jump to solution

Thanks for your thoughts. I'm thinking along the same lines. Very powerful, solid benefits, but maybe some homework needs to be done to get one's 'project' in shape to take advantage.

View solution in original post

0 Kudos