仿真器并非萬能

?現(xiàn)在已經(jīng)到了關(guān)鍵時刻。我們已經(jīng)確定了電路板的設(shè)計原型，現(xiàn)正送回實驗室進(jìn)行測試。由于后期規(guī)格更改，以及在布線后信號完整性分析過程中發(fā)現(xiàn)的問題，這個項目比原計劃滯后了兩周。這對我而言并非壞事，因為說實話我需要這兩周時間，以便將仿真用的測試臺準(zhǔn)備得停停當(dāng)當(dāng)。

????? 此項目采用 VHDL 編碼，而且我采取了一種循規(guī)蹈矩的方案——保持層級結(jié)構(gòu)，所有黑盒子 (Black-box)、原語和宏指令都采用全局聲明（以便完成的設(shè)計具有更高的可移植性并且可以符合 IEEE 標(biāo)準(zhǔn)），而且主要是一種 RTL 類型的方案。當(dāng)然，我的部分設(shè)計具有行為屬性，要不然就是我完全忽略了 HDL 的主要優(yōu)勢 ––– 應(yīng)用行為抽象的能力。

????? 因此我多費了點事，不過現(xiàn)在我可以開始啟動仿真工作了。仿真進(jìn)行了數(shù)毫秒，我對結(jié)果相當(dāng)滿意。我可以通過 Wave 編輯器測量占空比與周期得到了我希望的結(jié)果，復(fù)位邏輯按照我所預(yù)測的時鐘周期數(shù)出現(xiàn)，時鐘合成器運行正確無誤。而且I/O 信號顯示出我所希望的 1、0 以及三態(tài)。值得一提的是，我很清楚地記得我在幾千行代碼中，已經(jīng)謹(jǐn)慎地避免了異步過程和時鐘域交叉，最重要的是解決信號 (Resolved signal)。我想起學(xué)科導(dǎo)師曾經(jīng)略帶諷刺地說‘PCB 與芯片設(shè)計師才用三態(tài)’。

????? 開始時的信心百倍讓我想冒點險，我決定將設(shè)計綜合在一起。幸運的是，我使用的工具允許我輕松嘗試多種不同綜合引擎，因此我開始從其中一個內(nèi)置引擎入手。因為項目中采用了幾種復(fù)雜的行為狀態(tài)機(jī)，需要花點時間進(jìn)行優(yōu)化，不過完成時出現(xiàn)了少數(shù)幾個次要警告。到目前為止一切順利。

????? 我的信心更足了一點，接著繼續(xù)點擊“創(chuàng)建 (Build)”按鈕，接下來工作流程的“映射 (Map)”、“轉(zhuǎn)換 (Translate)”、“布局布線 (Place and Route)”以及“位文件生成 (Bit File Generation)”，這些操作全部通過與芯片廠商工具的命令行接口在后臺執(zhí)行。映射設(shè)計進(jìn)行了大約一分半就停止了，顯示出一條有關(guān) IBUFT 與 OBUFT 的難懂信息。唉……！我知道自己的好日子到頭了，真是大夢初醒?。?/P>

????? 我接下來通常會聳聳肩膀，然后切換到 FPGA 廠商的綜合器，看看其優(yōu)化器能否產(chǎn)生可以順利布局與布線的結(jié)果。因此，點擊幾下鼠標(biāo)之后我開始重新運行 “綜合（Synthesis）”與“創(chuàng)建（Build）”。這次我注意到綜合多少比以前快了一點。我心中燃起希望，因為廠商的引擎在進(jìn)行較少程度的優(yōu)化，而且將產(chǎn)生盡管更龐大、但更精確的實施方案。然后在映射過程中在同一地方嘎然而止，同樣出現(xiàn)了讓人費解的錯誤消息，然后是一條警告：
?
ERROR:NgdBuild:924 - bidirect pad net 'DATA_IO<15>' is driving non-buffer
?? primitives:
???? pin I1 on block U_dspboard_fpga/fb_epb_intf_inst/n12g with type AND2B1
WARNING:NgdBuild:465 - bidirect pad net 'DATA_IO<15>' has no legal load.

????? 我開始嘟嘟囔囔，旁邊的同事瞇起眼睛，像老鷹山姆那樣斜眼著我。慶幸的是，我能夠從消息屏幕中的錯誤消息中找到出現(xiàn)錯誤的代碼行。雙擊與兩個串聯(lián)的緩沖區(qū)有關(guān)的第一個錯誤消息后我找到了以下代碼片段：

