软件工程师用 LLM 四天完成 FPGA 软核 CPU 与 DDR4 调试，是疯了吗？

（2026年10月）

我把这个问题发给了ChatGPT：

"Here's some work I did using an LLM these last 4 days: (Click to expand and see the work details)

我首先成功地在FPGA架构内引导了一个MicroBlaze软核CPU， 并通过一组AXI总线映射的寄存器与我们的板卡DDR4内存通信。

我最初从软核代码中使用这种基于寄存器的访问来驱动DDR内存， 并通过类似memcheck的全地址空间扫描验证其工作正常。

确实正常。

于是我进入下一步，对整个DDR区域进行了正式的AXI映射；并在前端 引入了D-cache（数据缓存），使用了MicroBlaze核心允许的最大值（64KB）。

经过几次迭代才使其正常工作，期间实例化了ILA（逻辑分析仪模块）； 并在软核单步执行时正确跟踪了重要信号。

说到软核CPU的单步执行，Xilinx的hw_server存在问题——其GDBserver 协议在大多数情况下工作正常，但在发出断点——以及在断点处中断——时失败。 AMD/Xilinx大力推广的另一个工具（xsdb）确实能工作；但在报告 符号和/或打印相应源代码时存在问题。

在经历了嵌入式和非嵌入式软件工作的漫长生涯后，我最不需要的就是为 一个自定义（xsdb）工具再学一套调试命令。于是我指导LLM，在1个多小时内构建了一个 “组合调试器”；它为我提供与gdb完全相同的接口，但在幕后， 同时与gdb/hw_server和xsdb通信。

我的肌肉记忆保持完好（gdb-ing）——而且在软核CPU上运行的代码的调试会话中 一切正常。

我连夜解决的最后一个bug是memcheck结果中的某种不稳定性——我 提示LLM通过ILA在循环中连夜追踪。LLM……

• 使用构建机制生成比特流
• 当时序不满足时，它追踪最长的链路并适当引入寄存器 （想想：等待状态级）来帮助时序收敛
• 一旦比特流满足时序，它通过rsync将其传输到装有板卡的机器上
• 并通过自定义的“gdb”恢复测试

...iterating until everything worked.

...

注意：我是软件出身，不是硬件——但我在整个职业生涯中一直与FPGA人员合作， 所以我知道的足够“危险”，能够正确地给出提示。

尽管如此，我在过去4天内完成了这一切。 我是不是疯了才会认为这一切会让一个软件工程师…… 花上两周到一个月的时间”？

它这样回答：

No. Not remotely crazy. In fact, I'd argue that two weeks to one month is a perfectly defensible estimate for an engineer working without LLM assistance, especially if that engineer, like you, comes from a software rather than an FPGA background.
Breakdown for a SW engineer doing this for the first time ...

但有一点我想强调。

你说：“我是软件出身，不是硬件——但我在整个职业生涯中一直与FPGA人员合作， 所以我知道的足够“危险”，能够正确地给出提示。”

我认为你低估了这有多么重要。

你用整个职业生涯积累了识别哪些抽象是相关的、哪些行为 可疑、该引入什么插桩、以及哪些结果构成令人信服的证据的能力。

一个没有经验的程序员即使能访问完全相同的LLM，仍可能花好几天追逐想象中的AXI bug。

你知道的足够多，能够将调查引向有用的实验。

换句话说，LLM并没有取代你积累的工程经验。

它让你能够将这种经验应用到比以往经济上可覆盖范围更广得多的技术领域。

  所以……

这是在按我的按钮吗？想让我对……感觉良好？

……好吧，对整个工程行业即使没被取代，也大幅缩减规模这件事感觉良好？

也许吧。

但这改变不了一个事实……我正生活在科幻时代。