新世代可編程邏輯開發人員

曾幾何時，在邏輯合成尚未盛行之前，工程師可能就已被要求要設計純邏輯的系統。那時我們有雷達，但沒有微控制器，需要數位訊號處理，但沒有現成的數位訊號處理器。不過，我們還是對雷達進行了數位處理。

當時，剛畢業的工程師就得知道如何設計類比和數位硬體，以及如何開發軟體。我擔心工程師身兼十八般武藝的時代正在消逝，並為邏輯設計的未來感到擔憂。有句格言說，「如果你的工具只有一柄鐵錘，你就可能認為所有的問題都是鐵釘」。我們是不是覺得，每個問題看起來都像是軟體問題？

如果您在網路上搜尋「FPGA 應用」，會找到一連串最前線的電氣工程應用。應用範圍包括人工智慧和語音識別，乃至通訊和影像處理。這些應用的麻煩在於並不簡單，不適合初學者使用。若要掌握這些應用的實作，需要經過困難的學習過程，而且還要涉獵多個重要的主題。

不僅要學習可編程邏輯元件本身及其整合開發環境 (IDE；每個製造商都有自己的 IDE)，以及新的編程方法 (即硬體描述語言 HDL，及其對並行性和時間概念的配合)，還必須瞭解應用本身。除了專家，這幾乎沒人辦得到。對於希望提升可編程邏輯技能的下一代邏輯設計人員來說，這可不是讓他們大受鼓舞的好兆頭。門檻太高了。我認為這會阻礙人們踏入此領域，因此最終成為未來可編程邏輯狂熱者的人越來越少。網路上到處有人表示對可編程邏輯設計現狀感到沮喪，不過也有多個開放原始碼社群正嘗試解決這個問題。許多人認為元編程是救贖的解藥。這是一種編程技巧，即程式會將另一個程式視為自己的資料。

可編程邏輯公司身陷兩難。一方面，投資者要求開發功能更強大、價格更昂貴的晶片，而另一方面，能使用這些晶片的人相對較少。這些公司的解決辦法是將軟體開發人員轉換成硬體設計人員，而目前也正透過新的工具達到此目標。

高階合成 (HLS) 編譯器將設計抽象化帶到更高的境界，讓我們更加遠離邏輯設計的本質。若能從純軟體描述建構精密的硬體設計固然很棒，但就無法體驗到邏輯設計對人們的內在吸引力。我不否認人在最佳化方面能夠勝過電腦，但我認為，在以前設計簡易型電路比較簡單。這個麻煩在於，現在的簡易型電路比以前要難設計。

我到現在都還記得，當初看到自己手工製作的邏輯設計電路時，我是多麼興奮。靠著我的聰明才智，需要使用的元件數減到最少。當我在 90 年代初期學習可編程邏輯時，我感到非常開心的是，我能運用電路設計知識，在一個具有 128 個邏輯元素的元件裡實作我的邏輯電路。而且，我是靠自己的才智一一挑選出那些邏輯元素，而沒有倚賴某些默默無聞的演算法開發人員的智慧。

邏輯設計在進步，軟體設計也在進步。現在幾乎已進入物件導向編程 (OOP) 的世界，常見設計模式的函式庫也有妥善的記錄說明，並可隨時從程式碼函式庫取得。我的設計模式書是 Erich Gamma 等人曾紅極一時的著作《設計模式：可重複使用型物件導向軟體的基礎》(Design Patterns, Elements of Reusable Object-Oriented Software)。讓我覺得有意思的是，硬體設計雖從物件導向起步，但引進 HDL 後的發展卻陷入停滯。即使 HDL 可配合設計重複使用，設計函式庫包含的仍是最基本的功能。在網路上搜尋「7400 系列積體電路清單」，就會找到一些早期的硬體設計模式。我發現有一點很有趣，Meilir Page-Jones 在其著作《UML 物件導向設計基礎》(Fundamentals of Object-Oriented Design in UML) 中提到，積體電路是良好物件設計的典範，具有高內聚、低耦合。但是，在追求越來越複雜的可編程邏輯元件的過程中，我們捨棄了原本的根基，不再追求直截了當的簡易邏輯設計。現今的設計方法仰賴電腦演算法實作邏輯。我認為這個做法反而阻礙了可編程邏輯的初學者。

您可能會問：「插到電視機後面玩第一款《乓 Pong》遊戲中，有幾行程式碼？」答案是零。這是純硬體的作品 (見圖 1)，裡面沒有任何軟體！我不認為有很多剛畢業的工程師，不靠軟體就能設計出這款遊戲。他們會說：「為什麼要這樣做？」我的答案是：「為了切入不同的角度，因為你應該知道這是可以做到的。這比你想的還要簡單。」

