从「DFT工程师」到「不可替代的IC人」：Blog重构计划

写给自己的路线重构。核心问题：AI时代，什么样的IC工程师不会被淘汰？
答案：能做判断和决策的人，而不是翻译spec为代码的人。

一、现状盘点：我已经走到了哪里

回顾「从零开始的DFT工程师」前5周 + 特别篇，已完成的内容如下：

已完成	内容	属于哪个能力维度
Week 1	Verilog/SV环境搭建 + 语法复习	编码基础（会被AI替代的层）
Week 2	Makefile/Python/TCL 自动化脚本	工程效率（有价值但不稀缺）
Week 3	UVM环境搭建 + 第一个测试	验证编码（会被AI替代的层）
Week 4	UVM进阶：callback/TLM/RAL	验证编码 + 方法学入门
Week 5	SystemC基础	软硬件协同的种子
特别篇	Synopsys安装/Verdi/远程连接/SV语法	工具使用
课外	GPU Programming(宾大课程+光追)	体系结构的种子
课外	Chisel 入门	硬件设计新范式
在研	CIM SoC (FPGA) / RISC-V GPGPU	实际项目经验

诚实的评估：前5周主要在”编码基础”和”工具使用”层面，这些是必要的，但恰恰是AI最容易替代的部分。好消息是，你已经有了种子——SystemC是软硬件协同的入口，GPU编程是体系结构理解的入口，CIM项目是PPA直觉的入口。

二、四大能力支柱：重新定义学习目标

以后的每一篇 blog，都应该能归入以下至少一个支柱：

支柱 A：体系结构深层理解

不是背状态机，而是理解 为什么这样设计

你的缺口：只学过计组，没学过体系结构。
你的优势：正在做CIM SoC和RISC-V相关项目，学了CUDA，有硬件直觉。

具体要补的内容（按优先级）：

Memory Hierarchy 的 Why
- 为什么现代处理器cache层次是这样的？cache coherence到底在解决什么问题？
- 从你的CIM项目出发：存算一体的本质就是在挑战传统memory hierarchy，你比别人更有切入点。
- 推荐：CMU 18-447 / ETH Design of Digital Circuits 的相关章节，不需要全看，按需查。
并行架构的 Trade-off
- SIMT vs SIMD vs Dataflow，为什么GPU选了SIMT？为什么AI加速器倾向Dataflow？
- 从你的CUDA学习出发：写完kernel之后回过头理解warp scheduler的设计决策。
- 推荐：读NVIDIA的GPU Architecture Whitepaper（Ampere/Hopper），配合你写的CUDA kernel理解。
指令集与微架构的解耦
- 从你的RISC-V项目出发：RISC-V的扩展指令集设计哲学，custom extension怎么做。
- 推荐：RISC-V Spec 的 Volume 1 前几章（精读），Patterson & Hennessy 按需翻。

Blog 怎么写：每篇不是笔记搬运，而是回答一个 Why 问题。比如”为什么CIM架构要这样设计数据通路？”，而不是”CIM的数据通路是什么样的”。

支柱 B：PPA 直觉与物理感知

你写的RTL最终要变成门和版图，对timing/power/area的直觉决定了你是coder还是designer

你的缺口：没跑过综合，没接触过后端flow。
你的优势：CIM项目有FPGA实现，这是绝佳的练手场。

具体要补的内容：

综合基础（最优先）
- 用 Design Compiler 或 Yosys 综合你自己写过的 RTL
- 学会看 timing report 和 area report
- 核心直觉：什么样的 RTL 写法会导致 timing 收不敛？什么写法面积大？
时序约束基础
- 学会写基本的 SDC（create_clock, set_input_delay, set_output_delay）
- 理解 setup/hold violation 在实际综合中的表现
功耗感知
- 动态功耗 vs 静态功耗，clock gating 的原理和实现
- 从你的CIM项目出发：低功耗设计在存算一体里为什么特别重要？

Blog 怎么写：以你的实际项目为载体。比如把你CIM项目里的一个模块拿出来综合一下，记录”我改了这一行RTL，timing从-0.2ns变成+0.1ns”的过程，这种实证性的内容比任何教科书都有说服力。

