Specifying the RAM Activity for Jitter - Specifying the RAM Activity for Jitter - 2026.1 English - UG1387

Versal Adaptive SoC Hardware, IP, and Platform Development Methodology Guide (UG1387)
Document ID
UG1387
Release Date
2026-07-22
Version
2026.1 English

The USER_RAM_AVERAGE_ACTIVITY constraint specifies a value. This value represents the average frequency at which the device can switch all UltraRAM and block RAM (enabled/disabled). The Vivado tools use the value to model power supply noise induced by RAM switching. They also calculate jitter for global clocks in static timing analysis.

Static timing analysis reports the jitter as a component of clock uncertainty. If you do not specify the USER_RAM_AVERAGE_ACTIVITY, the Vivado tools compute the RAM_AVERAGE_ACTIVITY value. The jitter calculation uses this value, which can increase the difficulty of timing closure.

Important: AMD recommends that you calculate the USER_RAM_AVERAGE_ACTIVITY for your design to reduce the difficulty of timing closure. Refer to this link in the Versal Adaptive SoC Clocking Resources Architecture Manual (AM003) for detailed information on RAM Acitivity Jitter. The manual also provides information on calculating the USER_RAM_AVERAGE_ACTIVITY for your design.

The Vivado tool estimates RAM activity for flat designs based on RAM device resources used. It considers RAM enable pins connected to active signals. The tool also factors in the operating frequency of the RAMs. The Vivado tool assumes a pessimistic default value of 320 MHz for DFX designs. Vivado tools compute the RAM activity and apply it to the read-only RAM_AVERAGE_ACTIVITY property at the top-level [current_design] object.

To reduce pessimism in DFX designs, budget RAM Activity for your reconfigurable partitions. Calculate the USER_RAM_AVERAGE_ACTIVITY for your design using this link in the Versal Adaptive SoC Clocking Resources Architecture Manual (AM003).

To specify the USER_RAM_AVERAGE_ACTIVITY constraint, apply the constraint to the top-level [current_design] object in your XDC constraints:

set_property USER_RAM_AVERAGE_ACTIVITY 160 [current_design]

The following table shows how additional clock uncertainty caused by RAM switching can impact timing closure. In this example, a design has global clocks operating at 300 MHz, 400 MHz, and 500 MHz. The system calculates the USER_RAM_AVERAGE_ACTIVITY constraint to be 160, while the RAM_AVERAGE_ACTIVITY is 320. Applying the constraint decreases the clock uncertainty for all paths in each clock domain, which makes achieving design timing closure less difficult.

Table 1. Pessimistic Default Clock Uncertainty vs. Specified RAM Activity Clock Uncertainty
Clock Domain RAM_AVERAGE_ACTIVITY 320 Clock Uncertainty USER_RAM_AVERAGE_ACTIVITY 160 Clock Uncertainty Clock Uncertainty Decrease
300 MHz 0.103 ns 0.073 ns -0.030 ns
400 MHz 0.089 ns 0.066 ns -0.023 ns
500 MHz 0.078 ns 0.058 ns -0.020 ns