變化中的SoC設計流程

　　供應商正越來越多地注意到設計團隊的一個需求，那就是早在設計的分區和平面規劃階段，就要擁有初始的布線信息。Mentor Graphics公司布局布線部經理Pravin Madhani認為：“在設計的早期階段，最大的意外就是堵塞。因此人們會非常早地使用自己的布局布線工具，檢查潛在的堵塞問題。”這種趨勢轉而促使布局布線工具供應商擴展了自己的工具，使之可以用于設計的初期階段。

　　意外的堵塞問題會產生高昂的后果。Open-Silicon的Madraswala稱：“我們一系列塊都遭遇了堵塞問題。我們必須返回去，重寫RTL來解決這些問題。”這就要對那些塊再走一遍驗證、設置和綜合過程。而Open-Silicon則是從頭建立一個通向HiSilicon的RTL設計的快速反饋路徑，方法是在中國的HiSilicon公司派駐了一個六人設計團隊。

　　第三方IP的堵塞意外可能更糟。例如，IP供應商缺乏資源，不能按你的時間表修改RTL，或者堵塞是出現在一個硬IP塊的管腳處。在最差情況下，SoC團隊可能不得不更換IP供應商。于是，使設計分區和布局與功率策略保持一致，并且擁有一個頂級布線的早期視圖，就成為了任務關鍵的問題。

　　綜合與驗證

　　Open-Silicon、Vitesse和Redpine的設計團隊并不認為綜合是一個大問題。他們更關注如何避免重復地做綜合。Madraswala說：“我們把每個RTL塊看成像是一個獨立的片芯。然后我們在一個足夠高的結果品質上，關注每個塊在流程中的每個步驟。這樣的結果可能是，在時鐘插入后，我們只要做一次綜合。”Open-Silicon使用自己的綜合工具，自動地插入時鐘門控。另外，Madraswala稱，在架構級的配置用于處理芯片的電源管理。“存在著電源島，但是，由于電源管理已通過RTL成為顯式的，因此我們不需要像CPF一類的東西。”同樣，Vitesse的設計使用了大量的時鐘門控，但只有一個電源門控的塊，而Chadra報告稱普通綜合流程中沒有問題。

　　但是，Redpine采用了一種更積極的電源管理策略，使工具更加復雜。這種方案已影響到了設計流程(圖2)。Mattela稱，原則上，如果你正確地組織了RTL，并精確地捕捉了自己的電源意圖，就應該能將RTL、UPF和電源感知庫送入綜合步驟，并且獲得一個包含全部已就位絕緣體、電平轉換器以及控制的網表。但他傷心地說，現實中，“你按了按鍵，可什么事也沒發生。”結構上一切完美無誤，但如果用電壓感知工具做一次詳細的手工驗證，就會發現完全不同的情況。

　　圖2. Redpine公司的方法包括對電源意圖的早期捕獲，以及對實現的后期檢查。

　　驗證似乎采用了不同于綜合的新次序。隨著復雜性的增加，功能驗證開始得更早，在一個更抽象的層級。Vitesse的Chadra稱：“我們采用一種基于覆蓋的OVM(開放驗證方法)方案”。在24端口交換核心與MIPS CPU核心的性能模型中，設計早期啟動了該過程，以了解芯片在有流量情況下的動態性能。然后繼續對更多細節作驗證，直到時鐘門控電路和絕緣體就位，測試平臺驅動門級模型。Chadra說：“根據我們的需求文檔，我們的驗證計劃中有特定的目標。我們會隨著代碼覆蓋的程度而增加這些目標，指導驗證工作。”

　　Redpine的Mattela稱，該公司的DVFS設計需要特別小心。部分問題源于邏輯仿真器，因為它并不能說明，信號電平的一個失配是否會對電壓島之間的一根路徑造成毀滅性破壞。于是，Redpine的驗證工程師求助于手工技術，如強制某節點為三態，看下游會發生什么。Mattela警告說，一部分問題是你永遠不知道正在使用的模型的來源。他表示：“不要信任處于多電壓狀況下的那些模型。你不知道它們的編寫者是電子工程師還是軟件人員，后者認為一就是一，零就是零。”