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

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

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

原因很簡(jiǎn)單：大部分系統設計——據網(wǎng)站embedded.com最近的一項研究，55%的設計并不是新設計。它們實(shí)際上是對某類(lèi)現有設計的修改。這一事實(shí)意味著(zhù)，實(shí)際設計過(guò)程不僅僅取決于某些方法專(zhuān)家的建議，而且還要考慮需求的變化特性，以及設計團隊能夠得到的數據。結果可能是從形式驅動(dòng)的修訂過(guò)程，直至徹底的修改，甚至還有不可預測的改動(dòng)等。通常是，結果實(shí)際對整個(gè)系統重新設計：不是因為改動(dòng)的范圍，而是因為沒(méi)有重用規劃，也沒(méi)有能夠管理改動(dòng)的方法。

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

一些分類(lèi)

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

圖1.衍生設計分類(lèi)

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

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

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

第一步：有哪些變化?

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

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

作為對比，結構變化指出了系統硬件或者軟件的某些改變：例如，操作系統的變化，增加或者去除了硬件模塊，或者改變了模塊之間的互聯(lián)等。在某些應用中，例如通信基礎設施，系統I/O會(huì )經(jīng)常變化。Altera設計工作專(zhuān)家Kevin Weldon評論說(shuō)：“我們一直和客戶(hù)一起工作，實(shí)現他們的目標工作頻率。但是現在，我們看到更多的變化出現在I/O中?？蛻?hù)希望確定不會(huì )出現I/O阻塞。”

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

找到相關(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)足參數約束。

圖3.去掉部分平臺，使平臺設計滿(mǎn)足特殊需求。

但是這一概念也面臨一些難題。首先，不一定有需求文檔。因此，團隊不得不猜測平臺建立者的目的是什么，是否符合新需求。確定了不同點(diǎn)后，這就比較簡(jiǎn)單了。例如，Android能夠適用于攝像機和麥克風(fēng)。如果您并不需要這些，就可以把這些功能去掉。

功能需求會(huì )更具挑戰性。您可能需要一臺攝像機來(lái)采集MPEG4視頻。但是，您還需要四個(gè)ARM內核和一個(gè)DDR3 SDRAM接口嗎?用戶(hù)只是進(jìn)行網(wǎng)頁(yè)瀏覽，您還需要采集和壓縮視頻嗎?使用模型和功能需求的缺乏會(huì )迫使您進(jìn)行大量的系統級仿真，以發(fā)現哪些模塊實(shí)際參與了您需要支持的工作。

Schirrmeister觀(guān)察到，“您要明確新需求到底意味著(zhù)什么。我曾處理過(guò)一個(gè)項目，其視頻處理器需要采用信箱格式。這聽(tīng)起來(lái)只是簡(jiǎn)單的增加輸出格式。我們一開(kāi)始沒(méi)有認識到的是系統的工作方式，信箱格式使我們只有很少的時(shí)間對每一幀進(jìn)行解碼，因此，這對設計其他部分的性能要求很高。實(shí)際情況是理解需求變化的含義。”

參數需求的挑戰性更大。您不得不在RTL上采用芯片模型運行系統仿真，確定平臺能否滿(mǎn)足所需的規范要求。而且，幾個(gè)層面的仿真模型、精確的使用模型以及大量的測試臺都是實(shí)際設計平臺的關(guān)鍵組成。

修改上一次設計

從平臺開(kāi)始進(jìn)行工作，設計團隊只需要把模塊從平臺中取出并進(jìn)行優(yōu)化，就可以確定能夠滿(mǎn)足需求。但如果是從以前的設計開(kāi)始工作，或者難度更大的是，采用第三方參考設計開(kāi)始工作，情況又會(huì )怎樣呢?原理不變。但是在真實(shí)環(huán)境中，設計團隊在現有設計上一般不會(huì )有跟蹤需求，也可能沒(méi)有良好的系統或者模塊級仿真模型，或者完全適用的測試臺。方法取決于技巧。

挑戰是從找到有哪些變化開(kāi)始。Altera設計專(zhuān)家Stacy Martin認為：“這一過(guò)程一般沒(méi)有什么順序而言。團隊查看規范，找到特性或者接口的不足，然后，解決這些問(wèn)題。”

