IC-CAD Methodology 企业实战之 inhouse-tool 开发示例

Inhouse-tool 开发是 IC-CAD 岗位的重要工作内容之一。在大型 IC 公司，由于设计工艺的先进性和设计逻辑的复杂性日益增加，不同类型 IC 产品本身的差异化需求很难完全被通用 EDA 工具所覆盖，这种情况下，满足 special 需求的 Inhouse-tool 开发工作势在必行。据悉某超大型 IC 公司内部 inhouse-tool 开发部门的研发队伍就有近百人，堪以比肩中小型的 EDA 公司。

Inhouse-tool 根据应用场景不同，其开发规模差异也很大。小到基于 python 的几百行代码的流程工具，大到基于 c++ 的几万行代码的复杂仿真系统，都属于这个领域范畴。本文提到的 inhouse-tool 主要指那些逻辑功能和图形界面并不算过于复杂、代码量一般在万行以内、单人即可完成的、中小型定制化 IC 工具（更大型的，有的公司也称为 inhouse-eda），这样的工具在企业内需中数量是最大的。

下图是一个简要的 inhouse-tool（带图形界面）迭代开发流程。

图一 inhouse-tool 迭代开发流程

开发过程中需要特别注意如下几点。

1. 获取开发需求要不厌其烦，穷根问底，务求了解细节

IC 企业中 CAD 岗位最饱受诟病的地方之一在于，肩负着工具开发的重任，但是很多人不是 designer 出身，并不是那么精通实际的业务需求细节。软件开发的思维局限在于，依据 spec 做开发，spec 的详尽程度决定了工具最终产出的细节表现，而 ICer 大多是需求导向型，往往只会描述当前一个简略的工具需求，而这个需求本身往往还是不那么确定的，随着时间的变化而不断变化的，spec 更是多为粗鄙的功能性描述，缺乏细节，更缺乏前瞻性的需求考虑。所以如果工具开发者不在一开始就尽量了解需求细节，考虑到需求的变数以尽量做到功能兼容和扩展，开发出来以后再改动耗费的工作量极大，其工具的易用性也很难保证。

如果需求来自多个 ICer，则问题更加复杂，因为即便大的需求场景一致，每个人小的需求细节也很可能存在差异，但是并不是每个人都会在一开始就明确地指出这些差异性。这种情况下，一定要大家统一需求，最好是大家能做到一起讨论多次，直到形成文字性的共识为止。

用户需求的最终方案需要留有文字性的说明，这样做的好处在于，如果后期用户告诉你他的需求稍微调整了一下（变成了一个完全不一样的需求），只需要更改一下代码就可以了（完全重新写一个工具才能实现），那么拿出他最初的需求文档来让他看（滚）。

2. 代码书写要考虑到 “可扩展性” 和 “可维护性”

“可扩展性” 是指代码考虑到功能增加的可能性，要易于修改。初始的需求一般来说都是很难做到绝对精确的，后续的功能改动和新功能增加也是很正常的，如果逻辑功能不考虑可扩展性，后面的任何改动都会举步维艰。所以需要尽量采用模块化开发思路，每个逻辑功能块要尽量小，顶层逻辑功能要采用插拔式设计，利于增加，删除和修改。

“可维护性” 则涉及到代码风格，主要是为了后续维护方便，包括但不限于以下内容。

* 开发完成后要有工具文档，包括当初的需求来源、具体需求细节、顶层框架设计方案、底层模块组成、工具使用方式最好，最好配上一个 demo 方便演示基础功能。

* 代码中关键部位要有注释说明，方便后面维护的人了解关键代码逻辑。

* 注意逻辑代码和图形代码分开，相互调用逻辑清晰。

* 注意代码编写风格务求清晰易读（尽量避免晦涩的写法），注意缩进和变量命名规范，注意代码复用。

3. 注意可测试性

为了保证开发的工具能够满足需求，最好在设计之初就考虑好测试场景和测试项目，开发过程中完成相关功能即可展开测试，以保证每一部分代码都干净可靠。

上面说的有些抽象，下面以一个真实的 inhouse-tool 开发流程来做一下说明。

需求

华大九天有一款 EDA 工具叫 qualib，能够查看 timing lib 文件中单个 cell 的 timing/internal_power 信息，样子如下。

图二 qualib 中 library cell timing 信息展示

后来有 ICer 提出了一个需求，需要图形化对比不同 cell 的 timing/internal_power 信息。在咨询了华大九天的 AE 之后得知，qualib 没有这个功能，而且其中有些需求细节比较 special（同类型 cell 数据对比），所以短期内不会增加这个功能，所以我就自己写一个 inhouse-tool 来满足 ICer 这个需求。

在同 ICer 反复沟通之后，书面需求确定如下。

1. 查看一个 cell 的 area, leakage_power, timing, internal_power 的信息。

2. 查看同类型 cell 的 area, leakage_power, timing, internal_power 变化趋势。

每个 cell 只有一个 area 值，绘制一个 cell-area 的二维曲线很简单。但是每个 cell 有多个 leakage_power 值，有多个 timing，internal_power 表，而每个表里都有多个值，这种情况则需要通过提供一些列约束条件（pin/related_pin/related_pg_pin .../index_1/index2 等）来限定每个 cell 仅提取一个同位有效值，然后基于这个值绘制 value 变化曲线。

实际上工具开发完成后，又接收到了新的需求（这种坑永远不可能一开始就填上，因为新的需求总是在工具使用过程中不断产生）。