圖 1：Pong 遊戲線路圖 (圖片來源：Adafruit 部落格，原始來源未知)

IEEE 在 2019 年初發佈一份清單，列出工程師喜歡和討厭的編程語言。此清單顯示工程師喜歡 Python。我深信不疑。幾年前，我曾擔任 Texas Instruments 設計大賽的評審，我發現 10 個大專團隊中，有 9 個都在專案中採用 Python。VHSIC 硬體描述語言 (VHDL) 和 Verilog 都未出現在這份好惡清單。或許 IEEE 的編輯群沒有考慮到這些 HDL 編程語言，但我認為更有可能的是，沒有受訪者把 HDL 納入考慮。若果真如此，就表示很少有工程師想到這些語言或邏輯設計，這對邏輯設計領域來說不是個好兆頭。

那麼，該怎麼做呢？我們如何讓新的工程師具有正確的心態，在對待問題時考慮以軟體或硬體作為解決方案？畢竟多數問題都能用軟體或硬體的方式解決。我有個想法。

我認為 Arduino 平台培養出許多對軟體感興趣的年輕人。他們進入學校就讀，希望成為工程師和電腦科學家。此平台是如何做到的呢？Arduino 降低了開發軟體的學習難度，讓軟體開發不再那麼令人畏懼。

指定板件後，使用者不必設定連結器命令檔，訊號名稱成為了標準，而且其 IDE 隱藏了編譯細節。Python 有個優點，即要求嚴格的格式，例如縮排必須統一。這能避免進行低價值、任意性的選擇，讓整個開發過程更簡單，進而提高開發人員的生產力。可編程邏輯也需要同樣的效果，因此可編程邏輯產業有必要在某個標準上進行協作。

對於這個標準，我提議幾個屬性。Arduino 本身並沒有很強的能力來修改其底層架構 (例如配合嵌套式中斷)，同樣地，我們要假設在這個平台上解決的邏輯問題非常簡單，足以讓現今的可編程邏輯元件符合所有的時序限制。與 Arduino 等效的可編程邏輯元件板 (PLDB) 應具有足夠慢的時脈速度，確保能讓任何含有 1,000 個邏輯元素的設計成功運作。這表示平台只需要進行功能性驗證。

既然大家都愛用 Python，我提議 PLDB 應由 Python 來支援，並建構於 nMigen 或 MyHDL (見圖 2)，甚至是帶有 RTLIL 的 Yosys 等架構上。這樣一來，初學者便能以解譯性語言來模擬邏輯設計、產生真值表，並存取其他任何可用的 Python 函式庫。說到 Python 的函式庫，使用 Python 也可讓社群使用 Python 套件索引 (PyPI) 來發佈可重複使用的硬體區塊，有助於解決缺乏完備且共用型設計模式的問題。與 Python 一樣，nMigen 也支援元編程，因此即使這個架構支援簡易的設計，平台也能擴充以支援複雜的設計。

圖 2：以 Python 為基礎的架構 (圖片來源：MyHDL.org 與 m-labs.hk)

主機 PC 和 PLDB 之間的介面應使用 USB，同時嵌入 PLDB 的微控制器應具有相應的 API，可供主機 PC 用於瞭解 PLDB 的配置，確保能自動設定 Python 環境，進行可編程邏輯開發。此設定的結果應可隱藏合成、佈設及編程的細節，同時有利於在 PC 上進行功能性模擬，並在實際硬體上執行。

為了避免某些讀者認為不再需要解決簡單的邏輯問題，讓我來展示一下 Digi-Key 的微控制器銷售統計數據。圖 3 顯示客戶所購買微控制器類別的細分圖，圖 4 則顯示了每個類別的銷售量。總體來說，Digi-Key 上架超過 80,000 個微控制器零件編號，有超過 19,000 款微控制器庫存能立即出貨到世界各地。這些數字顯示，較多工程師使用簡易的 8 位元處理器，而 Digi-Key 出貨的 8 位元微控制器數量，超過其他任何類別的處理器。由此可見，在使用者遇到的問題中，更多是簡單問題，而不是複雜問題。

圖 3：購買每種微控制器的 Digi-Key 客戶數量 (圖片來源：Digi-Key Electronics)

圖 4：Digi-Key 每種微控制器的銷售量 (圖片來源：Digi-Key Electronics)

我們的目標應該是讓任何人都熱衷於可編程邏輯，即使沒有接受過正規的邏輯設計教育，但前提是我們必須改變開發做法。