Inhouse-tool开发是IC-CAD工作的一个重要内容之一。在大型IC公司，由于设计工艺的先进性和设计逻辑的复杂性，IC设计流程中具有更多special的需求是通用EDA工具所不能覆盖的，这种情况下Inhouse-tool开发 的需求在所难免。据悉某超大型IC公司内部inhouse-tool开发部门的研发队伍就有近百人，堪以比肩中小型的EDA公司。
Inhouse-tool也区分难易程度，据可靠消息，某IC公司曾经组织过近十人的研发队伍尝试开发类似于Cadence liberate_mx类似的memory characterization工具，效果尤未可知，但是从代码量和逻辑复杂程度而言，这种inhouse-tool完全可以比拟EDA工具了。本文提到的inhouse-tool主要指那些逻辑功能和图形界面并不算过于复杂，单人可以完成的普通inhouse-tool开发示例（主要原因是我没有参加过大型inhouse-tool的开发，惭愧惭愧），这样的工具在企业内研应用中数量是最大的。
下图是一个普通inhouse-tool（带图形界面）的开发流程。
图一 inhouse-tool 开发流程
开发流程中需要注意的几个关键点如下。
1. 获取开发需求要不厌其烦，穷根问底，务求了解需求细节。
由于很多时候ICer本身只有一个相对模糊的需求，并且这个需求本身还可能是不确定的，变动的，如果不在一开始尽量了解需求细节，以及考虑到需求的变数以尽量做到功能兼容和扩展，开发出来以后再改动耗费的工作量极大。
如果需求来自多个ICer，则一定要大家统一需求，最好是大家能做到一起讨论一次，形成文字性的共识。
用户需求的最终方案最好留有文字性的说明，这样做的好处在于，如果后期用户告诉你他的需求稍微调整了一下（变成了一个完全不一样的需求），只需要更改一下代码就可以了（完全重新写一个工具才能实现），那么拿出他最初的需求文档来就让他带着滚（滚得越远越好）。
2. 代码书写要考虑到“可扩展性”，“可维护性”
“可扩展性”是指代码已于更改扩展。初始的需求一般来说都是很难做到绝对精确的，后续的需求改动和新需求增加也是很正常的，如果逻辑功能不考虑可扩展性，后面的任何改动都会举步维艰。所以需要尽量采用模块化开发思路，逻辑功能块要尽量小，顶层逻辑功能要采用插拔式设计，利于增加，删除和修改。
“可维护性”则涉及到代码风格，主要是为了后续维护方便，包括但不限于以下内容。
* 开发完成后要有基础文档，包括当初的需求来源，需求内容，顶层框架设计方案，模块组成，工具使用方式，使用效果，最好配上demo。
* 代码中关键部位要有注释说明，方便后面的人了解关键代码。
* 注意逻辑代码和图形代码分开，相互调用逻辑清晰。
* 注意代码编写风格务求清晰易读（尽量避免晦涩的写法），注意缩进和变量命名规范，注意代码复用。
3. 注意可测试性
为了保证开发的工具能够满足需求，最好在设计之初就考虑好测试场景和测试项目，开发过程中完成相关功能即可展开测试，以保证每一部分代码都干净可靠。
上面说的很抽象，下面以一个真实的inhouse-tool开发流程来做一下说明。
需求
华大九天有一款EDA工具叫qualib，能够查看liberty格式的library文件中单个cell的timing/internal_power信息，样子如下。
图二 qualib library cell timing信息图形化展示
我司ICer提出了一个需求，需要图形化对比不同cell的timing/internal_power信息。我们咨询了华大九天的AE“qualib是否能够实现这个功能”，答“不能”。于是我们只好自己开发。
我同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仅提取一个值，然后绘制二位变化曲线。
实际上工具开发完成后，又接收到了新的需求。
1. 当显示单个cell的timing, inter_power的时候，可以选择显示整个表格为三维网状图，也可以进选择表格中的一行或者一列绘制一个二位曲线。
顶层框架设计
有了需求，我们开始设计工作。
第一步，嗯，不是顶层框架设计，是起名字，我给这个工具起名字叫做cellCompare，意思是用来做cell compare的，因为最开始的需求就是多个cell数据的图形化比较。
下一步才是设计顶层框架。
工具使用的逻辑流程如下。
读取library file（图形界面） >>> 解析library file >>> 选取cell（图形界面） >>> 选取约束选项（图形界面） >>> 从library数据中抽取约束所圈定的数据 >>> 信息展示（图形界面）
主要代码部分分为逻辑和图形两部分。
逻辑部分包括：
* library parser，抽取library数据并存储到一定的数据结构。
* 从数据结构中抽取可用的约束条件（并以参数选项的形式展示在图形界面中）。
* 根据约束条件从数据结构中提取数据。
图形部分包括：
* 整体图形设计（用笔在草纸上画就行，样子最好让ICer确认，不然他们嫌样子丑也是不会用这个工具的）。
图三 整体图形设计
* 图形细节设计及实现函数选型。
比如，cell列表采用层级复选框，超长列表则带横向和纵向滚动条。
约束条件部分采用下拉菜单。
数据展示部分采用表格。
图表展示部分采用二维/三维图像直接填充。
* 图形和逻辑功能的映射关系。
定义所有的映射关系，比如图形界面中加载library file则自动执行parser进行解析，并存储为一定的数据结构。
选中左侧边栏的cell后，根据数据结构读取到相应tab所有的约束条件可选值，并自动更新图形界面的下拉菜单选项。
选择下拉菜单选项后，自动更新下面数据表格和图表部分。
逻辑部分
逻辑部分分为两大块，library parser和cellCompare的逻辑功能。
library parser
第一部分为library parser，这个功能相对独立，就是解析liberty格式的library file，提取相关信息并保存为一定的数据结构。
本着尽量不自己造轮子，尽量复用的 观点，我们首先从网上找开源的parser，还真找到了一个（我们开发用python，github上找到了一个开源的python的liberty parser “lib_parser”），然后套到我们TSMC 7 nm的library file上一试，parser crash了，这就是代码设计不健壮的一个反面典型啊。没办法，我只能自己造一个轮子，而且应该是个好用并且健壮的轮子。
我们设计的library parser ... ... 此处省略652行
cellCompare逻辑功能
考虑到这个inhouse-tool的整体代码量不大（最总代码量不到2000行），逻辑功能和图形界面联系比较紧密，并没有大量的独立逻辑代码，所以我们直接把逻辑代码和图形代码放到一个文件中，以类内函数的形式散立存在。（如果整体代码量大，逻辑代码相对独立，最好是把逻辑代码单独拆分到独立文件中，至少是独立的类/函数中，更加容易维护）
对于示例中这种逻辑代码不独立的情况，开发过程中不是独立开发逻辑代码，而是在书写图形代码的时候，在写到逻辑调用关系的时候再书写逻辑代码，这样可以完成一个模块就测试一个模块。
对于复杂逻辑一定要提前想清楚再写，多花点时间在思考上一定比多花时间在修改上省力气，此处坑很多，不多说了。
图形部分
我们采用python的pyqt库进行图形功能开发，简单易用容易上手。
图形整体框架需要提前想好（手绘即可），然后向搭积木一样先把整体框架搭好，然后往里面填内容。分为三部曲：
1. 搭整体框架，看看样式对不对，有没有数据展示块的遗漏。
2. 填充细节，往里面填充标签，文本行，复选框，下拉菜单，按钮，表格，图表...
3. 书写图形调用逻辑的调用关系。
具体内容 ... ... 此处省略1700行
功能测试和用户确认
开发完成后首先要自己测试能否完成预定的需求。
需要自己设计测试用例，简单的测试而言一般需要关注以下两类：
1. 常用情况测试。
测试常用功能正常操作的情况。
测试常用的规范的输入文件。
2. corner case的测试
测试不常用功能，遍历所有的图形操作组合（甚至是乱点也可以），保证各种异常操作都能返回准确的反馈信息，不能crash。
测试不常用的不规范的输入文件。
自己确认inhourse-tool基本功能无误，能够满足最初需求后，需要书写较为详细的使用发发说明，提通使用demo，请需求方ICer试用并提出反馈意见，及时更改误解需求，及时添加新增需求（时间长了再改说不定就看不懂代码啦）。
一般来说开发完成后的修改是在所难免的，所以自我测试和用户试用反馈也是一个迭代的过程。
效果展示
cellCompare完成后效果如下。
展示单个cell信息，其中三维图形可以拖拽和旋转，便于查看数据单调性和变化趋势。
图四 单个cell timing数据三位网状图展示
多个cell数据对比展示。
图五 多个cell timing数据二位曲线展示
本文仅作为一个简单（单人）开发流程的示例，复杂inhouse-tool（尤其是多人协作）的实际流程则复杂的多，开源工具类的则要更加注意软件组织架构规范和书写格式，以便于多人协同开发便利性。
1497
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
