DarrenHChen_EDA-CSDN博客

原创【Backend Flow工程实践 28】Backend Flow Engineering 总结：从脚本、日志、报告到工程闭环

QoRviolationruntimememory这样 flow 才能持续演进。经过 28 篇文章，可以把 Backend Flow 能力分成四个层级。Backend Flow Engineering 的核心不是记住更多命令，而是建立一套系统能力。环境可复现命令可控制对象可查询输入可验证状态可转移报告可审计错误可诊断结果可比较交付可追踪流程可演进。

2026-05-04 00:36:54 317

原创【Backend Flow工程实践 27】Backend Script Template：一个可维护的后端脚本体系应该如何组织？

Backend Script Template 的价值，不是把命令整理得更漂亮。如何把后端实现从个人脚本，变成团队可维护的工程系统。环境层配置层阶段层报告层日志层错误处理层参数层版本层回归层归档层能运行能检查能复盘能比较能交接能扩展如果没有脚本架构，flow 会随着项目推进越来越混乱。如果有清晰模板，flow 才能随着项目推进不断沉淀。

2026-05-04 00:32:50 371

原创【Backend Flow工程实践 26】Hierarchical Design Flow：为什么大芯片后端必须分层、抽象、合并和签核？

Hierarchical Flow 可以用三个关键词理解。Abstract 是 block 对外提供的简化模型。它不是随意裁剪，而是保留 top integration 所需的信息。Abstract 的质量决定 top-level flow 是否可信。Physical abstract 的作用，是在 top-level flow 中代表 block。block sizeblock pinspower pinsblock 内部每一个 standard cell。

2026-05-04 00:30:39 316

原创【Backend Flow工程实践 25】UPF / CPF：为什么低功耗意图必须被后端工具显式理解？

UPF / CPF 的价值不是“多一个输入文件”。如何把低功耗架构意图转化为 eda tool 可以理解的设计语义设计对象归属跨域信号处理供电网络连接cell 插入和替换placement 合法性routing 连接方式PV 和 signoffECO 后一致性如果没有 power intent，eda tool 只能看到普通逻辑和普通物理结构。哪些逻辑会断电哪些逻辑必须常开哪些路径需要隔离哪些信号需要电平转换哪些状态需要保存哪些供电模式是合法的。

2026-05-03 09:03:38 319

原创【Backend Flow工程实践 24】Low Power Flow：power domain、always-on、retention 和 power switch 如何进入后端实现？

Low Power Flow 的核心不是多跑几个低功耗命令，而是把 power intent 转换成后端实现数据库中的对象、约束和物理结构。Power domain 决定逻辑和物理区域如何按电源语义分组。Always-on 保证系统在关断状态下仍有控制能力。Isolation 保证 power-off domain 的输出不会污染 still-on domain。Level shifter 保证不同电压域之间的信号可靠传递。Retention 保证断电后关键状态可以保存和恢复。

2026-05-03 08:47:00 287

原创【Backend Flow工程实践 23】Backend-to-PV Handoff：从 DEF/GDS 到物理验证，后端如何完成签核交接？

Backend-to-PV Handoff 的核心不是导出一个 GDS，也不是简单启动一个 PV 工具。它的本质是多视图一致性交接。可以用一句话概括：后端交付给 PV 的不是一个文件，而是一个带有逻辑、物理、几何、工艺、规则和例外说明的完整验证上下文。从架构角度看，handoff package 是后端实现系统和物理验证系统之间的接口协议。从方法论角度看，必须用 manifest、checklist、file inventory 和回流机制保证交接可复现、可审计、可闭环。

2026-05-03 08:41:06 372

原创【Backend Flow工程实践 22】ECO：为什么后端修改必须同时维护逻辑、物理、时序和验证一致性？

ECO 是后端工程中最能体现工程成熟度的阶段之一。它不是简单补丁，而是在设计状态高度收敛、自由度高度受限的条件下，完成最小扰动修改，并同时维护逻辑、物理、时序和验证一致性。可以用一句话概括：ECO 的目标不是“把问题改掉”，而是“在可验证、可回滚、可签核的条件下把问题改掉”。从架构角度看，ECO 需要 change set、delta report、verification checklist 和 closure report。从方法论角度看，ECO 必须先分类，再修改；

