不可不知的幾種真實(shí)設計環(huán)境中的系統設計

　　找到相關(guān)性

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

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

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

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

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

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

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

在真實(shí)環(huán)境中

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

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

　　在一個(gè)平臺上

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