久久久久久久999_99精品久久精品一区二区爱城_成人欧美一区二区三区在线播放_国产精品日本一区二区不卡视频_国产午夜视频_欧美精品在线观看免费

標題: 讀SRAM時序約束分析 [打印本頁]

作者: 51黑黑黑 時間: 2016-2-23 03:28
標題: 讀SRAM時序約束分析
讀SRAM時序約束分析 　　SRAM使用的是ISSI的61LV5128，8位寬，19條地址線。FPGA內部有一個地址產生計數單元，因此數據讀操作時輸出管腳的時序起點就是這些地址產生單元。因為希望快速讀SRAM，所以狀態機代碼讀SRAM是第一個時鐘周期送地址（SRAM的OE#信號始終接地），第二個時鐘周期讀數據。系統時鐘使用的是50MHz（20ns），SRAM的標稱讀寫速度可以達到8ns。感覺上20ns操作一個8ns的SRAM似乎很可行。

點擊看原圖

  　　上面SRAM的讀時序中，tRC=8ns，也就是說地址穩定后最多等待8ns數據總線上的數據是有效的（上面的說明只是相對于SRAM管腳而言，不考慮其它條件）。那么在地址穩定后的0—8ns之間的數據可能是有效的也可能是無效的我們無從得知（也許不到8ns數據就已經有效了，可以說8ns是一個很保守的讀取時間），但是8ns以后一直到數據地址發生變化的tOHA時間內的數據一定是穩定的。
  　　上面羅嗦了一大堆，下面步入正題。我們要計算FPGA和SRAM的數據總線接口上的input delay值，按照公式：Input max/min delay = 外部器件的max/min Tco + 數據的PCB延時 – PCB時鐘偏斜。
  　　我們先計算一下地址總線最終穩定在SRAM輸入管腳的時間，應該是FPGA內部時鐘的launch edge開始到FPGA輸出管腳的延時加上地址總線在PCB上從FPGA管腳到SRAM管腳的延時。前者的值為5.546ns—9.315ns（由FPGA時序分析得到，不包括launch edge 的clock network delay），后者的值為0.081ns—0.270ns（由PCB走線長度換算得到）。那么地址總線最終穩定在SRAM輸入管腳的時間max=9.585ns,min=5.627ns。
  　　其次，我們可以從SRAM的datasheet查到（也就是上面的時序圖的tRC）地址穩定后Tco=8ns數據穩定在SRAM數據總線的輸出管腳上。數據總線從SRAM管腳到達FPGA輸入管腳的PCB延時為0.085ns—0.220ns。
  　　從上面的一堆數據里，我們需要理出一條思路。首先需要對這個時序進行建模，和FPGA內部的寄存器到寄存器的路徑和類似，這個時序模型也是從FPGA內部寄存器（輸出管腳）到FPGA內部寄存器（輸入管腳），不同的是這個寄存器到寄存器間的路徑不僅在FPGA內部，而是先從寄存器的輸出端到FPGA的輸出管腳，再從PCB走線到外部器件SRAM的輸入管腳，然后經過了SRAM內部的Tco時間后，又從SRAM的輸出管腳經PCB走線達到FPGA的輸入管腳，這個輸入管腳還需要有一些邏輯走線后才達到FPGA內部寄存器的輸入端。整個模型就是這樣，下面看這個輸入管腳的Input delay如何取值。大體的這個路徑如下圖，也可以簡單的把兩個寄存器之間的路徑理解為FPGA內部的一個大的組合邏輯路徑。

  　　根據Input delay的定義，加上我們這個模型的特殊性，我個人認為input delay的路徑應該是從CLK的launch edge開始一直到FPGA的DATA總線的輸入端口。那么所有的路徑延時值在前面都給出了。最后計算得到input max delay = 17.765，input min delay = 13.731。
  　　無疑，上面得出的input delay參數都有些偏高了（由于該工程使用器件為Altera MAX ii EPM570，內部資源有限速度也無法做得太高，加之工程的其它控制模塊也相對有些復雜，所以這對于該工程在20ns內操作8ns的SRAM帶來了一定的挑戰。），下面進行時序分析即建立時間和保持時間余量的計算。
  　　Data Arrival Time = Launch Edge + Clock Network Delay + Input Maximum Delay of Pin + Pin-to-Register Delay = 0+3.681ns+17.765ns+ Pin-to-Register Delay = 21.446ns + Pin-to-Register Delay
  　　Data Required Time = Latch Edge + Clock Network Delay to Destination Register - utSU = 20ns + 3.681ns – 0.333ns = 22.348ns
  　　Clock Setup Slack = Time Data Required - Time Data Arrival Time = 22.348ns– (21.446ns + Pin-to-Register Delay) = 0.902ns - Pin-to-Register Delay
  　　若滿足時序要求，則：0.902ns - Pin-to-Register Delay > 0 即Pin-to-Register Delay < 0.902ns
  　　Data Arrival Time = Launch Edge + Clock Network Delay +Input Minimum Delay of Pin Pin-to-Register Delay = 0+3.681ns+13.731ns+ Pin-to-Register Delay = 17.412ns+ Pin-to-Register Delay
  　　Data Required Time = Latch Edge + Clock Network Delay to Destination Register + utH = 0+3.681ns+0.221ns = 3.901ns
  　　Clock Hold Slack = Time Data Arrival - Time Data Required Time = 17.412ns+ Pin-to-Register Delay – 3.901ns = 13.511ns + Pin-to-Register Delay
  　　若滿足時序要求，則：13.511ns + Pin-to-Register Delay > 0
  　　Pin-to-Register Delay 時間從時序報告里得出在4.711ns—6.105ns范圍內。那么建立時間余量顯然不滿足，建立時間時序違規。而保持時間則不會違規。
  　　雖然這個工程如此這般分析下來，似乎在這個工程條件下用50MHz的速率來讀存取時間為8ns的SRAM是不可行的。但是在我初步調試這個工程的時候，沒有進行時序約束和時序分析的情況下就進行了板級調試，而且調試的最終結果是正確的，讀寫SRAM的操作好像沒有出現預想之外的問題。這讓我很是納悶，為什么理論上進行靜態時序分析不可行的時序最后卻通過了板級調試了呢？思考了很久，歸納了以下幾種可能性：
  　　1，首先不排除上文里時序分析的方法有誤，很期待各位高手指點；
  　　2，時序分析的有些太苛刻了，可能有些地方都是想到了最壞的情況（當然這是必要的，有些時序違規不是一天兩天能出現的，甚至聽說過恩年出現一次的問題，這是最讓人郁悶的事，記得我們部門里的機器在實驗過程中出現了一點問題立刻大群人馬圍坐分析，畢竟我們搞的都是～～不是一般的馬虎不得的東西呵呵）；
  　　3，有些違規最嚴重的路徑可能是地址的高位，因為我們操作的時候都是遞增地址讀數據的，高位地址變化周期長，它的時序違規表現的不是那么明顯；
  　　4，還真有那么一次，發現一個從SRAM讀出的很小塊的顯示圖片區錯誤了，不排除是讀時序問題造成的；
  　　5，SRAM標稱的8ns是最大的等待時間，或許和開篇提到的一樣，SRAM實際上數據有效等待時間不需要那么長，也就是上面分析中外部器件的Tco減小了。
  　　這是我能想到的可能的情況，也許還有別的問題，也期待各位提出自己的一些看法。

歡迎光臨 (http://m.zg4o1577.cn/bbs/)