EDA软件研发的DevOps平台

1：什么是DevOps

DevOps是十几年前，在互联网比较火的词，实际上就是ci/cd平台的另外一种说法，核心是说打破研发，测试，运维的边界，能够将整个产品开发的流程快速循环起来，随时可发版，随时可测试，达到敏捷开发的目的。当然，这里还牵扯到大量的线上发布，自动化测试的手段。

记得在更早前，研发桌面软件，或者大型的ERP软件时，并没有持续集成的概念，那时，测试不可能天天拿到最新的版本，拿到可测试版本，至少要一个月的周期。

转眼间，互联网甚至移动互联网的风头已过，芯片热兴起，国内不少企业开始进入EDA软件的领域。那EDA软件的开发，是否需要有DevOps，或者说CI/CD平台呢？实际上，仍然是非常需要的，甚至在某些场景，它起到的作用，非常之大。下面以我见到的案例，讲解一下要研发一个大型的EDA软件（桌面软件），如何搭建一个CI/CD平台。

1.1：EDA软件的开发流程

我们先来看一张图：

上面这张图，是对一个FPGA EDA软件开发流程的理解，它本身就是一个需要快速循环的过程。谁的周转率快，谁就能在软件中占得先机。

行内人会知道，要研发一款全链的EDA工具，不光是在某些环节有很高的难度，它的规模实际上也是不小的。中等规模可能是 100人的研发团队，在Xilinx，曾经有超过1000人的软件团队针对一款工具进行研发。所以，要协同好大家的工作，保证软件快速的持续更新，必须要有Ci/Cd平台。

在早期的CI/CD平台，大家的理解就是 GitLab + Jekins ，Build Tool + Pipe Line

当然，这仍然是核心，但要真正让这个平台有用，还有非常多的细节。

1.2：EDA软件的功能

首先，我们还是来看一下一款EDA工具，它本身是做什么的。

我们仍然以FPGA的EDA工具为例，上图可以非常清楚看到软件提供了编写逻辑电路，综合，映射，布局，布线，生成位流，烧录到芯片的全过程。

1.3：EDA软件的技术架构图

要完成这个软件，我们来看看它的技术架构，见下图：

我们今天不是讲FPGA的EDA软件是如何实现的，只需要看到它的复杂度即可。从上面的图可以看到，一款EDA软件需要多个模块组成，会严格分为 架构，器件，GUI，综合，技术映射，布局，布线，时序，功耗，位流生成，软件集成，TCL支持，测试等......非常多的模块，而这些模块的技术实际上有很大的差别，需要一个比较庞大的团队来支撑。而要将这些模块串到一起，必须要有一个CI/CD平台。好的，我们终于讲到正题了。

1.4：EDA CI/CD 平台的架构

所以，我画一下CI/CD平台的流程，如下：（后面我们会按照这张图，来介绍CI/CD平台需要完成的事情，并不会讲实现的细节哈）

2：开发环境搭建

EDA 软件，一般是采用C++来开发，因为需要极致性能，这方面 C++ 是王者。当然，对于GUI，有可能会使用其它语言。今天我们以全C++的开发语言为例。

因此，我们可以认为这个EDA工个由多个子模块组成，每个开发人员都身处在每个模块中。

由于EDA软件会有非常强的安全要求，所以，一般公司会将代码放到物理隔离的红区，而且也不允许大家跨组查看其它组的代码。但是，又需要随时获取最新代码来完成集成和测试。这差不多是开发环境的基本需求。

于是，代码仓一定是多个，首先，需要搭建多仓的开发环境。

2.1：多仓开发环境

EDA软件本身是一个非常庞大的工程，需要有多个领域的开发人员参与，模块众多，为了开发效率和代码安全，分成多个代码工程，使用 Git 管理代码，Gitlab作为管理平台，完成代码储存、版本控制、代码权限控制等。

注意：git仓禁止 force push（切记，切记）

考虑不同模块和角色的人拥有的权限不同，使用google 提供的 Repo 进行多仓管理，为不同角色的开发者生成不同的manifest，获得不同的代码工程的组合。对于repo的使用（一般不会用到），

git仓的权限，需要通过公司的流程申请获得。原则上按最小权限授予。

如何获取最新代码呢？

一般会给开发提供一个快速的命令：比如 repo_xxx_clone:基于个人权限拉取工程到开发者本地目录（依次将有权限的git工程clone到本地）。对于每个仓的权限管理，当然是使用gitlab的权限管理工具。

如何更新代码环境？

一般会封装一个 xxx_update命令： 获取最新工程代码，如果权限有变更，将追加新授权的工程，或删除收回权限的工程。这里的好处就是，可以将权限集成到这里。不需要用户去关注自已到底有哪些工程的权限。

2.2：开发环境设置

获取代码后，需要对开发环境进行设置。

【环境设置】

• 设置软件的主目录------XXX_HOME设置为当前目录，并设置一些与主目录相关的环境变量：注意：这个 XXX_HOME是必须的，因为后续有大量的路径都是基于此。

• 设置git提交时的用户配置------username ， useremail 会取当前用户

• 装载git commit的拦截程序 这是一种本地检查代码的方法。

好了，这里讲到最关键的点，如果我不能获得全部源代码，我如何进行编译连接？对了，我们会将你没有权限的模块的编译产品（so,dll，以及相应的.h）放入到一个特殊的预置仓，你可以随时拉取最新的预置库，通过链接SO的方式来完成程序的构建。

当然，初期也可以存在全源码的构建方式，但一般随着软件的成型，一般不再允许有人拥有全部代码的权限，这样很不安全。

2.3：三方依赖库管理

这里注意一下，我们一定存在直接引用的三方仓库，但是在引用前，一定要做安全准入审查，保证它是合法的，不会有license上的问题（哪果公司有法务，可交给法务判断）。一般对于MIT，Aparch, LGPL等协议可以安全使用（商务无需开源发布）。如果对于三方库来源不信任，可能还需要做一些安全扫描。

依赖的三方仓一般会有几种用法：

• 动态库引用，这是最常见的用法。

• 基于三方开源代码（允许修改），需要做少量的修改和维护。

• 商业购买的三方代码，这各可以按自研源码处理。

• 头文件使用，三方库只有头文件，直接在源码仓中引入使用。

• 静态库方式使用。

这里要注意一点，为了保证三方仓的代码可以溯源，一般最好是建立三方仓的源码仓库，自行按需编译生成相应的动态库，这样，可以保证我们产品出问题，可以找到相应的源码，进行调试。

2.4：多分支协同开发规范

一般是创建main分支作为主干，用于存储完整的最新代码。

所有正式的对外发布版本，会创建一个对应的发布分支。

实际开发时，各开发小组自行创建开发分支，当然，也可以统一建议特性开发分支，这个一般不做强行要求，看项目的复杂度了。

对分支需要有相应的管理，一般来说，main分支，原则上只能通过MergeRequest合入，并且只有Leader可以有最终的Merge权限。

发布分支，一般有更严格的合入要求（因为是要正式发版的），在正式发布前的某个时间点，会锁定分支，集体评审后，专人合并（保证代码质量）。

开发分支，一般可以不做管控，创建，权限管理，销毁由各开发小组自行管理。原则上是在开发分支完成基本模块的开发和测试，然后合并到main分支或者发布分支。所有合并到发布分支的内容，原则上都应该在main分支中存在。

注意：代码入主干和发布仓会触发门禁和冒烟，如果不成功，无法入仓，这样用来保证代码质量。这是最关键的，如何做到，后面会讲。

3：代码质量

代码质量如何保证？最容易想到是单元测试，然后就是各种静态，动态检查工具。

3..1：单元测试

要选定单元测试框架，推荐使用 google test 框架。

这里的单元测试代码会作为入仓前的冒烟用例，用来守护代码的质量。

3.2：代码检查

对于提交的代码，一般会进行一些检查，某些情况会拦截，某些情况给出提示。

建议的检查项如下（只是建议）

|-----------|----------------------------|----|------------------------|
| 检测项 | 检查规则 | 动作 | 备注 |
| FileType | 检测提交文件类型，检查是否非代码文件 | 拦截 | 不能直接提交编译后的产物，无法保证找到原码。 |
| FileName | 检测提交文件名字，检查是否重名文件 | 拦截 | 会有编译错误 |
| CopyRight | 检测提交文件内容，是否有CopyRight声明 | 提示 | 不合规 |
| FuncLen | 检测提交文件内容，函数的行数超100 | 提示 | 过于复杂的函数 |
| Cpplint | cpplint检测提交文件内容，存在error的文件 | 拦截 | 是否出现error，每个工程有不同的配置 |
| MVG | 检测提交文件圈复杂度，默认拦截超过最大圈复杂度的提交 | 拦截 | 逻辑过于复杂，分支过多 |

3.3：代码静态检查

CppLint

cpplint是最常用的，检查项目非常多，可以自行网上搜索。

Cloc

主要用于做代码的统计。

Cppncss

主要用于代码（非注释）的统计。

Flawfinder

寻找代码潜在的安全漏洞（主要用于C，C++代码）。

pmd_cpd

检测代码中可能重复（复制，粘贴）的代码，去除冗余，提升代码质量。

Simian

查找分析重复或者相似的代码。

Cccc

专注代码复杂度，代码统计。

代码统计：代码行数（包括注释行，空白行，代码行），用于估计代码规模

代码复杂度：圈复杂度，衡量代码逻辑的复杂性。

代码质量评估：类的耦合性，类之间的继承分析

对代码进行增量检测或定期扫描（注意：需要在流水线中设置，定期检查）。

在开发初期，大家代码质量不太行，可以适度放宽检查，比如：建立一个配置表，让各小组自行选择此阶段要检查的项目。

3.4 代码动态分析

通过测试用例，在运行时统计代码覆盖率，用于覆盖率分析。

gcov

代码覆盖率分析：查找未被测试覆盖的代码。

执行频率分析：代码行执行次数，发现热点代码和冗余代码。

分支覆盖率：测试条件判断分支是否补充分测试。

3.5 代码内存分析

常用的两种方式，ASAN方式，Valgrind 方式

ASAN方式

使用 构建的 ASAN版本（添加可调试的符号），运行用例 ，查看输出的报告。

Valgrind方式

使用普通的调试版本即可。但需要依赖 valgrind工具。无需要源码。

valgrind --leak-check=full --track-origins=yes ./program

3.6 检查策略

为了保证代码质量，采用多种策略进行检查。

本地commit前检查（拦截或提示）

在本地代码执行 git commit 时，可以挂钩自已的程序，然后定制代码检查。

也可以定期生成报告，输出质量报告查看质量。

4：代码构建

好了，开始讲最重要的代码构建，下面以 linux的make方式构建为例：

4.1：make构建（linux)

经典构建框架：

Makfile.top

Makefile.temp

Makefile.com

MakeFile：凡是要参与构建的模块，需要定义Makefile

解析顶层参数：All，Release，Debug，ASAN，Clean，HeadList，checkHeads

MODULES：包含嵌套的需要处理的子目录（模块）

...... 可输出静态库，动态库，可执行文件的参数 ......

Include Makefile.top

解析Modules，完成向子模块传递构建。

Include Makefile.temp Include makefile.com

定义通用的三方库的引用

解析编译，输出参数，完成核心构建

构建有如下的输出：

• 子模块构建

在comp/子模块构建，输出 .so 动态库，或者.a 静态库

• 合并子模块构建

将多个模块合并成一个库，这是常见的，否则容易暴露产品的实现细节，一般最后做一次合并。

• 构建可执行程序

在prog/子模块构建，输出 .sh 可执行程序。

• 预置库的构建

  本地缺失的源码，使用 Prebuild_lib的动态库。这是开发端最常见的构建方式。

  请注意，请及时更新最新的Prebuild_lib中的动态库。可使用 update_api

• 全源码构建

  通常在系统平台的流水线中的使用，完成正式的构建。

• 清理构建输出物

  清理构建的全部输出。

• 头文件依赖检测

  检测头文件的依赖关系。

重要命令

• xxx_build

配置：debug / release / asan

模块：all / gui / clean

预制库的更新

定时重新生成所有的动态库，更新到 Prebuild_lib 仓库，包括API头文件。

保证开发人员可以及时获取最新的Prebuild_Lib。

构建的定期检查

循环构建，完成预制库的输出的同时，保证代码可正常编译。如有问题，及时报警。

构建加速

构建速度非常重要，除了需要配置更好的物理资源，也可做如下的优化。

• 增量编译

• 缓存处理

• 分布式编译

对于 cmkae 和 windows的构建，这里就不讲了。

5：代码入仓

5.1：MR入仓

代码进入Main和 Release_XXX仓，原则上不提倡直接Push(少数人也此权限），而是建议采用MergeRequest入仓，因为在MR前会有若干的处理，可以对入仓的代码进行检查，不符合要求将会被拦截。

• 触发流水线

通过配置 Webhooks，MR时调用 Jekins提供的流水线，

• 获取代码

将需要MR的代码和正式仓代码进行合并，生成完整代码

• 门禁检查

  尝试对源代码进行多种build，检查是否可正常。

• 冒烟检查

运行预置的单元测试，检查关键用例是否可正常执行。

• Rebase处理

建议对代码进行Rebase，这样保证可保留所有提交历史。

5.2：门禁检查

调用全源码的构建：（这里并不输出结果，只是借用构建查看代码是否正常）

• Liunx debug build

• Linux Release lbuild

• Windows build

任何一个构建失败，整体门禁检查失败。

这是非常重要和关键的一个步骤，可保证入仓代码的质量。

5.3：冒烟测试

冒烟测试可提供配置文件：让各模块的人员配置对应的单元测试。

[Basic]：每次必须要执行的用例 这个理解为主流程

[模块名]：匹配当前MR的工程模块，匹配上的话就执行用例的shell脚本 返回 0 成功

5.4：多仓联合提交

某些情况，存在多仓提交，需要采用多仓联合构建的方式。具体略，需要将仓暂时进行锁定，保证一致性。

5.5：PrebuildLib 入仓

持续构建生成so，定时提交仓库，备用。

同时，达成检测代码可用性的目标。这个很关键，否则，开发人员的工作无法进行。

6： 打包输出

输出多种版本，用于后续的测试或支撑继续开发。这是持续交付的关键，可以让测试的流程快速闭环起来。

6.1 打包输出流程

建议流程如下：打包输出流程主要定义为下面几个步骤，可定制。

• pre_build

在build前的一些参数预置，根据实际输出的需要，进行设置

• build

实际的build过程，一般是先清理，然后 make all

• pre_pack

pack前的预处理，可以交给各模块自行编写脚本插入。比如：生成Primitive 的 HDL templates.

• Pack

可定制打包最后需要追加和忽略的文件。

• Post_pack

pack的后处理，比如：将tcl script 进行加密处理。

6.2 重要输出

• 输出的控制点

选用的代码不同，可能是Main，可能是某个Release分支。

支持哪些器件

是否进行License管控

是否提供内部feature

parm的默认参数值

tcl命令开放列表

• 输出的所有版本

对控制点不同的配置，形成多种输出

1：内部测试版本------用于内部的开发测试

2：软件部的外部测试版本------给到软件部以外的部门，如：市场，validation，回片 进行测试

3：面向客户的版本------给到正式客户的版本。

4：合作商的版本------提供给我们的集成商的特殊版本，比如：给到 mentor的合作版本

5：DFT测试版本------提供给DFT测试的版本

• 输出的周期

这个按需提供。可能是每日定点，每周......

• 重要的输出流程

这个看公司的需求，成熟度不同的阶段，会有不同的测试粒度。

7：安装包发布

7.1 制作安装包

分为Linux版本和Windows版本的打包。

完成安装包文件的SHA验证码

安全检查

提供发版文件，提供安装手册。

上架发布（可能是网站或者其它方式）

7.2：License处理

提供浮动版和单机版License。

确定license申请和绑定的流程，提供相应的审批流，并记录背后的申领数据。

8：工具平台支撑

8.1：调度流水线

提供Jekins Pipeline 流水线，按时间，完成定时调度，或主动触发，可以定制完整的flow。

除了为各种输出提供流水线，也为日常的测试提供调度配置。

比如：DailyTest，QoRTest，RuntimeTest，CustomerTest，WeeklyTest，GUITest。

8.2 监控预警

提供预警API，用公司的协同工具完成消息推送。

预警点：环境输出失败，门禁失败，打包失败......

监控这里更多指的是必要服务的可用性监控，或者说是质量的看护监控，这个都需要自定义脚本来完成。

8.3 数据分析

代码质量看板

提供质量看板，为测试组提供代码覆盖率、缺陷率、代码量的持续监控看板，提高问题洞察效率。

Git仓授权检视

代码提交量统计

更多...... 注意，这里需要选用一款报表系统，进行可视化的展示。取数和加工根据实际情况进行开发。

8.4 安全加密

提供非对称密钥对，公钥在代码内置，私钥在打包时构建入代码。

加密工具可以将用户的代码进行加密，然后只能在EDA软件中安全使用。这样，可以保护用户和我司的代码。

用户也可以使用提供的加密工具，对代码进行加密，然后在EDA中使用。

这个很重要，因为客户的代码是绝密的，必须要想办法保护，在交付三方时，可以使用，但不可见源码。

8.5 三方集成

CI/CD平台需要与 协同工具，Gitlab，Jenkins等平台进行集成，比如：Git自动授权，代码权限审视，代码仓锁库，消息通知等。

8.6 现场调试

需要提供现场调试的能力，因为某些情况，只能在客户现场重现问题。

我们只能将某部分代码重编后，在客户现场通过GDB来调试。

现关的实现。略。

以我的经验，大概就讲这么多了，也摘自之前的总结。