現在要復雜一些。如果這些變化就含在現有實(shí)現的功能范圍內，那就可以進(jìn)行優(yōu)化。也可能會(huì )超出現有設計的范圍?；蛘?，沒(méi)有可信的需求文檔時(shí)，設計人員應從系統級模型中正確的估算出性能，再次進(jìn)行仿真以找到現有設計能夠實(shí)現什么。實(shí)際上，團隊應分析現有設計實(shí)現，以便重新生成該設計的需求。沒(méi)有正確的使用模型和良好的測試臺，在開(kāi)始任何重新設計之前，團隊會(huì )有很大的投入花在理解需求上。

這是很大的挑戰。Martin說(shuō)：“設計團隊嘗試盡可能多的重新使用設計。但是，您盡力嘗試重用后，發(fā)現有時(shí)候最好還是從頭開(kāi)始設計。”

在真實(shí)環(huán)境中，實(shí)際上衍生設計有不同的方法。我們這里介紹的只是一小部分，這與設計人員找到需求變化的技巧有關(guān)。最初的設計人員在可重用性上的投入越大——在需求、行為、結構和實(shí)施層面上維持正確的設計版本；鎖定使用模型；建立自適應測試臺；這樣，真實(shí)環(huán)境衍生設計就越能夠接近其理想形式。

產(chǎn)品線(xiàn)工程

但真實(shí)環(huán)境總是在變化。目前，在軍事、航空航天以及交通系統等某些應用中，需求可追溯性已經(jīng)成為合同條款。非常復雜的系統設計以及高成本的一次性SoC設計投入也會(huì )有這種要求。在目前的很多行業(yè)中，成本和復雜度壓力改變了系統設計的結構和方法。

新機遇意味著(zhù)新的芯片設計。但是，設計團隊越來(lái)越多的傾向于不再進(jìn)行新設計。團隊維持并繼續重新應用系列知識產(chǎn)權內核以及完整的測試臺，偶爾嘗試新的金屬掩模，很少使用全新的模板。對于每一設計是中心硬件/軟件IP衍生的應用，實(shí)際上都是產(chǎn)品線(xiàn)工程。

是否成功取決于設計重用的自動(dòng)化。IP裝配程度也取決于能夠嚴格追溯需求的方法，跟蹤到測試臺模塊、硅片IP模塊，以及軟件模塊，很容易從以前的系統級行為模型轉到詳細的硅片仿真和軟件調試。這也是IBM的智能物理基礎設施副總裁Meg Selfe的觀(guān)點(diǎn)。

Selfe說(shuō)，產(chǎn)品線(xiàn)工程的基礎設施跨過(guò)了三個(gè)領(lǐng)域——工具、過(guò)程和最佳實(shí)踐。其中，令人吃驚的是，一般并不缺少工具。Selfe報告說(shuō)：“我們通常和具有很多工具的組織一起工作。難點(diǎn)是，并不是通過(guò)一致的平臺來(lái)連接工具，因此，流程中有人工步驟。人工步驟導致出現中斷。”

Selfe強調說(shuō)，從傳統的SoC設計轉向產(chǎn)品線(xiàn)工程時(shí)——不僅要考慮下一設計需求，還要考慮企業(yè)是怎樣運轉的。Selfe建議，“確定在您的設計過(guò)程中要實(shí)現什么，找到原因，進(jìn)行糾正。”

她注意到，目前，可追溯設計流程最大的不足出現在需求和測試臺之間。今后，在早期系統建模文化中，系統模型與其測試臺之間的差異會(huì )越來(lái)越小。目標應用環(huán)境中完整的系統模型成為某一子系統詳細模型的測試臺。需求變化會(huì )與設計和測試臺中所有受影響的模塊相關(guān)聯(lián)。測試覆蓋標準會(huì )直接轉換成對設計需求覆蓋范圍的精確估算。設計會(huì )在自動(dòng)關(guān)注是否滿(mǎn)足需求變化上加大投入，而不是重新建立設計中沒(méi)有變化的部分，也不會(huì )復制IP中已有的功能。