fpga項(xiàng)目開發(fā)感言

fpga項(xiàng)目開發(fā)除了技術(shù)過硬之外，還需要一些合作的心態(tài)去看待項(xiàng)目，下面是我操刀過這么多的fpga項(xiàng)目外包服務(wù)的體會(huì)：

1.要和人配合。

以我們做硬件的工程師為例，測(cè)試的時(shí)候一般都需要軟件的配合，一個(gè)對(duì)硬件來(lái)說(shuō)無(wú)比復(fù)雜的工作，可能在軟件工程師看來(lái)就是幾行簡(jiǎn)單的代碼。所以要和人配合，多聽聽別人的意見，這樣必然可以產(chǎn)生新的know-how從而加快測(cè)試和開發(fā)的速度，退一步講，至少?zèng)]有壞處。

2.測(cè)試還是要?jiǎng)e人來(lái)做。

開發(fā)者看待自己的產(chǎn)品有如看待自己，大多是沒有勇氣去發(fā)現(xiàn)缺點(diǎn)的。一是源自自尊心，二是為了避免額外的工作。所以就算有問題，如果不嚴(yán)重就藏著掖著。但是這對(duì)項(xiàng)目來(lái)說(shuō)是不行的，所以測(cè)試，verification，一定要旁人來(lái)做。

3.多點(diǎn)時(shí)間思考。

出現(xiàn)問題后，不要急著修改。要思考推測(cè)可能的原因，想清楚后把這些可能的原因都用debug pin或者chipscope引出來(lái)。

4.注意復(fù)用已有的debug pin。

很多時(shí)候，在測(cè)試過程中產(chǎn)生了一大堆測(cè)試信號(hào)，但是時(shí)間一長(zhǎng)就忘了復(fù)用。實(shí)際上，當(dāng)一個(gè)問題產(chǎn)生的時(shí)候，通過反復(fù)觀察已有的debug-pin或許足以發(fā)現(xiàn)問題根源，而無(wú)需再引出新的pin，并浪費(fèi)時(shí)間去綜合和PAR。

5.仿真加時(shí)序足矣。

數(shù)字電路在時(shí)鐘同步的設(shè)計(jì)原則下，其功能通過simulation就可以驗(yàn)證。simulation的結(jié)果和PAR后產(chǎn)生的FPGA-image完全等價(jià)。當(dāng)然FPGA也要遵循同樣的設(shè)計(jì)原則：即時(shí)鐘同步。所以對(duì)于PAR的結(jié)果首先就要確保其時(shí)鐘同步的特性。體現(xiàn)為寄存器之間的path必須在一個(gè)時(shí)鐘周期內(nèi)完成。（當(dāng)然有其他約束的例外。）同時(shí)要滿足FPGA器件的setup和hold要求。一旦出現(xiàn)timing-error必須通過各種途徑消除error，因?yàn)閑rror的存在，意味著時(shí)鐘同步的大前提已經(jīng)被破壞，這時(shí)，simulation取得的結(jié)果和FPGA是不等價(jià)的，繼續(xù)測(cè)試也毫無(wú)意義了。

6.注意不可控的接口部分。

FPGA內(nèi)部的寄存器之間的timing完全可以通過PAR報(bào)告來(lái)確認(rèn)是否有問題。但是和外界的接口部分卻充滿了疑問。我們一般通過假定的input-delay和output-delay來(lái)對(duì)接口部分進(jìn)行約束。由于從一開始就施加的是假定的delay，所以即使沒有timing-error，其結(jié)果也存在諸多疑問。以我正在進(jìn)行的測(cè)試為例，模塊內(nèi)部loopback測(cè)試完全正常，但是一過cable，傳到對(duì)方FPGA，則馬上產(chǎn)生很多誤碼。由于simulation沒有問題，所以必然是我們的某個(gè)假定出現(xiàn)了問題，尤其是時(shí)鐘同步的假定會(huì)得不到滿足。這時(shí)候，就要想盡一切辦法，使接口也滿足假定的條件，或者調(diào)整設(shè)計(jì)，將不理想的接口adapting成理想的接口。

7.向直接上司匯報(bào)情況，尋求各種可能的許可。

懶得向直接上司匯報(bào)情況時(shí)，萬(wàn)一出現(xiàn)進(jìn)度或者結(jié)果不符，所有責(zé)任都需要本人承擔(dān)。如果提前向上司匯報(bào)情況并取得許可，則一切后果都在可控范圍內(nèi)。比如，工作繁忙時(shí)又被派給新的任務(wù)，則不能一味逆來(lái)順受。應(yīng)該向上司說(shuō)明困難，并提前想好一個(gè)可行的解決方案供上司參考。

8.外部接口是最大障礙。

如前所述，F(xiàn)PGA內(nèi)部如果timing沒有問題的話，一般和仿真結(jié)果是一致的，問題是外部的接口，包括cable連線等，不在我們確切控制的范圍內(nèi)，比如其延時(shí)特性在40Mhz下仍然正常，但是在80Mhz時(shí)可能出現(xiàn)不可預(yù)料的情況。所以應(yīng)該盡量使用經(jīng)過驗(yàn)證的"cable--frequency"組合?；蛘咄ㄟ^設(shè)備測(cè)量并確認(rèn)外部接口的延時(shí)特性。這樣可以進(jìn)行有針對(duì)性的調(diào)整。我最近的教訓(xùn)就是花了整整一個(gè)月調(diào)整并測(cè)試內(nèi)部的結(jié)構(gòu)，但是仍然失敗。結(jié)果發(fā)現(xiàn)由于cable的問題，80Mhz的信號(hào)（數(shù)據(jù)+使能+others）無(wú)法正常并行傳輸。如果換成40Mhz的信號(hào)就通過了。

9.綜合PR后的結(jié)果要和代碼等價(jià)。

前面提到仿真加時(shí)序足矣，這里面的前提是PR的結(jié)果和原始代碼要等價(jià)。為了確認(rèn)這一點(diǎn)，就要把握syn和pr過程中的所有warning以及error，warning的內(nèi)容不是完全可以忽略的。要特別關(guān)注綜合報(bào)表中的以下內(nèi)容：unused ports, removal of redundant logic, latch inference，simulation mismatch等等。在報(bào)表中輸入關(guān)鍵字查找即可。

審核編輯 黃昊宇