2026-05-03 08:36:06 163

原创【Backend Flow工程实践 21】DRC / Antenna / Metal Fill：为什么 route 之后还远没有结束？

Route 之后还远没有结束。Routing 只是完成了连接几何，后端真正的收敛还必须通过 DRC、Antenna、Metal Fill、post-fill extraction、post-fill timing 和 signoff PV 闭环来确认。可以用一句话概括本文：Route 解决的是“连得上”，DRC / Antenna / Metal Fill 解决的是“造得出、用得稳、签得过”。从工程架构看，route 后阶段不是一个尾声，而是从实现工具内部闭环走向物理验证和制造签核的过渡区。

2026-05-03 08:28:50 362

原创【Backend Flow工程实践 20】Routing：global route、detail route 与 route optimize 分别解决什么问题？

本文解释了 global route、detail route 和 route optimize 的区别。routing 的本质是把逻辑连接图映射成可制造几何；global route 解决 routing resource 和大方向规划问题；detail route 解决真实 track、via、pin access 和 DRC 落地问题；route optimize 解决 route 后 timing、DRC、antenna、SI 等收敛问题；

2026-05-02 11:08:12 281

原创【Backend Flow工程实践 19】CTS：从 skew group 到 clock route rule，时钟树综合到底在综合什

本文回答了：CTS 到底在综合什么？CTS 的输入包括 clock、sink、skew group、library、placement、route rule 和 timing context；CTS 的输出是 clock topology、buffer、latency、skew、transition 和真实 clock path；skew group 决定哪些 sinks 需要一起平衡；clock buffer 选择是 delay、transition、power、area 的折中；

2026-05-02 11:06:26 308

原创【Backend Flow工程实践 18】Clock Tree：为什么时钟网络不是普通 net，而是后端实现的节奏系统？

clock latency 可以理解为 clock 从 source 到 sink 的到达时间。从物理角度看，clock latency 不是越小越好。buffer 过多功耗过大routing 拥塞clock transition 过差skew 难控制Clock tree 的目标通常不是“最快”，而是“可控”。skew 是不同 clock sink 之间的到达时间差。如果两个寄存器属于同一个同步关系，clock 到达它们的时间差会直接影响 setup 和 hold。

2026-05-02 10:57:25 343

原创【Backend Flow工程实践 17】Timing Analysis：为什么 Backend Flow 的每一步都围绕 slack 和 path 展开？

本文讨论了 Backend Flow 中最核心的评价系统：Timing Analysis。Timing Analysis 检查的是时间一致性，不只是频率；timing graph 是后端实现的时间骨架；path 是 timing 问题的基本解释单位；slack 是后端优化闭环的统一反馈信号；setup 和 hold 是不同物理问题，修复方向可能相反；timing context 决定 report 是否可信；MCMM 让同一设计在多个场景下被同时约束；

2026-05-02 10:53:47 361

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

本文讨论了一个经常被低估的问题：为什么测试结构会影响后端布局？scan chain 在逻辑上是 DFT 结构，在物理上是真实连接；scan order 如果和物理位置不匹配，会增加 wirelength 和 congestion；scan register、scan enable、test clock 都会影响 placement 和 routing；physical-aware scan reordering 本质上是带约束的路径优化问题；

2026-05-02 10:43:45 402

原创【Backend Flow工程实践 15】Placement：为什么布局优化本质上是时序、拥塞、功耗和合法性的折中？

cell 合法位置；wirelength；ECO 修复空间。如果只追求单一指标，就可能牺牲其他关键目标。在合法物理空间中，寻找一个同时满足 timing、congestion、power、legality 和可修复性的折中解。这就是 placement 作为后端核心阶段的真正复杂度。

2026-04-29 14:40:13 379

