10-23-2018 07:28 PM
Reagind UG905, in pag5 I saw this:
IMPORTANT: This document applies only to 7 series devices, not UltraScale™ or UltraScale+™ devices. For more information about applications of hierarchical design in UltraScale and UltraScale+ devices, see Vivado Design Suite User Guide: Partial Reconfiguration (UG909)[Ref 6]
1. It comes to my attention that for UltraScale devices it points you to the Partial Reconfiguration User Guide, why is that?
2. Is it hierarchical design still used nowadays or this approach has moved to be tackled with partial reconfiguration?
3. is it any resources/tutorial about using hierarchical design with partial reconfiguration approach?
Thank for your help
10-31-2018 10:10 AM
Yes, I have thoughts and opinions on this.
1. Take a look at Appendix A of the Partial Reconfiguration User Guide UG909. This chapter discusses how to use the PR flow to meet in-context design preservation needs. Fundamentally, you build a PR design without the runtime management features, and you skip partial bitstream generation.
2. Yes, the approach for UltraScale/+ devices is to use the Partial Reconfiguration flow to meet design preservation needs. PR *is* a hierarchical design flow, as it allows to you lock down part of the design while you work on other parts.
3. Labs 2-4 within the Partial Reconfiguration Tutorial UG947 can be used to see how PR works, and it is this fundamental solution that you'd use for HD. Lab 1 is for 7 series, and labs 5 and 6 focus on the PR Controller IP, which you would not need.
Basically, as the silicon technology and Vivado software have both evolved, design performance has improved and many limitations have been removed. For example, you can include IO, clocks and transceivers in reconfigurable partitions (silicon improvement), and expanded routing footprints greatly reduce routing congestion (software improvement). Rather than build two very similar solutions, we focused our efforts on one, striving to make it as efficient as possible. Now this does not support true bottom-up implementation but that is something we're considering re-introducing in the future. But this PR-based solution does take care of many of the low-level details, such as the relative context of a module region, so that assembly of a full design becomes much easier than what would be necessary for an out-of-context flow.
09-09-2019 02:49 AM
09-09-2019 09:56 AM
For anything that is to be changed from one iteration to the next, it must be placed in a Reconfigurable Partition. This means all that logic, including IO components, clock buffers, transceivers, etc. must be under a single hierarchical top level (below top), and this module is mapped to a physical region on the device defined by a pblock. So all IO components must be instantiated as they cannot be inferred at the top level. Other than that, it should be business as usual once the wrapper layer of hierarchy is defined. More details can be found in UG909.