3. 当显示单个 cell 的 timing, inter_power 的时候，可以选择整个表格以显示为三维网状图，也可以进选择表格中的一行或者一列绘制一个二维曲线。

顶层框架设计

有了需求，我们开始设计工作。

第一步，嗯，还不是顶层框架设计，是起名字，我给这个工具起名字叫做 libView，意思是用来做 timing lib 文件的信息 view 之意。

下一步是设计顶层框架。

工具的逻辑流程如下。

读取 library file（图形界面） >>> 解析 library file >>> 选取 cell（图形界面） >>> 选取约束选项（图形界面） >>> 从 library 数据中抽取约束所圈定的数据 >>> 信息展示（图形界面）

主要代码部分为逻辑和图形两部分。

逻辑部分包括：

* library parser，抽取 library 数据并存储到一定的数据结构。

* 从数据结构中抽取可用的约束条件（并以参数选项的形式展示在图形界面中）。

* 根据约束条件从数据结构中提取数据。

图形部分包括：

* 整体图形设计（用笔在草纸上画就行，最终样子最好提前跟 ICer 一起确认）。

图三整体图形设计

* 图形细节设计及实现函数选型。

比如，cell 列表采用层级复选框，超长列表则带横向和纵向滚动条。

约束条件部分采用下拉菜单。

数据展示部分采用表格。

图表展示部分采用二维 / 三维图像直接填充。

* 图形和逻辑功能的映射关系。

定义所有的映射关系，比如图形界面中加载 library file 则自动执行 parser 进行解析，并存储为一定的数据结构。

选中左侧边栏的 cell 后，根据数据结构读取到相应 tab 所有的约束条件可选值，并自动更新图形界面的下拉菜单选项。

选择下拉菜单选项后，自动更新下面数据表格和图表部分。

逻辑部分

逻辑部分的实现分为两大块，library parser 和 library view 逻辑。

library parser

第一部分为 library parser，这个功能相对独立，就是解析 liberty 格式的 library file，提取相关信息并保存为一定的数据结构。

github 上找到了一个基于 python 的开源 liberty parser “lib_parser”，但是套到 TSMC 7 nm 的 library file 上一试，parser crash 了，这就是代码设计不健壮的一个反面典型啊。没办法，只能自己造一个轮子。

Parser 设计的核心原则在于：

通用性好（基于关键词解析会出现复杂度高，通用性差的问题，所以此处采用了基于文件结构解析的方式）。
解析速度快（需要通过内置逻辑调优来实现，最终测试测试 700 万行的 lib 文件，解析速度仅为 28 秒左右）

这部分被单独开源出来作为 library 类工具的基础组件。（详情参见 https://github.com/liyanqing1987/libertyParser）

Library view 逻辑

考虑到这个 inhouse-tool 的整体代码量不大（最总代码量不到 2000 行），逻辑功能和图形界面联系比较紧密，并没有大量的独立逻辑代码，所以我们直接把逻辑代码和图形代码放到一个文件中，以类内函数的形式散立存在。（如果整体代码量大，逻辑代码相对独立，最好是把逻辑代码单独拆分到独立文件中，至少是独立的类 / 函数中，更加容易维护）

对于示例中这种逻辑代码不独立的情况，开发过程中不是独立开发逻辑代码，而是在书写图形代码的时候，在写到逻辑调用关系的时候再书写逻辑代码，这样可以完成一个模块就测试一个模块。

对于复杂逻辑一定要提前想清楚再写，多花点时间在思考上一定比多花时间在修改上省力气，此处坑很多。

图形部分

我们采用 python 的 pyqt5 库进行图形功能开发，简单易用容易上手。

图形整体框架需要提前想好（手绘即可），然后向搭积木一样先把整体框架搭好，然后往里面填内容。分为三部曲：

1. 搭整体框架，看看样式对不对，有没有数据展示块的遗漏。

2. 填充细节，往里面填充标签，文本行，复选框，下拉菜单，按钮，表格，图表...

3. 书写图形调用逻辑的调用关系。

功能测试和用户确认

开发完成后首先要自己测试能否完成预定的需求。

需要自己设计测试用例，简单的测试而言一般需要关注以下两类：

1. 常用情况测试。

测试常用功能正常操作的情况。

测试常用的规范的输入文件。

2. corner case 的测试

测试不常用功能，遍历所有的图形操作组合（在图形逻辑不太复杂的情况下），保证各种异常操作都能返回准确的反馈信息，不能 crash。

测试不常用的不规范的输入文件。

自己确认 inhourse-tool 基本功能无误，能够满足最初需求后，需要书写较为详细的使用方法说明，提供使用 demo，请需求方 ICer 试用并提出反馈意见，及时更改误解需求，及时添加新增需求。

一般来说开发完成后的修改是在所难免的，所以自我测试和用户试用反馈也是迭代过程的一部分。

效果展示

libView 完成后效果如下。

展示单个 cell 信息，其中三维图形可以拖拽和旋转，便于查看数据单调性和变化趋势。

图四单个 cell timing 数据三维图形

展示同类型 cell 的数据变化趋势图。

图五同类型 cell timing 数据变化趋势

本文仅作为一个简单 inhouse-tool 开发流程的示例，复杂 inhouse-eda 的实际流程则复杂的多，需要多人协同工作，而开源工具类的则要更加注意软件组织架构规范和书写格式，要求又要复杂得多。

文中示例项目代码请参照 https://github.com/liyanqing1987/libView。