仿真器并非萬能之神

現在已經到了關鍵時刻。我們已經確定了電路板的設計原型，現正送回實驗室進行測試。由于后期規格更改，以及在布線后信號完整性分析過程中發現的問題，這個項目比原計劃滯后了兩周。這對我而言并非壞事，因為說實話我需要這兩周時間，以便將仿真用的測試臺準備得停停當當。
此項目采用 VHDL 編碼，而且我采取了一種循規蹈矩的方案――保持層級結構，所有黑盒子 (Black-box)、原語和宏指令都采用全局聲明（以便完成的設計具有更高的可移植性并且可以符合 IEEE 標準），而且主要是一種 RTL 類型的方案。當然，我的部分設計具有行為屬性，要不然就是我完全忽略了 HDL 的主要優勢 CCC 應用行為抽象的能力。
因此我多費了點事，不過現在我可以開始啟動仿真工作了。仿真進行了數毫秒，我對結果相當滿意。我可以通過 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_IO15>' 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_IO15>' 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 布線資源都不會允許這種連接。