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.