Reading and Interpreting a Complexity Report - 2025.2 English - UG906

Use the Complexity Characteristics table to evaluate Rent exponent and average fanout values for each level of hierarchy. These metrics help identify potential placement and routing issues early in the design process. By comparing the measured values against typical ranges and considering other contributing factors, you can determine whether corrective action is needed to improve design performance.

1. Review the Complexity Characteristics table to identify the Rent exponent and average fanout for each hierarchy level below the top level.
2. Compare each metric to these ranges:

   Rent exponent

   • 0.0–0.65: Low to normal complexity; no potential problems.
   • 0.65–0.85: High complexity, especially with more than 25,000 total instances.
   • Above 0.85: Very high complexity; with a high number of instances, implementation can fail.

   Average fanout

   • Below 4: Normal.
   • 4–5: Can cause placement difficulty and congestion. For SSI devices with more than 100,000 instances, placement in one SLR or across two SLRs can be problematic.
   • Above 5: Implementation can fail.

3. Always check the Total Instances column along with the Rent exponent and average fanout. Larger modules with high values have higher priority for review. Smaller modules (under 10,000 instances) can sometimes have high values without placement or routing issues.
4. Keep in mind that complexity metrics alone might not predict routing congestion. Review congestion reports after placement to assess the effects of I/O constraints, floorplanning, and macro primitive locations.
5. Consider these additional factors when interpreting results:
   • High LUT6 percentage increases average fanout and possibly the Rent exponent.
   • Many RAMB or DSP primitives can raise the Rent exponent due to high connectivity.
   • High metric values for some hierarchical instances might not be problematic because the placer can split them into easier groups of logic.
   • Low Rent exponent modules can still cause congestion if large dataflows pass through them.
6. If a large module with high metrics causes congestion or timing issues, take these actions:
   1. Reduce module connectivity by preserving hierarchy to limit cross-boundary optimization, which reduces LUT6 usage and netlist density.
   2. Reduce LUT inputs during synthesis.
   3. Disable LUT combining in synthesis.
   4. Use a Congestion Strategy or SpreadLogic placement directive. For SSI devices, try multiple SSI placement directives.
   5. Apply simple floorplanning at the SLR level (SSI devices) or clock region level (general) to separate congested logic or guide placement toward a previously successful configuration.
   6. Use QoR suggestions and Intelligent Design Runs to address congestion automatically.