芯片设计-如何在缺少 CAD 团队的情况下进行异常日志分析

半导体在发展最初，由于电路比较简单，对计算能力的要求不高，基本的设计工作可在单台工作站上完成。此时IT工程师负责基础设施的维护，而IC工程师负责芯片的开发。但随着电子工艺的发展，电路变得越来越复杂，设计工作对IT架构提出了更高的要求。设计架构的复杂化使得原有IT和IC工程师的技术栈已经不足以应对复杂的架构，如何在整个设计流程中最大化利用公司IT资源，优化设计流程，并帮助设计团队高效地完成设计工作，就成为了每个设计公司的重要任务。而这部分工作，往往由CAD工程师来完成。

国内大部分半导体设计公司都面临缺少 CAD 工程师的局面。缺少 CAD团队影响设计效率成为一个日益显著的问题。缺少 CAD 团队意味着缺少开发设计流程工具，缺乏流程管理，无法为作业失败后的日志分析提供良好的排查指导。本文以回归测试举例，阐述在回归测试过程中，当作业失败，需要针对异常状况进行分析时，提供一个简单的排查流程指导。各位可以根据公司自身的状况进行定制化设计，并通过异常分析流程在缺少 CAD 团队的情况下提升开发效率。

我们首先来看一下在一个大型的半导体公司中理想状况下的 EDA 堆栈。

以上的架构图中我们可以看到，在设计环节 IC 工程师、CAD、IT工程师是各司其职，同时协同工作完成芯片设计。他们之间的职能边界可以参考下图：

上图中可以看出 CAD 工程师是 IC 工程师和 IT 工程师之间衔接。在开发测试遇到异常问题的时候，CAD团队起到了排查流程创建和组织的作用。在缺少CAD团队的情况下，往往会因为IC工程师团队和IT工程师团队缺乏对芯片设计到基础设施管理的整体理解而导致回归测试周期延长，影响排查效率。

笔者进行了归纳和总结，针对如何在缺少CAD团队的情况下，对设计过程中的异常或失败日志进行分析形成初步解决方案。请注意，以下的分析流程是基于没有CAD团队，没有设计流程工具的状况下，可以由IC工程师和IT工程师协同工作进行初步异常分析。同时，本例中的EDA堆栈是基于AWS开源解决方案Scale-out Computing on AWS（简称SOCA）搭建。SOCA是一种可帮助客户轻松部署和操作多用户环境，从而支持计算机辅助工程 (CAE) 等计算密集型工作流的解决方案。该解决方案具有多种多样的计算资源、快速网络主干、可扩充存储空间以及直接集成在AWS中的预算和成本管理。

我们将设计过程中的日志分为四种：

• 调度器日志: 调度器服务会针对任何发生的错误记录诊断消息，并保存在日志文件中，这就是调度器日志。该类型的日志通常存储在调度器的安装路径下，例如SCHEDULER_HOME/server_logs。以SOCA为例，SOCA集成了开源调度软件PBS，并将PBS安装于’/var/spool/pbs/’路径下，日志文件保存在’ /var/spool/pbs/server_logs’目录下。如果无法打开日志文件，则调度器会将诊断消息写入系统控制台。在本文中，我们把这部分日志称为 server_logs 。

另外，会记日志也会对异常排查起到一定辅助作用，该日志可以展示作业运行结束后的终止原因，运行时长，资源使用量等内容。这部分的日志通常位于SCHEDULER_HOME/server_priv/accounting路径下。在SOCA中，这部分日志文件保存在’ /var/spool/pbs/server_priv/accounting’ 目录下，SOCA也整合了 Amazon Elasticsearch Service 对会记日志做大数据分析。在本文中，我们把这部分日志称为accounting_logs。

• 作业日志：IC 工程师可以在提交作业的同时输出作业日志，该日志会输出作业的执行信息。例如，在SOCA中我们使用PBS作为作业调度器，并且编写作业提交脚本job_submit. que，我们可以使用如下内容将作业执行过程中的日志进行输出：

#PBS -V -j oe -o /out/put/of/your/job.qlog

• EDA工具日志：描述 EDA 工具运行中产生的日志。在您使用相应的EDA工具进行设计时，开启日志并指定输出路径。建议这部分日志保存在共享文件存储上便于检查分析。
• 计算节点资源使用日志：计算节点设备状态日志，描述计算节点的资源状态信息，如 CPU 和网络的使用状况等。您可以周期性的对计算环境进行资源使用状况信息收集，例如 CPUUtilization, NetworkOut 等参数指标，从而绘制资源使用曲线用于帮助您诊断异常是否和资源过载有关。例如，SOCA中默认使用 Amazon CloudWatch 服务进行 CPU 利用率指标收集，并会在 Amazon CloudWatch 的服务台中绘制利用率曲线。

具体异常排查流程请参考如下流程图：

我们以SOCA中的异常分析来具体诠释以上的流程图。

Step1：如果作业提交发生异常，我们需要查看调度器日志，SOCA 集成了 PBS 作为调度器，那么在本例中我们需要查看的日志为：/var/spool/pbs/server_logs。同时，如果作业无法提交，还可能与IC工程师的权限相关，或者与该作业所在项目的预算超额相关。以上部分需要IT工程师结合第一类日志综合判断。

Step2：通过PBS的配置我们将第二类日志输出。如果作业异常任务失败，那么我们可以通过第二类日志的提示信息将异常分为两类：

• 任务自身造成的异常：该类异常通常输出造成异常的原因。例如软件安装异常或者套件缺失问题：

此时IC工程师可以联系IT工程师进一步确认异常原因。IT工程师可以排查第一类日志中的 server_logs 和 accounting_logs 来初步确定异常原因，如果异常信息的异常码小于128，例如 Exit_status=127 ，那么就可以进一步的确认异常来源于作业本身。

针对这类问题，可以进入 Step4。

• 系统原因：人为/操作系统/调度器终止任务，例如：

此时IC工程师可以联系IT工程师进一步确认异常原因。IT工程师可以通过排查第一类日志，如果异常信息的异常码大于128，例如Exit_status=143，那么就可以进一步的确认异常来源于系统问题。

针对以上状况，可以进入Step3.

Step3: 如果是因为系统原因造成了任务终止，可能是因为计算节点资源过载造成，此时IT工程师可以根据资源的实际使用状况进行综合判断。在SOCA中的所有计算节点都会定时向 Amazon CloudWatch 提交metrics数据，在 Amazon CloudWatch 的控制台中可以看到相应的曲线。例如：

如果计算节点的资源使用率过高，有可能造成任务被终止。任务异常可以通过配置更多的计算资源来解决。

Step4: IC 工程师通过排查第三类“EDA工具日志”，定位设计中的错误，修改设计文件来解决异常。

总结

以上排查方案旨在解决半导体设计团队在开发过程中异常状况分析的难题。典型场景是前端设计的回归测试中部分任务失败，IC 工程师和 IT 工程师因为缺少对 EDA 堆栈的整体理解无法定位异常原因。通过以上排查流程，在缺少 CAD 团队的情况下 IT 和 IC 工程师可以通过协作，初步定位到设计过程中失败作业的的异常原因。如果您遇到相似问题，可以基于以上流程进行初步排查，同时，还可以根据自身需求扩展和定制化排查流程。此外，为具体化实际的排查流程，本文中以 SOCA 作为EDA 堆栈来进行举例，如果您对 SOCA 感兴趣，请参考：《SOCA帮助半导体企业快速启动EDA云上部署》。

本篇作者