隨著敏捷方法的建立提高了生產力和質量，業界對於硬體設計的興趣正在增長。

儘管如此，人們普遍認為硬體領域的成功依舊是有限的。現實可能比想象要好一些，因為硬體中的某些敏捷性趨勢沒有明確標記。

例如，我們看到越來越多的努力將 IP 級設計和驗證與 SoC 級設計和驗證分離。在這種情況下，不同的 IP 團隊都從 SoC 專案的“列車模型”上以非同步的方式執行，當完成 SoC 設計時可以選擇任何版本的 IP。

雖然這種方法沒有被貼上敏捷的標籤，但這種方法確實符合敏捷哲學。

敏捷設計發展的最大阻力 —— 算力

晶片流片的高成本和流片後無法更改設計通常被認為是敏捷方法不能很好地對映到到硬體設計的關鍵原因。但是，流片後無法敏捷並不一定意味著我們不能在流片前更加敏捷。

在硬體設計中採用敏捷性設計最大阻力之一是硬體驗證的複雜性。測試軟體程式只需要執行該程式所需的計算，當然測試會全速執行。

測試硬體設計需要一個模擬器程式，該程式可以在軟體中模擬晶片設計在硬體中製造時的行為。這個模擬器程式的計算非常昂貴，但其執行速度比它正在模擬的真實晶片的速度慢數千倍。

設計硬體的公司在測試其設計時會受到計算能力的限制。幾家支援系統設計的公司都提供特殊的模擬加速器，它們使用專為模擬加速而設計的專用處理器或 FPGA。這些系統的模擬速度比通用伺服器上的模擬快數百倍，它們的成本也相應地更加昂貴。因此，設計團隊發現他們在這些平臺上的計算資源同樣有限。

敏捷設計需要持續整合和測試，不僅是單元級別，整個系統級別同樣如此。如果測試受限於計算能力，那麼敏捷設計需要更高的計算效率，尤其是在系統級別。例如，一個典型的現代 SoC 需要在數千臺機器的伺服器群上進行長達五天的連續計算來完成一組基本的完整晶片測試。

在如此極端的計算背景下，設計團隊如何才能讓晶片設計變得更加敏捷？

解決敏捷計算挑戰的兩個方法

有兩個關鍵方法可以推動解決敏捷硬體設計中的計算障礙：通過引數化減少設計規模和通過計算物流，計算物流涉及使用計算和高等數學來規劃和實施大型和複雜的任務。計算物流應用於許多領域，包括貨物、服務和相關資訊從原產地到消費地的流動和儲存。）減少測試規模。

第一，引數化。複製在 SoC 設計中越來越普遍，無論是 IP 級複製（如多核 CPU），還是架構級複製（如 GPU 中的著色器核心或 AI 加速器中的 MAC 節點）。通過利用引數化，可以在某種形式的引數化下將更多相似但不同的事物融合在一起，從而顯著增強複製的範圍。

設計中的複製越多，自動生成設計的縮減配置的可能性就越大，這些配置更小但對測試仍然有意義。引數化的使用越複雜，在 SoC 級別最小化用於測試特定功能的設計尺寸就越靈活。

System Verilog 等主流硬體描述語言 (HDL) 已經很好地支援複製和引數化，但可以通過採用更高階的語言作為 HDL 生成器來進一步啟用它們。例如，SystemC、Matlab、Python 或 Chisel。與分離 IP 和 SoC 級設計的趨勢一樣，採用高階語言進行硬體設計也出現了類似的趨勢。

至於計算物流，如果我們在敏捷設計方法下持續整合和測試，那麼每次整合和測試都是對之前的整合和測試的增量。對於給定的增量設計更改，計算邏輯意味著自動確定最佳設計配置、測試集和測試配置，以便以最低的計算成本提供良好的驗證質量。

可以將其視為一類新的 EDA 工具 —— 一個引擎在完整的驗證流程中控制所有其它引擎。

我們看到了通過計算物流提高驗證計算效率的巨大潛力，特別是如果期待異構的、基於雲的未來，在廣泛的模擬和模擬平臺上可以對無限使用容量進行計費。正如計算物流改變了 UPS 和 FedEx 等運輸公司的包裹吞吐量一樣，它也可以改變硬體設計中的驗證吞吐量。

總結

硬體設計已經變得更加敏捷，但仍有很大的改進空間。與軟體驗證相比，這種改進的一個關鍵障礙是硬體驗證的巨大計算成本。

通過利用複製、引數化和高階語言作為 HDL 生成器，我們可以最大限度地減少測試中的設計尺寸。

通過採用計算物流，我們可以最大限度地減少測試工作量並進一步優化測試中的設計尺寸，尤其是在支援雲的未來，以及基於使用無限制驗證計算的可用性。

（譯自 eetime，本文作者Paul Cunningham 是 Cadence Design Systems 系統和驗證組的高階副總裁兼總經理）