Tz50 HyperRAM Characteristics

The Tz50 FPGA in the F100S3F2 package includes a HyperRAM device. This topic describes the distributed refresh interval.

Attention: This topic only appliesto the F100S3F2 package with HyperRAM.

The HyperRAM device has a volatile memory array that requires a periodic refresh of all bits in the array. The refresh operation is performed by internal self-refresh logic that evenly refreshes the memory array automatically.

This automatic refresh operation occurs in standby mode or hybrid sleep mode when it is not being actively read or written by the host system. The refresh logic waits for the end of any active read or write before doing a refresh, if a refresh is needed. If a new read or write begins before the refresh completesc, the memory drives RWDS high during the CA period to indicate that additional initial latency time is required at the start of the new access to allow the refresh operation to complete before starting the new access. The automatic refresh operation continues to run for data retention for as long as the HyperRAM remains in standby mode or hybrid sleep mode.

The evenly distributed refresh operations requires a maximum refresh interval between two adjacent refresh operations. The maximum distributed refresh interval varies based on the temperature as shown in the following table.

Table 1. Distributed Refresh Interval by Temperature
Device Temperature (Tj °C) Maximum Distributed Refresh Interval (μs) CR1[1:0]
TJ < 85 4 01b
85 < TJ < 125 1 10b

The host should not perform burst transactions longer than the distributed refresh interval because longer bursts prevent distributed refresh operations happening when needed. Therefore, there is an upper limit to the length of read and write transactions so that the automatic distributed refresh operation can be done between transactions. This limit is called the CS# low maximum time (tCSM); it is equal to the maximum distributed refresh interval.

The host system must respect the tCSM value by ending each transaction before violating tCSM, which would result in a data retention fault. The host memory controller can split long transactions when it reaches the tCSM limit, or the host system hardware or software should not perform a single read or write transaction longer than the tCSM time. As noted in Table 1, the maximum refresh interval is longer at lower temperatures, and the increase in the tCSM allows for longer transactions. The host system uses the CR1[1:0] value shown in the table to determine the maximum operating temperature. Alternatively, use a temperature sensor to determine the current system operating temperature and determine the distributed refresh interval based upon this sensor data.
Note: Refer to the HyperRAM Controller Core User Guide for managing tCSM if you are using the HyperRAM Controller IP core.