4. General Partitioning Guidelines
4. General Partitioning Guidelines
The first step in planning your design partitions is to organize your source code
4.1 Plan Design Hierarchy and Design Files
hierarchy :
the partition includes the assigned instance and entities instantiated below that are not defined as separate partitions.
combine hierarchical partitions into a single partition, as long as they have the same immediate parent partition.
keep logic in the “leaves” of the hierarchy
files:
Create entities that can form partitions of approximately equal size.
Create each entity in an independent file.
Commands such as VHDL use and Verilog HDL include create dependencies between files, Avoid these types of file dependencies if possible.
4.1.1 Using Partitions with Third-Party Synthesis Tools
create a separate Verilog Quartus Mapping File (.vqm) or EDIF Input File (.edf) netlist for each hierarchical partition.
4.2 Partition Design by Functionality and Block Size
Keeping functional blocks together means that synthesis and fitting can optimize related logic as a whole
how many partitions --> the size
compiling small partitions is typically faster than compiling large partitions --> the size not too big
too many partitions can reduce the quality of results by limiting optimization --> each partition should contain more than approximately 2,000 LEs or ALMs
4.3 Partition Design by Clock Domain and Timing Criticality
keep clock domains within one partition.
Additionally, limiting the number of clocks within each partition simplifies the timing requirements for each partition during optimization.
4.4 Consider What Is Changing
As a general rule, create partitions to isolate logic that will change from logic that will not change.
compile one time and immediately preserve the results and not have to compile that part of the design again.
recompile only the changing part while the rest of the design remains unchanged.
