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

原创
2019/01/09 16:23
阅读数 2.5K

     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信息,样子如下。

图二 qualiblibrary 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设计的核心原则在于:

  1.  通用性好(基于关键词解析会出现复杂度高,通用性差的问题,所以此处采用了基于文件结构解析的方式)。
  2.  解析速度快(需要通过内置逻辑调优来实现,最终测试测试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。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
2 收藏
2
分享
返回顶部
顶部