本文轉自：http://www.eetop.cn/blog/html/28/1561828-6339373.html

面向方面的設計方法（aspect-oriented）能否幫助我們更快更好地完成電路設計呢？一切都還是未知，雖然這些技術在驗證領域的初步嘗試並不成功。

1992年，Yoav Hollander就試圖將面向方面程式設計（AOP: Aspect-oriented programming）這一軟體程式設計的思想應用到硬體驗證當中去。後來這些思想被融入到了e語言（e-language）當中，並藉助Verisity進一步形成了商業化的產品。

Hollander很早就發現，使用面向物件技術（Object-oriented）能夠將測試平臺的抽象程度提高到暫存器傳輸級之上，但是如果增加一些面向方面的功能將能夠使得測試平臺更加靈活，甚至可以將RTL的更新作為測試平臺的一點補丁而不用重寫整個測試平臺。

在那時,e語言的應用是測試平臺構建方式的一個重大改進，雖然得到了Cadence公司的大力支援，但自從SystemVerilog和UVM測試方法學的出現以來，其使用率一直在下降。驗證的發展能給我們提供一點經驗來幫助改進設計流程嗎？

如今，許多設計都是圍繞著一個平臺。這個平臺可能已經驗證完備了而且在矽片上也已經驗證功能完全。但是如果我們要新增一個新的外圍模組呢？那麼要改變多少的系統程式碼呢？有多少部分需要重新驗證呢？又或者是另外一種情況，設計程式碼保持不變但是需要增加低功耗的特性，這時候是不是就不必去改變任何已經被驗證完備的RTL程式碼了呢？

Mentor Graphics公司的驗證技術專家Tom Fitzpatrick解釋說，AOP（面向方面程式設計）就是要在已有的程式碼中新增一些新的功能點而不用去改變內部的程式碼。雖然這正是行業所希望實現的，但是這是否現實呢？

Sonics首席技術官Drew Wingard從更高的層次來解釋硬體的抽象模型。在片上網路(OCN: On-chip network)空間內，網路看起就像一個地址對映，它表明硬體的抽象模型正在與哪個硬體資源進行通訊，以及正在訪問該資源內部的哪個地址。我們最關心的部分還是這些系統的效能特性。大部分的成本降低或者效能提升都是通過共享一些緊張資源如片外儲存器來實現的。共享程度的大小必須確保系統中的各個元件能夠達到相應的效能水平。”

Wingard注意到，與實際的硬體設計人員相比，制定硬體效能模型架構的工程師和習慣抽象底層硬體模型的驗證人員之間存在更多的默契。這或許也可以表明面向方面程式設計(AOP)更適合在更高的抽象層次上使用，而不適合將其用於RTL設計相關的流程當中。

Wingard繼續說：“當我們進行效能分析時，我們首先要制定一個使用模型，並可以從中映射出一種使用場景。例如對一個給定的SOC來說，硬體設計團隊往往關注的是該SOC一些極其重要和典型的使用案例。這樣我們只需要適當地調整記憶體的大小以及合理的配置記憶體和網路來滿足核心的吞吐量要求即可。”

功耗是否也類似呢？我們是否能夠使用面向方面程式設計（AOP）來指定設計的功耗特性呢？如果這樣的話我們是不是就可以在不修改設計功能性程式碼的前提下實現該設計的功耗特性呢？Wingard看到了一些相似性以及進一步協同設計的可能性。我們設計了一系列的使用案例，從中我們可以映射出一系列工作場景。我們在這些工作場景中測試功耗並希望在這些執行場景中可以表現出良好的低功耗特性。我們可能會問功耗和效能之間有什麼可以協同設計的地方嗎？答案是它們之間大約會有80%的交叉部分。為了優化電路網路拓撲結構而進行的抽象場景描述，和為了提高系統性能而設計的記憶體特性以及為了降低功耗而優化的電源域設計等均存在著可以協同設計的可能。”

那麼為什麼工業界還沒有快速切換到面向方面程式設計（AOP）呢？

功耗可能存在問題

Janick Bergeron是Synopsys公司的一名研究員，同時也是e語言的熟練使用者。他認為面向方面程式設計（AOP）的問題在於，雖然其在解決某些型別的問題上非常強大，但它同時也有很大的風險。“作為一名IP設計者，我希望知道我的設計最終在執行什麼，如果任何人都可以使用我的程式碼，替換它，擴充套件它，以我無法控制的方式修改它，這將使得我的技術支援成為一場噩夢。我需要知道確切的程式碼，以及確切的執行方式以此來重現發現的問題。”

Mentor公司的Fitzpatrick也同意，他說，關於AOP的主要抱怨就是，你必須非常小心，否則很容易陷入困境。但是業界也有一種eRM的解決方法來幫助我們避免這種問題。並且從那以後，類似的功能被帶入了UVM。UVM側重於面向物件這一部分，我們可以通過擴充套件一個基類來建立一個新類，並使用工廠機制來交換(swap)它們。這樣追蹤你最終的結果就要容易得多。雖然這樣可能需要多編寫一點的程式碼，但是它卻可以在不犧牲很大的靈活性的情況下給予我們很方便的控制能力。

