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目录种组装示例，左图是库上目录构造的关系，右图是本地代码组装的成果。