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