Isolation Fence

Table 1 lists out the fence sizes in terms of PUs for the various user tiles.

To achieve isolation within a single device, the concept of a fence is introduced. The fence is just a set of unused PUs in which no logic is present. The results of the isolation analysis performed by AMD shows that if specific PUs is placed between isolated Pblocks, it guarantees that no single point of failure exists that can compromise the isolation between the two Pblocks. An example of fence placement between two isolated modules is shown in the following Figure 18. In this figure, two Pblocks are defined (each outlined in purple and red). The translucent PUs are part of the fence. The fence, like a Pblock, can be of any shape. The Vivado tools do not place any logic in the fence PUs.

Figure 1. Pblocks and Fences

As mentioned in Pblocks and Programmable Units, UltraScale+ architecture consists of Back-To-Back (B2B) interconnects. Due to the presence of these B2B interconnects, a fence encompasses both logical tiles on either side of the interconnect and their associated interconnects i.e., the whole Programmable Unit (PU). While this might lead to loss of usable resources like IOBs or BRAM and DPS etc., not having the whole PU as part of isolation fence does not guarantee isolation (protection against single point of failure).

Important: The fence location is not directly specified by the designer, rather it is created indirectly by applying the appropriate physical constraints of the isolated module’s PU resources to the corresponding module’s Pblocks. The PU resources that are not included in any Pblock, forms the Isolated Fence. It is up to the designer to ensure that this fence provides isolation to the isolated Pblocks in accordance with the fence rules. For guidance on which PUs can be used as a fence and the fence size, see Table 1.

Note: Except for GT programmable units, any Pblock that abuts to another Pblock creates a fence violation. When GT PUs abut, one I/O channel from either GT PU cannot be used at the abutment edge. This unused I/O channel becomes part of the fence. Other than the PUs listed in Table 1, no other PU or any tile resource can be used as a fence.

The minimum fence width is determined by a detailed schematic analysis. This analysis provides for a minimum of two faults (though in most cases it is much more) before the separation between two isolated modules is violated. While it is not mandatory to keep the size of the fence to this minimum as listed in Table 1, you can incur a stiff penalty for using larger fences. Since IDF rules prevent routing touchdowns in the fence (i.e., having a PIP in the fence), having a fence size larger than the minimum does not provide any more protection against faults but rather might lead to difficulty in meeting routing and timing constraints.

There are Trusted Routing rules that act as a filter to the router when implementing isolated designs (see Trusted Routing Rules). Any route that violates the Trusted Routing rules gets removed from the list of valid resources visible to the router. This is what creates the trusted routes – i.e., all possible routes that adheres to the rules such as no touchdown in fence, no PIPs in fence, and so on. If the fence in the design is too wide, all routes are removed and then the design will not be able to route (if communication across that boundary is intended). Hence, it is highly recommended to keep the minimum size fence width to maximize the routing resources available between isolated Pblocks. Additionally, if two isolated modules communicate with each other, then their corresponding Pblocks must be adjacent, i.e., side by side, along with a valid fence between them. It can give rise to issues if this is not the case.