不可不知的幾種真實設(shè)計環(huán)境中的系統(tǒng)設(shè)計
找到相關(guān)性
在理想的環(huán)境中,從幾種相容的觀點看,存在一個最早的設(shè)計——這是我們從中獲得新系統(tǒng)的設(shè)計。我們不僅僅會有形式需求文檔,而且還有行為模型——可能同時以更抽象的C代碼以及會話級版本的形式提供。我們還會有硬件和軟件的模塊級體系結(jié)構(gòu)模型。對于實際實現(xiàn),會有RTL和軟件代碼。
在這種環(huán)境中,下一步是觀察。我們通過修改行為模型來滿足行為需求的變化。結(jié)構(gòu)需求的變化會觸發(fā)對IP或者互聯(lián),甚至是軟件功能的調(diào)整。參數(shù)變化會導(dǎo)致實施層面代碼的修訂。
在每種情況下,我們都會有可追溯和設(shè)計無關(guān)文件,以確定我們進行的調(diào)整會怎樣影響設(shè)計的其他部分(圖2 ),因此,例如,如果我們修改數(shù)據(jù)結(jié)構(gòu)的定義或者設(shè)計中某一部分信號的帶寬,那么,我們就會知道,這些修改會影響設(shè)計中的哪些區(qū)域。工具會幫助我們保存從需求到實現(xiàn)的所有文檔。
圖2.可追溯性簡化了需求向工作聲明的轉(zhuǎn)換
每次調(diào)整后,我們會在適當(dāng)?shù)某橄蠹壷匦逻M行仿真,以驗證修改后的設(shè)計現(xiàn)在能否滿足新需求。然后,把這種修改傳遞到后面的底層抽象層,重新優(yōu)化,直到我們的新設(shè)計通過了驗證。
Schirrmeister指出,這種理想化的過程非常依賴于兩組其他的數(shù)據(jù),但不能保證可以使用這些數(shù)據(jù)。首先是使用場景。在正確的使用場景中,我們可以限制對修改后的設(shè)計進行驗證,特別是對用戶比較重要的模式和輸入。如果沒有使用模型,我們需要確定新設(shè)計在所有可能的實際環(huán)境下都滿足現(xiàn)有以及修改后的需求。
其次是足夠的測試臺,針對整個系統(tǒng)和關(guān)鍵子系統(tǒng)。在實際中,測試臺體現(xiàn)了人類語言文檔無法表示的需求。很多設(shè)計團隊認(rèn)識到這方面的不足,重新建立系統(tǒng)測試臺,這一項目規(guī)模與系統(tǒng)設(shè)計本身一樣大——如果不能提供第三方SoC等關(guān)鍵元器件的數(shù)據(jù),其規(guī)模會更大。
在真實環(huán)境中
對于一些設(shè)計人員組織而言,我們的理想化實例不一定具有可行性。汽車、交通、民用航空等領(lǐng)域的設(shè)計團隊需要面對ISO 26262或者DO 178B等標(biāo)準(zhǔn),要求設(shè)計和測試臺中的每一單元都能夠追溯到需求文檔的控制單元。這些設(shè)計團隊能夠找到設(shè)計中的哪一部分需要進行測試,甚至進行修改以符合需求的變化。他們可以指出哪些模塊需要在測試臺中進行修改。這一開始就需要很大的投入。
但是在大部分實際設(shè)計中,很難實現(xiàn)形式需求的可追溯性。這種項目的可追溯性只存在于設(shè)計團隊成員的大腦中。即使最初的設(shè)計人員還能夠說出,是什么原因讓他以某種方式來實現(xiàn)某一模塊,但是,在有人向他提問之前,他可能已經(jīng)離開公司了,或者不在這一行業(yè)中了。我們不得不質(zhì)疑我們的理想場景怎樣應(yīng)用在這些真實環(huán)境中。
在一個平臺上
考慮設(shè)計團隊使用平臺設(shè)計的情況。平臺一般是由SoC供應(yīng)商提供的,是系統(tǒng)設(shè)計的擴展,而Android是個明顯的例外。您要針對這一體系結(jié)構(gòu)進行的嘗試都含在規(guī)范中。概念非常簡單。建立您自己的需求,找到您不需要的部分平臺,不用它們(圖3 )。然后,根據(jù)需要來優(yōu)化其他部分,以滿足參數(shù)約束。
評論