A Typical Clock Network

A Typical Clock Network

A typical clock network (shown in Fig. 12.2 ) in a FPGA starts with a pin that is fed by an external oscillator. If a frequency modififi cation is required, you should feed the incoming clock to a MMCM/PLL and then into a global clock network via a BUFG. From this point it can access clock pins of basic logic elements like flfl ip- flfl ops and RAMs. There are many variants of this. This chapter explains your choices depending on your requirements and optimal implementation for UltraScale FPGAs.

Clocks Entering a FPGA

There are two primary places where a clock source will enter a FPGA. The fifi rst is a global clock IO or GCIO . In UltraScale, there are four P/N pairs per clock region. For single-ended clock, connect on the P side. From these inputs there is a direct connection to a PLL and MMCM or BUFGs.

The other main entry points are gigabit transceivers. Each quad has two clocks that can enter the FPGA. These clocks can be used in the fabric as is or can be used with some modififi cation of frequency. Access to MMCMs can be made through BUFGs. In Zynq MPSoC, there is a third source of clocks and that is the processing subsystem. These can pass clocks to the FPGA fabric.

Generating Clocks with Different Frequencies

Designs typically require many different clocks of different frequencies. FPGAs provide the facility to generate clocks of different frequency and phases using MMCMs and PLLs. PLLs can be considered as MMCMs with reduced features. Each MMCM/PLL can generate multiple output clocks at different frequencies and/or phases, over a wide range of frequencies. MMCMs/PLLs are usually driven by (a) clocks that come from external oscillators, (b) source synchronous IO interface clocks, or (c) other internally generated clocks.

A typical clock network.png

Usually you need to ensure that clocks supplied to these components should not stop. If they do, you need to reset these components. It is generally advisable to reset the components before using them.

Use the Clocking Wizard IP to make use of MMCMs/PLLs. This IP is part of Vivado IP Catalog , explained in Chap. 3 .

Zynq MPSoC components also have their own PLLs to change the frequency of input clocks to the subsystem. Additionally frequency change can be achieved within a gigabit transceiver, and clock division can be done in BUFGCE_DIVs and BUFG_GTs which are described next. Detailed analysis of Zynq and transceiver clocking is not covered here.

Accessing Global Routing

Clock buffers BUFGCE , BUFGCE_DIV , BUFG_GT, and BUFGCTRL instruct Vivado to use the special clock routing resources. There are no special requirements to come off the global routing. Collectively these are called BUFG*. There is a BUFG primitive, which is inherently a BUFGCE, but without using the enable function. Vivado can infer BUFG automatically or you can instantiate them. Alternatively, IP can include them via instantiation. Only BUFG buffers can be inferred. Other types of clock buffers have to be instantiated in your HDL or in IP.

The following buffers exist in clock regions that contain IOs:

– BUFGCE—It offers an enable/disable switch. There are 24 per region. This is the base primitive.

– BUFGCE_DIV—This is similar to the above but also can divide the clock frequency. There are 4 per clock region.

– BUFGCTRL—This offers muxing capability. This is required for clock switching or multiplexing. There are 8 per clock region. The following buffers exist in clock regions that contain GTs:

– BUFG_GT—The input has access from any of the transceiver clock sources.

These have dynamic divide capability. There are 24 per region.

The access to each of the BUFGCEs in each region is independent. Each of the 24 buffers can be accessed on the input side from any MMCM/PLL output, internal FPGA resource, or IO. However, the output side will drive a particular clock track. For BUFGCE_DIV and BUFGCTRL, the input sides are shared with BUFGCEs, but the output side is flfl exible. Figure 12.3 shows how BUFGCE uses different clocking tracks.

The complex connections of these buffers mean that generally Vivado should decide the locations of the buffers. You can place them at the clock region level through the command below, but Vivado will determine the track numbers.

BUFGCE output track usage by other buffers.png

Clock Routing, CLOCK_ROOT, and Clock Distribution

Due to additional clocking resources, UltraScale has introduced new terms. From the output of one of the BUFG*, the clocks travel on clock routing. This is new term to describe the wires after a BUFG. Each clock region has 24 of these tracks. The point at which the clock signal transfers to distribution resources is termed the CLOCK_ROOT . Distribution resources will carry the signal to flfl ip-flfl op clock pins and other endpoints. Each clock region has 24 of these too. They are mutually exclusive in each clock region, except that both will be used in the CLOCK_ROOT region. Figure 12.4 explains the terminology.

Clock roots can be seen after place design using the following TCL command:

report_clock_utilization –clock_roots

Vivado will approximately choose the geometric mean of the locations of the load on the clock tree to determine the CLOCK_ROOT. Balancing the clock root is important as it impacts clock tree skew which impacts timing. When interfacing to

Clocking terminology explained.png

Difference in delay due to clock root placement。.png

a GT, CLOCK_ROOTS may be placed close to the GT in order to meet a skew requirement on transceiver clock network. This can mean that the CLOCK_ROOT is not in the geometric center. You can control the CLOCK_ROOT using the following constraint:

set _property USER_CLOCK_ROOT <clock_region> [get_nets <clock net after BUFG>]

When two or more clock networks have the same source MMCM, they can go to

different CLOCK_ROOTS. This can mean that there are different delays on the

clock networks, as shown in Fig. 12.5 . Different delays on clock networks will

translate to skew in timing which can make designs diffi cult to close timing.

If there are paths that are related between these clocks, you should link the two

clock networks using USER_CLOCK_GROUP constraint.

set_property USER_CLOCK_GROUP <group_name> [get_nets [list <clock after BUFG1> <clock after BUFG2>]]

This will ensure that clock paths have roughly similar delay as shown in Fig. 12.6

CLOCK_ROOT impacts the general skew that a network has. Clock skew can be positive for setup when moving away from the clock root and negative as you move toward the clock root (Fig. 12.7 ). Smaller networks will have optimal CLOCK_ ROOT placement with lesser skew. For this reason, it can be benefifi cial to break a larger clock network into two smaller ones if the interface timing can be managed, e.g., using a FIFO where the networks cross. For this to be effective, there should be no cross clocking timing.

Clock roots and length of clock tracks aligned through USER_CLOCK_GROUP.png

Clock tree skew impacted by CLOCK_ROOT.png

TABLE OF CONTENTS