有一個基本的自然法則適用于任何計算芯片，無論是處理器、微控制器還是片上系統：軟件總是會發現硬件錯誤。在我的整個職業生涯中，我參與過的項目中沒有一個被證明是正確的。

如果你很不幸，在你制作芯片后軟件發現了一個錯誤，那么接下來會發生什么取決于問題的嚴重程度。

如果它不是致命的，并且如果你很幸運并且像一些知名處理器制造商那樣擁有市場力量，那么每個人都會圍繞這個 bug 編寫代碼，然后所有未來的版本都必須復制這個 bug 以實現向后兼容性。這不適用于我們大多數人。更傾向于：

您可能必須刪除不起作用的功能。

功率可能太高，或性能太慢，損害您的競爭力和獲得好價格的能力。

在最壞的情況下，您可能不得不花費大量時間并旋轉另一套面具。額外的延誤和費用。

最好的解決方案是在您投入芯片之前運行該軟件并捕獲這些錯誤。您將同時驗證軟件和硬件。但是怎么做呢？

模擬軟件非常慢。我們說的是幾年。除了瑣碎的代碼之外，根本不是一個選項。

相比之下，仿真被證明是解決這個問題的關鍵工具。您可以在模擬器上實例化硬件，然后讓它在合理的時間范圍內運行實際代碼。也許不是真正的系統速度，但足夠快以使其成為可行的解決方案。

但是，假設您要找到問題，您必須能夠追蹤這些問題的原因，而調試部分在歷史上一直是問題所在。事實上，許多工程師一直不愿意使用仿真，因為在過去，訪問內部處理器狀態的唯一途徑是通過 JTAG。仿真器以幾 MHz 的時鐘速度運行；仿真器上的 JTAG 只運行其中的一小部分。

那么，例如，如果你想單步執行指令？這意味著通過 JTAG 傳輸大約 400 萬個低級位。在仿真器上以 1 MHz 完成，這將需要 4 秒非常昂貴的實時仿真器時間。

而且，更糟糕的是，它是侵入性的：在這 4 秒內，時鐘正在走動。處理器狀態將保持不變，但處理器之外的世界將繼續。如果您只是在調試處理器代碼，這可以工作（即使速度很慢）。但是，如果您嘗試調試與非處理器硬件的交互，這將變得非常困難，因為在您完成該單個步驟時，處理器之外的所有內容都已更改狀態。

由于仿真器上的 JTAG 既緩慢又具有侵入性，調試——尤其是與性能和同步相關的問題——變得非常令人沮喪。因此，考慮到這一點，仿真在過去并不是首選解決方案——阻力仍然存在。

今天的模擬器調試速度很快

但是時代和模擬器已經改變。Mentor 有一種單獨的方法來捕獲不依賴于 JTAG 的處理器狀態，因此它可以快速發生 - 在 40-50 MHz 范圍內。這可能比 FPGA 原型上的 JTAG 更快。數據被饋送到我們的 CoModel 主機，狀態歷史可以在其中存儲和重新創建，一個周期一個周期。

鑒于已存儲的跟蹤，您現在可以針對該跟蹤重放任何有問題的軟件，它將遵循系統狀態，以便您可以看到哪里出了問題。可以單步執行；您可以探測寄存器和內存；你可以看公交車。一切都沒有入侵：您的調試工作不會改變系統狀態。這一切都可以離線完成——您無需使用實時仿真器，這使其更具成本效益。

因此，關于軟件調試在模擬器上是否實用的歷史擔憂不再適用。您可以在流片前徹底使用您的計算平臺。軟件開發人員可以在芯片可用甚至 FPGA 原型可用之前很久就開始軟件開發。可用于調試的工具旨在為軟件工程師所熟悉——即使您最終發現了硬件錯誤。

行使部分系統

我們要解決的下一個挑戰是影響單個 IP 塊的開發人員，這些 IP 塊最終將成為整個系統的一部分。今天的問題是，在完全系統集成之前，你真的不能用真正的軟件運行你的塊，因為系統需要你的部分和所有其他部分才能工作。因此，即使您提前完成了塊設計，也是“快點等待”。

在 Mentor，我們正在開發一個測試平臺增強功能，它將提供計算平臺的關鍵部分。鑒于 ARM 的流行，我們將從 ARM 架構和與 ARM 相關的總線開始。處理器將覆蓋 Android 或 Linux。這將讓您在仿真器上實現您的模塊，并在完整系統設計可用之前將其“插入”抽象環境，讓您在驗??證方面領先一步。

總之，您必須在生成掩碼之前運行軟件，以證明您的計算硬件是正確的。仿真是做到這一點的唯一現實方法，而目前 Mentor 的 Veloce 仿真器上提供的工具使其成為非常實用、高效的練習。您可以用最少的實時仿真時間快速調試您的軟件和硬件。而且，在不久的將來，您將能夠在完全系統集成之前在 IP 塊上運行和調試該軟件。

您可以更早地編寫軟件，并且可以更快地驗證您的硬件。所有這些都使得您在真正的硅片中發現這些硬件錯誤的可能性大大降低。

審核編輯：郭婷