找到相關性

　　在理想的環(huán)境中，從幾種相容的觀點看，存在一個最早的設計——這是我們從中獲得新系統(tǒng)的設計。我們不僅僅會有形式需求文檔，而且還有行為模型——可能同時以更抽象的C代碼以及會話級版本的形式提供。我們還會有硬件和軟件的模塊級體系結構模型。對于實際實現，會有RTL和軟件代碼。

　　在這種環(huán)境中，下一步是觀察。我們通過修改行為模型來滿足行為需求的變化。結構需求的變化會觸發(fā)對IP或者互聯，甚至是軟件功能的調整。參數變化會導致實施層面代碼的修訂。

　　在每種情況下，我們都會有可追溯和設計無關文件，以確定我們進行的調整會怎樣影響設計的其他部分（圖2 ），因此，例如，如果我們修改數據結構的定義或者設計中某一部分信號的帶寬，那么，我們就會知道，這些修改會影響設計中的哪些區(qū)域。工具會幫助我們保存從需求到實現的所有文檔。

　　圖2.可追溯性簡化了需求向工作聲明的轉換

　　每次調整后，我們會在適當的抽象級重新進行仿真，以驗證修改后的設計現在能否滿足新需求。然后，把這種修改傳遞到后面的底層抽象層，重新優(yōu)化，直到我們的新設計通過了驗證。

　　Schirrmeister指出，這種理想化的過程非常依賴于兩組其他的數據，但不能保證可以使用這些數據。首先是使用場景。在正確的使用場景中，我們可以限制對修改后的設計進行驗證，特別是對用戶比較重要的模式和輸入。如果沒有使用模型，我們需要確定新設計在所有可能的實際環(huán)境下都滿足現有以及修改后的需求。

　　其次是足夠的測試臺，針對整個系統(tǒng)和關鍵子系統(tǒng)。在實際中，測試臺體現了人類語言文檔無法表示的需求。很多設計團隊認識到這方面的不足，重新建立系統(tǒng)測試臺，這一項目規(guī)模與系統(tǒng)設計本身一樣大——如果不能提供第三方SoC等關鍵元器件的數據，其規(guī)模會更大。

在真實環(huán)境中

　　對于一些設計人員組織而言，我們的理想化實例不一定具有可行性。汽車、交通、民用航空等領域的設計團隊需要面對ISO 26262或者DO 178B等標準，要求設計和測試臺中的每一單元都能夠追溯到需求文檔的控制單元。這些設計團隊能夠找到設計中的哪一部分需要進行測試，甚至進行修改以符合需求的變化。他們可以指出哪些模塊需要在測試臺中進行修改。這一開始就需要很大的投入。

　　但是在大部分實際設計中，很難實現形式需求的可追溯性。這種項目的可追溯性只存在于設計團隊成員的大腦中。即使最初的設計人員還能夠說出，是什么原因讓他以某種方式來實現某一模塊，但是，在有人向他提問之前，他可能已經離開公司了，或者不在這一行業(yè)中了。我們不得不質疑我們的理想場景怎樣應用在這些真實環(huán)境中。

　　在一個平臺上

　　考慮設計團隊使用平臺設計的情況。平臺一般是由SoC供應商提供的，是系統(tǒng)設計的擴展，而Android是個明顯的例外。您要針對這一體系結構進行的嘗試都含在規(guī)范中。概念非常簡單。建立您自己的需求，找到您不需要的部分平臺，不用它們（圖3 ）。然后，根據需要來優(yōu)化其他部分，以滿足參數約束。