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

    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（尤为是多人协做）的实际流程则复杂的多，开源工具类的则要更加注意软件组织架构规范和书写格式，以便于多人协同开发便利性。