支柱 C：验证方法学——“怎么想”

最好的验证工程师不是写最多testbench的人，而是”能想到别人想不到的bug场景”的人

你的缺口：UVM语法学了，但还没真正做过一个从testplan到coverage closure的完整流程。
你的优势：UVM基础已经有了，callback/TLM/RAL都碰过。

从 Week 6 开始，验证部分的学习重心应该转向：

Testplan 思维训练
- 拿一个你熟悉的模块（比如CIM里的一个控制器），不写代码，先写testplan
- 问自己：哪些功能点需要覆盖？边界条件在哪？什么情况下这个模块会死锁？
- 这个过程中，AI帮不了你——因为它不了解你的设计意图。
Coverage-Driven Verification 实战
- 定义 functional coverage model：不是”所有信号都toggle过”，而是”所有有意义的功能场景都被执行过”
- 学会看 coverage report，找 coverage hole，针对性补测试
Formal Verification 入门
- SVA（SystemVerilog Assertion）你已经在Week5计划里了，要真正用起来
- Formal 的思维方式和仿真完全不同：你在描述”什么是对的”，而不是”给一组激励看结果”
- 推荐：JasperGold 的 tutorial，或者开源的 SymbiYosys
- 这个方向特别值得深入——AI写testbench容易，但写正确的property很难
Bug 分析与 Debug 思维
- 每次遇到bug，不只是修，而是记录：这个bug的root cause是什么？它属于哪类问题？什么样的coverage或assertion能提前抓住它？
- 积累久了，你会形成”bug直觉”——这是无法被AI替代的核心能力

Blog 怎么写：记录完整的验证故事，不是”我搭了一个UVM环境”，而是”我验证了X模块，testplan是这样设计的，coverage model是这样定义的，最后在Y场景下发现了一个Z类型的bug”。

支柱 D：软硬件协同设计

站在软硬件的边界上工作，这是你技术栈的最大隐藏优势

你的缺口：各技能点分散，还没有一个项目把它们串起来。
你的优势：C/C++、Python/PyTorch、SystemVerilog/UVM、SystemC、CUDA、Chisel 你都碰过——这个技术栈的广度在同龄人里非常少见。

具体发展方向：

Performance Modeling（和你的研究直接相关）
- 用 SystemC TLM 或 C++ 搭建你 CIM 架构的性能模型
- 核心问题：在真正做 RTL 之前，能否用高层模型预测性能瓶颈？
CUDA ↔ 硬件加速器的映射
- 你学 CUDA 不只是为了写 GPU kernel，而是理解”一个并行算法怎么映射到硬件”
- 未来可以做：给你的 CIM 加速器写一个软件 driver/runtime，类似 CUDA 对 GPU 做的事
AI 工具集成到你的工作流
- 用 LLM 辅助生成 UVM testbench boilerplate → 你来做 testplan 和 coverage 决策
- 用 LLM 辅助写 RTL 初版 → 你来做架构选择和 timing optimization
- 把这个过程记录下来，本身就是很好的 blog 内容

三、Blog 系列重构方案

改名与定位

原系列「从零开始的DFT工程师」可以继续保留作为子系列，但整体 blog 技术板块建议升级为一个更大的框架。建议的组织方式：

技术板块（主页）
├── 🏗️ 从零开始的DFT工程师（原系列，继续更新）
│   ├── Week 1-5（已完成，保持原样）
│   ├── Week 6+（继续，但每篇标注涉及哪个支柱）
│   └── 特别篇（工具安装等，保持原样）
│
├── 🧠 体系结构笔记（支柱A，新系列）
│   ├── 从CIM理解Memory Hierarchy
│   ├── GPU架构：从CUDA kernel到Warp Scheduler
│   ├── RISC-V扩展指令集设计
│   └── ...
│
├── ⚡ PPA实证录（支柱B，新系列）
│   ├── 第一次综合：我的RTL到底多大多慢
│   ├── Timing Closure实战
│   ├── Clock Gating与低功耗设计
│   └── ...
│
├── 🔍 验证思维（支柱C，从DFT系列分化）
│   ├── 我的第一个完整Testplan
│   ├── Coverage-Driven的完整流程
│   ├── Formal Verification入门
│   ├── Bug故事集
│   └── ...
│
├── 🔗 软硬件协同（支柱D，新系列）
│   ├── SystemC性能建模实战
│   ├── CUDA学习路线（已有，可迁入）
│   ├── 给加速器写软件栈
│   └── ...
│
└── 🤖 AI辅助IC设计（贯穿性主题）
    ├── 用LLM写RTL：哪些能用，哪些不能
    ├── AI辅助验证的workflow
    └── ...

