基于ARM V9 CPU的PC SOC设计数据管理关键技术分析

基于ARM V9 CPU的PC SOC设计数据管理关键技术分析

石松华

此芯科技（上海）有限公司

摘要：本文探讨了基于ARM V9 CPU的PC SOC设计项目中的数据管理技术。项目目标是打造一款适用于多平台的高性能、低功耗PC SOC。针对芯片设计的复杂性和大规模团队的协同需求，本文提出了基于Perforce的协同设计数据管理方案。通过比较Subversion和Perforce，选择了Perforce作为版本控制工具，并引入了创新的mixed（混合）模式，优化了数据集成和研发流程。实践证明，该方案提高了设计数据管理的效率和准确性，减少了开发错误，加强了团队合作。该研究成果对高性能PC SOC设计领域具有重要的理论和实践贡献。

关键词：ARM V9 CPU；PC SOC设计；数据管理；Perforce；协同设计流程

引言

随着信息技术的快速发展，高性能计算设备的需求日益增长。特别是在移动和车载平台，对CPU性能和功耗的要求更加严苛。基于ARM V9架构的PC SOC设计，旨在实现高性能与低功耗的完美平衡，以满足多样化的应用场景。本研究聚焦于该SOC设计中的数据管理关键技术，探讨如何通过先进的版本控制和协同设计流程，提高研发效率和产品质量。立项意义在于解决大规模集成电路设计中的复杂性问题，确保设计数据的一致性和可维护性，对于推动高性能计算设备的发展具有重要的战略和实用价值。

1.项目概况

本项目围绕ARM V9 CPU展开，旨在打造一款性能卓越、能效比高的跨平台PC SOC。采用5nm/6nm先进工艺，集成了包括ARM-CPU、GPU、NPU、VPU、DPU在内的多种处理单元，以及LPDDR、USB、PCIE等高速接口，通过IP和系统总线实现组件间的互联与协同。力图开发出能耗比优秀、性能调节灵活的SOC，满足多样化应用场景。项目周期设定为2022年4月至2024年4月，覆盖了从硬件架构设计到软件、系统集成、验证、测试直至流片的完整研发流程。

2.设计数据管理需求分析

在本项目中，对于数据管理平台的需求主要集中在以下方面：集成的IP模块数量急剧增加，设计文件类型繁多，这就要求数据管理系统必须能有效地处理和管理复杂性；能够支持大规模团队协作，确保设计流程的同步性和一致性；同时保证历史版本的可追溯性和可比较性；既能支持IP团队的独立开发，又能保证与SoC团队的紧密协作；能够方便错误追踪与修复；该系统还需要具备高性能，以应对大量数据的快速存取和处理，保证系统的稳定性和可靠性；最后，数据管理系统必须提供足够的安全措施，防止未授权访问和数据泄露。

项目面临的核心技术难点是：在芯片设计过程中，涉及众多IP和SoC的协同开发。若管理策略不当，将严重影响开发进度，甚至导致工作停滞。传统的hosted和nested模式虽各有优势，但均无法全面支持研发的顺畅进展。

3.协同设计数据管理方案选择[S1]

在本项目中，设计数据管理方案的选择是经过综合考虑的。随着芯片技术的飞速发展，我们面临着管理日益增长的复杂性，其中包括集成众多IP模块和处理种类繁多的设计文件，项目规模的扩大也带来了团队协作上的挑战，需要上百名工程师在同一个平台上高效协同工作。在这样的背景下，设计数据库的维护和管理变得尤为关键。

为了应对这些挑战，我们对业界广泛使用的多种版本控制方案进行了深入的比较分析。最终选择了基于Perforce的版本控制软件来构建设计数据管理系统。Perforce以其卓越的性能和强大的功能，在处理大规模数据和多用户协作方面展现出了明显的优势。

本项目的系统将充分利用Perforce的版本管理能力，确保设计数据的准确性和一致性，同时支持设计团队之间的有效协作。通过这一系统，能够实现对设计变更的精细跟踪，保障历史版本的可追溯性，以及在多团队环境中维护数据的完整性。

此外，Perforce提供的灵活的权限管理和强大的分支合并功能，将极大地促进我们的研发流程，加快产品的上市速度。选择Perforce不仅满足了当前项目的需求，也为未来可能的扩展提供了坚实的基础。通过这一决策，期望能够显著提高设计数据管理的效率，降低研发风险，最终推动项目成功。

4.基于Perforce的协同设计流程开发

4.1基于混合模式的IP/SoC数据树结构

4.1.1常见集成开发结构

在大规模芯片设计项目中，团队通常分为IP团队和SoC团队，前者负责设计开发各IP模块，后者则在芯片顶层集成这些IP数据进行全芯片的验证和设计。Perforce作为版本控制和数据管理平台，支持两种集成IP数据的模式：nested模式和hosted模式。

Nested模式中，IP模块和SoC在Perforce中拥有独立的树目录，通过层层引用构建数据架构[1]。IP团队在开发节点发布变更号，SoC团队根据此变更号配置客户端下载特定版本的IP数据。这种方式保障了IP团队的独立开发，但一旦SoC团队在验证过程中发现IP错误，修复周期可能较长，因为IP团队可能已在原版本基础上进行了多次迭代更新。若错误涉及多个相互依赖的IP，修复将更加复杂，可能导致SoC团队工作停滞。Perforce客户端配置的示例如下：

图1 Nested 模式的Perforce 客户端配置

Nested 模式的数据开发结构示意图如下：

图2 Nested 模式的数据开发结构

相对地，Hosted模式将所有IP和Subsystem数据目录放置于SoC目录下，便于IP和SoC团队紧密协作[2]。IP团队可以选择发布变更号或让SoC团队直接引用最新版IP。这种模式以SoC设计为中心，便于及时修复发现的错误，但牺牲了IP团队的独立性。一旦SoC团队发现IP错误，IP团队需要解决错误并考虑如何将修复与当前版本合并，这可能影响IP团队的开发效率。Perforce 客户端配置的示例如下：

图3 Hosted 模式的Perforce 客户端配置

Hosted 模式的数据开发结构示意图如下：

图4 Hosted 模式的数据开发结构

两种模式各有优势和局限，选择合适的集成开发结构对提高设计效率、降低错误修复周期、保证项目进度具有重要意义。项目团队需根据具体情况和需求，权衡两种模式的利弊，以实现高效的协同设计和数据管理。

4.1.2新型混合模式集成开发结构

在芯片设计领域，传统的nested模式和hosted模式各有利弊，需要在IP团队和SoC团队的开发进度间做出权衡。为了解决这一问题，提出了新型的mixed（混合）模式，以期实现更高效的协同开发。

Mixed模式结合了nested和hosted模式的优势[3]。在Perforce数据架构中，IP模块和SoC各自保有独立的树目录，同时通过合并操作（p4 integrate）允许SoC团队将IP团队发布的变更号下的数据拷贝到SoC目录下。这种硬拷贝机制，与nested模式中的软链接相比，提供了更高的灵活性和控制力。SoC团队在验证过程中发现IP错误时，IP团队可以直接在SoC目录下进行修复，避免了SoC工作的停滞，同时保证了IP团队开发进度的独立性。

此外，IP团队能够灵活决定错误修复的合并时间和方式，有效管理了开发流程和进度。这种模式不仅提升了协同工作的效率，也优化了错误修复流程，减少了因等待修复而导致的项目延误。

图5 Mixed 模式的数据开发结构

Mixed模式的数据开发结构如图5所示，其特点在后续章节有更详细的介绍和分析。表1通过对比nested、hosted以及mixed模式，可以更清晰地理解每种模式的适用场景和潜在优势，为实际的芯片设计项目选择合适的开发结构提供了理论依据和实践指导。

表1 三种模式的数据开发结构的比较

4.2基于Perforce的IP研发流程

为确保SOC团队按计划进行，IP团队需严格遵循项目时间表发布数据。发布前，IP团队须完成以下工作：在IP树目录进行仿真验证，确保测试通过率达到规范要求；IP模块需通过设计质量检测，包括语法检查（Lint）、跨时钟域检查（CDC）、跨复位域检查（RDC）和可综合性检查（Synthesizable）；完成SOC团队要求的芯片级验证。

发布时，IP负责人需记录变更号并发布给SOC团队。为保证数据一致性，发布前需确认：全部文件版本已提交，无遗漏；本地客户端使用的是正确版本号的文件；无Perforce非管理状态下的本地修改。这些检查可通过执行p4 status命令，查看客户端本地文件状态来完成，确保变更号发布时数据的准确性和完整性。

4.3基于Perforce的SoC研发流程

在SoC设计流程中，IP团队与SoC团队的协同工作至关重要。SoC团队在收到IP团队发布的变更号后，整合负责人负责配置客户端，将IP数据与SoC树目录数据一同下载至本地，形成标准模板。随后，进行一系列全芯片级别的设计质量检查，包括Lint、CDC、RDC、Synthesizable和Compile等，确保设计符合质量标准。

通过检查后，整合负责人执行p4 integrate整合IP数据至SoC目录，处理p4 resolve解决数据冲突，并执行p4 submit提交新数据。完成操作后，通过p4 diff2命令比较SoC目录下IP子目录数据与IP目录变更号标签下的数据，确保一致性。最终，根据整合结果创建新的客户端模板供SoC团队使用。

SoC验证部门首先执行完备性检查（sanity check），若发现错误，将遵循一系列处理步骤。首先记录错误并追踪状态，使用如Jira或Redmine等错误追踪平台。接着评估错误级别，区分为重大或非重大错误，并确定错误来源，决定是由SoC团队内部处理还是通知IP团队。

对于IP模块的重大错误，IP团队需迅速分析原因，判断是否可在当前版本下修正。如果可以，修改代码并通过相关检查后发布新变更号给SoC团队。若当前版本无法快速修复，则在SoC目录下IP子目录进行修正。对于非重大错误，IP团队可自行决定立即修复或合并至下次发布。无论选择哪种方式，IP团队都需在用户手册中记录错误并提醒相关团队。

在整个错误修复过程中，IP团队需在错误追踪平台上持续更新修复状态和进度。一旦SoC验证部门通过完备性检查，SoC目录下的当前变更号将被发布，包含芯片顶级数据和IP模块数据。此变更号基础上，SoC性能验证和硬件加速仿真部门可开展进一步的深入验证工作，确保设计质量与项目进度。这一系列流程不仅提高了错误处理的效率，也加强了团队间的协作与沟通，为SoC项目的顺利进行提供了坚实保障。

Mixed模式下SOC研发流程如下图所示：

图6 Mixed模式下SOC研发流程图

4.4基于Perforce的ECO研发流程

在芯片项目接近流片的后期，为保障最终验证和仿真的顺利进行，必须通过Perforce的权限设置(p4 protect)关闭SOC和IP模块树目录下设计数据的编辑权限。此时，若仿真验证发现错误，便需启动ECO（工程变更）流程进行修复，即在接近完成的设计上实施小范围的增量式修改。

ECO流程在Perforce管理下的操作步骤包括：研发团队首先通知项目经理并记录错误，以便追踪。项目经理随后组织相关团队定位错误原因，并确定最小变动的修复方案。研发团队根据方案在本地客户端修复错误，并提交验证团队验证。验证通过后，研发团队提交修改文件列表给项目经理审阅，确保符合预定方案。审阅通过，项目经理指示Perforce管理员开放编辑权限，允许研发团队上传修改，并在完成后再次关闭编辑权限。最后，项目经理更新错误修复记录，完成ECO流程。

这一流程确保了在设计后期，对关键数据的修改是受控和有序的，减少了因随意修改带来的风险，同时提高了修复效率和准确性，保障了项目按期成功流片。

5.结论

本文针对基于ARM V9 CPU的PC SOC设计项目，提出了创新的协同设计数据管理方案。利用Perforce作为版本控制工具，结合nested、hosted和mixed模式，有效应对了大规模集成电路设计中的复杂性、协同工作和版本控制问题。实践证明，该方案能显著提高设计数据管理效率，减少错误，加强团队协作，加速产品上市。同时，项目对ECO流程的优化确保了临近流片阶段的高效错误修复。这些成果为高性能PC SOC设计及类似复杂项目的数据管理提供了理论和实践指导，具有重要的应用价值和行业影响力。

参考文献：

[1]Silvello G. Structural and Content Queries on the Nested Sets Model[C]//SEBD. 2012: 283-288.

[2]Kumar P, Pramanik P K D. Host selection methodology in cloud computing environment[J]. International Journal of Advanced Research in Computer Engineering & Technology (IJARCET), 2012, 1(8): 1-5.

[3]Torsten Mähne.Efficient Modelling and Simulation Methodology for the Design of Mixed-Signal Systems on Chip[J].epfl, 2011.DOI:10.5075/epfl-thesis-4993.

[S1]当前内容与第4章内容重合度过高，没有重复介绍的必要，需要您调整内容描述或删去整章内容。若是原第3章标题不太合适，您也可以酌情调整为：“协同设计数据管理工具选择”等标题。
这部分内容原本在大纲提取阶段主要是想让您简单介绍一下关于“选择基于版本控制软件perforce 来构建设计数据管理系统”的考量。因此大纲中只给此部分内容分配了400字。

参考的业绩撰写内容如下：
随着芯片技术的发展，芯片的复杂度越来越高。芯片的研发过程中往往要集成数十个甚至上百个IP模块，其中涉及的设计文件类型多达几十种；同时，参与芯片研发的团队规模也在逐渐增大，在大规模复杂的芯片设计中，需要上百名工程师协同开发。这便对芯片的设计数据库的维护管理都提出了更高的要求。版本管理软件对于构建稳定可靠的开发和发布系统的流程起着至关重要的作用。

为满足上述需求， 在对业界使用较多方案做过对比之后选择基于版本控制软件perforce 来构建设计数据管理系统。

此系统将利用perforce 实现对设计数据的版本管理，保证设计数据的正确性和设计团队协同开发