A BUFG (Global Clock Buffer) is a dedicated high-fanout clock-driving primitive found in Xilinx FPGAs that connects a clock source to the device's global clock network, distributing a low-skew, low-jitter clock signal to flip-flops and other sequential elements across the entire fabric. It is distinct from ordinary routing resources and is implemented in silicon as a dedicated buffer with its own low-impedance distribution network.
In practice
In Xilinx FPGAs (Spartan, Virtex, Artix, Kintex, Zynq families), a BUFG is inserted automatically by the synthesizer or place-and-route tool when a signal is recognized as a clock driving a large number of flip-flops. Most devices in these families provide a limited number of global clock networks, with the exact count varying significantly by family, device size, and clocking architecture — commonly in the range of 16 to 32, but this is not a universal rule. Exceeding that count forces clocks onto regional or local routing, which degrades skew and timing closure.
A BUFG is often instantiated explicitly in HDL when the tool does not automatically promote a signal to the global clock network, or when clock muxing is needed. The BUFGMUX variant adds a glitch-free select input so the design can switch between two clock sources at runtime without producing a runt pulse. The BUFGCE adds a clock enable that gates the output without affecting the distribution network impedance.
A common pitfall is driving logic with a signal that is functionally a clock but has not been routed through a BUFG. This results in the signal traveling on general-purpose routing, which introduces higher and unpredictable skew across the device. The timing analyzer will typically flag these as clock-routing, skew, or clocking-rule warnings rather than clean timing closure. Conversely, wasting BUFGs on low-fanout signals that do not need global distribution can exhaust the limited supply.
In designs that generate clocks from a PLL or MMCM (Mixed-Mode Clock Manager), the PLL/MMCM output clock ports are often connected to BUFG inputs before reaching the fabric, though some designs use regional buffers or other clocking resources depending on the design requirements. Some Xilinx tools insert this BUFG automatically; others require the designer to do it explicitly in the IP configuration or HDL. Omitting it can cause the clock to be routed through fabric, degrading jitter and skew significantly.
Frequently asked
How many BUFGs are available on a typical Xilinx FPGA?
The count varies by family and device. Spartan-6 parts provide 16 global clock buffers per device. Artix-7, Kintex-7, and Virtex-7 devices typically provide 32 BUFG resources, split across clock regions. Zynq-7000 SoCs follow the 7-series
FPGA allocation for the programmable logic portion. Always check the device-specific datasheet and clocking architecture guide, as the usable count can be further constrained by package and I/O bank assignments.
What is the difference between BUFG, BUFR, and BUFIO?
BUFG drives the global clock network and can reach every
flip-flop on the device with low
skew. BUFIO is restricted to clocking I/O logic (ISERDES, OSERDES, IDDRs) within a single I/O column and cannot directly drive fabric flip-flops. BUFR is a regional buffer that can drive fabric and I/O logic within one clock region and also supports integer clock division (divide by 1 to 8). Use BUFG for fabric-wide clocks, BUFIO for source-synchronous capture, and BUFR for regional or divided clocks.
Does the synthesizer insert BUFGs automatically, or do I need to add them manually?
Xilinx tools (both legacy
ISE and current
Vivado) will promote signals identified as clocks to a BUFG automatically in most cases, particularly when the signal enters through a dedicated clock-capable I/O pin (MRCC or SRCC). However, internally generated clocks, clock signals derived from
combinational logic, or clocks selected by a mux may not be promoted automatically. In those cases you should instantiate the appropriate BUFG, BUFGMUX, or BUFGCE primitive explicitly in your
HDL to guarantee global routing.
What is BUFGMUX and when should I use it instead of BUFG?
BUFGMUX is a 2-to-1 clock multiplexer connected to the global clock network. It allows
glitch-free switching between two clock inputs under control of a select signal, provided the switch is performed when both clocks are low (or when using the BUFGMUX_CTRL variant, which handles the handshaking internally). Use it when a design needs to switch between a high-speed and a low-speed clock at runtime, for example entering a low-power mode or switching from a
PLL output to a safe reference clock during PLL lock acquisition.
Can I use a BUFG on a non-clock signal to improve fanout?
Technically yes, a BUFG can drive any high-fanout net, including synchronous reset or clock-enable signals, since it is electrically just a strong buffer on the global network. However, this is generally discouraged. Clock-enable and reset signals are better handled through the dedicated control-set routing available in modern Xilinx fabric (e.g., the
CE and SR inputs of
flip-flops). Misusing BUFGs for non-clock signals wastes a scarce resource and can confuse the timing analyzer. Reserve BUFGs for actual clock signals unless you have a well-understood reason to do otherwise.
Differentiators vs similar concepts
BUFG vs. BUFR: BUFG drives the device-wide global clock network and can reach all fabric
flip-flops with uniform, low
skew. BUFR is a regional buffer limited to one clock region, but it can divide its input clock by an integer from 1 to 8, making it useful for deriving slower regional clocks from a fast source. BUFG vs. BUFIO: BUFIO is restricted to clocking I/O primitives (ISERDES, OSERDES, IDDR) within a single I/O column and cannot drive fabric flip-flops directly; it targets ultra-low-skew source-synchronous capture. BUFG vs. BUFGMUX/BUFGCE: BUFGMUX adds a
glitch-free 2-to-1 clock select input; BUFGCE adds a clock-enable gate. In UltraScale and UltraScale+ devices, Xilinx introduced newer global buffer primitives such as BUFGCE and BUFGCE_DIV that supersede some older variants for those families, though the exact naming, availability, and degree to which older primitives are supported depends on the specific device family and tool version.
