如何在開發IP的同時去鞏固集成和復用覆蓋率？IP的某些功能和性能是可以配置的，需要考慮的是IP被各種合理配置后的工作是否都能夠正常，將功能覆蓋率先整理為層次化的抽象功能覆蓋率模型，稱之為cover model。

這是一篇關于IP開發時如何考慮復用覆蓋率的論文。就硬件設計IP而言，我們無非是在實現IP，或者集成IP。就目前情形來看，IP的實現越來越多被集中在大型公司。一方面是由于他們有更多的經驗來保證可配置化的IP可以滿足各種用戶需求，另外一方面是由于他們的客戶基礎深厚，同時高質量的IP研發成本和大量的silicon-proven可以形成良好的業務發展。目前多數公司在重要IP上面都會采用商業IP，這來自于多方面的考慮。作為Verifier可能會有更多的機會去一家SoC公司，從事于定制模塊、核心知識模塊或者IP模塊的驗證。SoC中至少有三分之一以上的工作都屬于IP模塊的集成驗證，SoC verifier看待IP更多的角度是從集成驗證出發的。

這次摘錄的這篇論文的視角則是從IP開發的角度出發的。正好借這個機會，小編可以有空梳理一下IP在設計和驗證兩方面開發的流程。由于文章中以PCIe為例，我接下來關于IP開發流程和集成驗證流程的敘述也以PCIe為例吧。

對于一個成熟的PCIe IP而言，一家商業IP公司可能出售它的硬件設計IP，也可能出售它的驗證IP，或者兩者都出售。例如Synopsys就同時出售它的設計IP和驗證IP，也就是說這家大型的IP百貨公司在出售給你設計方案的同時，還會建議你購買他家的驗證方案。無論是設計還是驗證，你都首先需要一個PCIe功能模式的配置。這個配置是結合SoC的架構來制定的，從前期架構研究中會選擇合適的功能、性能以及功耗等參數。Designer和verifier將都使用這個配置文件來生成定制化的設計IP或者驗證IP。那么可以將配對的設計IP和驗證IP進行測試環境搭建，繼而進行IP級或者SoC級的驗證工作。但是在驗證的過程中，我們如何完成在IP級和SoC級的驗證量化呢？這肯定離不開覆蓋率，尤其是功能覆蓋率。但是往往功能覆蓋率不會伴隨著設計IP或者驗證IP一并生成，這是為什么？其實還是跟高度可配置化的IP本身有關。在這篇論文中就PCIe設計IP為例，講述了針對可配置化IP定義功能覆蓋率的困難之處。

由于IP的某些功能和性能是可以配置的，比如有一些功能可能在配置之后就會被禁止（靜態的），也有一些功能可能通過仿真時的寄存器配置被禁止（動態的），那么這些不同的配置就對定義一種通用的功能覆蓋率模型提出了挑戰。從文章來看，PCIe IP的開發者在驗證時已經很苦惱，因為他們面臨的挑戰要遠大于SoC verifier，前者需要考慮所有的配置可能，而后者只需要選擇有限的配置進行集成驗證。或者這樣說，前者需要考慮的是IP被各種合理配置后的工作是否都能夠正常，而后者需要考慮的是IP在被SoC集成后是否能夠良好地融入系統。

IP集成的一個問題是，IP提供者不知道IP在被各種客戶集成時，集成方式是否正確；而IP使用者也幾乎對于生成的IP其自身的可靠性、在IP系統級和SoC級的測試覆蓋情況抱有模糊的認識。擋在雙方中間的障礙來自于他們缺少一個清晰的數據來表明對方的測試完成狀況。從這篇文章來看，如果IP提供商可以在生成定制IP的同時也能夠生成定制的功能覆蓋率，那么這樣的一份覆蓋率無論對于IP開發者在驗證IP自身，或者是IP集成者在驗證IP的集成時，都將產生指導性的幫助。

那么是否存在這樣一份伴隨著IP配置文件而可以定制生成的功能覆蓋率呢？這篇文章給出了一種解決方案。從這篇文章最后的結論部分來看，可配置化的功能覆蓋率將伴對應著每一種配置化的IP，而在測試這么多的IP配置時，開發者可以利用這些功能覆蓋率來衡量IP的驗證完備情況。如果這樣一份功能覆蓋率也能夠伴隨著IP一同交給SoC集成方，在IP集成時就可以綜合IP級和SoC級的驗證情況來收集反饋在這份功能覆蓋率模型上。這樣如果IP提供方和集成方都基于同一個功能覆蓋率模型進行交流，那么也將更容易一起回顧IP的功能測試和集成情況。

接下來小編概括這篇論文是如何實現高度可配置化IP的功能覆蓋率定制情況的。

將功能覆蓋率先整理為層次化的抽象功能覆蓋率模型，稱之為cover model。

抽象覆蓋率模型由多個block model構成，這些block model所代表的某一項重要的功能最終合并起來，就可以構成整體的功能情況，即cover model。

對于block model各自的樹狀結構，其每一個樹狀末端構成了一個覆蓋變量，cover variable。但是這些覆蓋變量并不指向具體的信號，而仍然從抽象上來描述它所要測試的功能、關系的值域。

利用cover variable，可以將它們放置，或者交叉生成新的覆蓋率，稱之為cover group。

這些樹狀的覆蓋率模型包含的底層cover variable和cover group被收入到Excel表格中。伴隨它們的，還有配置化變量。配置化變量之所以重要是因為不同的設定可能決定了某些cover variable的值域范圍，或者是否存在某些cover variable。

層次化放置的Excel表格被Perl腳本讀取，并且產生了層次化的SystemVerilog covergroup。這些covergroup也伴隨著block model，與各個功能一一對應，構成了層次關系，最終作為一個定制化產生的cover model。

這篇論文同我現在做的一些在SoC級定義功能覆蓋率的方式不謀而合。首先功能覆蓋率在沉淀之前，需要有抽象的功能定義，那么不同的功能將可以作為獨立的block model。復雜的功能可以進一步拆解為child block model，最終拆解到不能拆分為之，那么不能拆分的點就是cover variable。也許有的公司習慣于將功能測試點以平鋪的方式（plain text）展開，這對應的也將是平鋪的SV cover group定義；如果你定義的功能點是抽絲剝繭，從Excel表格開始就得到了腳本處理的保障，那么你可以一開始將設計拆分為幾大功能，接下來利用層次化方法定義子一級的block model。

樹狀的覆蓋率模型與平鋪的覆蓋率模型相比有什么優勢呢？它容易做測試回顧（review）和覆蓋率分析，而對于這篇論文中的IP驗證，樹狀結構也有利于一些變量的層次化傳遞和腳本的針對性處理。從復用角度來看，如果實現了Excel到SV cover group的腳本化流程，那么樹狀結構的功能點拆分也有利于日后的維護，例如從樹狀結構中刪除某一個節點及其以下的所有子節點（即刪除某一項功能），又例如將IP級的覆蓋率樹狀結構嫁接到SoC系統的覆蓋率樹狀結構中，使其成為其中的某一個節點，都是可行的方法。

結語

Excel到SV cover group的自動化是一個合適的方向，但在實現過程中，還需要理清，如何將抽象的功能點測試具象到各個cover group。比如功能點測試之間可能具有包含的關系，比如某些功能點測試可能仍然過于抽象需要進一步細分，這篇論文利用腳本結合Excel中的IP配置變量來生成了層次化的功能覆蓋率模型，是一個不錯的嘗試。這個覆蓋率如果可以從IP級貫穿到SoC級，那么將能夠更好地衡量IP集成測試的情況。