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