FS者，Feature SPEC也。

Feature者，芯片的功能與特性也。

特性者，Functionality和Performances也。

就像小孩過滿月，親朋好友歡聚一堂，舉杯同慶，為新生兒送上期許和祝福。在芯片的設計初期，也需邀請市場、客戶和產品等多方專家共聚一室，共同討論，為待研發的芯片，送上期望和需求。匯聚成冊，形成Original Request文檔。這些需求，可大致分為功能和規格的需求、性能需求、電氣特性需求、功耗和面積的需求等等。

明確需求，形成OR文檔是芯片研發諸多環節中，比較重要的一步，但只是第一步。

接下來，眾人退去，芯片系統工程師（System Engineer，SE）粉墨登臺。根據需求文檔（OR），SE開發芯片的特性規格文檔，即Feature SPEC。

從應用的角度看，也從規格和特性角度看，FS是芯片唯一最全面和最權威的技術文檔。其他芯片的業務文檔，可以從FS中裁剪或細化而得到。例如，芯片的用戶手冊可以是FS的裁剪版（部分特性不對用戶開放，而裁剪），電路結構實現的技術文檔（Architecture SPEC, AS）是對FS的細化和實現，由IC設計者依據FS進行撰寫。

在IC驗證者看來，FS通常要包括芯片的業務場景，規格特性，以及業務相關的報文結構、業務處理流程、算法協議等。也包括芯片的微架構圖（micro Architecture），以及各個接口的協議、總線協議、子系統和模塊的劃分和連接、相關信號的列表和時序。也包含芯片的系統工作頻率，芯片主頻，時鐘復位以及低功耗特性等。

詳細說來，大致可分為以下五點。

其一、業務功能和應用場景。

或許，這是FS最重要的內容。

SE定義一顆芯片，首先是從芯片的功能開始。簡單而獨立的功能直接定義即可。復雜的功能通過抽象和歸納，可成為芯片的業務和特性。這些都是站在芯片本身來看。若是站在用戶的角度看，每個功能、業務和特性都會有對應的應用場景。芯片的功能分簡單和復雜，應用場景也分簡單場景和復雜場景。通過描述用戶（通常是指軟件）如何使用這些功能、業務和特性，可將業務功能和應用場景結合起來。這包括不限于：數據流和控制流如何流動，軟件和硬件如何交互和配合。

因此，從一個驗證者角度看：SE撰寫這部分FS內容時，“要把一碗水端平”，既要站在芯片電路實現的角度思考，也要站在芯片用戶使用的角度思考。既要考慮芯片電路的可實現性，也要考慮芯片業務的可驗證性。

其二、業務處理流程和相關的報文。

IPO模型通常用來描述業務的處理流程，即 Input-Process-Out。在FS中描述業務的處理流程時，也可遵從IPO的規則。輸入的報文，經過怎樣的處理和轉換，最終以怎樣的數據格式或報文進行輸出。如果SE能在芯片的微架構圖中，用箭頭將業務包含的數據流和控制流標注出來，就像戰爭地圖中描述行軍路線那樣，那真是太好了。

此處的描述只是在抽象度較高的事務級層面，對報文的處理步驟或過程進行抽象的描述。可闡述相關的算法處理和信息轉換，而不必涉及到實現的細節。SE需要把握好這個“度”，太寬泛不好，太深入也不好。既不能只見樹木不見森林，也不能只見森林不見樹木。

其三、微架構圖：子系統、模塊的組合劃分、接口描述和連接關系。

顧名思義，芯片微架構圖主要是展示芯片的微架構。芯片的整體功能是由多個小功能組合而成。因此，芯片微架構圖就應該由多個較為獨立的功能模塊構成。對于功能較為緊密的多個模塊，可組成子系統。多個子系統和模塊可由片上網絡相連，通過接口與片外通訊。這些組合成芯片的微架構。

微架構的最小單位是功能模塊，其次是子系統。模塊或子系統的關鍵參數可標注到微架構中，但是模塊內部的實現細節，不應在微架構中體現。

連接各個子系統和模塊的總線，也可看作是一個模塊或子系統。例如AMBA。芯片的接口分為通用外設接口（低速）、業務數據傳輸的Serdes接口（高速）、Debug接口。存儲模塊分為片內和片外。若是在片內，通常掛在總線上。若是片外，通常由芯片接口與之相連。

驗證者可根據微架構圖，明確芯片的內部結構，劃分驗證層次和制定驗證策略。

