1.一定要逐條閱讀編譯報(bào)告
規(guī)模稍微大一點(diǎn)的FPGA工程的警告和criticalwarning動(dòng)輒兩三千條，雖然其中包含大量的“無威脅”警告和重復(fù)警告，但是我覺得至少95%的程序隱患和設(shè)計(jì)問題都可以從這些報(bào)告中找到蛛絲馬跡。

工作中有不少人問過我這些問題：這么多警告怎么看的過來呀？這個(gè)警告、還有那個(gè)到底是什么意思啊？這個(gè)警告我該怎么去掉？........我能夠理解問出這些問題的人的心情，因?yàn)槲耶?dāng)初也被這些警告嚇懵了，也退縮了一段時(shí)間。但是我不能夠理解的是，為什么春天問過我，到了秋天還問我？后來我明白了，因?yàn)橐稽c(diǎn)長進(jìn)都沒有??！

逐條閱讀編譯報(bào)告是合格設(shè)計(jì)者的必須做到的！他能幫助我們在仿真或在線調(diào)試前：

2.閱讀編譯報(bào)告的兩個(gè)階段
我把閱讀工程的編譯報(bào)告分為兩個(gè)階段：細(xì)嚼慢咽階段和一目十行階段。

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

在這個(gè)階段，很多問題修正后警告就會(huì)消失，減少了警告的總數(shù)；腦中形成了本工程編譯報(bào)告的輪廓后，再閱讀編譯報(bào)告時(shí)就可以快速略過熟悉的“無威脅”警告了，同時(shí)還會(huì)對新出現(xiàn)的警告更加敏感。因?yàn)楫?dāng)新警告出現(xiàn)后，你會(huì)更容易的發(fā)現(xiàn)編譯報(bào)告的“長相”和你印象中的那個(gè)“她”不一樣了。

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

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

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

3.1Literalvaluetrunctated
如下圖所示。這個(gè)警告我應(yīng)該是最近才遇到的。

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

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

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

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

永遠(yuǎn)不要忽視任何警告，因?yàn)樵O(shè)計(jì)錯(cuò)誤或者功能異常很可能隱藏在這些警告中。

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

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

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

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

3.5用不同的編譯器編譯

這是我最近才發(fā)現(xiàn)的解決疑難問題的方法之一。

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

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

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