Perforce 研讨会回顾 | Helix Core 在芯片行业的应用实例：芯片项目的版本控制、持续集成及自动化

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

如需获取何刚完整回顾视频，请点击此处