仿真器并非萬能

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

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

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

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

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

????? 我接下來通常會聳聳肩膀，然后切換到 FPGA 廠商的綜合器，看看其優化器能否產生可以順利布局與布線的結果。因此，點擊幾下鼠標之后我開始重新運行 “綜合（Synthesis）”與“創建（Build）”。這次我注意到綜合多少比以前快了一點。我心中燃起希望，因為廠商的引擎在進行較少程度的優化，而且將產生盡管更龐大、但更精確的實施方案。然后在映射過程中在同一地方嘎然而止，同樣出現了讓人費解的錯誤消息，然后是一條警告：
?
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.

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

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)

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

???

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

?

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

?我首先認識到可以用原理圖當畫出以下簡單的 IOBUF 電路：

???

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

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

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