The basic device architecture is composed of blocks of CRs. CRs are organized into tiles and thus build columns and rows. Each CR contains slices (CLBs), DSPs, and 36K block RAM blocks. The mix of slice, DSP, and block RAM columns in each CR can be different, but are always identical when stacked in the vertical direction, thus building columns of those resources for the entire device. I/O and GT columns are then inserted with columns of CRs. In addition, there are one or more columns that contain PCIe® , Interlaken (ILKN), 100G multirate Ethernet MAC (MRMAC), 600G Ethernet MAC (DCMAC), and soft- decision forward error correction (SD-FEC). An HCS runs horizontally through the device in the center of each row of CRs and GTs. The HCS contains the horizontal routing and distribution tracks across the programmable logic region as well as leaf clock buffers. The clocking columns provide interconnects between HCS routing and distribution. Vertical tracks of routing and distribution in the vertical clocking column can connect to all CRs that are to the left and right side of it. There are 12 horizontal routing and 24 horizontal distribution tracks and 24 vertical routing and 24 distribution tracks (see the following figure). The top and bottom clocking rows have 24 routing tracks. 24 local horizontal distribution lines in each individual CR are driven from the clocking column through delay lines for local deskew. The purpose of the clock routing resources is to route a clock from the global clock buffers to a central point from where it is connected to the loads through the distribution resources. This central point of the clock network is called a clock root in the Versal® architecture. The root can be next to any CR in a device from where it is routed to the loads through the clock distribution resources. This architecture optimized clock skew, routing, and distribution resources can either connect to adjacent CRs or disconnect (isolated) at the border of the CR as needed.
The clocks can be distributed from their sources in one of two ways (see the following figure):
- The clocks can go onto routing tracks that take the clocks to a central point in a clocking column next to a CR without going to any loads. The clocks can then drive the distribution tracks from which the clock networks fan out. In this way, the clock buffers can drive to a specific point next to the CRs from which the clocks travel vertically and then horizontally on the distribution tracks to drive the clocking points. The clocking points are driven through leaf clocks with divide capability in that CR.
- This distribution scheme is used to move the root for all the loads to be at a specific location for improved and localized skew. Furthermore, both routing and distribution tracks can drive into horizontally or vertically adjacent CRs in a segmented fashion. Vertical routing drives a vertical distribution H tree to balance vertical delay to each row. The vertical distribution tree can also feed into the horizontal distribution on top and bottom of the devices. Routing tracks can drive both routing and distribution tracks in the adjacent CRs getting rebuffered while the distribution tracks can drive other horizontal distribution tracks in adjacent CRs through rebuffers as well. The CR boundary segmentation allows construction of either truly global, device-wide clock networks or more local clock networks of variable sizes by reusing clocking tracks.
- Alternatively, clock buffers can drive straight onto the distribution tracks and distribute the clock in that manner. This reduces the clock insertion delay.
Where GC inputs are used to drive XPIO corner banks, clock buffers BUFGCTRL and BUFGCE_DIV cannot be placed after MMCM because the sites are reserved. The corner bank affected is below PS (bottom left corner) and does not have full access to programmable logic resources. There is no restriction for the corner bank below the GTs at the bottom right corner. When you need to use an MMCM in the restricted corner bank, it is recommended that you insert a BUFGCE (after the MMCM) which in turn drives the BUFGCTRL and BUFGCE_DIV (and also other BUFGCEs). Refer to the Versal ACAP Hardware, IP, and Platform Development Methodology Guide (UG1387) for details on how to work with the restrictions.