Ti60 HyperRAM Characteristics

Distributed Refresh Interval

Attention: This topic is only relevent if you are using a HyperRAM-enabled F100S3F2 package, such as the Ti60.

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

This automatic refresh operation occurs in either standby mode or hybrid sleep mode while 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 at that time. If a new read or write begins before the refresh is completed, the memory will drive 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 either 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 will vary based on the temperature as shown in the table below.

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

It is important that the host does not perform burst transactions longer than the distributed refresh interval as longer bursts will to prevent distributed refreshes operations when needed. This sets an upper limit on 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) and the tCSM is equal to the maximum distributed refresh interval.

The host system must respect the tCSM value by ending each transaction before violating tCSM resulting in data retention fault. This can be done by the host memory controller logic splitting long transactions when reaching the tCSM limit, or by the host system hardware or software not performing a single read or write transaction longer than the tCSM. As noted in the table above, the maximum refresh interval is longer at lower temperatures, such that an increase in the tCSM allows for longer transactions. The host system uses the CR1[1:0] value from the table above to determine the maximum operating temperature. Alternatively, a temperature sensor is used to determine the current system operating temperature and the distributed refresh interval is determined 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.