开篇先交代个背景。我平时的工作里SKILL脚本写得不算少但大多是“一次性脚本”——跑完验证流程就搁那儿了时间一长自己都看不懂当初那个函数里为什么要多写几个哨兵条件。更麻烦的是每次在Cadence Virtuoso环境里调试SKILL都是开一个CIW窗口一行一行地往里面贴代码跑通了就算完事跑不通就打断点加printf反复试错。这种工作流在脚本规模小的时候还凑合一旦逻辑复杂起来涉及到多个cellview遍历、层次化设计规则的检查、参数化单元的参数更新代码就会迅速膨胀成一大坨难以维护的“面条代码”。这次我决定对SKILL的开发方式做一次全新尝试先搭一个相对固定的“框架层”把通用的初始化、错误处理、日志输出、环境检查这些“套路”全部沉淀到统一的入口再用“细节层”把具体业务逻辑拆成一个小函数对应一个小动作最后用一份完整的测试项目文档把整个脚本的功能边界、函数接口、测试覆盖范围全部记录下来。整个过程跑下来最大的感受就是以前是“写完代码再想它干了什么”现在是“先想清楚框架怎么承载细节再把每个细节填进去”。这篇文章就把这次尝试的完整过程、踩过的坑、验证的结果都写出来给同样在EDA脚本开发里摸爬滚打的朋友一个参考。1. 传统SKILL脚本的问题为什么这次非改不可1.1 函数堆叠式开发的真实痛点先说我以前写SKILL的常态。需求来了比如“检查当前Library里所有testbench cellview的pin连接关系把悬空pin报出来”我的写法通常是打开CIW在里面临时定义几个procedure然后直接在命令行里执行。代码结构大概是这样procedure(checkPins(libName) let((cvList cv pinList) cvList ddGetObj(libName) foreach(cv cvList when(cv~lib~name libName foreach(pin cv~terminals ; 一堆检查逻辑 ) ) ) ) )这种写法在功能上没问题跑完也确实能出结果但有几个很现实的问题第一个问题是环境依赖隐式化。这个函数里用到的ddGetObj、dbOpenCellViewByType这类API隐含了整个数据库连接环境、library路径配置、display resource文件加载等前置条件。如果换一台机器跑或者库文件路径没配好脚本可能报一堆莫名其妙的错误但你永远不知道是环境问题还是代码问题。第二个问题是函数之间没有清晰的边界。真实场景下一个检查流程往往要拆成“遍历cellview—获取pin信息—分析连接关系—生成报告—高亮异常”五个步骤。如果这五个步骤硬塞在一个procedure里那这个procedure会变得巨长无比变量作用域也乱后面想复用其中某一步的逻辑基本只能复制粘贴。第三个问题也是我最头疼的是可验证性几乎为零。没有文档、没有测试用例、没有统一的输出去向脚本跑到一半出了错只能靠眼睛盯着CIW里的提示信息去猜。万一某个函数在特定条件下会触发空指针之类的错误可能得在数据上反复尝试才能撞见。1.2 项目文档为什么是框架化的一环这次我之所以把“编写测试项目文档”作为整个验证方式的载体不是因为文档本身有多大价值而是文档逼着我去梳理框架设计。在动手写文档之前我被迫先回答这些问题这个脚本项目要对谁负责输入是什么输出是什么终止条件是什么哪些操作是通用的应该放进框架层哪些逻辑是本次任务特有的应该放进细节层错误分几种类型每种类型对应什么处理策略测试怎么组织拿到一个什么样的结果才算“验证通过”这些问题如果不落到纸面上最后肯定会被“先跑起来再说”的心态带偏。所以我把“编写测试项目文档”放在整个流程的第一位文档不是事后补充说明而是驱动设计的前置动作。框架搭好之后每个细节函数的职责、入参、返回值和异常行为都清晰列在文档里代码只是把这些描述翻译成SKILL语法。2. 框架细节方式的整体设计先把“骨架”立起来2.1 框架层到底装哪些东西所谓“框架”在我的这次实践里并不是要引入某个现成的第三方开发框架——SKILL本身也没有那种东西。这里的框架是指我自己定义的一套固定套路和公共组件让每个具体的脚本项目都能在这套骨架上生长。整个框架按职责可以分成四层层级职责包含内容入口层统一入口、参数解析、环境准备top-level procedure读取命令行参数或表单输入调用初始化模块公共服务层与业务无关的通用能力日志输出、错误捕获、定时器、文件读写辅助函数业务逻辑层具体任务的执行单元遍历cellview、检查pin、生成报告、高亮异常等函数数据层配置和数据的统一访问配置文件解析、常量定义、路径映射表入口层比较好理解就是项目跑起来的起点。比如我的脚本入口设计成一个主函数procedure(PCBTestMain(key libName cellName ruleFile outFile) let((initOk) initOk pcbInit(logFile outFile verbosity 2) when(initOk pcbRunChecks(libName cellName ruleFile) pcbFinish() ) ) )pcbInit、pcbRunChecks、pcbFinish这三个函数就是框架的一部分它们具体做什么看名字大概能猜出来。入口函数本身不处理任何业务细节它只负责“启动—执行—收尾”的生命周期管理。这样设计的好处是不管底层的业务逻辑怎么变入口永远稳定CTRLL加载脚本之后敲入的调用命令永远是一致的。公共服务层是框架的重点。我在这次实践中写了几个常用工具函数比如procedure(picoLog(msg key level) let((timeStr logLine) timeStr timeToString(getCurrentTime()) logLine strcat(timeStr [ level ] msg) when(boundp(picoLogPort) picoLogPort fprintf(picoLogPort %s\n logLine) ) printf(%s\n logLine) ) )这个函数承担了所有日志输出的职责业务函数里一律不直接使用printf而是统一调用picoLog。这样做的好处是日志的格式、去向、分级策略都集中在一个地方管理。测试的时候可以把日志写到文件生产运行的时候可以只打印ERROR级别改起来只动一个函数。业务逻辑层是“细节”的所在地。这里我给自己立了个规矩一个函数只做一件小事。比如“遍历某个library下所有cellview”是一个函数“读取某个cellview的pin列表”是另一个函数“判断某个pin是否悬空”又是一个函数。函数之间通过参数传值不共享全局变量这样每个函数都能单独拎出来做单元测试。数据层相对简单就是把所有可配置的参数比如检查规则里的最小线宽、pin命名前缀约定、需要排除的cellview名称列表集中放到一个配置文件里脚本启动时一次性加载。这样业务代码里就不会散落一堆魔法数字了。2.2 细节层怎么和框架咬合框架和细节之间不是“两层皮”它们需要通过明确的接口约定咬合在一起。我总结出了三个关键的咬合点第一个咬合点是错误处理策略。框架定义了错误怎么被捕获、怎么被记录、怎么向上传递业务函数只需要抛出正确的错误级别即可。我定义了一个简单的规则procedure(picoAssert(condition msg) when(!condition picoLog(sprintf(nil %s msg) level ERROR) error(Assertion failed: %s msg) ) )比如在检查pin的时候如果发现某个pin的类型既不是input也不是output也不是inout那就属于数据异常业务函数直接调用picoAssert失败退出。而如果只是发现某个pin悬空那属于设计问题只需要记一条WARNING让检查流程继续跑完。第二个咬合点是数据结构约定。框架推荐用SKILL里最通用的list结构来传递数据但在特殊场景下也会用到table关联数组。我在文档里明确规定业务函数返回数据时如果是一个集合统一用list如果是键值对映射统一用table禁止在不同函数之间传db对象的裸指针——除非函数名字里明确标明它接收db对象。这个约定看起来很小但在实际协作和调试时减少了大量“这个函数到底返回什么东西”的困惑。第三个咬合点是命名规范。框架层函数统一加pico前缀取自项目代号PICO-Test业务层函数统一加业务缩写前缀。这样在CIW里输入函数名补全的时候一眼就能看出哪些是框架函数、哪些是本次业务的定制函数。命名规范还延伸到局部变量临时变量用tmp开头标志位变量用flag开头错误码用err开头。这些细节单独看都不起眼但当函数数量超过二十个时命名就是维持秩序的核心工具。2.3 什么是“细节方式”的落地标准在传统写法和框架细节写法之间判断标准就一句话把代码里的每一个隐含假设都显式化。举个例子。以前我写一个获取cellview pin列表的函数可能直接写cv~terminals就完事儿了。但“细节方式”要求我多问自己几个问题cv会不会是nil如果是说明cellview打开失败这是一个错误还是可以跳过terminals成员是否需要区分term~name和term~net两者都有可能为nil吗是否要过滤掉特定类型的terminal比如power类型这些问题在“一次性脚本”模式下根本不会有人问因为它跑一次就完了遇到异常直接从报错信息里看。但一旦要写成可复用的测试工具这些边界情况就必须在函数里显式处理。我在每个业务函数里都加入了参数合法性检查、空值保护、类型守卫并在注释里写清函数的输入输出契约。这个“显式化”的过程就是细节方式的落地标准。3. 测试项目文档的编写实录从“脚本说明”到“设计契约”3.1 文档结构怎么规划这次编写的测试项目文档我最终定的目录结构是这样的1. 项目概述 1.1 项目背景 1.2 目标与范围 1.3 术语定义 2. 总体设计 2.1 框架结构 2.2 文件清单 2.3 执行流程 3. 函数接口说明 3.1 入口函数 3.2 框架公共函数 3.3 业务细节函数 4. 配置说明 4.1 配置文件格式 4.2 规则项详解 5. 测试计划与用例设计 5.1 测试环境 5.2 功能测试用例 5.3 异常测试用例 5.4 边界测试用例 6. 验证记录 6.1 用例执行结果 6.2 缺陷记录与修复 7. 附录 7.1 已知限制 7.2 后续扩展方向和普通的脚本文档不同这份文档里的“函数接口说明”不只是一张函数名列表而是每个函数都要写清楚功能描述、输入参数及类型、返回值及类型、异常行为、依赖关系、调用示例。写这份文档的工作量确实比单纯写脚本要大但回报也立竿见影——后续写代码的时候我基本上是在“翻译”文档里的描述而不是临场发挥。3.2 文档里最有价值的部分函数接口契约以我这次做的“PCB Pin连接关系检查”测试项目为例文档里对核心函数是这样描述的函数名: pcbGetAllPins 功能: 获取指定cellview中所有terminal的pin信息 输入: - cv: 已打开的cellview对象 输出: - 成功: list类型每个元素为table包含name、direction、netName、isFloating四个字段 - 失败: nil并将错误信息写入日志 异常行为: - 当cv为nil时记录ERROR日志返回nil - 当cellview中不存在terminal时记录WARNING日志返回空list - 当terminal的direction字段无法识别时记录WARNING并跳过该terminal 依赖: - 需要已初始化数据层能够正确解析cellview路径 - 调用picoLog输出日志信息 调用示例: let((pins) pins pcbGetAllPins(cv) foreach(pin pins printf(pin name: %s, net: %s\n pin-name pin-netName) ) )写完这段接口契约之后再动手写函数思路会变得前所未有的清晰。我不需要再在写代码的时候犹豫“这个参数要是nil怎么办”“这个成员访问不了怎么处理”——这些决策在文档阶段已经做完了代码阶段只是机械地把它们翻译成SKILL语法。3.3 测试用例怎么设计才有验证价值文档里测试用例的设计是我这次最满意的部分。过去我测试SKILL脚本基本是靠“拿真实数据跑一遍”跑完没报错就当通过。这次我改成“分层测试法”第一层是单元测试。针对每个核心业务函数构造最小化的输入数据验证输出的正确性。比如pcbGetAllPins函数我不直接去打开一个大的设计库而是先手工创建一个只包含一个cellview、两个pin的测试库然后跑函数看返回的list是否符合预期。这种小数据量测试跑起来非常快而且定位问题特别精准——哪一步错了马上就能从函数内部日志看出来。第二层是集成测试。用一个中等规模的实际设计库跑完整的检查流程验证各个函数之间的配合是否正确。这一层主要暴露接口对接问题比如某个函数返回的list格式和另一个函数期望的输入不一致。第三层是异常场景测试。故意构造一些异常情况比如打开一个不存在的cellview、传入一个被锁定的db对象、配置文件包错误类型数据等验证脚本是否能按文档里承诺的方式处理这些异常。一个具体的用例表格长这样用例编号用例类型输入描述预期结果实际结果状态TC-001单元测试空cellview无terminal返回空list记录WARNING返回空list记录WARNING通过TC-002单元测试cellview包含3个pin其中1个悬空返回3个元素的list悬空pin的isFloating为t结果一致通过TC-003异常测试传入nil的cellview对象记录ERROR日志返回nil记录ERROR日志返回nil通过TC-004集成测试中等规模library跨cellview检查正确识别所有悬空pin并写入报告报告与实际检查一致通过表格看起来简单但当我真正按这个表格逐条执行、逐条填写“实际结果”的时候才发现有些函数的行为和我设计的并不完全一致。比如TC-002里我本以为悬空pin的判断逻辑只检查term~net是否存在结果发现有些pin的net是一个“全局信号”特殊对象也需要算作有效连接。这个例外情况在文档阶段没有捕获到是写测试用例的时候才意识到“悬空”的定义需要更细化。4. 实际跑通的关键细节配置、入口、日志和断言的取舍4.1 配置文件的组织方式别在代码里藏魔法数前面框架设计里提到数据层负责管理配置。这次我用的配置文件格式是简单的键值对加段落标记格式长这样[library] libName PCB_Test_Lib cellName test_top [check] minPinCount 2 ignorePins VSS,VDD allowFloatingGlobal t [output] reportFile ./report/pin_check_report.txt logLevel INFO解析这个配置文件的函数是框架层提供的picoParseConfig它会把文件内容读进来返回一个table业务函数只需要用configTable[check]-minPinCount这种形式取值。为什么坚持用配置文件而不是常数定义因为很多SKILL脚本最后是要交给别的工程师用的。如果我硬编码一个minPinCount 2使用的人为了改成3就必须去翻我的源代码。而配置文件的方式他们只需要在配置里改一行。更关键的是配置文件和代码分离之后代码的通用性大幅提升同一个检查脚本换个配置文件就能针对不同设计规范做检查。这个收益在第二次复用脚本的时候就能明显感觉到。4.2 入口的生命周期管理init、run、finish缺一不可入口层的三个动作是有讲究的。init阶段负责做所有“前置检查”和“资源申请”我在测试项目里pcbInit做了这几件事读取配置文件并解析解析失败则返回nil终止后续流程检查输出目录是否存在不存在则创建打开日志文件准备日志流检查指定的library和cellview是否存在如果不存在记录FATAL级别的错误并返回nilrun阶段负责真正的业务执行通过传入的libName和cellName调用业务函数。这一阶段本身不需要处理异常因为它只管“执行”异常统一被框架的全局错误处理器接住。finish阶段负责资源回收和收尾汇报。关闭日志文件输出汇总信息处理的cellview数量、发现的悬空pin数量、耗时等最后把关键统计信息写进报告文件。特别想提一下finish阶段的重要性。很多脚本开发者在“跑完了”之后根本不关心资源回收的问题。但SKILL脚本跑在Virtuoso环境里如果脚本打开了大量cellview但没有关闭长时间运行会占用大量内存严重时会让整个EDA工具越来越卡。我在文档里把“所有打开过的db对象必须在函数退出前显式关闭”写成了一条强制约束并且让finish函数遍历一个全局的“打开对象登记表”发现有未关闭的对象就自动补关并输出WARNING。4.3 错误处理策略什么时候该停什么时候该继续这个话题值得单独展开。我以前的脚本很大一个毛病是“一错到底”某个cellview遇到问题脚本可能直接崩了后面的cellview全都不会检查。后来我明白了错误处理必须先分类FATAL级别整个脚本无法继续执行的环境级错误比如配置文件打不开、library不存在。遇到这种错误立即终止。ERROR级别某个输入数据有误导致某个子任务无法完成但其他子任务还可以继续。比如某个cellview无法打开那就跳过这个cellview继续检查其他cellview但最后报告中要明确标注有多少个cellview因错误被跳过。WARNING级别发现设计上值得关注的问题但流程可以正常走完。比如悬空pin、命名不符合规范等。INFO级别正常的信息记录比如当前正在检查哪个cellview。这个分级策略在框架层统一实现在业务函数里只需要按照实际情况调用对应级别的日志函数或者触发对应的断言。这样“哪儿出错了、错得多严重、该不该停”全都有章可循。测试项目文档里也对每个级别的处理方式做了明确说明避免使用脚本的人看到一条ERROR日志就慌慌张张来问“是不是脚本坏了”。5. 验证过程的真实记录哪些坑是文档驱动开发帮我躲过的这里写几个这次实践里遇到的具体问题以及它们是怎么被提前发现或快速定位的。5.1 配置解析的bug引号处理第一个问题出现在picoParseConfig函数里。配置文件里所有的字符串值都写成带双引号的形式比如libName PCB_Test_Lib。我最初的解析逻辑很简单按号分割取右侧并去掉首尾空白。结果跑单测的时候就发现解析出来的值变成了PCB_Test_Lib带引号——这在SKILL里会引起后续字符串匹配失败。这个问题如果在以前的一次性脚本模式里大概率要等到实际跑库的时候才暴露到时候查错方向可能是“为什么library名字对不上”完全不会想到是配置文件解析时引号没剥干净。但有了单元测试我在十分钟内就发现了问题并修复。修复后的解析逻辑是先检查值首尾是否都是双引号如果是剥掉后再存进table。这让我更加确信“单元测试文档化”这套组合的威力。5.2 cellview锁定带来的隐蔽失败第二个问题更隐蔽。测试数据里有一个cellview是处于“只读”状态的我只读它的pin信息本身没有任何写操作按理说不会出问题。但当我调用dbOpenCellViewByType打开它的时候函数返回的db对象和正常打开的对象在某些属性访问上行为不一致——访问某些成员时SKILL直接抛出了一个未捕获的异常导致整个测试进程中断。这个问题是异常测试用例TC-013故意构造出来的。构造方法很简单把测试库的某个cellview设置成只读模式然后跑一遍脚本。如果没有这轮异常测试这个bug大概率会等到用户拿真实设计库跑的时候才爆发一旦爆发用户看到的是一个堆栈回溯信息的屏幕输出完全不知道发生了什么。修复方案是在打开cellview之后、访问任何成员之前先用dbCellViewIsReadOnly判断一下是否只读如果是就把该cellview标记为“只读数据源”后续代码走另一条更安全的属性访问路径。解决之后我把这个case写进了回归测试列表防止以后再被改坏。5.3 断言不能替代业务检查一个小体会断言机制虽好但别滥用。我在项目前期犯过一个“到处加断言”的毛病每个函数开头都写一堆picoAssert(参数不为nil)。后来发现这其实是一种偷懒断言代替了真正的业务检查掩盖了可能存在的逻辑漏洞。比如pcbGetAllPins函数我一开始在入口处断言cv~terminals能正常访问。但后来意识到真正需要设计的不是“断言terminals能访问”而是“当terminals访问失败时是应该继续还是应该停止”。断言只会告诉你“这里炸了”但它不会告诉你“为什么不炸更好”。所以后面我调整策略断言只用于捕获“绝无可能发生”的编程错误而对于数据和环境的异常情况一律通过显式的if/when加上日志记录来处理。这样代码里每一条日志都是“有意义的信息”而不是一串堆栈回溯。6. 这次实践给我留下的收获与教训整个项目从设计框架、编写测试文档、写代码、跑测试到最终验证通过前后花了一周多时间。比起以前“一天写完一个脚本”的效率这套流程确实慢了不少。但从整体收益来看我认为这笔账是划算的。第一笔收益是可复用性。以前写的一次性脚本换个项目基本要从头写。但这次这个框架后续再做类似的检查工具只需要把业务逻辑层替换掉公共服务层和入口层可以直接拿过来用。我在测试项目文档里专门留了一节“框架扩展指南”告诉未来的自己或同事新增一个检查项需要改哪几个文件、加哪几个函数、补哪几个测试用例。这个“指南”把经验固化成了流程比我个人口口相传可靠得多。第二笔收益是调试体验的质变。有了分类日志、断言、统一入口、独立的测试database之后脚本出错了我看一眼日志文件就能定位到具体函数、具体输入数据、具体异常原因。而不是像以前一样在CIW窗口里被一大片报错刷屏。第三笔收益是心态上的变化。以前写SKILL脚本给我的感觉是“又脏又险”踩到哪个坑是运气问题。现在我把它当成一个正规的软件开发流程来对待文档、测试、配置、异常处理全部配齐整个工程变成了一种踏实可控的工作。你要说SKILL能不能支撑特别大型的软件项目那确实有点强人所难但对于我们日常在Virtuoso里做的自动化检查、批量处理、PCell参数验证这些场景这套框架细节的开发方式已经绰绰有余了。最后如果只能分享一句话的经验我会说写SKILL脚本之前先逼自己开一个文档文件把“这个脚本到底要干什么、函数边界在哪里、异常怎么处理”写清楚然后再动手写代码。这个过程会逼你思考很多平时不会想的问题也会帮你躲过不少只有跑到生产环境才会爆发的雷。