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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor asi_ka
Visitor
1,003 Views
Registered: ‎05-10-2017

PR: Separate Implementation of Reconfigurable Module

I think I'm not understanding PR process entirely. Just a clarification that I'm trying to use PR to achieve HD.

 

I'd like to synthesize top T and instance A separately, which I believe I'm doing properly by OOC synthesis runs.

- T: synth_design -mode default -flatten_hierarchy rebuilt -top T

- A: synth_design -mode out_of_context -flatten_hierarchy rebuilt -top A

 

I'd like to implement (place/route) T and A separately. I can implement T without A (using dummy modules as A), but I don't know how to implement A by itself.

 

To keep things simple, I'm placing T and A into separate SLRs with pblocks.

 

Thank you.

0 Kudos
3 Replies
Xilinx Employee
Xilinx Employee
936 Views
Registered: ‎11-17-2008

Re: PR: Separate Implementation of Reconfigurable Module

@asi_ka,

 

With the PR flow, the different parts of the design cannot be implemented truly out of context.  The top-level design (a.k.a. static, or in your case "T") can be implemented without any module, but you'd need to insert a grey box as a placeholder (by using update_design -buffer_ports).  Once the top-level is established, then you can implement any modules (e.g. "A"), but this is done within the context of the static.  That is to say that you must open the routed static design, insert a module, then run place and route.  Only the module is actually implemented, but the top-level must exist.

 

Without the top-level design locked and visible to A, how would Vivado know what resources are available or off-limits to A?  How would it know the clocks or resets to use, and how would it know how to connect the two parts of the design together?  This is what loading the static design first permits.

 

While it may seem that keeping T and A in separate SLRs would open up possibilities for out-of-context implementation, but it does not.  Vivado still has a fundamental assumption that A is a submodule of T and the two parts of the design are connected.

 

thanks,

david.

Visitor asi_ka
Visitor
910 Views
Registered: ‎05-10-2017

Re: PR: Separate Implementation of Reconfigurable Module

thank you very much.  I guess my main concern is place/route time.  Does the tool truly ignore the "locked down" regions? If so, I guess there's no penalty to implementing A along with a locked down T.

 

cheers,

0 Kudos
Xilinx Employee
Xilinx Employee
902 Views
Registered: ‎11-17-2008

Re: PR: Separate Implementation of Reconfigurable Module

@asi_ka,

 

No, the tools do not completely ignore the locked down portion of the design.  The rest of the design is loaded into Vivado and used for timing analysis, resource usage information, interface connections, and many more details.  It is simply not permitted to change, so the tools won't spend any time trying to optimize that part of the design.  In many cases we do see runtime and/or memory usage improvements, especially when the locked static design is the more complex or larger portion of the design, but every design is different.

 

thanks,

david.

0 Kudos