對基于SoC系統(tǒng)設(shè)計(jì)正確方法的爭論非常激烈。是傳統(tǒng)的寄存器傳送級（RTL）流程？還是C語言行為模型的高級綜合？減少了代碼生成的知識產(chǎn)權(quán)（IP）重用方法又怎樣呢？

　　對于設(shè)計(jì)團(tuán)隊(duì)?wèi)?yīng)該怎樣從需求分析到制造實(shí)現(xiàn)，每個專家都有自己的觀點(diǎn)。每一觀點(diǎn)都基于自己的偏好，過去的經(jīng)驗(yàn)，或者——EDA供應(yīng)商本身會考慮產(chǎn)品供貨情況。但是在很多真實(shí)環(huán)境中，所有這些觀點(diǎn)可能都是不相干的。

　　原因很簡單：大部分系統(tǒng)設(shè)計(jì)——據(jù)網(wǎng)站embedded.com最近的一項(xiàng)研究，55%的設(shè)計(jì)并不是新設(shè)計(jì)。它們實(shí)際上是對某類現(xiàn)有設(shè)計(jì)的修改。這一事實(shí)意味著，實(shí)際設(shè)計(jì)過程不僅僅取決于某些方法專家的建議，而且還要考慮需求的變化特性，以及設(shè)計(jì)團(tuán)隊(duì)能夠得到的數(shù)據(jù)。結(jié)果可能是從形式驅(qū)動的修訂過程，直至徹底的修改，甚至還有不可預(yù)測的改動等。通常是，結(jié)果實(shí)際對整個系統(tǒng)重新設(shè)計(jì)：不是因?yàn)楦膭拥姆秶?，而是因?yàn)闆]有重用規(guī)劃，也沒有能夠管理改動的方法。

　　在本文中，我們將與方法專家和實(shí)際設(shè)計(jì)人員進(jìn)行討論，當(dāng)系統(tǒng)需求變化時，到底會怎樣，有沒有一種一致的方法。然后，我們將在幾種真實(shí)設(shè)計(jì)環(huán)境中應(yīng)用這種工作方法，通過它來建議應(yīng)采用怎樣的設(shè)計(jì)過程，怎樣使其更好的工作。

　　一些分類

　　至少在三種不同的環(huán)境下會出現(xiàn)衍生設(shè)計(jì)（圖1 ）。最明顯的是，現(xiàn)有設(shè)計(jì)的一系列需求變化定義了新項(xiàng)目后：例如，新功能、新外設(shè)，或者新的性能指標(biāo)等。

　　圖1.衍生設(shè)計(jì)分類

　　而至少還有其他兩類。一類是使用平臺設(shè)計(jì)，例如谷歌的Android平臺。Cadence的系統(tǒng)開發(fā)包產(chǎn)品市場集團(tuán)總監(jiān)Frank Schirrmeister特別指出了德州儀器的開放多媒體應(yīng)用平臺（OMAP），這是一個很好的例子。他觀察到，OMAP平臺定義的擴(kuò)展平臺幾乎含有應(yīng)用領(lǐng)域中能夠想到的所有系統(tǒng)。設(shè)計(jì)團(tuán)隊(duì)通過把未使用的模塊拿到平臺之外來產(chǎn)生某種例化，在某些情況下，重新優(yōu)化得到的設(shè)計(jì)。

　　第三類是相關(guān)的：使用參考設(shè)計(jì)。這一過程實(shí)際上是衍生設(shè)計(jì)的一個例子，但卻是重要的方法，它不同于自己修改現(xiàn)有設(shè)計(jì)，也不同于應(yīng)用一個平臺。

　　對于這三種情形，只有第一種可以被分類為衍生設(shè)計(jì)。基于平臺的設(shè)計(jì)和基于參考的設(shè)計(jì)一般被認(rèn)為是新設(shè)計(jì)。但所有這三種都有共同的特性。它們從一個已經(jīng)完成的設(shè)計(jì)開始，然后，針對現(xiàn)有規(guī)范來對比新設(shè)計(jì)需求。它們找到與現(xiàn)有設(shè)計(jì)的不同，然后進(jìn)行實(shí)施。

　　第一步：有哪些變化？

　　這些設(shè)計(jì)過程都從一些新需求開始。每一過程的第一步是找到新需求和現(xiàn)有設(shè)計(jì)之間的不同點(diǎn)。理論上，這是一個嚴(yán)格的過程。我們可以通過對比最初的需求文檔和修改后的需求文檔來找到這些不同。但是在很多情況下，設(shè)計(jì)團(tuán)隊(duì)無法使用現(xiàn)有設(shè)計(jì)最初的、當(dāng)前的、正確的需求文檔。我們將在本文的后面討論這些情形。

　　我們理論過程的下一步是將每一需求變化分成行為、結(jié)構(gòu)和參數(shù)三類。行為變化——系統(tǒng)功能的變化，這是最常見的，據(jù)embedded.com研究，它占據(jù)了衍生設(shè)計(jì)的一半以上。有趣的是，目前自動化設(shè)計(jì)工具為它們提供的支持很少，只是提供一些表格。

　　作為對比，結(jié)構(gòu)變化指出了系統(tǒng)硬件或者軟件的某些改變：例如，操作系統(tǒng)的變化，增加或者去除了硬件模塊，或者改變了模塊之間的互聯(lián)等。在某些應(yīng)用中，例如通信基礎(chǔ)設(shè)施，系統(tǒng)I/O會經(jīng)常變化。Altera設(shè)計(jì)工作專家Kevin Weldon評論說：“我們一直和客戶一起工作，實(shí)現(xiàn)他們的目標(biāo)工作頻率。但是現(xiàn)在，我們看到更多的變化出現(xiàn)在I/O中?？蛻粝Ｍ_定不會出現(xiàn)I/O阻塞?！?/p>

　　參數(shù)變化以可測量的指標(biāo)標(biāo)明變化量：例如，響應(yīng)時間、帶寬、供電電流，以及材料成本等。通過某些硬件和軟件模塊的需求文檔直至其含義，很容易找到這些變化，但是很難跟蹤。

　　找到相關(guān)性

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

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

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

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

　　每次調(diào)整后，我們會在適當(dāng)?shù)某橄蠹壷匦逻M(jìn)行仿真，以驗(yàn)證修改后的設(shè)計(jì)現(xiàn)在能否滿足新需求。然后，把這種修改傳遞到后面的底層抽象層，重新優(yōu)化，直到我們的新設(shè)計(jì)通過了驗(yàn)證。

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

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