一条扫描链在测试机上挂了日志甩给你的是一个 instance 名、几个 pattern 编号和一个莫名其妙的 cycle 数剩下的全靠猜——这是很多做 DFT 的人共同的起点。Tessent Visualizer 就是干这件事的把 Tessent Shell 里那些离散的、文本形态的链定义、pattern、fault 和网表数据拼成一张能点、能搜、能顺着往下追的图。这篇内容围绕 Tessent Visualizer 的Components和Preferences两块展开组件那一半讲每个窗口背后挂的是什么数据、什么时候该用它偏好那一半讲怎么把界面和加载行为调成顺手的状态以及怎么把这份设置固化成团队能共享的东西。不管你是刚接手调试任务的新人还是已经用了几年但一直只用默认配置的老手下面这些内容都能直接拿去用。1. 别急着开窗口先弄清 Visualizer 在调试链路里的位置1.1 日志能给你的信息和它永远给不了的信息ATPG 或者诊断流程跑完之后工具输出的是一份结论。它会告诉你第 17 条链的第 233 个触发器在 pattern 8821 上 mismatch期望值是 1 实际抓到 0。这三条信息本身没有错但它天然缺少两个东西上下文和空间关系。上下文的意思是这个触发器上游是谁、它的时钟域是什么、它的 scan enable 从哪儿来、同一条链上前后几个 cell 是不是也异常。空间关系的意思是这个 fail 的点在版图上落在哪里是不是和上个月另一个 case 的 fail 点聚在同一个区域。这两个东西在纯文本日志里是表达不出来的或者说表达出来的成本高到没人愿意做——你得手写脚本去解析日志、去翻网表、去比对坐标。Visualizer 的价值就在这儿。它把同一次会话里已经加载进内存的设计数据、链数据、pattern 数据、fault 数据用图形的方式重新组织了一遍让你可以在看到一个异常点之后两步之内跳到它的物理邻居、逻辑邻居或时序邻居上去。这不是更好看的日志而是完全不同的一类操作。1.2 关键认知Visualizer 自己不产生数据它只是会话的一个视图层这一点是很多人第一次用的时候最容易懵的地方。Visualizer 不会自己去读 netlist不会自己去解析 STIL它展示的所有东西都来自当前 Tessent Shell 会话里已经加载的内容。换句话说你在 Shell 里set_context到了哪个设计GUI 里就只能看到哪个设计你没读进来的 pattern波形窗口里就是空的你当前的 fault list 是上一轮 ATPG 留下的Bins 面板展示的就是上一轮的分类结果。所以GUI 打开是空的或者GUI 里的链和我想的不一样这类问题九成不是 GUI 的问题是会话状态的问题。我的建议是养成一个习惯开 GUI 之前先在 Shell 里用报告类命令确认一遍当前 context、当前设计名、已加载的 pattern 数量确认无误再开窗口。这比在 GUI 里翻半天菜单找原因快得多。提示Visualizer 和 Shell 是同一份数据的两个视图。任何在 GUI 里做的过滤、高亮、隐藏通常不影响 Shell 侧的数据反过来Shell 侧重新加载了设计GUI 侧大概率需要刷新甚至重开。1.3 什么时候该开 GUI什么时候 grep 更快不是所有问题都值得开图形界面。启动一次 GUI 加上加载数据在大设计上可能就是几分钟的事情。所以我一般按下面的标准分问题类型推荐方式原因统计类比如某条链有多少 cell、某个 pattern 覆盖多少 fault直接用报告命令一条命令就有答案开 GUI 纯属浪费定位类比如某条链从第几个 cell 开始出错GUI 的 Chains 组件需要视觉上看趋势文本很难看出从哪开始追踪类比如一个 X 从哪儿一路传下来的GUI 的 Schematic 组件需要顺着路径一层层跳文本描述会爆炸物理相关比如 fail 点在版图上的聚集GUI 的 Layout 组件需要坐标和图层叠加这是文本做不到的汇报类比如给团队讲清一个 caseGUI 加会话保存保存下来的会话本身就是最好的说明材料这个分法不绝对但能帮你避开为了看一眼链长就开 GUI这种低效操作。做技术的效率差距往往就藏在这些小判断里。2. Components每个窗口背后挂的是什么数据Visualizer 的界面是由一组可以停靠、可以隐藏、可以拆分的组件拼起来的。不同版本里组件的数量和名字会有些出入最靠谱的确认方式是打开 GUI 之后看一眼 View 或 Window 菜单——菜单里列出来的就是你这套环境支持的全部组件。下面按使用频率从高到低讲几个真正会被反复用到的。2.1 Chains 组件它的价值不在看链有多长新手最容易把 Chains 当成一个链长度查看器那就把它的能力浪费了。它真正有用的地方是链上顺序和沿链的数据流。一条扫描链在逻辑上就是一串首尾相接的触发器。当它挂了可能性有几类某一段物理断开下游收到的数据整体偏移或者全 X、链序与预期不符工具以为的顺序和实际插入的顺序不一致、某个 cell 被 mask 掉导致比对基准错了、某几个 cell 的时钟或 enable 接错导致只在特定 pattern 上出错。这几种情况在 Chains 组件里的长相是不一样的整体偏移是一条平滑的错位线单点异常是链上孤立的红点链序问题则表现为一种周期性的、跟着某个模块边界重复的错位。我看链的时候有个固定动作先在 Chains 里让工具把出错的位置标出来然后不要急着看这个点本身先看它前后各二十个 cell 的状态。如果前后都正常那基本是单点问题往物理方向查如果前后也有异常但程度不同那更像是这条链的某个控制信号边界出了问题往逻辑方向查。这个动作能省掉大量来回试探。另外一个细节Chains 组件里的数据通常和当前加载的 pattern 集合绑定。如果你只读了一小部分 pattern 做快速验证看到的现象可能和全量 pattern 下的现象不一致。判断是不是真的链断这类结论时务必确认 pattern 集合是完整的。2.2 Waveform 组件把 pattern 摊平成时间轴Waveform 是周期级的视图横轴是 shift cycle纵轴是链上的信号或者某几个关键控制信号。它的典型用法是回答在哪个 cycle 上第一次出现不一致。这个组件最需要注意的是加载范围。默认状态下如果让它把全部 pattern 全部 cycle 都铺开在大设计上内存占用会非常可观窗口滚动也会变得很卡。做法是按需加载先根据日志里给出的 pattern 编号只加载那一个 pattern 以及它前后相邻的几个确认了现象之后再决定要不要扩大范围。在这个组件里我一般会把几个信号固定显示出来主时钟、scan enable、以及链上数据输入输出的两个端点。有这四条就能判断一个异常到底是时钟没动还是数据没进来还是数据进来了但比对基准不对。这三种原因的修复方向完全不同先分类再动手比一上来就翻网表有效得多。注意波形上的期望值和实际值是两套数据。比对的时候先确认你看的是哪一套我曾经因为盯着期望值排查了半天最后发现实际值早在三个 cycle 前就已经不对了。2.3 Schematic 组件追 X 传播路径的主战场如果说 Chains 是横向看一条链Schematic 就是纵向往逻辑里钻。它展示的是门级的网表连接关系支持逐层展开、按信号高亮、按方向追踪。这个组件最重要的一类用途是追 X 的来源。一个 X 出现在某个 cell 的输出上可能是它自己产生的比如没有初始化的寄存器、多驱动冲突也可能是上游传下来的。Schematic 的着色和追踪功能可以让你从下游一路往上游跳直到找到一个输入都正常、输出却是 X的节点那基本就是源头。实际操作中有一个组合动作非常高效在 Waveform 里选中一个异常信号直接让它跳到 Schematic 里高亮对应节点定位完源头之后再从 Schematic 里把可疑节点送回 Waveform看它在时间轴上的首次异常周期。这样两个组件来回切比在任何一个里死磕都快。另外提醒一句Schematic 展示的层次深度最好按需控制。全展开一个大型模块的网表渲染时间和内存都不友好。我通常只展开到能看清可疑路径的那一层需要继续往下的时候再展开下一层。2.4 Layout 组件只有做物理相关分析时才真正用得上Layout 组件把逻辑上的异常点叠加到物理版图上支持按层过滤、按区域聚类。它解决的是另一类问题同一个失效模式在物理上是否集中。判断一个 fail 是随机缺陷还是系统性缺陷最直观的证据就是空间分布。随机缺陷在版图上是散的系统性缺陷往往会沿着某个方向排成线、或者聚成块甚至和图上的某条电源走线、某个阱边界重合。这种判断用坐标表格做会很痛苦用 Layout 一眼就看出来了。但这个组件有个前提你得有对应的物理数据。没有版图数据源的时候这个面板就是灰的点不动。所以如果你的流程里根本不产出物理数据就别在这个组件上浪费时间把精力放在 Chains 和 Schematic 上更实际。2.5 Bins 与 Log最容易被忽略、但最省时间的两个组件这两个组件经常被当成附属品实际上它们的性价比很高。Bins 组件展示的是 fault 的分类统计也就是 ATPG 跑完之后那些对象分别落在哪个桶里。它的用法是反向定位当你发现某个模块的覆盖率特别低可以直接在 Bins 里筛出这个模块下所有未被覆盖的对象然后逐个看它们为什么没被覆盖——是逻辑上不可测还是被约束挡住了还是工具根本没找到路径。这比反复跑 ATPG 加选项试要快得多。Log 组件则是一个和 Shell 输出联动的文本窗口。它的价值在于上下文回跳日志里有一条报错你直接在 Log 里选中它就能看到它前后几十行完整输出而不需要往上翻终端回滚缓冲。这在会话跑了很久、输出几千行的情况下特别有用。把这几类组件整理一下大致是这样组件回答的核心问题前置数据使用频率Chains链上从哪个位置开始不对链定义、pattern高Waveform在哪个 cycle 第一次不对pattern 数据高Schematic这个异常是从哪儿来的门级网表高Layout异常点物理上是否聚集版图数据中物理分析时高Bins哪些对象没被覆盖、为什么ATPG 结果中Log这条报错的上下文是什么Shell 输出中3. Preferences把界面调成顺手的工具而不是每次重来3.1 偏好存在哪儿谁覆盖谁偏好设置一般分三层生效顺序从低到高大致是出厂默认 → 用户级偏好文件 → 当前会话里临时改的。很多人的问题是只改了第三层在 GUI 里调了半天颜色和布局关掉窗口再打开全变回去了。所以第一件事是搞清楚你这套环境里偏好文件的落盘位置。常见的查找方式有两个。一是看 GUI 里偏好对话框的底部或者关于页面通常会提示当前使用的配置来源二是在你的账户目录下找相关的隐藏配置文件名字里一般带工具名。找到之后先备份一份这一步别省。我见过太多次因为一次误操作把攒了半年的布局和配色全冲掉的案例。还有一点值得注意偏好文件通常和版本绑定。升级到新版本之后旧版本的偏好文件可能不兼容表现是部分设置被忽略、或者启动时报一条警告然后回到默认。遇到这种情况不要硬扛直接把旧文件备份走用新版本重新配一份再把可迁移的部分手工搬过去比研究兼容性省事。3.2 真正值得改的项和不值得折腾的项偏好项很多但真正影响效率的就那么几个。下面这张表是我自己的取舍偏好项建议理由配色与字体换成对比明显的深色方案长时间盯着波形看对比度比美观重要窗口默认布局固定一套别每次拖肌肉记忆能显著减少找面板的时间波形默认显示信号集固定时钟、enable、数据端点省掉每次手动加信号Schematic 默认展开层级限制在浅层避免打开大模块时卡住自动加载上次会话小设计开大设计关大设计下自动加载会让启动变得很慢外部编辑器路径配上需要看源文件时能一键跳出去数值/单位显示格式按团队习惯统一避免沟通时的进制误会动画和过渡效果关掉纯粹的性能消耗不值得花时间折腾的各种装饰性的图标风格、窗口阴影、主题皮肤。这些东西对排查问题没有任何帮助调起来还容易把自己绕进去。3.3 把偏好固化成文件跟着项目走一个人用和一支团队用是完全不同的两件事。如果团队里每个人都用自己的偏好会出现一个很尴尬的情况同事把会话发给你你打开看到的布局和配色跟他描述的完全不一样沟通成本瞬间拉高。我的做法是维护一份项目级的偏好基线文件放在项目的公共目录下内容只包括那些影响看数据的项配色、波形默认信号集、Schematic 展开层级、单位格式。个人的字体大小、窗口位置这类私人口味不放进基线。这样新同事进来引用一次基线文件就能达到和团队看到的一样的状态剩下的个性化他自己调。有一点必须注意偏好文件里如果有绝对路径换机器或者换目录结构就会失效。所以凡是涉及路径的项一律用相对路径或者环境变量来表达。这个坑我踩过一次一份看着好好的配置拷到同事机器上就报了一串找不到文件的错误排查了半天才发现是路径写死了。4. 一次完整的实操从启动到定位一条断链4.1 环境与数据准备先确认三件事工具版本、当前账户下有没有可用的授权、以及你要分析的数据放在哪。授权这件事单独拎出来说因为 Shell 能跑通并不代表 GUI 能起来两者可能对应不同的授权项。启动失败先查授权能省掉大量排查时间。数据方面一次完整的链调试通常需要设计网表含链定义信息、pattern 数据、以及上一轮产生的日志或结果文件。把这几样放在一个独立的、名字带日期的目录里别和别的 case 混在一起。目录结构固定下来之后会话文件的可复用性会高很多。4.2 从 Shell 到 GUI 的握手整个流程是先在 Tessent Shell 里把会话状态准备好再打开图形界面。大致顺序如下# 进入 Tessent Shell tessent -shell # 设置并确认当前上下文具体取值以你的流程脚本为准 set_context pattern -scan # 加载设计与 pattern 数据 # 实际命令名随版本略有差异先用 help 确认一遍最稳 read_patterns ./patterns/scan.stil # 确认会话状态设计名、pattern 数量、链定义是否存在 # 这一步别跳跳了后面 GUI 里出问题只能靠猜 # 打开图形界面 visualizer最后一步打开 GUI 的命令名在不同版本里略有出入有的版本还支持前台、后台之类的参数。别去背进 Shell 之后敲一次帮助命令看一遍参数列表比查文档快。提示把上面这几步写成一个脚本文件每次进会话直接执行它。这样做的价值不只是省几条命令更重要的是保证每次的会话起始状态完全一致。调试中最怕的就是上次还好好的这次看到的完全不一样而十次里有八次是起始状态不同造成的。4.3 定位一条断链的完整动作假设日志告诉你某条链在某几个 pattern 上出错。我的动作顺序是这样的第一步在 Chains 组件里定位到这条链让工具把异常位置标出来然后看异常点前后各二十个 cell 的状态判断是单点问题还是边界问题。第二步根据第一步的结论决定下一步。如果是单点直接在 Schematic 里展开这个 cell 周围两层看它的输入输出、时钟、复位如果是边界问题跳到 Waveform 里看这个边界对应的控制信号在时间轴上的行为。第三步在 Waveform 里只加载出问题的那个 pattern把时钟、enable、数据端点四条信号固定显示确认首次出现不一致的 cycle。第四步从异常信号跳到 Schematic 里追 X 的来源找到输入正常输出异常的节点。这个节点就是你要交给后端或者版图同事的东西。整个流程走下来快的话十几分钟慢的也就一两个小时。相比之下纯靠文本日志和手写脚本同样的定位可能要花掉一天。4.4 保存会话让别人能复现定位完不是结束把会话保存下来才算完整。保存下来的会话至少应该能让同事做三件事看到你定位到了哪个点、看到你是怎么一步步跳过去的、以及把视图恢复到和你一样的状态。所以保存之前做两件清理把无关的临时高亮和过滤去掉只留下真正说明问题的那些标记把窗口布局整理成一屏能讲清楚的样子。会话文件加上一份简短的文字说明哪条链、哪个 pattern、结论是什么、下一步该找谁就是一个完整的交接材料。5. 踩过的坑大设计与长会话下的 Visualizer5.1 内存和加载时间什么数据不要一次性加载这是我见过最多的坑。大设计上把全部 pattern 的波形一次性加载内存占用会迅速上去窗口响应变得极慢严重的时候直接把进程拖死。对应的做法是分级加载先只加载日志里点名的那个 pattern确认现象之后再按需扩大范围波形窗口里只固定那些真正需要的信号不要顺手全加进去Schematic 的展开层级按需增加不要一上来就全展开。这三条做下来同样的数据量体感差别是数量级的。5.2 图形界面在远程环境下的性能问题如果 GUI 是通过远程连接投射到本地看的图形操作会明显变卡滚动波形的时候尤其明显。这不是工具的问题是图形数据在网络上来回传输的成本。我的经验是能用本地显示就用本地所有数据先拷到本地的工作目录再分析不要直接在网络存储上开 GUI 读数据。网络存储的顺序读性能对图形界面这种随机访问的模式非常不友好。如果确实只能在远程跑那就减少交互操作改成用命令生成报告把图形界面留给真正需要看的那几步。5.3 会话数据和设计不同步这个坑特别隐蔽。设计重新综合之后网表里的实例路径和层次结构可能发生变化而你之前保存的会话文件里记录的还是老路径。打开之后的现象是会话能加载但高亮的位置全是错的或者干脆加载失败。解法是加一条纪律会话文件必须和产生它的设计版本绑定。目录名里带版本号或者日期会话文件里也标注对应的设计版本。打开一个旧会话之前先确认它对应的是哪个版本的设计。5.4 启动失败先怀疑授权再怀疑环境GUI 起不来的时候排查顺序建议是授权有没有、显示环境变量对不对、偏好文件是不是坏了、然后是数据加载问题。授权排第一是因为它最常见而且报错信息经常不直观偏好文件排第三是因为它很容易被忽略——把旧的偏好文件临时改名看能不能起来这是一个非常快的二分判断。5.5 偏好文件被覆盖多人共用环境下的隐患如果多个人共用同一个账户用户级的偏好文件就是共享的谁改谁生效互相覆盖。这种情况下要么每人独立账户要么在启动时显式指定自己的偏好文件路径。项目级的基线文件可以共享个人的偏好文件必须分开。6. 顺手提效的几个习惯6.1 一个可复用的启动脚本把设置上下文、加载数据、确认状态、打开界面这四步写成一个脚本文件放在项目目录里。每次分析新 case 的时候复制一份改改路径就能用。这个脚本的另一个好处是它本身就是流程文档——新人拿过去看一遍就知道一次完整的分析需要哪些输入。6.2 常用操作小抄场景做法确认当前会话状态用报告类命令查当前上下文、设计名、已加载数据量打开图形界面在 Shell 里执行界面启动命令参数用帮助命令确认波形卡顿减少加载的 pattern 数量只固定关键信号网表窗口渲染慢减少默认展开层级按需下钻定位到可疑节点后从波形跳网表追源头再从网表跳回波形看首次异常 cycle会话交接清理临时标记整理布局附一份文字说明换了设计版本不要复用旧会话重新建立会话并标注版本6.3 关于这套工具的一点个人体会用了几年下来我最大的感受是Visualizer 这类工具的能力上限其实取决于使用者有多清楚自己想看到什么。组件只是窗口偏好只是配置真正决定效率的是你脑子里那套排查路径——先横向看链还是先纵向追逻辑还是先看物理分布。这套路径想清楚了哪怕用的是默认配置也能很快定位路径没想清楚把界面调得再漂亮也只是在漂亮地迷路。所以我的建议是先把 Chains、Waveform、Schematic 这三个组件的配合方式练熟把从异常点到源头这条链路走顺再考虑 Layout 和 Bins 这些更专用的组件。偏好配置也一样先固定住那几个真正影响阅读的项剩下的等用出痛点再改别一开始就把时间花在调界面上。