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。