當你信心滿滿的解釋完fifo原理和RTL coding後
老闆們總是喜歡嘗試擊破那個有自信的你
地獄般的題組考驗這就來了
fifo觀念解釋的很棒, rtl coding也沒問題
那靠gray code就能保證post silicon不會有問題了嗎?
如果chip回來發現fifo的read write出問題的話
可能是哪邊導致的? 需不需要下些constraint去做預防
這篇我們就來探討一下何謂constraint 又為了要預防甚麼
在async fifo的世界中
同時有兩種資訊在傳遞
- pointer
- data
然而 我們先前提到說
我們利用了gray code的模式來預防source端的pointer在同一個cycle內有多個bits的跳動,
source同時多個bits的跳動,將會導致接收端接到Data時無法得知倒底是不是vaild的value,
因此儘管pointer 由快到慢, 被rx端抓到時已經跳動多個bits了但也能很肯定地說
這些取樣到的值都一定是valid的,他們一定曾經被使用過
再利用這個pointer去判斷是否可以抓取fifo中的Data或儲存Data於fifo中
聽起來相當完美了,
但有沒有想過一個問題
pointer和data兩個為獨立的資訊,
我們利用pointer去判斷儲存Data的region是否可以使用,
但這個有個先決條件
1.我們data必須走的比pointer快
這是甚麼意思呢 我們稍後來研究一下
另外就是
fifo設計中通常會把 data fifo擺在write clk端
也就是說,
2.我們在data端傳輸時進read端會有個Multibits的Data跨CDC 傳輸的問題出現
那我們又是怎麼說讀到的data不會有問題的呢?
CDC最難的就是要讀multibits呀,才會搞一堆甚麼gray code的東東
怎麼好像忘記處理它了只修好了pointer
還是data端也要用gray code加密嗎?
