在真實環(huán)境中

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

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

　　在一個平臺上

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

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

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

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

　　Schirrmeister觀察到，“您要明確新需求到底意味著什么。我曾處理過一個項目，其視頻處理器需要采用信箱格式。這聽起來只是簡單的增加輸出格式。我們一開始沒有認識到的是系統(tǒng)的工作方式，信箱格式使我們只有很少的時間對每一幀進行解碼，因此，這對設計其他部分的性能要求很高。實際情況是理解需求變化的含義?！?/p>

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

　　修改上一次設計

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

　　挑戰(zhàn)是從找到有哪些變化開始。Altera設計專家Stacy Martin認為：“這一過程一般沒有什么順序而言。團隊查看規(guī)范，找到特性或者接口的不足，然后，解決這些問題?！?/p>

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

　　這是很大的挑戰(zhàn)。Martin說：“設計團隊嘗試盡可能多的重新使用設計。但是，您盡力嘗試重用后，發(fā)現(xiàn)有時候最好還是從頭開始設計?！?/p>

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

　　產(chǎn)品線工程

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

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

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

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

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

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

　　作者：Altera公司總編輯Ron Wilson