Bergeron也發現了AOP的擴充套件性問題。“當這個專案是一個小型的IP核時，AOP還可以發揮很大的作用，但是隨著設計的規模越來越大，它就成了管理的噩夢。”

敏捷開發和麵向方面程式設計

敏捷開發也是在當今獲得相當多關注的另一種技術。敏捷開發已經開始逐步取代已建立的採取漸進式的瀑布型開發方法。看起來面向方面程式設計似乎是對敏捷開發的補充。

Bergeron說：“面向方面程式設計允許我們從外部完成敏捷開發所要求的漏洞修復和迭代。所以如果我現在更改我的基礎程式碼並擴充套件它，我現在或者以後是否會承擔相應的技術債務（technical debt）呢？”Bergeron將技術債務定義為通過走捷徑而積累的一種類似於慣性或者熵的術語。“反正你最終必須付出相應的代價”Bergeron補充到。

所以Bergeron看到了AOP支援協同開發的特性，但並不看好它的適用性。他認為AOP會積累很多上面提及的技術債務，但是敏捷開發恰恰相反，它是儘可能地去減少這種技術債務。AOP非常適合去做測試，因為這是產品開發的最後一項工作了。對於任何基礎架構性的或者需要可重用的部分，他建議不要去使用AOP因為你不能很好地去控制它以及保護它。

其他方法

問題在於，如何在不增加技術性債務的前提下充分利用AOP的優勢呢? Bergeron解釋說：“AOP試圖將所有交叉相關的程式碼組合在一起。您也可以使用純粹的面向物件程式設計來完成上述事情，將所有類的擴充套件和回撥放在一個檔案裡面即可。這是一個程式碼組織和方法論的問題。”

Fitzpatrick表示，他們已經在SystemVerilog和UVM的工廠機制中做了類似的事情。

AOP在設計中的應用

Bergeron提出了一個AOP應用到設計當中的假設。“AOP可能與設計相關，因為設計都沒有可能面向物件。設計是一個固定的結構性的東西。如果你有一個設計的模組，並且想新增一些新的功能，你是不可能基於這個模組來擴展出一個新的模組。模組上沒有虛擬的東西可以被用來做擴充套件。我們必須修改整個設計檔案。如果這樣做的話我們就相當於建立了一個新的模組，並且我們必須還要修改之前的驗證環境來驗證之前保留的功能以及新增的新的功能是否正確。但是如果我們在設計模組上定義一些面向方面的東西呢？通過這個來新增一些新的功能以及一些新的埠，這樣的話原始的模組仍然存在，保留的功能不需要再驗證而只需要為新新增的功能搭建一個測試平臺。”

Fitzpatrick表示他並不急於將AOP應用於設計當中。“在設計團隊當中，硬體設計人員甚至都不願意用面向物件的思想去思考問題，更不用說AOP了。如果盲目去使用AOP來設計電路可能最後就會是一些義大利麵條式的程式碼。並且我還不確定是否要告訴設計團隊我們有能力使用AOP來進行RTL設計。”

看起來採用統一功耗描述形式(UPF: Unified Power Format)就可以定義出硬體電路的功耗特性。Bergeron說：“我們確實需要定義AOP這一單一的程式語言要包含的所有東西。一般來說執行語義（execution semantics）是由各個相關的方面來定義的（defined by adding the aspects ）但是功耗不會影響執行語義，它只是從一個不同的角度來表徵硬體的執行情況。功耗會影響最後的電路實現，所以從這個角度來看，功耗和RTL功能是兩個不同的方面但它們並不是面向方面的程式設計（AOP），因為你需要使用不同的程式語言。”

Calypto產品營銷總監Anand Iyer說，UPF描述的是硬體電路的一個方面，但是我們還沒有一種工具能夠將UPF按AOP的形式來使用。許多專案開發後期所使用的工具都面臨著很大的挑戰，這些工具很難將硬體電路的各個方面都綜合在一起。並且想要弄清楚各個方面的相互影響，我們仍然需要進行效能分析，而這都只能在專案開發的後期出現。

Fitzpatrick仍然擔心一些AOP模型不能完全適用的情形。他說：“從編寫程式碼的角度來看，我更喜歡所有的東西都只存放在兩個地方，無論是在模組定義中還是在該模組的UPF規範當中。這樣你完全能夠清楚哪項功能是在哪裡實現的，而不必擔心我的編譯器可能會連結到其他的一些程式碼從而修改一些我很滿意的東西。”

