Understanding AMD Timing Constraints Management

PLL and MMCM Clock Constraining

Reading time 6-7 minutes

An essential need for all FPGA designs is a clock tree management with provided dedicated clock trees and dedicated clock resources. Register Transfer Level (RTL) design coding, which is an essential requirement for the Hardware Description Language (HDL) coding, needs to include the appropriate instantiations of dedicated clock resources such as clock tree buffers and PLLs or dedicated clock input buffers. With the default settings of the Vivado synthesis tool, essential dedicated clock input and clock-net driver buffers can also be included if these are missing. But a PLL is not auto-included by a synthesis compiler: it needs to include those elements from the user side or by IPs when these have specific clock requirements. Here we do not talk about design entry tools of higher abstraction like AMD Vivado IP Integrator, Vitis HLS, Vitis AI or Vitis Model Composer. But these tools support RTL code generators which typically include clock resources and, additionally, PLLs. In the end, clock synchronisation rules for the synthesis compilation based on RTL coding are the same, regardless of the design entry tools used.

Current AMD FPGA architectures support two types of PLL: a so-called PLL primitive and a PLL type with more features – the Mixed-Mode Clock Manager (MMCM). Have a look in the product selection guide of AMD FPGA or adaptive SoC families to see the amount of provided PLL resources in the chip. In Ultrascale(+) architectures, there is always a group of 3 PLLs per clock region when these include dedicated clock inputs. The method of timing constraining is the same when we use PLL or MMCM-type PLLs. First, we need to know that timing constraining is based on a Static Timing Analysis (STA). This means for the PLL, timing constraining is only reasonable with an assumption of a locked PLL. During the synthesis compiler run, the PLL conectivity is checked to determine that the phase-locked-loop is closed with valid clock in the feedback path and also in a valid range of its frequency. Under these conditions the timing constraining will work and the basic synopsys-defined timing constraint syntax is:

create_clock -name <my_clock_name> -period <values_ns> [get_ports <my_clock_input>]

It is quiet important to know that during power-up or when applying resets on PLL, the PLL will unlock for a longer time period, which is signalized by the LOCKED output. This can be really critical, as timing violations might occure during this time, potentially leading to unreabilities that might never recover to a known state. Therfore, a user reset management is also quiet important for the PLLs and their digital dependant circuits to initialize the digital modules getting a reliable reliable behavior once all PLLs are locked.
 

So, timing constraining and timing analysis only take care after all PLLs and MMCMs are locked. Since the PLL is a recursive phased-locked loop, it is sufficiant to have a clock constraint on the clock input pin. This could be sufficiant if we only take care of the PLL frequency outputs but not a specific phase. The most important aspect of a clock architecture is system synchronisity, where the FPGA internal clock is in phase with the PCB clock at the FPGA input. This can be achieved by assigning a clock constraint to a physical FPGA pin (which is the type of port in the netlist).

Constraints management for the AMD Vivado tool flow

In between, we have buffer component delays and net delays to get to the PLL input pin. But when dedicated clock inputs and clock buffers are used, we will get a clock tree purely using dedicated resources and a compensation of net and component delays, if the PLL feedback path to the PLL feedback input pin also includes a clock buffer. That is all we need for system synchronisity and clock constraining for PLLs and MMCMs.

All hardware configuration features of PLLs and MMCMs, like a fixed phase offset or negativ polarity, are taken into account by the timing engine during synthesis and implementation runs. These runs need to calculate the timing slack, which tells us if timing requirements have been achieved or not. This slack calculation is for the endpoint flipflops or RAM cells in the FPGA fabric, which is the value of the difference between the required and achieved timing. The system synchronisity uses the PLL feedback path with the reference from the FPGA internal clock tree – after the clock buffer. If we want to achieve a system synchronisity with an external device, where the PLL output drives an FPGA output pin wired to the clock pin(s) of the external device(s), this is a required PLL feedback reference not from the FPGA fabric – this requires a PLL feedback reference not from the FPGA fabric but from the PCB clock net connected to a dedicated pin in the same clock region as the PLL/MMCM to achieve system synchronicity. As the PLL external wire closes the phase-locked loop, this information is not available in the context of the compiler. That is the reason for the need of a second timing constraint for clock mirroring to an clock input of an external device:

set_external_delay -from [get_ports {…}] -to [get_ports {…}] <time_value>

PLL constraining using an external feedback

Also, be aware that all clock inputs to the PLLs require clock capable pins in the same clock region. These are the most important two approaches of PLL applications we need to know. And all clock outputs, with its freqencies and phases, are determined in the timing-driven compilations based on the timing constraints, which forward to the clock inputs of the PLLs / MMCMs. AMD highly recommends using the Clock Wizzard IP, which allows the selection of a specific PLL type and we see provides us access to all customizable features and features of dedicated clock resources, like clock buffers.

Dedicated primitives of clocking resources could also be instanced by the hardware HDL programmer, but the Clock Wizzard IP keeps it all together and organized: the architecture, the timing constraints, and the IP generation process, which also creates the timing constraints. The IP approach is the recommended and safe method to achive the best quality and a deterministic timing for the clock tree. Another important point: a design migration to a newer AMD technology can use an IP migration, generating the required HDL and constraint files, even with different features in clock tree cells. Lastly, I would like to emphasize that even a cascade of a PLL and MMCM, in both dependencies is perfectly supported without the need of an additional timing constraint, as the forwarding clock path concept calculates the clock edge position as well for a PLLs in a cascade. This also includes the clock jitter calculation for the PLL / MMCM outputs.

What we see at the endis that timing constraint methodology is really simple with inclusions of PLLs and MMCMs. However, the hardware designer needs to understand how to validate that the timing constraints have been met after synthesis and compilation. For example, if a port name and type differs between the IP and top-level HDL module, the auto-generated timing constraint might not fully match and may require a user constraint to correct this.

Some of these aspects are discussed in our next blog >Primary Clocks and Generated Clocks<