原 DFT 系列 Week 6+ 的调整

原计划 Week 6 往后是 auto UVM test、AI accelerator pipeline、systolic array等。建议调整如下：

原计划	调整后	变化
Week 6: auto UVM test	Week 6: 用AI辅助生成UVM boilerplate + 你亲手写testplan	从”学怎么写”变成”学怎么想”
Week 7: AI accelerator pipeline	Week 7: 设计一个简单pipeline + 综合它，看timing和area	加入支柱B
Week 8: systolic array	Week 8: systolic array设计 + 写performance model对比RTL	加入支柱D
Week 9: systolic array验证	Week 9: 完整的coverage-driven验证流程	支柱C的核心实战
Week 10: log parser	Week 10: 用Python做coverage分析 + AI辅助debug workflow	工具 + AI集成
Week 11: DFT scan/MBIST/JTAG	保持，但加上 “为什么需要DFT”的架构视角	加入支柱A
Week 12: RTL2GDSII	保持，这本身就是支柱B的核心内容	已对齐

每篇 Blog 的写作模板建议

以后每篇技术文章，开头标注：

---
支柱: [A/B/C/D 中的一个或多个]
本篇核心问题: "为什么XXX？" 或 "如何判断XXX？"
AI能做的部分: [列出哪些是AI辅助完成的]
AI做不了的部分: [列出哪些是你自己的判断和决策]
---

这样做的好处：

强迫自己思考每篇文章的价值在哪里
读者能看到你在做什么层次的思考
积累久了，你的blog本身就是能力证明

四、具体行动计划（接下来 3 个月）

Month 1：补体系结构 + 验证思维转型

体系结构（支柱A）：

读 NVIDIA Ampere/Hopper Architecture Whitepaper，写一篇 blog 回答”GPU为什么用SIMT”
结合你的 CUDA 学习，每写一个 kernel 都记录”这个优化在硬件层面意味着什么”

验证思维（支柱C）：

挑一个你CIM项目里的模块，不写代码，先写一份完整的 testplan（Word/Markdown都行）
然后基于 testplan 搭建 coverage model，记录整个思考过程

继续 DFT 系列：

Week 6 按调整后的计划推进

Month 2：PPA直觉建立 + 软硬件协同起步

PPA（支柱B）：

用 Design Compiler 或 Yosys 综合你写过的一个 RTL 模块
写一篇 “我的第一次综合” blog，记录 timing report 怎么看、area report 怎么解读

软硬件协同（支柱D）：

用 SystemC TLM 给你的 CIM 设计搭一个 cycle-approximate 性能模型
对比 RTL 仿真结果和 SystemC 模型的预测，记录差异

继续 DFT 系列：

Week 7-8（pipeline + systolic array + 综合 + 性能建模）

Month 3：整合 + AI工作流

整合：

Week 9-10 做一个完整的 coverage-driven 验证闭环
记录一个完整的 “bug故事”：从发现到定位到修复到防御

AI 工作流：

记录你用 LLM 辅助 IC 设计的真实体验
哪些场景有效（boilerplate生成、文档查询、代码审查）
哪些场景无效（架构决策、timing分析、corner case发现）
这本身就是非常有价值的 blog 内容，因为很少有IC从业者在系统性地做这件事

五、一句话总结

以前的 DFT 系列在回答”怎么用”，以后的 blog 要同时回答”为什么”和”怎么判断”。

“怎么用”这个问题，AI 回答得越来越好。

“为什么这样设计”和”这个方案行不行”，在可预见的未来，还是得你自己来。

Last updated: 2026-03-21