IDF Rules Checklist

The following checklist is a helpful set of items which you can use to verify that all the basic rules and guidelines for an IDF design are followed. The checklist can be used before, during, or after project design to help ensure the rules have been followed and to determine if overall good IDF design practices have been considered.

IDF Checklist

• The HD.ISOLATED property is applied to all isolated modules (except global clocking modules).
• All isolated modules have corresponding Pblocks associated with them.
• Pblocks must contain the required resource types in enough quantities to implement the intended function or functions.
• Map out Pblocks that need connectivity and those that need IOBs for better floorplanning strategy.
• Each isolated module must be in its own level of hierarchy.
  • Isolated modules cannot be nested
• A valid isolation fence (unused PU) must exist between Pblocks.
  • The fence is constructed indirectly by the space between isolated regions / Pblocks.
  • Refer to Table 1 for creating a valid fence.
  • Fence size is determined through schematic analysis and stated in rules and guidelines throughout this document.
  • Use the minimum fence width/height to maximize routing resources.
  • Bigger fence is not better. A bigger fence will not increase fault immunity but instead might impact timing due to a reduction in the availability of trusted routes.
• Isolated modules that communicate with each other must share a coincident Pblock edge separated by a valid fence otherwise routing might fail.
• Pblocks must enclose all available tiles in the device except the ones needs for minimum fence size (only the fence remains).
  • Do not leave large gaps because the gaps do not provide an advantage and can even result in routing difficulty.
  • Making the fence larger than necessary can make it difficult or impossible for inter-region signals (trusted routes) to cross the fence.
    • For example, IDF rules prevent routing touchdowns in the fence. A fence size of one PU (the minimum fence size allowed) prohibits the use of all routes (to cross the fence) that span only a single PU. Larger fences further limit the routing resources available.
• Only global clocking logic should not be isolated. All other logic should be associated with an isolated module and placed in the associated isolated Pblock.
• For global logic instantiated within an isolated module, the HD.ISOLATED_EXEMPT property must be set (TRUE) for the tools to route to or from that global logic.
• Feed-through signals are not allowed without buffering of some kind (LUT, FF, etc.).
  • Vivado does this automatically unless you choose to disable this feature
• Ports communicating between two isolated modules can only have one source and one destination.
  • Vivado does this automatically unless you choose to disable this feature
• IOBs must be instantiated or inferred inside isolated modules for proper isolation of the IOB.
  • Vivado does this automatically unless you choose to disable this feature.
• These are the limitations on Vivado automatically inserting IOBs
  • Input with multiple destinations, including top-level (i.e., reset to MMCM and isolated module)
  • Output whose input drives the IOB in question and at least one other region, including top-level
  • Output whose input comes directly from an input port of the isolated module in question
  • Bidirectional IOB where input and output do not go to the same isolated region
  • IOB with connections only to top level. Top level IOB driving only top-level logic will not be moved.
  • IOB was manually instantiated by you or the IP.
    • Directly instantiated IOB with the DONT_TOUCH property set on the buffer will not be moved. The DONT_TOUCH property can be inherited by the IP that instantiates the IOB or you can add it directly.
• Enable VIV by executing the Tcl command set_param hd.enableIDFDRC true in Vivado’s Tcl console. This step is not needed from Vivado version 2021.1 onwards.
• Run the AMD Vivado Isolation Verifier (VIV) on the elaborated design (constraint checking) to check for DRC violations for device and package pins (pin adjacency) and for IOB bank violations (if required).
• Run AMD VIV on the placed and routed (implemented) design to check for DRC violations for Isolation violations.