原创【Backend Flow工程实践 14】IO / Macro / Row：物理约束如何决定后端实现的搜索空间？

在后端实现中，placement、CTS、routing 都不是随意尝试。它们是在一定约束下寻找可接受解。这个“可接受解”的范围，就是搜索空间。core 区域有多大；row 在哪里；哪些区域有 blockage；macro 占了哪些区域；IO pin 在边界哪个位置；power stripe 占用了哪些 routing resource；哪些 cell fixed；哪些区域有密度限制；哪些路径需要更短距离。如果搜索空间太大，工具需要更多计算。如果搜索空间太小，可能根本没有可行解。

2026-04-29 14:38:54 408

原创【Backend Flow工程实践 13】Floorplan：为什么后端实现不是从 placement 开始，而是从边界、row、site 和电源结构开始？】

后端实现不是从 placement 开始，而是从 floorplan 开始。因为 placement 需要一个已经定义好的物理世界。这个世界由 floorplan 建立。坐标系统；die/core 边界；row/site 合法放置空间；macro/blockage 物理约束；utilization 目标；power/ground 结构；routing resource 预留；IO 边界约束。

2026-04-28 10:52:38 387

原创【Backend Flow工程实践 12】Collection / Property / Filter：为什么对象查询能力决定 Backend 脚本工程上限？

Collection 让脚本可以操作对象集合。Property 让脚本可以观察对象状态。Filter 让脚本可以把工程经验转换成对象选择条件。三者组合起来，才形成真正可靠的对象查询能力。从海量设计对象中，稳定、可解释、可复查地找到目标对象。一个 Backend Flow 能不能长期维护，往往不取决于命令写得多不多，而取决于对象查询层是否清楚、稳定、可扩展。

2026-04-28 10:33:03 174

原创【Backend Flow工程实践 11】设计对象模型：cell、net、pin、port 为什么是 Backend Flow 工程化的基本单位？

回到题目：cell、net、pin、port 为什么是 Backend Flow 工程化的基本单位？因为 Backend 工具真正理解设计，是从对象模型开始的。cell 表示设计中的实例化单元；net 表示连接关系和后续物理布线对象；pin 表示 cell 与 net 的连接界面，也是时序路径节点；port 表示 top-level boundary 与外部约束入口。这四类对象共同构成设计数据库的基本连接图。

2026-04-27 10:11:23 397

原创【Backend Flow工程实践 10】从 Import 到 Link：为什么 link_project 决定设计是否真正被工具理解？

对象开始拥有完整上下文。这些对象查询之所以有意义，是因为 instance 已经绑定到 master cell，pin 已经和 library view 对应，design hierarchy 已经解析。名字存在，但语义不完整。对象存在，引用可解析，属性可查询，后续命令可消费。这就是 link_project 在自动化中的深层价值。它让 design 从“文件解析结果”进入“对象操作空间”。Backend Flow 有很多质量门。link gate其中 link gate 的位置非常靠前。

2026-04-27 09:53:38 331

原创【Backend Flow工程实践 09】Design Import 不是读文件：它是在建立设计数据库的第一层语义

回到题目：Design Import 不是读文件：它是在建立设计数据库的第一层语义。因为 Backend Flow 真正操作的不是文件，而是工具内部设计数据库。解析 Verilog，建立 module / instance / net / port / hierarchy；解析 LEF，建立 physical abstract / pin geometry / site / layer / blockage；

2026-04-26 23:21:34 397

原创【Backend Flow工程实践 08】LEF / Liberty / Verilog / DEF：Backend Flow 为什么依赖多格式协同？

回到题目：LEF / Liberty / Verilog / DEF：Backend Flow 为什么依赖多格式协同？因为后端设计不是单一文件能描述的对象。格式核心语义Verilog逻辑连接关系Liberty时序、功耗和单元逻辑模型LEF物理抽象、工艺层、pin 和 blockageDEF当前设计实例的物理实现状态Backend 工具真正要做的，不是简单“读文件”，而是把这些格式融合成统一设计数据库。文件完整；路径可复现；格式可解析；cell 名一致；

