[Verilog] 再次征戰FIFO地獄 - (7) fifo constraint

當你信心滿滿的解釋完fifo原理和RTL coding後

老闆們總是喜歡嘗試擊破那個有自信的你

地獄般的題組考驗這就來了

fifo觀念解釋的很棒, rtl coding也沒問題

那靠gray code就能保證post silicon不會有問題了嗎?

如果chip回來發現fifo的read write出問題的話

可能是哪邊導致的? 需不需要下些constraint去做預防

這篇我們就來探討一下何謂constraint 又為了要預防甚麼

在async fifo的世界中

同時有兩種資訊在傳遞

1. pointer
2. 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加密嗎?