亲自测试的我，所测试的是Virtuoso IC618以及Calibre 2022.2_35.28，所经历的最为糟糕的情况便是一个个、一条条单独地点开DRC结果之后转过头再去修改版图，一张规模较大的芯片修改完成竟然需要两天时间。
配置一个不会漏报的DRC Runset
做第一步行为时，要将你的Calibre Interactive界面打开，在输入文件栏里，需把Rule File指向由foundry所提供的完整.drc文件，绝对不要去使用自己修改过的测试版本。我见识过非常多的人，他们为了节省时间，仅仅去跑最小rule set，结果把密度检查以及天线检查给遗漏掉了，最终在流片之前悲痛哭泣，连后悔都来不及了。
第二步：在Outputs选项卡里，将Run Directory设置为一个固定路径，像/project/DRC_BATCH/这种，随后勾选对Export from layout以及包括Generate DRC Database等的设定选项。然后勾上Export from layout和Generate DRC Database两个选项。特别重要的是，在SVDB选项里去挑选Hierarchical模式，借助如此这种的方式，才能够在后续借助脚本以批量的形式提取所有cell的报错。
要注意避坑，在此处最容易出现的报错情况是，显示“SVDB database is too large”，实际上并非数据库真的大得出奇，而是你忘记了在Rules选项卡里，勾上Abort on first 5000 errors旁边的那个Limit hierarchy depth，其默认状态是无限层级，要是处理小芯片的话跑起来不会出现问题，然而处理大SoC时则会直接导致爆内存，出现故障。
用Tcl脚本一键提取所有DRC违规
先完成一回完整的DRC操作之后，在CIW窗口当中键入drcListResults( “/project/DRC_BATCH/drc.db”?outputFile “./drc_all.txt” )，此步骤产生了一份文本清单，其中包括了所有cell里每一条DRC报错的位置，含有该条报错的层次，以及其所属的类型。这一回，是那个我历经三次跌入陷阱方才寻觅到的API，官方所给出的文档里，记述得知相当隐晦，刚入门的新手压根就无从知道。
第二步：进行如下操作，先撰写一个简易的shell脚本，该脚本要针对上面提及的文本去做两件事情，一件事情是运用grep按照DRC error type进行分组并统计数量，另一件事情是借助awk提取出每个cell里重复次数处于最高位次的前三个报错类型，之后将其输出到一个全新的文件drc_summary.csv里。
第三步：在Virtuoso Layout里，借助脚本达成自动高亮操作，我时常运用的命令是geSelectByRegion( list( list( “M1” “0.18” ) ) )，配合前文中所提取出来的坐标范围，一次性选取全部同类错误，接着通过右键点击选为相同一种颜色，凭借视觉效果能够马上分辨出哪些区域为重灾区。
【新手避坑】：你极有可能碰到“Error drcListResults: database file not found”这种情况，其原因在于, Virtuoso的工作目录，与你的Run Directory并不一致，是另有情况的，你可得留意了。处理途径颇简易：在运行DRC之前，先在CIW里键入cd(“/project/DRC_BATCH/”)，将工作目录切换至Run Directory下，而后运行DRC，如此脚本便能顺利寻得数据库了。
原因相当单纯，一种为GDSII此格式的数据库文件，尽管其体积稍微大一些，然而它同Virtuoso Layout的兼容性却是最为出色的，在后续借助脚本回标高亮时，不会出现坐标偏移的情况，经过实际测试 , OASIS格式于IC618上会随机丢失大概5%的报错坐标，排查起来很令人头疼。
对于两种实操方案对比，一种是本文所提及的脚本批量提取以及自动高亮方案，此方案适用于芯片规模较大，且cell数量超过1000个的复杂设计，另一种是Calibre RVE自带的Cell List面板手动点选方法，这种方法适合仅有几十个标准单元的简单模块。若是你的设计已然步入顶层集成阶段，那就务必采用脚本方案，这是由于RVE的Cell List在顶层加载的时候速度极其缓慢，每点击一个cell都会卡顿5秒钟，要是有300个cell，你点击一个小时，手都会废掉。
一个呈现为高频且完整状态的报错: “Error dbComputeNode: failed to allocate memory” 所涉及的这种报错，其出现一般是在你借助脚本运行完DRC结果之后，还要尝试将所有 cell 的 highlight 一次性加载到版图这个行为发生时。第一步，先将Virtuoso关闭，把临时文件通过命令rm -rf /tmp/cal*进行清理；第二步，把版图重新打开，在Layout Editor里选择Options这个选项，接着选Display，再将Dynamic Highlight改成Static；第三步，仅加载前50个最为严重的错误类型，不要全部选择，如此内存便稳住了。
有一种方法，说到底它仅仅是适宜于后端版图工程师，在集成验证这个阶段去运用的。要是你仅仅是从事前仿真，或者是进行单元库建库的工作，那么跑单条的DRC就已经足够了，根本没有必要去折腾脚本。替代的方案是很简易的，运用Assura自身所具备的Batch DRC功能，在Runset当中配置一种仅针对Top Cell的模式，运行完毕后直接去查看RVE的Summary，虽说没办法进行批量高亮显示，不过好在配置速度相当快，五分钟就能够完成。