DATA_IO? <= DATA_IN when CNTL_IN(4) = '0' -- write to Ext. Device
??????????????????? else (others => 'Z');
DATA_OUT <= DATA_IO; -- data from core to CF (5000_0050)

????? 我最初的想法是“啊哈，我弄出了一個三態(tài)端口與多路復(fù)用器，多么好的想法呀？”。聰明而又經(jīng)驗豐富的讀者一眼就能看清這個問題，但是這種錯誤會讓 FPGA 新手難倒好幾天，讓人寢食難安，心力憔悴。我盯著這三行代碼看了半分鐘，意識到應(yīng)該隨便找張紙畫出我最初的意圖：

???

????? 現(xiàn)在我認(rèn)識到，我之前認(rèn)為綜合引擎會明白我并不想在器件中加入高阻抗信號。實際上，當(dāng)我再次查看錯誤與警告消息之后才清楚它就是這么干的：

?

????? 如果您是一名出色的 FPGA 設(shè)計人員并且確實閱讀了數(shù)據(jù)手冊與程序庫指南，那么您立刻就會明白這是不可能的事情。我所知道的任何 FPGA 布線資源都不會允許這種連接。

?我首先認(rèn)識到可以用原理圖當(dāng)畫出以下簡單的 IOBUF 電路：

???

????? 由于DATA_IO 與 DATA_OUT連接到較高層文檔中的 IO 接口，綜合器會插入用于 DATA_OUT的適當(dāng) OBUF，因此我無需在此畫出。這個例子可以很好地說明了原理圖與方框圖設(shè)計方案如何能實實在在地減少未知錯誤。我的第二個更加驚人的發(fā)現(xiàn)是我在 VHDL 代碼中編寫的內(nèi)容能夠全部得到正確仿真，這里顯示出了我實際預(yù)期的信號變化。當(dāng)然，我始終明白能夠仿真與能夠綜合之間的區(qū)別。這里有一個新的誤解 —— 我可以無錯地仿真并合成我的設(shè)計。我敢斷言，現(xiàn)在應(yīng)該被問：“它可以仿真，那么可以合成嗎？可以被映射嗎？”

????? 這個場景是我虛構(gòu)的，盡管它出自我親身經(jīng)歷過的真實事件。我曾經(jīng)與許多喜歡在設(shè)計流程中使用 VHDL 和 Verilog 的 FPGA 設(shè)計人員深入探討過。我和他們有一致的看法，就是他們的大多數(shù)設(shè)計對于基于原理圖的方法來說過于復(fù)雜。也就是說，您是否主要通過 RTL 進(jìn)行設(shè)計。HDL 的發(fā)明可減少描繪邏輯函數(shù)的工作量，因為門電路與觸發(fā)電路的數(shù)量太多，也太繁復(fù)。然而， FPGA（和 ASIC）一直繼續(xù)遵循著摩爾定律。設(shè)計也是如此，復(fù)雜到使用VHDL 或 Verilog 設(shè)計會把你帶入泥潭，讓你再也看不清整體設(shè)計意圖。上面問題就是例證。

????? 設(shè)計人員需要保持他們設(shè)計的領(lǐng)先地位。我深信他們將別無選擇地這么做 —— 采用更高端的方法來贏得時間和自由，從而可以集中精力進(jìn)行其產(chǎn)品最重要部分的設(shè)計，即在市場上能使他們脫穎而出的部分。這個行業(yè)正在面臨的挑戰(zhàn)是：技能嫻熟的資深設(shè)計人員必須放下架子來使用與工具配套提供的免費的IP，而不是自己親手通過 HDL 把它們重新出來。我能理解這個挑戰(zhàn)：作為一個真正的工程設(shè)計迷，我所做的應(yīng)該是這個世界上許多人都做不到的（或者說我也相信）。不過事實上，如果我想設(shè)計更好的產(chǎn)品，并且更快地完成，我就必須站在別人的肩上，對他說“謝謝”，然后采用方框圖的方法迅速將我的系統(tǒng)組合出來。接下來我就可以專心致力于設(shè)計我的創(chuàng)意，并且把它集成到整體系統(tǒng)中，使整個系統(tǒng)更加可靠并出類拔萃。