【Backend Flow工程实践 16】从 Scan Chain 到 Placement：测试结构为什么会影响后端布局？

作者：Darren H. Chen

方向：Backend Flow / 后端实现流程 / EDA 工具工程 / DFT 与物理实现协同

demo：LAY-BE-16_scan_chain_placement

标签：Backend Flow、EDA、DFT、Scan Chain、Placement、Physical-Aware Test、可测性设计

很多人第一次理解 scan chain 时，会把它当成一个纯 DFT 问题：

text 复制代码

把寄存器串起来，方便测试。

这个理解没有错，但不完整。

在真实后端实现中，scan chain 从来不是一个只存在于测试流程里的抽象结构。它一旦进入 netlist，就会变成一组真实的 cell、net、pin、clock、test enable、scan input、scan output 和逻辑连接关系。它会影响 placement 的搜索空间，影响局部拥塞，影响 timing path，影响 routing resource，甚至影响后续 ECO 和 signoff 的复杂度。

所以，scan chain 和 placement 的关系不是：

text 复制代码

DFT 做完，后端照着摆。

更准确地说是：

text 复制代码

DFT 结构定义了一部分物理连接约束，placement 必须把这些约束纳入物理优化模型。

本文讨论的核心问题就是：为什么测试结构会影响后端布局，以及成熟的 Backend Flow 应该如何把 scan chain 变成可分析、可优化、可验证的工程对象。

一、Scan Chain 在逻辑上是什么？

Scan chain 的基本思想，是把设计中的一部分或全部寄存器改造成 scan register，使它们在测试模式下可以被串行控制和观察。

一个普通寄存器大致只关心：

text 复制代码

D -> FF -> Q

而 scan register 通常还会增加测试输入路径：

text 复制代码

functional data path : D  -> FF -> Q
scan shift path      : SI -> FF -> SO
control signal       : scan_enable / test_mode

抽象成数据通路，可以这样理解：

text 复制代码

                +----------------+
D  -----------> |                |
SI -----------> | scan register  | ----> Q
SE -----------> |                | ----> SO
CLK ----------> |                |
                +----------------+

在 functional mode 下，寄存器按原设计逻辑工作；在 scan shift mode 下，寄存器之间形成串行链路：

text 复制代码

scan_in -> FF1 -> FF2 -> FF3 -> ... -> FFn -> scan_out

这条链在逻辑上是测试结构，在物理上却是一串真实连线。

这就是问题的起点。

二、为什么 Scan Chain 会进入 Placement 问题？

Placement 的核心任务是把逻辑图映射到物理平面。

如果没有 scan chain，寄存器的位置主要受功能逻辑连接影响。例如：

text 复制代码

组合逻辑 A -> FF1 -> 组合逻辑 B -> FF2

placement 会尽量让强相关逻辑靠近，减少 wirelength，改善 timing 和 congestion。

但 scan chain 插入后，寄存器之间又多了一类连接：

text 复制代码

FF1.SO -> FF2.SI
FF2.SO -> FF3.SI
FF3.SO -> FF4.SI

这类连接不一定和功能逻辑的物理邻近关系一致。

如果 scan chain 的顺序完全按逻辑层次或工具默认顺序生成，就可能出现这种情况：

text 复制代码

物理位置：

左下角 FF1
右上角 FF2
左上角 FF3
右下角 FF4

scan 顺序：

FF1 -> FF2 -> FF3 -> FF4

那么 scan path 就会在芯片中反复跨越大区域：

text 复制代码

long wire
long wire
long wire

结果是：

text 复制代码

scan net wirelength 增加
局部 routing congestion 增加
scan enable / test control fanout 变复杂
shift mode timing 变差
后续 routing 修复压力上升

因此，scan chain 虽然来自 DFT，但它一旦形成 netlist 连接，就成为 placement 必须处理的物理约束。

三、底层原理：Placement 看到的是图，不是"测试意图"

从 eda tool 的底层视角看，placement 通常看到的是一个图模型：

text 复制代码

G = (V, E)

V: cell / macro / register / pin
E: net / timing arc / physical connectivity

scan chain 进入 netlist 后，本质上就是往这个图里增加了一批边：

text 复制代码

E_functional : 功能连接边
E_scan       : 测试链连接边
E_control    : scan enable / test mode 控制边
E_clock      : scan clock 或 test clock 相关边

placement 优化器不会天然知道"这条边只是测试模式下用"。如果 flow 没有清楚建模，它可能把 scan 连接当成普通连接，也可能完全忽略 scan 连接的物理代价。

两种极端都不好。

如果过度重视 scan net，可能破坏 functional timing placement。

如果完全忽略 scan net，可能造成后期 routing 和 shift timing 问题。

成熟方法不是简单"考虑"或"不考虑"，而是要把 scan 结构分层建模：

