1.一定要逐條閱讀編譯報告
規模稍微大一點的FPGA工程的警告和criticalwarning動輒兩三千條，雖然其中包含大量的“無威脅”警告和重復警告，但是我覺得至少95%的程序隱患和設計問題都可以從這些報告中找到蛛絲馬跡。

工作中有不少人問過我這些問題：這么多警告怎么看的過來呀？這個警告、還有那個到底是什么意思?。窟@個警告我該怎么去掉？........我能夠理解問出這些問題的人的心情，因為我當初也被這些警告嚇懵了，也退縮了一段時間。但是我不能夠理解的是，為什么春天問過我，到了秋天還問我？后來我明白了，因為一點長進都沒有?。?/p>

逐條閱讀編譯報告是合格設計者的必須做到的！他能幫助我們在仿真或在線調試前：

2.閱讀編譯報告的兩個階段
我把閱讀工程的編譯報告分為兩個階段：細嚼慢咽階段和一目十行階段。

2.1細嚼慢咽
這個階段一般和工程的前幾次（兩三次就夠了）迭代對應。在工程的前幾次迭代過程中，建議每一次都認真的讀每一條警告。這樣做的主要目的包括修正設計中明顯的問題和在大腦中形成本工程編譯報告的輪廓。

在這個階段，很多問題修正后警告就會消失，減少了警告的總數；腦中形成了本工程編譯報告的輪廓后，再閱讀編譯報告時就可以快速略過熟悉的“無威脅”警告了，同時還會對新出現的警告更加敏感。因為當新警告出現后，你會更容易的發現編譯報告的“長相”和你印象中的那個“她”不一樣了。

需要格外注意的是，如果是初學者，不要遇到看不懂的就問。而是先嘗試自己定位和修改，如果解決不了就去閱讀相關的技術文檔，然后使用搜索引擎。經過這些嘗試，即使不能解決問題，相信你也會收獲頗豐。這時候再去問別人才會有平等對話的機會。

2.2一目十行
度過了細嚼慢咽階段后，自然就可以一目十行了。現在我一般第一次閱讀編譯報告會用30分鐘到1個小時（前提是不出現難以定位和比較詭異的警告），大概兩次后，閱讀報告并確定修改是否引入新問題就只需要30秒到2分鐘了。

3.分析警告并判斷其“威脅”程度
本章節將列出自己遇到的警告，以及分析定位警告的過程，供大家參考。

3.1Literalvaluetrunctated
如下圖所示。這個警告我應該是最近才遇到的。

可以看到這個警告非常有規律，都集中在vfg_cmp文件中，而且是很集中的幾行，下圖是代碼部分。

出現警告的前幾行分別是261、262、269、270、277....直到最后的302行，初看以下代碼我其實挺懵的，感覺沒什么問題。

但是我發現，同樣的寫法，為什么警告只提示到第302行，302行以后反而沒有？下面是最后兩個case的條件。

同樣是在給cmpl_in_d1_r1_and賦值時出現了固定值，為什么309和310沒有警告呢？這時通過仔細觀察和對比發現，由于疏忽，前面賦值時居然使用了6'h111111、7'h1111111等等這種寫法。7'h1111111理所當然被trunctated到了7bits，這將導致cmpl_in_d1_r1_and在很多條件下的固定值部分出現錯誤，比如7'b1111111變成了7'b0010001。而cmpl_in_d1_r1_or雖然也犯了同樣的錯誤，但是由于寫法是6'h000000，所以沒有給出警告。

永遠不要忽視任何警告，因為設計錯誤或者功能異常很可能隱藏在這些警告中。

3.2Unusedsequentialelementremoved
這個警告是指特定的寄存器被移除。個人人為這是一個威脅度很低，而且很難找到具體位置的警告。比如下面的警告，第一次遇到的時候，我仔細的檢查了每一個被移除的sequential單元，但是一無所獲。經過多次驗證和實踐，絕大多數這個警告都沒有問題。我估計其主要原因有以下：

3.3Widthdoesnotmatch
下圖所示的警告也很常見，這種警告最好逐條閱讀并排除其威脅。位寬不匹配會導致該警告，比如32bits位寬的信號，在端口處連接到一個10bits的信號。下圖的警告則是因為一個32bits的端口，其所在模塊被例化的時候該端口被連接，但是連接該端口的信號沒有被定義。沒有定義的wire型信號被默認為1bit位寬。

3.4分析警告的步驟
前面列舉了幾個例子，本章節簡單介紹以下自己分析警告的步驟。

1.認真閱讀警告。對于警告內容清晰易懂的自然沒有問題，有些警告會寫的晦澀、很難定位，這時候需要細扣每一個句式、每一個單詞和每一個術語。
2.與程序相互對照。警告一般都會給出文件的位置，這是需要認真對照警告和源碼。有時候警告給出的位置不一定準，有可能是附近或者其他關聯位置。
3.查詢文檔。有些警告中可能會涉及一些FPGA內部的一些特殊電路，這時候可能需要下載和閱讀相關的文檔。
4.在官方論壇查詢。這是非常有效的手段，大部分少見和特殊的錯誤都能在這里找到。
5.在官方論壇提問。極少數問題在論壇上也找不到對應的回答，這時候需要在論壇上提問。運氣不好的話，你發的貼子可能幾天、幾個星期沒人理。這時候建議把帖子挪個論壇分區再發。
6.找技術支持。為什么把這個列在最后一步呢？因為通過前面的步驟，個人水平會有很大的進步，不要養成所有問題都依賴技術支持的習慣。

3.5用不同的編譯器編譯

這是我最近才發現的解決疑難問題的方法之一。

我使用Vivado2019.2版本時，總是會產生一個莫名的錯誤。我核對了不下10次，檢查了相關的文件，都沒能定位該問題，耽誤了大概兩天時間。后來經朋友提醒：多換幾個編譯器版本試試，甚至包括一些第三方編譯器。

我使用Vivado2019.1版本重新編譯，果然給出了另一個錯誤，這個錯誤與2019.2給出的錯誤沒有任何聯系。我把2019.1給出的錯誤修改后，再回到2019.2編譯，竟然再也沒有任何錯誤產生了。

FPGA的編譯器是非常復雜的EDA工具，不同版本之間存在差異或者個別版本有bug都是很正常的，所以換版本，甚至換不同EDA工具都是可行的方法。