Modular Design Tips

Following are tips for working with Modular Design. For additional help, use the resources at http://www.xilinx.com/support.

Constraints

The following constraints are used to implement a Modular Design. You can use these constraints to improve your Modular Design results. For more information, see the Constraints Guide.

AREA_GROUP

COMPGRP

FROM-TO

LOC (on module ports using PIN statements)

NET TPSYNC

OFFSET (on module ports through TPSYNC groups)

PERIOD

RESERVED_SITES

Note: This constraint is not supported for TBUFs, slices, multipliers, block RAMs, or CLBs.

ROUTE

TIG

Note: Many of these constraints are automatically generated by the Floorplanner when sizing or positioning modular regions or positioning module ports. Other constraints are automatically generated by the Floorplanner, PACE, and the Constraints Editor GUIs when constraining a design. In general it is not necessary to manually add them to your design.

Partial Reconfigurability and AREA_GROUP Constraint Attributes

Partial Reconfigurability, as described in "Partial Reconfiguration" chapter, is a form of Modular Design used for generating designs that can be actively reconfigured on a device while it is running. The following constraints need to be manually inserted into the top-level design UCF to enable this functionality. Their use is not required for strict Modular Design. All of these are supported as optional ‘attributes’ or subfields of the AREA_GROUP constraint:

MODE=RECONFIG

Module-based Partial Reconfiguration, as described in Chapter 5, "Partial Reconfiguration," is a form of Modular Design used to generate designs that can be actively reconfigured on a device while it is running. The MODE=RECONFIG attribute must be manually inserted into the top-level design UCF to enable this functionality. Its use is not required for strict Modular Design. The use of this attribute implies the following for the AREA_GROUP it is applied to:

Its area should be extended to include all device resources that are part of the same configuration frames.

Its internal routing should not consume device resources that lie outside of the boundary in the defined region.

The mapper should generate local constant signals for the AREA_GROUP. If this attribute is not specified, global constant signals are generated during finally assembly.

The format for this constraint follows:

AREA_GROUP module_name MODE=RECONFIG

Note: The MODE=RECONFIG attribute sets the ROUTE_AREA, RECONIFIG_MODE, and DISALLOW_BOUNDARY_CROSSING attributes correctly, so specifying each of these attributes explicitly is not necessary.

Types of Modular Design Errors during Partial Reconfigurability

The following consists of the types of routing or other errors that can occur during Modular Design:

Route areas for reconfigurable regions overlap.

Route areas for reconfigurable regions are non-contiguous.

Route areas for module designs targeted to the same reconfigurable region are of different size.

Routes are incomplete inside of a route area for a module design.

Connections between the clock_iob, global clock buffer, and DCM/DLL use non clock structures.

Nets have loads in multiple route areas.

TBUF bus macro are misaligned with respect to the route areas.

Note: All top-level TBUFs must be located with the LOC constraint to a TBUF site during the Initial Budgeting phase. This is necessary to avoid contention between the 3-state signals. For additional information on this topic, please refer to Answer Record #12437 at http://www.xilinx.com/support.

ROUTE_AREAs are defined on a slice boundary, when it should be defined on a CLB (tile) boundary. The RANGEs for an AREA_GROUP as defined in the PCF file can be different than the RANGEs for the ROUTE_AREA placed on the NC_ACTIVEMODULE object during mapping. This results in the placement are differing from the routing area, which could make completion of routing impossible.

Propagation of Constraints during Modular Design

When assembling PIMs, whether for a partial or standard design, or when running the Sequential Guide flow, the implementation tools generally guide and implement each module identically to its individual module implementation. However, conflicts may occur that cause PAR to reroute the initial routing. If a PIM that originally met timing fails to meet timing in the assembled design, this indicates that this particular type of conflict and rerouting occurred. Properly constraining the paths within the modules during final assembly ensures that any rerouting is done correctly. These constraints need to be stored in the top-level UCF rather than NCF since NGDBuild discards module constraints from the NCF file in a PIM. Following are some general guidelines:

Remove constraints on module ports before the Final Assembly phase.

For example, remove any PIN LOC, TPSYNC/FROM-TO, or TPSYNC/OFFSET constraints on module ports. When the module is used as a PIM, the tools may improperly constrain or over constrain the design.

Place OFFSET constraints on module ports relative to the actual clock pad net, not to the module clock port.

Note: This is a current limitation with Modular Design.

Before assembling modules or using a PIM for the Sequential Guide flow, copy the relevant constraints from the module’s UCF file to the top-level UCF file.

Copy only those constraints that apply to paths completely contained within the module. This ensures that all relevant constraints are considered during routing. Following are examples of constraints you should copy:

FROM-TO specifications (and associated TNM, TNM_NET, and TIMEGROUP definitions) for which both endpoints are within the module

PERIOD specifications (and associated TNM, TNM_NET, and TIMEGROUP definitions) for clocks that are used only within the module

Note: A PERIOD specification on a top-level clock controls paths inside any PIM that is clocked by that signal, so it is not necessary to replicate the specification.

TIG directives on nets or pins within the module, provided that the TIG is global (that is, it has no value) or applies to a specification (TSid) that has also been copied

Note: You can enter global and top-level constraints with the synthesis tools, but most module-specific constraints must be entered manually or using the Constraints Editor or Floorplanner. See the online help available from each of these GUIs for more information.

Design Size and Performance

To take full advantage of Modular Design, use this design flow with large designs that have been created with Modular Design in mind. When working with very large designs the issues of memory usage, run time, and sheer complexity often make implementation difficult. Because Modular Design allows multiple designers to work in parallel and make changes to previously implemented modules in an assembled design, overall efficiency is improved when compared with implementing a large, flat design. These advantages include reduced run time overall and efficient use of resources.

Note: Modular Design can be used on small designs to learn Modular Design techniques, but many of the steps may be burdensome and complex for a small design.

MAP Report

After the Active Module Implementation and Final Assembly phases, review the following sections of the MAP report (MRP file) to help improve your area groups in the top-level floorplan:

Modular Design Summary

You can use this section to help you do the following: determine which components of your design are part of a module, distinguish whether you are running a partial or full Modular Design Assembly, and verify your design.

Guide Report

If you mapped your design using a guide file, you can use this section to find out the guide mode used (EXACT or LEVERAGE) and the percentage of objects that were successfully guided.

Area Group Summary

You can use this section to find out the results for each area group. MAP uses area groups to specify a group of logical blocks that are packed into separate physical areas.

Note: If you want to debug NOMERGE errors and warnings after the Active Module Implementation phase, set the XIL_MAP_LISTPORTNETS environment variable. When you set this environment variable, the Modular Design Summary section of the MRP report includes a list of the port nets for the active modules.

PAR Reports

After the Final Assembly phase, review the “Guide Summary Report” section of the PAR report file (design_name.par). This section provides a summary of how many components and signals in the design were guided by the files in the PIMs directory.

For a more detailed report, review the Guide Reporting file (design_name.grf). This file includes the same “Guide Summary Report” section as the PAR file and also includes a “Detail Report” section. The “Detail Report” section contains a section for each PIM guide file. Each of these sections contains the following information about the components and signals that PAR guided or attempted to guide in the final design:

Guided comps located in the guided site

This section lists the components that were matched and guided from the PIM to the final design. It also lists the component’s location on the chip.

Guided comps unable to be located in the guided site

This section lists the components that were matched but could not be guided in the final design based on their location in the PIM. It also lists the component’s location on the chip.

Components in the Guide File that did not match Placement

This section lists the components in the PIM that could not be matched in the final design.

Signals in the Guide File that did not match

This section lists the signals in the PIM that could not be matched in the final design.

XFLOW Automation of Modular Design

You can use Xilinx’s XFLOW command line tool to automate the Modular Design flow. See "XFLOW" chapter for general information on this tool. For information on the flow types specific to Modular Design, see the following sections: