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来调试。

现关的实现。略。

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