|
基于Xilinx MIS IP的DDR3讀寫User Interface解析 特權同學，版權所有，轉載請注明出處 參考文檔：ug586_7Series_MIS.pdf 1. Command時序 首先，關于User Interface的Command時序，ug中只給出以下波形。簡單的來講，app_cmd和app_addr有效，且app_en拉高，app_rdy拉高，則該命令成功發送給DDR3 Controller IP；若是在app_cmd、app_addr和app_en都有效時，app_rdy為低，那么必須保持app_cmd、app_addr和app_en的有效狀態直到app_rdy拉高，那么該命令才算是成功發送給DDR3 Controller IP。 
找一個實例來看，如圖所示，在app_en連續拉高發起多次寫入命令時，第58個時鐘周期，遇到了app_rdy拉低的情況，此時需要保持當前的app_cmd和app_addr不變，app_en也繼續為高，直到第59個時鐘周期，app_rdy拉高了，那么說明該寫命令成功。
2. 數據寫入時序 對于單次的數據寫入DDR3 Controller IP，ug中也只給出如圖所示的時序波形。這里對應寫入command發起的前后有1、2和3不同時間的Data Write時序，也就是說，對應這個寫入command，數據比command早一點或晚一點寫入都是可以的。
怎么理解“數據比command早一點或晚一點寫入都是可以的”這句話？ug有提到，command以及data都有各自的FIFO，因此他們是需要同步的，換句話說，如果讓我設計這個controller的User Interface，并且和目前的機制一樣，command和data都有FIFO，那么很簡單，我會根據command FIFO中的新命令，對應取一個data FIFO中的寫入數據，也不用管它們誰先被送到各自的FIFO中。當然了，command FIFO有命令是data FIFO取數據的先決條件。至于兩個FIFO萬一不同步，那么怎么辦？沒辦法，用戶必須保證它們同步。事實就是這么殘酷，特權同學在這里吃盡苦頭，總算是搞明白了，必須mark一下。 前面說command時關注接口app_cmd、app_addr、app_en和app_rdy，這里寫數據則需要關注接口app_wdf_data、app_wdf_wren、app_wdf_end和app_wdf_rdy。 先說app_wdf_end，DDR3實際讀寫的Burst =8，舉例來說，DDR3的數據位寬為16bit，Burst為8，就是說每次對DDR3執行讀寫，必須是連續的8*16bit數據。那么在User Interface這端，如果邏輯時鐘為DDR3時鐘的4分頻，且數據位寬為128bit，那么單個時鐘周期就對應Burst=8的一次讀寫操作；而如果數據位寬為64bit，那么必須執行2次數據操作才能夠完成一次Burst=8的讀寫。對于前者，app_wdf_end始終為1就可以了；而對于后者，app_wdf_end每2個寫數據時鐘周期內，前一次拉低，后一次拉高。 余下3個信號app_wdf_data、app_wdf_wren和app_wdf_rdy，他們的工作原理和command時序類似。app_wdf_data有效，且app_wdf_wren拉高，必須app_wdf_rdy也為高，才表示當前數據寫入DDR3 Controller IP。 來看個實例，如圖所示，app_wdf_en一直拉高進行數據寫入。第158個時鐘周期，app_wdf_rdy拉低連續5個時鐘周期，此時即便app_wdf_en一直拉高也無法完成數據寫入，app_wdf_data必須一直hold直到第163個時鐘周期app_wdf_rdy拉高。
必須提醒的是，執行寫數據command和執行寫數據操作，它們是一一對應的，雖然控制時序可以分開實現。 3. 讀數據時序 理解了寫時序，讀時序也就很容易領會了，它們本質上是一樣的。每個數據的讀操作，也需要先有讀command的發起，當有效讀command發起后，若干個時鐘周期后，app_rd_data_valid拉高，此時app_rd_data有效，用戶邏輯據此讀出數據即可，非常簡單。對于連續讀取也是一樣的。User Interface可以嘩嘩送一大堆讀command，注意這些讀command必須都是有效command，隨后就等著app_rd_data_valid拉高接收app_rd_data即可。
也看看實際操作，如圖所示，發起數據讀操作后，大約經過30個時鐘周期后，數據才連續出現。數據是pipeline方式出現的，所以盡可能連續的讀取數據可以大大提高數據吞吐量。
|