其四、芯片頂層接口的協議：報文、信號和時序。

頂層接口對驗證而言，非常重要。畢竟，驗證產生的激勵需要從接口輸入。芯片處理的結果要從接口輸出，驗證要從接口進行采樣。

驗證者關注接口，實際上就是關注接口對應的信號位寬、傳輸方向、關鍵信號之間時序關系和接口信號所傳輸的信息報文。

接口信息應該用表格呈現，信號時序需要畫出時序圖。

其五、芯片的時鐘頻率、reset、低功耗和DFX設計。

芯片的非主業務的功能也是驗證者關心的內容。首要的是時鐘和復位。只有給到正確的clock和reset，芯片才能正常工作。所有支持的clock頻率和reset信號的組合，都應該被驗證過。在業務中間進行復位的場景（在線復位），也是重要的一種驗證場景。低功耗特性是芯片中較為常見的特性。伴隨clock和power的關閉和打開，芯片進入和退出低功耗狀態，而邏輯電路在這個過程通常容易出錯。因此，這些是驗證者需要重點關注的場景。

如果SE能在FS中重點說明這些場景，那就太好了。比心。

DFX是芯片專門設計的定位手段。SE設計DFX時，要全面而精準的覆蓋關鍵邏輯電路，但不能過于冗余。做到這點，需要SE對芯片的邏輯電路有深入的理解，對芯片的問題定位有豐富的經驗。

以上五點就是從驗證角度看，FS應該包含的內容。然而，理想很豐滿，現實很骨感。現實中有些FS的寫法，在驗證者看來，是存疑的，是不合時宜的，是有待商榷的。

舉例說明：

1.在FS中將業務相關的信號名稱、模塊（module）名稱、寄存器以及各個域的名稱都定義。

竊以為，FS應該是從業務和應用層面對業務功能的描述，相對于設計實現，有一定的抽象性。實現細節相關的內容，應在數字邏輯詳細設計文檔中體現。寄存器相關內容應在寄存器表單中定義，而寄存器表單的制定和設計，應歸類為數字邏輯的詳細設計。撰寫者，應是數字設計工程師（Design Engineer, DE），而非SE。

FS不需要詳細到可以編碼，但是FS要能夠通過細化 和分解 ，可用于代碼的實現。不能寫出來的 過于抽象 ，細化 時 ，實現不了。也不能寫出來的就是細化后的設計文檔 。 要求SE要同時具備宏觀業務場景的精準把握和微觀設計實現的****了然于胸。

2.根據IP支持的最大頻率，設定芯片的工作頻率（主頻）。此頻率通常會大于真實應用場景所需要的頻率。SE之所以這樣做，或是為了芯片的下一版做性能提升的預研。或是為了給后端收斂時序時，預留了降頻的空間。方便了后端，方便了數字設計，也方便了自己，唯獨苦了驗證。

竊以為，FS應該根據應用場景和業務來確定芯片的工作頻率。驗證者保障芯片本身的特性的正確性，不應保障芯片集成的IP的全部特性的正確性。

3.集成IP的芯片的FS，IP相關內容直接在FS中插入IP的用戶手冊。

竊以為，不妥，原因同第2點。

4.時序圖包含了數字邏輯內部的信號的時序。

竊以為，FS中接口部分的時序圖，主要包含接口信號的時序。若需要加內部信號的時序，請在時序圖中將該信號與接口信號的時序的關系標注出來。否則，對于這種非接口信號的時序，讓驗證者有種奇妙的感覺：前不著村后不著店，丈二和尚摸不著頭腦。

5.FS中羅列芯片特性時，不分類。

竊以為，FS的Feature有大有小，應分類羅列。耦合度高的多個小特性，可歸納到一個大特性。對于復雜的特性，FS要通過專門的章節進行說明。涉及到的算法原理，處理流程，也要有專門的章節說明。

6.FS凍結之后，仍有源源不斷的FS變更。有些變更只有SE和DE知道，驗證者被蒙在鼓里，直到TO之后樣片回來，被測試出來。

竊以為，FS凍結之后，不能隨隨便便再修改了。如果非要改，要知會到所有相關的人，并且要征得他們的同意才行。

以上六點是驗證者眼中的FS的瑕疵之處。雖說瑕不掩瑜，但美玉無瑕，更加令人喜歡。

驗證者嘴里常常嘟囔：“無文檔不驗證”。須知，此處的“文檔”就是寫的好的FS。