2026-04-26 22:34:23 381

原创【Backend Flow工程实践 07】从 Project Library 看 EDA 工具如何管理工艺库与标准单元库

回到题目：从 Project Library 看 EDA 工具如何管理工艺库与标准单元库？Project Library 的本质不是路径管理，而是工艺和单元知识的工程化管理。读取和组织 technology file；管理 LEF 物理抽象；管理 Liberty 时序 / 功耗模型；关联标准单元的多种视图；检查 cell name / pin name / site / layer 等一致性；为 design import 和 link 提供 library context；

2026-04-25 00:22:51 397

原创【Backend Flow工程实践 06】为什么成熟的 Backend Flow 要先建立命令帮助基线？

回到题目：从 Project Library 看 EDA 工具如何管理工艺库与标准单元库？Project Library 的本质不是路径管理，而是工艺和单元知识的工程化管理。读取和组织 technology file；管理 LEF 物理抽象；管理 Liberty 时序 / 功耗模型；关联标准单元的多种视图；检查 cell name / pin name / site / layer 等一致性；为 design import 和 link 提供 library context；

2026-04-25 00:00:22 414

原创【Backend Flow工程实践 05】Backend Tcl 脚本为什么必须先验证再执行？

回到题目：EDA Tcl 脚本为什么必须先验证再执行？因为 EDA Tcl 脚本不是普通脚本，而是工具 session 和设计数据库的状态变更入口。数据库状态污染输出文件覆盖半完成 session错误定位困难replay 不完整团队协作困难文件级 precheck环境变量检查上下文检查阶段入口条件catch错误边界fail-fast / continue-on-error 策略cmd.log / summary log 配套记录。

2026-04-24 23:52:59 319

原创【Backend Flow工程实践 04】从 log 到 cmd_log：EDA 工具如何实现可回放的工程现场？

从 log 到 cmd_log：EDA 工具如何实现可回放的工程现场？log 负责完整轨迹cmd.log 负责命令回放summary 负责阶段摘要source 负责把外部脚本纳入会话负责预检查debug_tcl负责增强诊断性reports 负责结果固化这些机制叠加起来，才让一次 EDA 会话从“临时执行”变成“可复盘工程现场”。所以，从工程角度看，日志系统绝不是配角。它本身就是自动化基础设施的一部分。

2026-04-23 17:09:12 388

原创【Backend Flow工程实践 03】为什么 Tcl 是 EDA Flow 自动化的核心胶水语言？

为什么 Tcl 是 EDA Flow 自动化的核心胶水语言？命令系统设计数据库参数体系流程编排可观察性可复现性所以，Tcl 在 EDA Flow 里的价值，从来不只是“会不会写脚本”。把复杂 EDA 工具，从一个主要依赖交互操作的应用，变成一个可以被控制、被观察、被复用、被沉淀的工程系统。这就是它为什么会长期处在 EDA 自动化体系中心位置的原因。

2026-04-23 17:05:28 353

原创【Backend Flow工程实践 02】EDA 工具启动背后的状态空间：路径、初始化、日志与命令流如何共同决定一次 Session

LogSystem,第一，EDA 工具运行结果由多个状态变量共同决定，不是单个 Tcl 脚本决定。第二，隐式初始化和个人 HOME 配置会降低工程可复现性。第三，显式 source、显式 log、显式 tmp、显式工具路径，是可复现 flow 的基础。第四，command log 和 summary log 是 session 可观测性的核心。第五，EDA 自动化的本质，是管理工具 session 的状态空间。

2026-04-20 15:20:46 379

原创【Backend Flow工程实践 01】为什么 EDA 工具真正的第一步，不是导入设计，而是建立可复现运行环境？

第一，EDA flow 的第一步不是导入设计，而是固定工具 session 的上下文。第二，HOME 级隐式初始化不适合作为项目可复现依赖。第三，项目初始化、日志路径、命令流和临时目录都应该显式化。1. 工具路径显式指定2. 工作目录显式指定3. 项目初始化显式 source4. 日志路径显式指定5. tmp 目录显式指定6. 命令流保存为 Tcl 文件7. 关键环境变量用 setenv 传递8. 不依赖个人 HOME 隐式配置。

