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!

Reply

PR design flow simplification

Accepted Solution Solved
Highlighted
Contributor
Posts: 45
Registered: ‎02-20-2017
Accepted Solution

PR design flow simplification

To do my PR design, I have been following the flow suggested by UG909: I synth the static part of the design with a black box where the RM goes, I synth the RM ooc, then I open the dcp for the synth'd static design, insert the dcp for the synth'd RM, then implement. I am wondering, is this complication necessary? Why can't I just synth and implement the full design, as long as I flag the RM as reconfigurable? I just tried this. I just make a full design, set HD.RECONFIGURABLE 1 on the module I want reconfigurable and gave it a pblock. I am using project flow, though I did not convert it to a PR project. I just implement the design like a normal project and I get a full bitfile, as well as partial and clearing bitsreams (ultrascale arch) for the RM. I can then open the implemented DCP and replace the RM with a black box and save the DCP for use developing different versions of the RM. Is there any problem with doing it this way?

 

Thanks,

Jon


Accepted Solutions
Xilinx Employee
Posts: 440
Registered: ‎04-16-2008

Re: PR design flow simplification

Hi Jon,

 

Yes, there is a problem with this. The problem is optimization. Setting HD.RECONFIGURABLE on the cell at synthesis will prevent some optimization, but not all. For instance synthesis will push constants or do logic combining across the boundary (Static-->RP and RP-->Static that can result in optimizations to your static logic you weren't anticipating. The first configuration will go through fine and even work in HW. However, when you download a second RM that interfaces to Static in a slightly different way, thing may not longer work as expected because logic was optimized based on the connections of whatever RM you used initially.

 

The only way to guarantee optimizations by synthesis are PR compatible is to do OOC synthesis on all RMs, and have a blackbox for the RM during static synthesis. We can only support and guaranteed the PR flow if used as directed. Since you have to setup OOC synthesis for all subsequent RMs, and since static and all RMs can be synthesized in parallel, I don't think your method simplifies the flow much and could cost you a lot of time in debug.

 

Hope this makes it clear.

View solution in original post


All Replies
Xilinx Employee
Posts: 440
Registered: ‎04-16-2008

Re: PR design flow simplification

Hi Jon,

 

Yes, there is a problem with this. The problem is optimization. Setting HD.RECONFIGURABLE on the cell at synthesis will prevent some optimization, but not all. For instance synthesis will push constants or do logic combining across the boundary (Static-->RP and RP-->Static that can result in optimizations to your static logic you weren't anticipating. The first configuration will go through fine and even work in HW. However, when you download a second RM that interfaces to Static in a slightly different way, thing may not longer work as expected because logic was optimized based on the connections of whatever RM you used initially.

 

The only way to guarantee optimizations by synthesis are PR compatible is to do OOC synthesis on all RMs, and have a blackbox for the RM during static synthesis. We can only support and guaranteed the PR flow if used as directed. Since you have to setup OOC synthesis for all subsequent RMs, and since static and all RMs can be synthesized in parallel, I don't think your method simplifies the flow much and could cost you a lot of time in debug.

 

Hope this makes it clear.

Contributor
Posts: 45
Registered: ‎02-20-2017

Re: PR design flow simplification

Thank you for the informative reply!

Contributor
Posts: 45
Registered: ‎02-20-2017

Re: PR design flow simplification

Actually, I have a follow up question. Will this same problem apply if I am doing tandem + field updates? Should I follow the same black box/ooc flow if I plan to make use of field updates?

 

Thanks!

Jon

Contributor
Posts: 45
Registered: ‎02-20-2017

Re: PR design flow simplification

Just in case someone else has the same question, yes field updates are the same thing as PR and the design flow is the same. The tandem/FU example project makes this abundantly clear in the implementation scripts.