Skill脚本定制 三步搞定IC设计自动化痛点
我测过IC617版本，在Skill脚本定制时，遭遇过函数找不到路径的情况，也碰到过语法报错但却没有提示的麻烦。
定制前先把路径写对
不少刚开始接触的新手一开始就着手去写脚本，以至于出现load报错提示函数未被定义。实际上大概百分之八十是由于未曾将脚本放置到恰当的加载路径。在CIW窗口当中输入getSkillPath()，先去查看一下系统当下的搜索路径列表。我养成了一种习惯，会将自定义脚本都一块仍到~/.cadence/这个地方，接着是在.cdsinit里，亲自附加这一行内容：还有的是setSkillPath(append1（，需要把getSkillPath()进行调用，还要加上 “~/.cadence/”）)，然后才会是这样。
有新手避坑的情况，存在常见的报错表现为, Error load: can’t access file – “xxx.il”，其原因在于路径并未被注册进入Skill解释器的搜索列表里，解决的办法是，先要去确认文件是真实存在的，之后还要去检查.cdsinit里路径字符串有没有写错反斜杠或者遗漏了引号。
函数封装与参数最优推荐值
成就一个可运行的通用类型脚本，重点在于封装，像要做出一个自动打孔对齐脚本，其核心函数起码得接纳三个参数，分别是目标 cellView ID，孔类型字符串，对齐基准坐标。最优推荐数值是将孔间距设定为 0.5 微米，此数值在多数 0.18um 工艺情况下，既能确保 DRC 干净，又不会因过密导致版图编辑器出现卡顿现象。过密 （0.3 以下）易于出现 Via 间距违例情况，过疏 （0.8 以上）则会造成面积浪费。
关于新手需要避开的坑，存在这样一种常见的报错情况。报错内容为, Error getGetName，冒号后面说，参数一号应该是一个列表或者符号。而之所以出现这个报错，原因在于你把字符串传递给了那种本应该传递列表的参数。应对方式：一开始去查验 geGetEditCellView() 所返回的究竟是不是 nil，要是是 nil 则表明你未曾选中任何的版图窗口，如此一来脚本自然而然地就找寻不到目标了。
两种定制方案对比与取舍
达成同一个自动化功能, Skill脚本存在两种主流写法，一种是纯函数式，另一种是面向对象式。
适合20行以内简单任务诸如批量改Label大小的纯函数式是这样，直接定义全局函数，参数全部手动去传，写完直接load运行，调试速度快。然而其存在缺点，一旦逻辑变得复杂起来，全局变量到处都是，容易相互覆盖。
在面向对象的方式当中，会运用defstruct或者class这个机制，它是适合那种超过50 Lines的复杂流程的，就像全自动版图生成脚本这种情况。它会将数据封装在对象内部，并且让方法之间彼此相互隔离，这样一来后期维护所需要的成本比较低。不过它存在的代价就是学习曲线比较陡峭，新手在使用的时候会搞不清楚self->；以及 =>；的具体用法。
若是你仅临时使用一回的那个小点的脚本，那就选择纯函数式的便可，能节省时间。要是属于团队里需要长时间去维护的工具，那就坚决采用面向对象式的，哪怕在前期的时候多写上两行关于结构的代码，后续更改需求时你会回过头来感激这种的决定的。
【新手避坑】：常见出现的报错情况为: Error, Error之后是undefined function这一情况，具体为 – dbCreateInstance。其核心导致原因成为：你是以直接的方式去调用了db层对应的函数，然而在脚本里面却忘记了去加载db库。解决手段是：在脚本起始之处添一行loadContext(“db”)，又或者直接在CIW里先运行一回dbCreateInstance以使系统自行加载。采用高频完整报错一次解决办法：要是出现报错Error leHiCreateInstance: argument #1 should be a list – nil情况，先先去确认版图窗口是不是处于激活状态，接着再去检查geGetEditCellView()是否返回的值为nil，最后再去查看是不是由于没有关掉其他菜单命令从而导致冲突，按照这样的顺序去做排查工作, 95%的情况都能够得到解决。
交代完这几个实操的套路之后，要留意这个方法主要是面向交互式手工改版图的情况。要是你正在做纯批处理、并无GUI环境的数据流脚本，上面的geGetEditCellView这类函数就会直接报错。替代的方案是运用dbOpenCellViewByType直接开启库文件操作，接着将结果写入日志文件里，无需打开版图编辑器。
