2023年2月28日，龍智聯合全球領先的數字資産管理和DevSecOps工具廠商Perforce共同舉辦Perforce on Tour網絡研讨會——“賦能‘大’研發，助力‘快’傳遞”。
研讨會上，在晶片行業有15年經驗的Perforce Helix Core深度使用者——何剛了帶來精彩演講，從晶片開發的需求和痛點出發，分享如何利用Perforce Helix Core來實作快建構，快疊代，高協作，大檔案的版本管理，如何實作晶片項目的持續內建和自動化，并運用執行個體讓大家具體了解如何在晶片的研發中落地Helix Core版本控制。
何剛現任上海星思半導體晶片開發部部長，他從事晶片開發工作已15年餘，曾擔任十幾顆大型複雜晶片的開發骨幹，如華為早期無線基站晶片SD6xxx，投影儀晶片PA168，AMD銳龍R9系列dGPU顯示卡晶片和自動駕駛晶片A1000等。何剛從業以來所有參與晶片，包括近期負責的5G基帶晶片，均一版成功。
以下是何剛演講内容的節選，回顧視訊請于文章末尾擷取。
線上研讨會“賦能‘大’研發，助力‘快’傳遞”内容回顧
《晶片研發中的IP資産管理》
演講嘉賓：何剛，上海星思半導體晶片開發部部長
大家好，我是上海星思半導體晶片開發部的部長，何剛。非常感謝龍智的邀請，讓我有機會與大家分享Perforce (Helix Core) 的使用體驗。今天，我将從晶片開發的IP資産管理角度來分享Perforce使用體驗。
晶片項目開發需求和痛點
我簡單地總結出以下八大需求和痛點：
首先，需要穩定、可靠的版本管理來提高工作效率，沒有版本管理的晶片開發就是一團亂麻。
其次，需要細緻的權限管理來滿足安全性。因為晶片開發過程涉及到很多團隊配合，是以不同團隊的權限管理需要不同的配置，保障公司資訊安全。
然後需要進行代碼的分級管理，持續內建。晶片開發過程中，在設計的時候是Top down，但是開發的時候是Bottom up。Bottom up實際上是先從小子產品到大子產品，到IP再到磁吸層最後到晶片的過程，這個過程也要分級管理，也就是持續內建，CI/CD。
再然後是經常需要拉各種分支進行某種特性開發，要保證主分支的穩定性，拉一些開發分支進行特性的開發。特性開發比較多，是以開發分支也會比較多。
接下來是經常需要做多分支同時merge到主分支，開發分支被拉出去後，相當于将它展開，還是需要收回來的。
有時還需要做大檔案和大資料量管理。前方開發在開發代碼的過程中不會涉及到大檔案和大資料量，但是因為晶片開發有綜合和後端，這就會生成大檔案，最好能做版本管理，但其他工具沒有這個能力。一些公司使用SVN或Git，但由于它們不是用檔案夾來進行管理，是以會造成資訊的損失，檔案和原版的對齊可能出現錯誤。
一般都可能需要跨地區、多團隊協作，晶片開發動辄幾十人，甚至成百上千人，特别大的公司上萬人，肯定涉及跨地區、多團隊協作。
因為使用者較多、使用方式較雜，需要使用者接口友好，降低使用成本。否則難以操作會增加使用過程的困難性，進而導緻成本增加。
今天主要從四個方面說起。首先是回顧Perforce的優勢，第二是晶片的項目版本管理，第三是晶片項目持續內建和自動化，也就是CI/CD。晶片行業的CI/CD可能沒有傳統軟體領域的CI/CD那麼好、那麼徹底。但是晶片項目如果引入了CI/CD将會帶來非常大的效率和品質提升。最後給大家介紹晶片行業應用執行個體。
Perforce的優勢
部署維護簡單，我相信使用過Perforce的人應該有很深的感受，它的部署和維護是很快、很簡單的。使用者界面非常友好，還有強大且成熟的圖形化GUI界面，對我來說十分便利。
Perforce對大檔案大資料量的支援很優秀，這一點也是有目共睹的。團隊的協同工作在使用Perforce後更便利、更高效了。Perforce的權限管理非常靈活友善，SVN已經很友善了，但與Perforce相比還是略遜一籌。最後，我會簡單地比較一些版本管理工具。
Perforce部署維護相當簡單，大約500人的團隊隻需一位管理者來進行部署和維護。備份也特别友善。使用過程中無需擔心Perforce本身的問題，因為Perforce已經是業界公認的使用無問題的軟體。
Perforce使用者界面是多方面友好的，經典集中式管理對于以前使用CVS、SVN、ClearCase的使用者來說易于上手。GUI界面工具P4V能夠和指令行工具結合使用。圖形界面可以友善地浏覽檔案版本的演進曆史，分支結構和目錄結構一目了然。指令行工具可以更友善的實作腳本化。
Perforce對大檔案大資料量的支援主要展現在大于10G的檔案，隻有Perforce能進行管理，其他工具無法承受。Perforce多線程技術可以充分使用網絡帶寬和本地磁盤的速度，給上傳下載下傳帶來高速的體驗與感受。它無需存儲本地控制資訊，也能大幅提升上傳下載下傳檔案的速度。Perforce可以按需下載下傳檔案，當要擷取某一個需要的檔案時，不需要擷取整個倉庫。
團隊協同工作便利高效是因為Perforce的集中式管理可以早期發現沖突，減輕在後期合并時的工作量。您可以帶鎖check out，避免check out檔案被他人修改。跨地域全球部署，各地的開發人員在本地伺服器上工作，本地送出後全球站點都可使用。
Perforce的權限管理非常靈活友善，可以細化到檔案級别，SVN等隻能針對檔案夾做管理，不能對檔案進行管理。除了管理者管理權限以外，您還可以委托給各個分部門進行權限管理。無需将所有的權限管理都給權限管理者。公司級可以由管理者管理，部門級設定管理者支援部門内部的、更精細的權限管理。權限管理也可以細化到檔案級，管理者可以委托部門管理者進行管理，減少業務部門等待時間。
晶片行業早期也使用CVS、ClearCase等工具，但CVS隻針對檔案進行管理，無法對檔案夾進行排名。ClearCase我們以前用來管理文檔、代碼，現在比較少見。目前來說SVN、Perforce和Git是主流。
SVN和Git都有各自的優勢，也有各自的缺陷。SVN有很強的權限管理，但是分支和merge能力很弱。是以在使用SVN開發晶片時，是沒辦法拉分支的。如果拉了分支後面的merge會很難受。
Git的分支能力還可以，但它的權限管理非常弱，隻能對整個庫進行權限管理，幾乎沒辦法對子目錄、子檔案夾進行權限管理。
他們各自的優點Perforce都有，但他們的缺點在Perforce裡都解決了。Perforce有很強的權限管理，同時有很強的分支能力。他的分支能力可以說是非常靈活自如，并且有規則。
比如主分支、釋出分支、開發分支、測試分支，這些基本的分支建立後，開發過程中就能非常自如拉分支、進行合并。
Perforce可以進行文檔管理。文檔有時也要分不同的架構進行不同部門的權限配置。SVN、Git、ClearCase其實都可以管理文檔，Perforce當然也沒問題。Perforce對整個開發過程中需要版本管理的檔案進行版本管控。
剛才回顧Perforce的優點，我們目前幾乎沒有發現他的缺點，歡迎大家來挑刺。
晶片項目版本管理
Perforce擁有強大的晶片項目版本管理能力。它有經典的Local類型分支管理功能，Stream類型分支管理功能。接下來會講到Stream Graph示例，Changelist與Revision的概念，以及靜态标簽、自動标簽，最後是便捷的CI/CD。
Perforce經典的Local類型分支管理功能中，項目組裝是對各子產品的引用，而不是拷貝。在工作區中組裝SOC時，通過View Mapping即可完成。便捷的Branch Mapping功能能夠友善地維護分支間的對應關系。這一塊已經被使用多年。
Perforce還有Stream類型分支管理功能，它規範了每個分支的目錄深度，避免分支層次混亂。在目錄深度方面，Stream是直接定義好的。規範每個分支的類型和父子分支之間合并行為，就是主分支、釋出分支和開發分支這幾個類型之間的合并行為。将SOC組裝從工作區定義提升到Stream定義，Stream已經把SOC組裝定義好，使用者可直接使用Stream定義來實作SOC組裝。同一工作區可自由切換Stream分支，減少磁盤空間占用。比如您的工作區原先在主分支上，現在想切換到某個釋出分支，在同一個工作區内可以自由切換，這樣您就可以在不同的分支上進行活動，無需再下載下傳一個工作區。可視化的Stream Graph分支管理視圖，看起來非常便利。
這是Stream Graph的一個示例，有主分支、釋出分支、開發分支。一般來說，一個IP或一個子產品就會有一個這樣的Stream體系。每個子產品可能含有其它子產品的釋出分支，同時也會有自己的新開發内容。
Changelist與Revision的概念是，Revision是針對檔案有數字累加的版本，Changelist是整個庫的Changelist。但是針對單個檔案，它既有Revision号，同時也有Changelist号。
晶片項目版本管理的靜态标簽方面，您可以獲得任何一個檔案的版本号，做成靜态标簽，使用者可以使用靜态标簽對版本進行check out。
Auto Label可直接使用Changelist作為智能标簽。
晶片項目持續內建和自動化
晶片項目的持續內建和自動化其實借鑒了軟體行業多年的實踐經驗。
晶片開發的整個Fullchip中有很多子系統，例如5GNR、ISP、AI/NPU、PCIe、CPU、GPU、LPDDR5、USB，每個子系統中又包含多個IP，每個IP又內建了多個子產品。在開發過程中，這些子產品先進行開發，然後釋出給IP。IP開發到一定成熟度時，釋出給子系統，子系統再釋出給Chip。這個過程有點像流水線，從子產品流到IP，IP流到子系統等等。
這樣的流過程如何實作？您需要對每個子產品進行版本釋出，其實就使用了它的釋出分支，它本身在也還在開發過程中，當然有些第三方IP例如PCIe，底下的一級代碼是成熟的，但是自研子產品必須邊開發邊往上一級進行版本釋出。
每個子產品都有自己的主分支、開發分支和釋出分支。在IP這一層也有自己的三個分支，有釋出分支、主分支，它的開發分支指IP的頂層。
這些分支，例如若幹個子產品的釋出分支被IP拿到後，就是在子產品進行開發時，釋出分支可以人為釋出，也可以自動化釋出。當然，自動化釋出要基于一些規則。比如一些新的特性已經開發成熟，或是最簡單的，一些典型的case已經pass，這是就可以用工具自動化釋出，當然手動釋出也可以。
這些釋出分支如果IP的三個版本中還沒被拿，那麼目前這個版本就可以把它拿進來，然後讓工具做自動回歸，自動回歸通過後，新釋出的版本就被這個IP拉進來了。這是就完整的一次流水過程。
IP到子系統也是同樣的道理，各個IP自己做流水，子系統也在做流水，Fullchip也在做流水，當流水線對接後，整個晶片開發流水線就形成了，因為Perforce有非常強大的分支管理能力，能夠完全支撐流水線，非常友善。
子產品級、IP級經過CI到Harden級。Harden是由一些大的IP形成的。然後再到子系統級，最後到Fullchip級。每一級都是相似的流水線過程。
當流水線實作後，能夠使得晶片開發過程變得特别高效。舉個簡單的例子，如果有持續內建的過程，新的版本形成新的內建，例如IP進子系統或進Harden的過程會自動完成，無需人為推動。人為推動很容易疲勞，并且會發生跟不上的情況，去催促版本也不友善。
CI就算沒有成功，比如子產品進IP的過程失敗了，馬上就會發郵件給相關的人。假設有子產品1和子產品2失敗，報出來的錯誤是接口不對，郵件立即發送給相關的負責人，相關的負責人一看就知道，原來是釋出版本的接口不一緻導緻失敗，他能夠迅速解決，再merge到之前的釋出分支。
版本更新後可以重新做一次CI。CI可以自動化，也可以人為觸發。是以即使是失敗也是有意義的。無論是pass還是fail都是有意義的。
我們以前的項目流水線一般做四級，後來我們簡化為三級。
晶片行業應用執行個體
晶片項目有大有小，大的項目也是由若幹個子系統或IP組成。小型項目或IP可以使用單一Stream管理就足夠了。大型項目分子產品組織Stream。
使用Stream管理分支和IP有以下幾個類型，都可以使用Perforce進行管理，在此不多做介紹。
有一點需要強調，當上一級內建下一級子產品的時候，一般用它的釋出分支。然後在本層，例如IP層級，本身也有基礎的代碼，不僅需要子子產品的釋出分支，自己本身也可能處于主分支/開發分支/釋出分支中。
小型項目使用單一Stream如圖所示，每個分支包含Soc的所有部分，整個項目裡面都這樣疊代。
大型項目分子產品組織Stream，不同子產品的疊代速度不同，有些開發較快，有些開發較慢。
分子產品組織Stream，分别按照Feature釋出自己的Golden版本，也就是釋出分支。
SOC項目按需選擇各個子產品的不同分支下的Golden版本。
這是一個SOC Stream Graph示例。Soc_main作為系統頂層，內建了Coretex、pcie、usb、isp、npu等IP或子系統。或者說IP本身就是子系統。有些第三方的IP核配置一個版本就能一直運作，不用再做開發，是以不用再頻繁拉釋出分支。
SOC Stream定義示例，大團隊使用Stream soc_main的Stream定義中，可以按需指定導入子產品。您可以看到子系統、IP的import和釋出分支。
Stream定義通常由項目管理者，也就是PM制定。開發人員使用時，隻需在工作區中指定Stream的名字即可。
這是SOC目錄種組裝示例，左圖是庫上目錄結構的關系，右圖是本地代碼組裝的效果。
擷取“賦能'大'研發，助力'快'傳遞”線上研讨會完整回顧視訊