text 复制代码

functional critical path    : 高优先级
scan chain physical length  : 中优先级
test control fanout         : 中高优先级
scan shift timing           : 按测试频率约束
routing congestion impact   : 需要参与全局评估

也就是说，scan chain 的工程处理，本质上是一个多目标权重问题。

四、Scan Chain 对 Placement 的四类影响

1. 影响 wirelength

scan chain 最直接的影响是增加寄存器之间的串行连接。

如果 scan order 和物理位置不匹配，就会产生很长的 scan net。

可以把 scan chain 的物理代价简化成：

text 复制代码

ScanLength = sum(distance(FF_i, FF_i+1))

这里的 distance 不一定是真实布线长度，可以先用 Manhattan distance 估算：

text 复制代码

D = abs(x1 - x2) + abs(y1 - y2)

这个指标虽然简单，但对 early placement 很有价值。

当 ScanLength 过大时，说明 scan order 和 physical placement 不匹配。

2. 影响 congestion

scan net 本身可能不是最关键 timing path，但它会占用 routing resource。

尤其在寄存器密集区域、macro channel、clock buffer 附近，scan net 很容易和 functional net、clock net、电源结构竞争资源。

典型问题包括：

text 复制代码

局部水平金属拥塞
垂直跨层过多
macro 边缘通道被 scan net 占用
scan enable 高扇出网络拥塞
scan chain 跨 partition 带来长距离绕线

placement 阶段如果完全不看 scan 连接，routing 阶段才发现问题，修复成本会明显增加。

3. 影响 timing

scan chain 至少涉及两类 timing：

text 复制代码

functional mode timing
scan shift mode timing

functional mode 下，scan mux 会增加寄存器输入路径上的 delay 和 loading。

scan shift mode 下，链路 SO -> SI 也有自己的 setup / hold 要求。

如果 scan shift 频率不高，setup 可能压力不大，但 hold、transition、fanout、clock skew 仍然可能成为问题。

尤其当 scan chain 跨越较大物理距离时：

text 复制代码

wire delay 增加
buffer 插入增加
hold 修复增加
scan mode timing report 变差

这就是为什么 scan chain 不是"测试完成后就不用管"的原因。

4. 影响 ECO 和可维护性

如果 scan chain 在 placement 和 routing 后才发现问题，再进行重排或修复，就可能牵涉大量改动：

text 复制代码

scan chain reconnect
incremental placement
incremental routing
timing re-analysis
DFT rule recheck
logic equivalence check

因此，成熟 flow 会尽量在早期建立 scan chain 的物理可见性，让问题在 placement 阶段就暴露出来。

五、Physical-Aware Scan Reordering 的本质

所谓 physical-aware scan reordering，表面上是在调整 scan chain 顺序。

本质上，它是在解决一个路径优化问题：

text 复制代码

给定一组 scan registers 及其物理坐标，寻找一条或多条链，使总连接距离更短，同时满足 DFT 和物理约束。

这和旅行商问题有点相似，但芯片实现中的约束更多：

text 复制代码

不能跨不允许的 clock domain
不能破坏 scan compression 结构
不能破坏 test mode 分组
不能跨越不允许的 power domain
不能违反 chain length balance
不能打破 lock-up latch 规则
不能破坏现有 DFT 约束

所以真实 scan reorder 不是简单按最近邻排序，而是约束优化。

一个更工程化的抽象是：

text 复制代码

Objective:
  minimize scan wirelength
  minimize scan congestion impact
  balance chain length

Constraints:
  preserve scan architecture
  preserve clock-domain legality
  preserve power-domain legality
  preserve test protocol
  preserve endpoint definition

这就是为什么 scan chain 需要和 placement 互动，而不是只在 DFT 工具里一次性定死。

六、架构视角：一个成熟 flow 如何处理 Scan Chain？

成熟的 Backend Flow 不会只把 scan chain 当作 netlist 的附属物，而会建立专门的数据层：

text 复制代码

scan_chain_db
├─ chain_id
├─ scan_in / scan_out
├─ ordered_register_list
├─ clock_domain
├─ test_mode
├─ chain_length
├─ physical_bbox
├─ estimated_wirelength
├─ crossing_count
├─ congestion_score
└─ timing_status

然后在 placement 前后分别做分析。

placement 前

text 复制代码

读取 scan chain 定义
识别 scan registers
检查 chain 完整性
检查 chain clock domain
检查 chain length balance
生成 initial scan physical report

placement 后

text 复制代码

提取 register 坐标
计算 scan chain estimated wirelength
识别长跳线
识别跨 macro / 跨 partition 连接
评估 congestion impact
给出是否需要 reorder 的建议

reorder 后

text 复制代码