Fitzpatrick也看到了一些優勢，我們確實想將傳統驗證所關心的邏輯上的功能與一些會增加驗證複雜性的附加功能分開。就像將硬體的功耗作為一個獨立的功能方面來進行驗證也是非常有意義的。我們可以確保在進行功耗設計和驗證之前，RTL的功能是正確的。這樣就把RTL的功能問題與電路的功耗問題分開了，使得我們既可以分開考慮又可以把他們放在一起綜合分析，這是非常強大的。

並不是每個人都將UPF視為自上而下設計過程中的一部分。Wingard認為UPF是一個抽象概念，對那些有功耗要求的硬體的設計非常有幫助。我們將設計網表按照實際物理電路的要求劃分，然後自動建立與之相匹配的UPF檔案。Wingard將UPF看作一種說明文件。我們都希望每個IP都有一個相應的UPF文件，用來描述該IP的功耗特性。這樣在頂層整合的時候我們就能知道我們的晶片要負載多少個電源域？我們是否要在每個電源域周圍增加電源隔離單元？我們應當如何減少電源域和電平的總數使其能達到一個可控的水平？當我們為各個電源域開發功耗控制單元的時候，需要確保它們與UPF的描述一致。

未來的展望

多年以前Gary Smith和我有一場持續數年關於電子系統層級抽象ESL（Electronic System Level）的應用的討論。雖然Smith專注於設計工具的開發，比如高層次的綜合工具。但我始終認為只有在解決了抽象設計的建模和驗證之後這種工具才有可能完全成功。現在還有很多問題沒有解決比如要驗證哪些方面，如何驗證這些方面。這些問題沒有解決，ESL的價值將會一直被質疑，並且設計的流程也將無法確定下來。

Wingard表示：“ESL所面臨的挑戰是如何將投資回報率(ROI)提高到晶片架構師願意投資一些新工具的水平。現在大多數SOC架構師還在使用電子表格來幫助設計。如果我們能捕獲一些實際工作場景的詳細資訊，並且這些資訊可以被用來驅動系統模型以此來評估系統性能或者來驅動電源架構，這樣的工具更有可能被他們採用。”

Accellera行動式激勵工作小組的努力可能會提出更好的方式來描述工作場景，從而推動未來的驗證和設計方法。

路桑說

一切的一切終將歸於虛無。EDA和這些首席們考慮問題的時候都是登高望遠，用“抽象”、“哲學”的系統性思維來考慮next step。路桑並不是這裡專門跪舔這種吃一年種三年的長遠眼光，而是覺得無論你的身份是設計、驗證、後端還是EDA，隨著經驗的提升，都需要往形而上，高層次的地方去探照IC設計這座冰山。我們每個人的日常都只是那冰山表面的1%，至於剩下的部分，可能需要我們更多的時間，從更多的人和case那裡收集到專案中的痛點在哪兒，用什麼方式去黏合，甚至從方法學層面上來繼承原有的優點而再推出新的流程。

 

比如文中提到的eRM方法學，路桑也是曾經的擁躉。除了談到的AOP的程式設計思想，這種“打補丁不傷衣”的方式在當時寫測試用例的時候真是懶人的幫凶。還有e語言的天生柔軟性，軟到幾乎你想要讓它做的事情它從隨機約束、覆蓋率、斷言、驗證結構都已經覆蓋到，20年前啊神思路啊。再來看看SV後來居上之上，發生了什麼——將e語言原來的OOP和AOP的雙臂斷了一臂，為什麼？已經那麼牛X了，怎麼還會倒退？這跟文中加粗字型的專案吐槽不無關係，什麼意思呢？當第一個人構建eRM驗證結構的時候，她就是瑪麗蓮夢露啊，宛如芙蓉；當第二個人試圖維護eRM結構，新增新組建和新用例的時候就不自覺地使用AOP這個打補丁的特性，漸漸地，你會發現夢露的體型越來越大不說而且身材比例還不勻稱；等到第三個人再來此地的時候，他一看這程式碼身材，我靠，寫得雲裡霧裡，前人打得補丁自己又不能動，只能自己繼續加補丁，加到後來就成了賈玲了。

 

路桑在講什麼意思呢，AOP在驗證的部分誠如Bergeron大神所說，它在程式碼中的使用會使得善意的程式碼初衷經過一兩一兩的加碼之後，讓原有程式碼的完美身材變得面目全非，這就是Bergeron所給的比喻，技術債務。技術債務在我們驗證環境維護的過程中已經是屈指可數的幾件頭痛大事。如果你在對新模組開發驗證環境的時候沒指望後來的維護者對你感恩戴德瘋狂打call，那麼雜亂無章的結構再配合AOP的打補丁神技真得可以讓你的雙手在鍵盤上飛起來，然而每次當我遇到這種“天才式”的程式碼方式，我只能暗自嘆一聲倒黴，如果我還想讓她變回夢露的話，我必須給她瘦身，花那些看起來可有可無的力氣瘦身。我不知道我這種處女座的傾向是不是都一分不落地遺傳給我大女兒身上，至少她現在每天早上去幼兒園繫鞋帶追求完美的氣質就夠讓我無奈了。