Introduction - 2022.1 English

Vivado Design Suite User Guide : Hierarchical Design (UG905)

Document ID
Release Date
2022.1 English

Hierarchical Design (HD) flows enable you to partition a design into smaller, more manageable modules to be processed independently. In the Vivado® Design Suite, these flows are based on the ability to implement a partitioned module out-of-context (OOC) from the rest of the design. The following is a list of the current methodologies in the Vivado Design Suite.

Module Analysis
This flow allows you to analyze the module independent of the rest of the design to determine resource utilization and perform timing analysis. No wrapper or dummy logic is required; just synthesize, optimize, place and route the module on its own. Perform resource usage analysis, inspect timing reports, and examine placement results just as you would for a full design.

The Module Analysis flow implements a partitioned module or IP core out-of-context of the top level of the design. The module is implemented in a specific part/package combination, and with a fixed location in the device. I/O buffers, global clocks and other chip-level resources are not inserted, but can be instantiated within the module. The OOC implementation results can be saved as a design checkpoint (DCP) file.

Module Reuse
This flow reuses placed and routed modules from the Module Analysis flow within a top-level design, locking down validated results. Users can iterate on a specific section of a design, achieving timing closure and other specific goals, then reuse those exact results while turning their attention to other parts of the design.

Reuse of out-of-context modules requires knowledge of where the module pins and interface logic have been placed so that the connecting logic can be floorplanned accordingly. The preservation level of the imported OOC module can be selected, allowing for minor placement and routing changes if desired. This flow does not yet support moving or replicating the OOC implementation results to other areas of a device, or to a different device.

The Module Reuse flow has two variations, with the difference between the two variations being the mechanism for establishing the module constraints. Context constraints (which define how a module connects in the full design) and timing constraints are critical for successfully assembling the top level design with one or more reused modules.

The variations of Module Reuse are:

Bottom-Up Reuse
Using this methodology, the OOC implementation is done with little to no knowledge of the top-level design in which it is reused, and the OOC results drive the top-level implementation. This approach enables you to build a verified module (such as a piece of IP) through place and route for reuse in one or more top level designs. In this flow, the top-level design details are not known, so you must supply the context constraints. These define the physical location for the module, placement details for the module I/O, definitions of clock sources, timing requirements for paths in and out of the module, and information about unused I/O.
Top-Down Reuse
Using this methodology, the top-level design and floorplan create the OOC implementation constraints, and the top-level design drives the OOC implementation. This approach enables a Team Design methodology, enabling parallel synthesis and implementation of one or more modules within the design. Team members can implement their portions of a design independently, reusing their exact results in the assembled design. In this flow, the top-level design details (pinout, floorplan, and timing requirements) are known, and are used to guide the OOC implementation. This allows for OOC module pin constraints, top-level input/output timing requirements, and boundary optimization constraints to all be created from the top-level design.

All of these flows result in overall run time reduction by enabling the tools to implement only one module of the design, instead of the whole design. This allows you to compile many more turns per day, reducing time to design, verify, and meet timing on a per module basis. It also allows designers to actively work on a module even if the rest of the design is not complete or available.

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: Dynamic Function eXchange (UG909).