Overview
This content is intended to help the reader understand the read/write sequencing of the EMIF (External Memory Interface) IP core.
Read/write access to memory is accessed from the user interface in accordance with the Avalon® Interface. The AFI interface, which is the communication protocol between the memory controller and the PHY, does not need to be controlled.
The figure below shows a signal example for the Altera® 10 FPGA EMIF + DDR3.
Some signal names may differ or not exist depending on the device family. Also, the number of bits may differ, such as avl_size.
Below are the differences in signal names between UniPHY and Arriar® 10 FPGA EMIF.
For Acalon® Interface specifications, please refer to the following link
Write Sequence
The write sequence is described in the following waveform diagram, which includes signals inside the IP.
Below is a waveform with Size=1 and no wait (avl_ready = Low) occurs at request. In actual operation, a wait will be generated, so the user should consider the case where a wait is generated in the design. Please refer to the attachment to this article for the protocol in that case.
In this diagram, ① and ② are user interface signals, ③, ⑤, and ⑦ are AFI interface signals, and ④, ⑥, and ⑧ are external memory interface signal operations.
Read Sequence Read Sequence
The read sequence is explained in the following waveform diagram including signals inside the IP.
Below is a waveform with Size=1 and no wait (avl_ready = Low) at the time of request. As with the write sequence, the user should design for the case where wait occurs. Please refer to the attachment to this article for the protocol in that case.
In this figure, (1) (8) is the user interface signal, (2) (4) (7) is the AFI interface signal, and (3) (5) (6) is the external memory interface signal operation.
Frequently Asked Questions/Mistakes
(Please refer to the attached document for a summary of protocol violations)
1. avl_ready drops low for a long period of time (frequently).
- The following may be the cause. The following may be the cause, and please check if there is any protocol violation.
- In case of V series, when DQS tracking is enabled, avl_ready may drop to Low for a long time.
Read/write operations are stuck. Why?
- Reads and writes get stuck if there is a protocol violation or connection error. For example
- When issuing a read/write request, the address and size signals must be valid
- Size must be greater than or equal to 1 (access with size 0 is a violation) and less than or equal to the value specified during IP generation
- It is a violation to issue a read and write at the same time
- MPFE must be connected to the same clock and reset signals within the same port
- When Ready = L, the signal given by the user circuit must be held until it goes High, except for burstbegin (Once issued, request information cannot be "withdrawn" while Ready = L is still in effect. Doing so would be a protocol violation).
- For writes of size 2 or larger, a valid write data transfer (avl_ready and avl_write_req both High) must be performed for the size set at the beginning of the request.
More read data than the read request is returned.
- When writing, a valid write data transfer must be issued for the amount specified by Size, but when reading, only one valid read request is issued per burst transfer, even if Size is 2 or more.
- Valid write data transfer: avl_ready and avl_write_req are both High
- Valid read request: Both avl_ready and avl_read_req are High
- For example, when one cycle of "avl_read_req=H" is accepted, avl_rdata_valid=H (the (8) part of the waveform of the above read sequence) is returned for the amount specified by size
- If a read request is mistakenly issued for size times, only size × size read data will be returned. 4.
No read/write data is returned, why?
- Check for protocol violations.
- For example, if the user logic is designed so that the latency (interval from (1) to (8) in the figure) between issuing a request and receiving data in a read sequence is constant, there is a possibility of getting stuck or missing data.
5. bandwidth drops. Why is this?
- The bandwidth will drop a little due to the refresh operation, but other factors include the following.
- In case of DDR4, bandwidth may drop depending on the address change and BG assignment position (related to tCCD_L and tCCD_S).
- In the case of V series, when using MPFE, one extra clock minute may be consumed and bandwidth may drop.
- If DQS tracking is enabled, avl_ready may be low for a long period of time (frequently).
- Bandwidth may be improved by changing the following settings
- Command Queue Look-Ahead Depth, Burstcount, Starvation limit for each command
List of commands
List of DDR3 commands
List of DDR4 commands
Summary
The above overview of the sequence, including the IP internal signals, for the user interface of the EMIF IP core when Size=1 and no wait occurs (avl_ready=H at all times) for both write and read. It also described frequently asked questions/issues about writes/reads.
In practice, waits may occur, and there are four possible patterns as described below. Users need to respond to all cases that may occur depending on how they use the system. If there is a lack of response, the system may malfunction due to protocol violations.
Please refer to the attached document for details.
(1)avl_size=1, avl_ready = H (burst length 1, no weight)
(2)avl_size=1, avl_ready = L (burst length 1, with weight)
(3)avl_size≥2, avl_ready = H (burst length 2 or longer, no weight )
(4)avl_size ≥ 2, avl_ready = L (burst length 2 or longer, with weights)
Appendix: Supplemental EMIF IP User Interface (Access Waveform Description)