Implementing a module out-of-context has the following requirements.
- Each module implementation must have a Pblock constraint to control the placement. If a Pblock is not used, placement conflicts are likely during the assembly phase.
- Add the CONTAIN_ROUTING property to all OOC Pblocks. Without this property,
lock_designcannot lock the routing of an imported module because it cannot be guaranteed that there are no routing conflicts.
- Pblock ranges for each OOC module must not overlap. If a top-level design is to import multiple OOC module results, the modules must occupy separated regions in the device.
- Nested or child Pblocks are supported within the OOC implementation as long as the nested Pblock range is fully contained by the parent Pblock range, and the PARENT property is correctly set. See Pblock Constraints.
- All clock buffers (both in top and the OOC module) must be locked. Buffers inside the OOC module must have LOC constraints, and the locations of buffers in the top level should be identified by HD.CLK_SRC constraints. See Out-of-Context Design Constraints, for a description of the HD.CLK_SRC constraint.
- If the OOC implementation results are to be reused, it is strongly recommended that the OOC
module pins be locked down during the OOC implementation using HD.PARTPIN_RANGE or
The partition pins serve two main purposes in an OOC implementation.
- A partition pin creates a physical location to guide the placement of the associated interface logic. Timing constraints (set_max_delay) to and from the PartPins are needed to affect placement.
- A partition pin gives the router a point to route the interface subnet. Without PartPins the interface nets cannot be routed, and it is possible to create an OOC result where routes internal to the module block routing resources needed by the interface nets during reuse. This prevents the preservation of all OOC nets without causing an unroutable design.