输出新的 scan order
检查 DFT 约束是否保持
重新评估 wirelength
重新评估 congestion
重新生成 scan chain report

这就是 scan chain 从"测试连接"升级成"物理可分析对象"的过程。

七、方法论：不要等 routing 后才看 scan chain

scan chain 最容易犯的工程错误，是太晚才处理。

常见错误流程是：

text 复制代码

DFT 插入 scan
后端直接 import netlist
placement 忽略 scan 结构
routing 后发现拥塞
timing 后发现 scan shift path 问题
再回头 reorder / ECO

更合理的流程是：

text 复制代码

DFT netlist ready
↓
scan chain precheck
↓
physical-aware placement
↓
scan chain physical report
↓
必要时 scan reorder
↓
incremental placement
↓
routing
↓
scan mode timing / DFT rule check

也就是说，scan chain 应该在 placement 阶段就进入闭环。

八、一个推荐的 Scan Chain Placement Report

为了让 scan chain 可观察，建议至少生成以下报告：

text 复制代码

scan_chain_summary.rpt
scan_chain_length.rpt
scan_chain_long_jump.rpt
scan_chain_cross_domain.rpt
scan_chain_congestion_hint.rpt
scan_chain_reorder_suggestion.rpt

其中 scan_chain_long_jump.rpt 可以包括：

text 复制代码

chain_id
from_register
to_register
from_location
to_location
estimated_distance
clock_domain
power_domain
suggested_action

例如：

text 复制代码

[LONG_JUMP]
chain      : SCAN_CHAIN_03
from       : u_core/u_reg_128
to         : u_periph/u_reg_007
distance   : 1820 um
reason     : cross-region scan connection
action     : consider physical-aware reordering

这类报告的价值不是替代 DFT 工具，而是把测试结构对后端实现的影响显式化。

九、demo 设计：LAY-BE-16_scan_chain_placement

这个 demo 不绑定任何具体商业工具命令，而是展示 scan chain 如何影响 placement 分析。

推荐目录结构：

text 复制代码

LAY-BE-16_scan_chain_placement/
├─ data/
│  ├─ scan_chain.def
│  ├─ registers.csv
│  └─ placement_after.csv
├─ scripts/
│  ├─ run_scan_physical_check.csh
│  └─ clean.csh
├─ tcl/
│  ├─ 01_read_design.tcl
│  ├─ 02_read_scan_chain.tcl
│  ├─ 03_report_scan_chain.tcl
│  ├─ 04_analyze_scan_distance.tcl
│  └─ 05_write_reorder_suggestion.tcl
├─ reports/
│  ├─ scan_chain_summary.rpt
│  ├─ scan_chain_length.rpt
│  ├─ scan_chain_long_jump.rpt
│  └─ scan_chain_reorder_suggestion.rpt
└─ README.md

运行入口可以抽象成：

csh 复制代码

#!/bin/csh -f

setenv EDA_TOOL_BIN /path/to/eda_tool
setenv DESIGN_ROOT  /path/to/LAY-BE-16_scan_chain_placement

$EDA_TOOL_BIN -batch $DESIGN_ROOT/tcl/03_report_scan_chain.tcl \
  >&! $DESIGN_ROOT/reports/run_scan_chain.log

注意这里的重点不是命令本身，而是 demo 要验证三件事：

text 复制代码

scan chain 可以被结构化读取；
scan chain 可以和 placement 坐标关联；
scan chain 的物理代价可以被报告和比较。

十、从专家视角看 Scan Chain 与 Placement

如果只会说"scan chain 是 DFT 的事情"，说明还停留在单工具视角。

真正的后端工程视角会看到：

text 复制代码

DFT 改变 netlist；
netlist 改变 connectivity graph；
connectivity graph 影响 placement；
placement 影响 routing；
routing 影响 timing、DRC 和 signoff；
signoff 结果又反过来影响 ECO 和 DFT 修复。

这是一条完整的工程链。

Scan chain 的价值不是只让芯片可测试，它也要求后端 flow 具备跨阶段建模能力。

十一、总结

本文讨论了一个经常被低估的问题：

为什么测试结构会影响后端布局？

核心结论可以概括为六点：

scan chain 在逻辑上是 DFT 结构，在物理上是真实连接；
scan order 如果和物理位置不匹配，会增加 wirelength 和 congestion；
scan register、scan enable、test clock 都会影响 placement 和 routing；
physical-aware scan reordering 本质上是带约束的路径优化问题；
成熟 flow 应该在 placement 前后建立 scan chain report；
scan chain 不是 DFT 孤岛，而是 Backend Flow 中必须被建模的工程对象。

结尾一句话

后端实现不是把"功能逻辑"放进芯片就结束了；真正成熟的 Backend Flow，必须让测试结构、物理布局、时序路径和布线资源在同一个工程模型中相互可见。