Intel® Quartus® Prime Pro Edition User Guide: Design Optimization

ID 683641
Date 4/03/2023
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents

6.5.7.1. Aggregation Use Case

Aggregation helps you see all the results from your compiles in one workspace. For example, you can use aggregation to determine whether particular timing failures occur commonly or occasionally. Focusing your optimization work on failures that occur commonly has higher impact than focusing on failures that occur occasionally.

Aggregation is helpful because of the stochastic nature of the Intel® Quartus® Prime Compiler. This stochastic nature means that the Compiler employs random heuristics in some decision-making processes. These heuristics perform well on average, but certain sequences can have unusually good or bad outcomes.

Often, the seed value that governs these random decisions is a project input that you can change to explore for a given design without changing the design. Because these random decisions are sensitive to specific netlist topologies, constraints, and design file content ordering, various different project element changes can result in the “seed effect” without any meaningful change to the design. Therefore, any given compilation result is not a precise measure of the quality of the design. While an individual compilation is the only source of programming files, you can run multiple compilations with different seed values in parallel, with each project containing its own seed value, to obtain the best results.

When performing aggregation, you are usually looking for common trends and limitations among the results. Since the compiles that you analyze with aggregation are different compilations of the exact same design, any random differences between the projects should cancel out, and any fundamental issues should recur.

Nevertheless, there can be certain projects and seeds that are outliers. You can then compare to the aggregate of the remaining projects. You can use this method to either explain unusually good or unusually bad results in the outlier projects in comparison with typical results.