2026-04-20 15:12:30 347

原创 VCD-＞WGL 不是终点：它怎样接到 ATE、WGL 合并和可综合 Testbench

很多工程问题之所以后来变成瓶颈，不是因为它们本身太难，而是因为它们在早期被误认为“只是个小步骤”。VCD->WGL就很典型。读个 VCD写个 WGL够用就行那它迟早会在后面的 ATE 使用、多 WGL 合并、Testbench 生成、加速执行链路里暴露出大量问题。这一步真正做的是“把仿真语义整理成测试可消费的结构化资产”那它就不再只是一个转换脚本，而会变成测试自动化体系里一个非常有价值的中间层能力。表面上看，它在转换文件实际上，它在衔接系统而基础设施的价值，往往就藏在这种“衔接”里。

2026-04-14 12:18:45 425

原创为什么 VCD-＞WGL 脚本最后都要重构成 C++ 工具？

为什么很多 VCD->WGL 脚本最后都要重构成 C++ 工具？为了性能为了维护为了扩展为了接入现有平台这些都对。因为问题已经变了。怎么把 VCD 先转成 WGL。怎么让这条转换链长期稳定、可维护、可复用、可集成。当问题从“单次完成任务”变成“长期支撑流程”，原来的脚本式思维就一定会碰到边界。所以，真正要重构的，不只是语言，不只是文件读写逻辑，甚至不只是某几个函数。真正要重构的，是从“救火原型”走向“基础设施工具”的思维方式。而这，恰恰也是很多芯片测试自动化系统真正开始变成熟的标志。

2026-04-13 14:04:51 406

原创 VCD 转 WGL，真正难的不是“改格式”，而是“怎么采样”

ATE 或 pattern 执行环境并不总是接受“你看到什么就照抄什么”这种处理方式。xz未驱动状态双向口切换过程中的过渡值到底是保留、屏蔽、转成 don’t care，还是转成有效位控制，往往都需要明确策略。所以从工程角度说，VCD -> WGL从来不是一个纯粹的格式问题，而是一个采样策略问题。你如何定义“一拍测试向量”的生成规则。今天输出 WGL明天输出内部中间格式后天接入别的 pattern 组织方式但只要你的采样语义是稳定的，整个工具链就有可复用基础。代码写得很快。

2026-04-13 13:40:16 381

原创双向管脚、有效位与用例切换：一个 Testbench 如何跑通多种 Pattern？

一个统一 Testbench 想跑通多种 Pattern，关键不在文件数量，而在是否把“管脚角色、有效性和切换边界”都建成了显式语义。你是不是生成了 input.txt你是不是生成了 output.txt你是不是给 testcase 编了号当前谁该驱动当前谁该比较当前哪些 pin 有效当前 testcase 的角色上下文是否已经切换完成当前管脚控制权有没有被正确释放或接管这些问题一旦没处理好，多 Pattern Testbench 就很容易停留在“结构存在、行为混乱”的状态。

2026-04-09 14:51:05 332

原创多测试用例合并最难的地方，不是生成文件，而是时钟与时序偏移对齐

多测试用例合并的真正难点，不在文件层，而在时间层。同一个精度基准同一套时钟解释框架同一个周期边界机制同一套偏移触发体系只有这样，输入激励、输出采样、结果比较才不会在跨用例复用时逐渐漂移。所以从工程价值上看，第7篇真正要强调的不是：“offset 怎么写”为什么没有统一的时钟与偏移模型，多测试用例合并就只会停留在文件层面的成功，而不是执行层面的成功。

2026-04-09 10:45:12 386

原创一个可综合 Testbench，到底由哪些关键部分组成？

