fpga項目開發除了技術過硬之外,還需要一些合作的心態去看待項目,下面是我操刀過這么多的fpga項目外包服務的體會:
1.要和人配合。
以我們做硬件的工程師為例,測試的時候一般都需要軟件的配合,一個對硬件來說無比復雜的工作,可能在軟件工程師看來就是幾行簡單的代碼。所以要和人配合,多聽聽別人的意見,這樣必然可以產生新的know-how從而加快測試和開發的速度,退一步講,至少沒有壞處。
2.測試還是要別人來做。
開發者看待自己的產品有如看待自己,大多是沒有勇氣去發現缺點的。一是源自自尊心,二是為了避免額外的工作。所以就算有問題,如果不嚴重就藏著掖著。但是這對項目來說是不行的,所以測試,verification,一定要旁人來做。
3.多點時間思考。
出現問題后,不要急著修改。要思考推測可能的原因,想清楚后把這些可能的原因都用debug pin或者chipscope引出來。
4.注意復用已有的debug pin。
很多時候,在測試過程中產生了一大堆測試信號,但是時間一長就忘了復用。實際上,當一個問題產生的時候,通過反復觀察已有的debug-pin或許足以發現問題根源,而無需再引出新的pin,并浪費時間去綜合和PAR。
5.仿真加時序足矣。
數字電路在時鐘同步的設計原則下,其功能通過simulation就可以驗證。simulation的結果和PAR后產生的FPGA-image完全等價。當然FPGA也要遵循同樣的設計原則:即時鐘同步。所以對于PAR的結果首先就要確保其時鐘同步的特性。體現為寄存器之間的path必須在一個時鐘周期內完成。(當然有其他約束的例外。)同時要滿足FPGA器件的setup和hold要求。一旦出現timing-error必須通過各種途徑消除error,因為error的存在,意味著時鐘同步的大前提已經被破壞,這時,simulation取得的結果和FPGA是不等價的,繼續測試也毫無意義了。
6.注意不可控的接口部分。
FPGA內部的寄存器之間的timing完全可以通過PAR報告來確認是否有問題。但是和外界的接口部分卻充滿了疑問。我們一般通過假定的input-delay和output-delay來對接口部分進行約束。由于從一開始就施加的是假定的delay,所以即使沒有timing-error,其結果也存在諸多疑問。以我正在進行的測試為例,模塊內部loopback測試完全正常,但是一過cable,傳到對方FPGA,則馬上產生很多誤碼。由于simulation沒有問題,所以必然是我們的某個假定出現了問題,尤其是時鐘同步的假定會得不到滿足。這時候,就要想盡一切辦法,使接口也滿足假定的條件,或者調整設計,將不理想的接口adapting成理想的接口。
7.向直接上司匯報情況,尋求各種可能的許可。
懶得向直接上司匯報情況時,萬一出現進度或者結果不符,所有責任都需要本人承擔。如果提前向上司匯報情況并取得許可,則一切后果都在可控范圍內。比如,工作繁忙時又被派給新的任務,則不能一味逆來順受。應該向上司說明困難,并提前想好一個可行的解決方案供上司參考。
8.外部接口是最大障礙。
如前所述,FPGA內部如果timing沒有問題的話,一般和仿真結果是一致的,問題是外部的接口,包括cable連線等,不在我們確切控制的范圍內,比如其延時特性在40Mhz下仍然正常,但是在80Mhz時可能出現不可預料的情況。所以應該盡量使用經過驗證的"cable--frequency"組合。或者通過設備測量并確認外部接口的延時特性。這樣可以進行有針對性的調整。我最近的教訓就是花了整整一個月調整并測試內部的結構,但是仍然失敗。結果發現由于cable的問題,80Mhz的信號(數據+使能+others)無法正常并行傳輸。如果換成40Mhz的信號就通過了。
9.綜合PR后的結果要和代碼等價。
前面提到仿真加時序足矣,這里面的前提是PR的結果和原始代碼要等價。為了確認這一點,就要把握syn和pr過程中的所有warning以及error,warning的內容不是完全可以忽略的。要特別關注綜合報表中的以下內容:unused ports, removal of redundant logic, latch inference,simulation mismatch等等。在報表中輸入關鍵字查找即可。
審核編輯 黃昊宇
-
FPGA
+關注
關注
1629文章
21729瀏覽量
603019
發布評論請先 登錄
相關推薦
評論