为什么把多份 WGL 合并成一个可综合 Testbench，吞吐会提升。这个可综合 Testbench 到底是由什么搭起来的。结论并不复杂：统一接口的hw.v记录用例时钟信息的参考时钟记录文件承载激励与期望的向量文件负责结构连接的ate.v负责执行控制的ate_tb.v但真正重要的，不是记住这些文件名，而是看懂它们各自承担的工程角色。因为一旦你看懂了这五部分的职责分工，你就会发现：所谓“可综合 Testbench 生成”，本质上是在搭一套可执行、可扩展、可复用的验证运行框架。

2026-04-08 11:41:53 372

原创为什么多 WGL 合并成一个可综合 Testbench，能明显提升验证吞吐？

很多验证系统表面上看性能不足，实际上问题并不在运行阶段，而在执行组织方式。如果每个 WGL 都单独生成、单独编译、单独运行，那么再快的平台，也会被不断重复的前处理拖住。把多个 WGL 组织进统一的可综合 Testbench 包让多个测试共享一套接口、框架和逻辑实现用一次编译结果承载更多连续执行的测试任务整个平台终于开始以“吞吐”而不是“单次运行”来工作。这也是为什么，多 WGL 合并成一个可综合 Testbench，不该被理解为一个简单的文件生成技巧，而应该被看作验证加速链路中的关键工程抽象。

2026-04-08 10:41:01 359

原创 JTAG 状态机不是黑盒：TDI / TMS / TCK / TDO 是怎样一步步“推出来”的？

最后一位最容易在工程实现中出错。当前数据流的最后一个 bit当前 Shift 状态的尾拍下一状态跳转的触发点这类问题如果不在驱动层处理清楚，生成出来的向量就会出现“看起来 bit 对了，但状态不对”的隐蔽错误。为什么模板层已经得到，还不能直接认为向量生成完成？因为从工程上看，那只是事务级描述，不是位级执行结果。逐拍可执行的 TMS 路径逐位可发送的 TDI 序列统一节拍下的 TCK 结构可采样、可比对的 TDO 窗口。

2026-04-07 14:05:12 193

原创把芯片测试任务拆成基础模板：DP/AP 读写为什么是关键抽象？

很多芯片测试自动化系统，前期推进很快，后期却越来越难维护。表面上看，是测试场景越来越多；本质上看，是一开始没有找到合适的基础抽象。在基于 JTAG / DAP / AHB 访问链路的测试系统里，很多复杂任务最终都可以被还原成四类基础动作：DP 写、DP 读、AP 写、AP 读。真正决定系统能不能平台化演进的，不是支持了多少“任务脚本”，而是能不能把大量上层测试需求稳定地压缩到这四类基础模板上。

2026-04-07 10:48:40 362

原创从功能测试指令到 JTAG 向量：一种模板化生成方法

文章摘要：本文提出了一种创新的芯片测试向量生成方法，通过将"功能测试指令"直接转换为JTAG测试向量，替代了传统的基于波形的冗长流程。该方法的核心是建立"指令模板层"，将测试意图映射为协议操作数据，特别是针对DP/AP读写等基础操作建立标准化模板。通过JTAG状态机驱动，将协议数据转化为具体的TDI/TMS/TCK/TDO时序组合，实现了从测试语义直接生成向量的范式转变。相比传统方式，这种模板化方法显著降低了修改成本，提高了复用性，更适合ATE场景和平台化发展，为测试

2026-04-06 15:23:35 426

原创为什么传统功能测试向量生成流程越来越慢？从 WGL、JTAG 到可综合 Testbench 的工程拆解

在芯片功能测试与验证流程中，很多团队仍然沿用“testbench/testcase → 仿真波形 → WGL/STIL → ATE 或后续验证”的传统链路。这条流程在测试用例较少时还可以接受，但一旦进入批量回归、ATE 联调、加速仿真和复杂 SoC 验证阶段，效率往往会迅速下降。问题并不只是“脚本跑得慢”，而是整条链路在变更成本、重复编译、多用例组织、时间精度统一、动态双向管脚处理等方面都存在系统性瓶颈。

2026-04-06 10:32:21 479

空空如也

空空如也