AI时代下的FPGA-MCU异构HIL技术链路讲解（长贴）

RAIN

在 AI 代码生成能力快速提升的时代，一些原本需要大量人工投入的复杂工程问题，已经可以通过“工作流拆分 + AI 代码生成/优化 + AI 辅助验证”的方式逐步完成。
在特定 HIL 场景下，系统往往不仅仅是单一硬件平台独立运行，而是需要多种不同架构的硬件进行协同交互。这里以 MCU-FPGA 架构为例。
MCU-FPGA 架构通常出现在这样一类场景中：系统同时存在高频实时计算、高精度求解、大矩阵计算或强并行计算需求，单靠 MCU 很难满足实时性和算力要求。因此，FPGA 会作为系统中的“特种兵”，承担其中最重、最难、最需要并行加速的部分。
但 FPGA 的开发体系与传统 MCU/CPU 体系并不相同。MCU 侧通常基于 C 语言和 CPU 内存执行模型进行开发，而 FPGA 侧则更多依赖 HDL 或 HLS 工具链，本质上是在描述硬件结构和并行计算逻辑。这也带来了更高的开发门槛、更复杂的时序约束，以及更难排查的工程问题。
而 AI 的价值，恰恰可以体现在这个过程中：它不一定能完全替代 FPGA 工程师，也不一定能直接生成最终可商品化的硬件方案，但它可以在代码生成、结构拆分、接口设计、测试用例构造、通信逻辑验证、仿真结果比对等环节显著提高开发效率。
以一个简单的闭环 PMSM-FOC 速度环控制 HIL 场景为例，我在工作中通常会按照以下链路推进整个工程从设计到落地：

• 基于场景需求进行系统级建模与功能拆分
• 完成 MIL 仿真，对控制逻辑和对象模型进行初步验证
• 进行 FPGA 侧算法结构优化和实时性优化
• 完成 FPGA 侧工程验证，包括综合、时序、接口和仿真验证
• 设计 FPGA 顶层结构、通信接口，并完成硬件落地
• 进行 MCU 侧控制算法优化和资源适配
• 完成 MCU 侧顶层设计、通信逻辑设计及工程落地
• 进行硬件级闭环 HIL 仿真验证，完成 MCU-FPGA-被控对象之间的闭环测试
  

在展开这条完整工程链路之前，我会先单独讨论两个和 FPGA 开发强相关的问题，也算是自己在工作中的一些阶段性心得：

• FPGA 代码生成：AI 能做到什么，做不到什么
• HLS 的意义：为什么它不是简单的“C 语言转 HDL”，但依然有工程价值
  

后续会围绕这两个问题展开，再结合 MCU-FPGA 异构 HIL 的具体工程链路，聊一聊 AI 时代下这类工程问题的开发方式会发生哪些变化。
本帖不讨论ZYNQ架构。

RAIN

# FPGA 代码生成：AI 能做到什么，做不到什么

## 一、FPGA 的开发语言

大家都知道，主流 FPGA 所使用的代码是 HDL（Hardware Description Language，硬件描述语言）。HDL 大类又包含两个体系，即 Verilog 和 VHDL。

Verilog：简洁、灵活、容易快速写 RTL。
VHDL：严谨、笨重，描述更加稳定。

Verilog 和 VHDL 的区别，好比一个青年学者和老学究。

VHDL 往往用于一些超长期使用，且底层代码不易变更的工程中。比如军工、航空、医疗等场景，底码变更难度巨大，会更倾向于使用 VHDL。我以前的房东年轻的时候就是写 VHDL 出身，他的 VHDL 一直写到 70 岁被辞退，也能看出来 VHDL 的历史之悠久。

Verilog 则是当下更流行的 HDL 语言。由于轻量级，更具有开发优势和代码量优势。同时到了 SystemVerilog 之后，接口、类型、约束和验证能力都有了更好的补充，因此更加好用。

楼主是数字 IC 设计出身，常年和这两个东西打交道。整体来讲，当下市场还是 Verilog/SystemVerilog 比 VHDL 用得更多。本帖后面所提及的 HDL 语言，主要特指 Verilog/SystemVerilog 这一套体系。

---

## 二、SystemVerilog 和 Verilog

在国内很多时候，大家讨论 SystemVerilog 和 Verilog，往往会说：

> SystemVerilog 用于验证，Verilog 用于设计。

事实真的如此么？

大错特错。

更准确地说，SystemVerilog 是 Verilog 的扩展增强，兼容传统 Verilog 代码。换句话说，Verilog 能做的事情，SystemVerilog 基本都能做。

SystemVerilog 额外提供了很多更适合现代工程的能力，比如更清晰的 RTL 描述方式、更好的类型系统、更方便的接口封装能力，以及对 C 更友好的 DPI 接口。这些能力不仅服务于验证，也服务于设计和工程组织。

但是这里也要注意，SystemVerilog 里面有一部分高级验证语法，比如 class、随机约束、coverage 等，是不可综合的，不能直接变成硬件。所以不是所有 SystemVerilog 语法都能用于 RTL 设计。

因此二者不是“SystemVerilog 只能验证，Verilog 只能设计”的关系。更准确的说法是：

> SystemVerilog 既可以用于设计，也可以用于验证；
> Verilog 可以理解为 SystemVerilog 体系中的一个旧子集；
> 只是 SystemVerilog 中的部分验证特性不可综合。

很多工程里嘴上说写 Verilog，实际已经在用 SystemVerilog 的语法。尤其在现在的 ASIC/FPGA 设计中，SystemVerilog 已经是更加工程化的写法。传统 Verilog 当然还能用，但如果一个新工程完全不使用 SystemVerilog 的增强能力，本质上就是自己给自己加难度。

---

## 三、传统 HDL 代码生成

不是所有的模型都能生成 HDL，不是所有的 HDL 都能烧到 FPGA。

这句话解释起来比较复杂。一旦涉及 HDL，由于其独特的 PPA 概念，也就是功耗 Power、性能 Performance、面积 Area，它就不是“生成代码之后就能用”的东西。

HDL 不是普通软件代码。C 代码只要编译通过，CPU 大概率就能按指令执行。但是 HDL 背后对应的是硬件结构，后面还要经过综合、实现、布局布线、时序分析、资源分析和板级验证。

所以 FPGA 工程里经常会出现这种情况：

能仿真，不代表能综合。
能综合，不代表能实现。
能实现，不代表能过时序。
能过时序，不代表资源合理。
资源合理，也不代表上板之后一定没问题。

这也是很多非科班出身的人对 FPGA 敬而远之的原因。它不是写完代码就完事，后面有大量硬件级二次开发工作。

从模型到静态 HDL 代码生成的效率往往很低，其根本原因是：你需要在模型层级就提前考虑 HDL 代码的时序和并行能力。

### 1. 并行能力的问题

一般来讲，工程上 FPGA，对性能是有需求的。FPGA 之所以快，就在于其特殊的并行能力和多 IO 能力。

但是从建模层级，很难真正操作和提升并行能力。模型更多描述的是系统行为、数学关系和信号流，它告诉你“这个系统怎么算”，但不一定告诉你“这个硬件应该怎么长”。

真正到 FPGA 里，需要考虑的是：

哪个循环要展开，哪个模块要流水，哪个数组要分区，哪个乘法要进 DSP，哪个存储要用 BRAM，哪个路径要打拍，哪个接口要流式化。

这些问题本质上已经不是单纯的模型问题，而是硬件微架构问题。

所以模型生成 HDL 最大的问题，不是“能不能生成代码文本”，而是“生成出来的硬件结构到底好不好”。

### 2. 时序违例的问题

从建模层级也很难真正处理时序违例问题。

即使有部分时序参数可调，也往往只是粗粒度调节。它可以给你一些参数和容差，但很难像 IC/FPGA 工程师一样，对关键路径、寄存器位置、流水结构、资源映射和布线压力做细节调整。

而时序问题往往又非常具体：

组合路径太长，乘加链太深，BRAM 端口不够，数组访问冲突，pipeline 插得不合理，模块之间握手反压，跨时钟域没处理好，接口协议拖慢吞吐。

这些东西不是模型层级点几个按钮就能彻底解决的。

而对于模型工程师来说，像 IC 设计工程师一样考虑 HDL 的综合行为、时序路径和硬件资源映射，更是天方夜谭。

所以 HDL Coder 类的静态编译器能用，但是不好用。

它可以解决一部分规则清晰、边界明确、性能压力不大的场景。但如果目标是高频、高性能、强实时的 FPGA 工程，后面大概率还是要 FPGA 工程师下场继续修。

RAIN

## 四、AI 时代下的 HDL 代码生成

我们不得不考虑一个大前提：

一个芯片工程师在写 HDL 的时候，完成工程后通过综合、实现和后仿真验证，观察到存在时序问题，是能够回来修的。

他知道哪里可能形成长组合路径，知道哪里需要打拍，知道哪里要流水，知道哪里可能映射到 DSP 或 BRAM，也知道哪里可能因为资源和布线导致时序炸掉。

而很多 HDL 代码生成的场合下，建模工程师们本来就不太会写 HDL，更别说自己去修时序违例、优化资源和硬件级算法速度了。

因此，AI 时代下的 HDL 代码生成依旧存在两个问题：

老问题：时序和并行。
新问题：HDL 代码训练数据少，生成结果往往不稳定。

### 1. 老问题的原因

AI 时代下，HDL 代码生成更加灵活，但它依旧绕不过时序问题和并行问题。

因为 HDL 表面上是代码，本质上是电路。

AI 可以生成文本，但是它不一定真正理解自己生成的东西在目标 FPGA 上会变成什么电路结构。功能写对，只是第一步。后面还有时序、资源、延迟、吞吐和接口问题。

很多时候真实工程最麻烦的不是功能跑不通，而是：

功能跑通了，时序不过。
时序过了，资源爆了。
资源没爆，延迟太大。
延迟压下来了，吞吐又卡住了。
仿真没问题，上板又出问题。

这些问题不会因为 AI 出现就自动消失。

所以 AI 直接生成 HDL，并没有从根本上解决时序和并行的老问题。

### 2. 新问题的原因

LLM 生成 HDL 的能力不稳定，这个没什么办法。

相比 C/C++/Python，公开的高质量 HDL 代码本来就少，而且 HDL 代码高度依赖工程上下文。不同 FPGA 厂商、不同工具链、不同项目规范、不同接口协议，最后综合出来的电路结果并没有一个完全统一的标准。

更麻烦的是，HDL 里有大量“能仿真但不可综合”的语句。AI 如果没有被严格约束，很容易生成一种看起来像 HDL、甚至仿真能跑，但是综合不了、时序很差、接口不规范、资源乱炸的代码。

这就是 AI 直接生成 HDL 的核心问题：

它不是完全不会写，而是它不知道自己写出来的东西最后到底是不是一个可用的硬件。

但是，AI 对 C 代码生成的能力，由于 C 代码的泛用性和训练方向的优先性，是极强的。

因此我们的思路是：把一部分 HDL 问题先拉到 C 层级去解决。

C 语言大家一般都看得懂，嵌入式也可以用，AI 生成速度快，验证也方便。模型生成的 C，或者人工写出来的静态 C，都可以先在 C 层级完成算法拆分、功能验证和结构优化。

后续再讨论如何从 C 进入 HLS-C，以及 HLS 在整个流程中的意义。

所以这里先不展开 HLS，只先说明 AI 时代下 FPGA 代码生成的一个核心变化：

> AI 不一定适合直接生成复杂 HDL，但非常适合在 C 层级做算法拆分、代码生成、结构改写、测试构造和初步优化。

因此，在 FPGA 代码生成这件事上，AI 更适合先干它擅长的部分，而不是一上来就强行生成最终 HDL。

也就是：

```text
模型 / 算法描述
        ↓
C / C++ 功能模型
        ↓
后续进入 HLS-C / HDL 工程链路
```

HLS下一章再讲，AI润色还是爽。

admin

来学习啦！

RAIN

# HLS：为什么它不是简单的“C语言转HDL”

在第二章的开头，我还是重申一下本人的立场。

> “最好和最烂的代码永远都是人写的。但是对于不追求极致的高流程化工作，自动化生成将会解放大量的时间，让工程师的精力放在算法和架构的设计上面。”

HLS在本篇文章中指代高阶综合技术（High Level Synthesis），其作用是通过HLS编译器，将C/C++语言转化为同等语义、同等功能的HDL语言。

HLS工具通常由FPGA厂商或EDA厂商提供，包括Xilinx的Vitis HLS、Siemens的Catapult、Intel的Intel HLS。不同厂家的HLS基本思想和功能类似，只是指令集、约束方式和工程流程存在差异。本文中所提及的HLS工具，主要指Vitis HLS。

此处我们不必深究HLS的底层原理。HLS作为工具，毕竟是拿来服务工程的。在AI时代，它也可以被AI拿来作为从C到FPGA实现的中间工具。

---

# HLS的问题

HLS技术出来很多年，但是用的人并不多，大多数在Lab里面用于算法方向的设计原型落地，而难以大规模商业化。其根本原因在于两点：

第一，HLS虽然是从C开始，到HDL结束的一键式生成，但是该技术链的门槛较高，精通更难。

第二，HLS生成的代码相较于手写代码存在性能劣势，即在PPA（性能Performance，功耗Power，面积Area）上，不如优秀工程师手写。

尽管在HIL工程的场景下，随着AI介入，这两者都会被一定程度上缓解，我们先回头讨论一下原因，以便于理解。

---

# HLS的门槛

HLS技术对初学者和非IC设计类工程师具有较高门槛。

因为HLS技术的初衷，是让工程师将设计和验证前移到C层级开发，从而在架构和抽象上获得更大的优势，跳过一部分繁琐的位级描述和RTL编写。

然而IC设计工程师对这种方式往往并不积极，因为科班出身的IC设计方向工程师更习惯直接使用Verilog/VHDL描述电路。对他们来说，HDL是直接可控的，而HLS反而隔了一层。

而不从事IC设计的工程师，虽然会写C，但是不知道自己写下的C最后会变成怎样的HDL。在C写得不符合HLS规范的情况下，甚至无法通过HLS编译器。

以楼主做过的EMTP算法移植优化为例，同一份C代码的生成结果前后速度差距26000倍，消耗的资源只增大了6倍。初学者和老手对编译器、流水线、数组分区、接口映射的理解不同，可能带来上千倍的加速比差距。

最终，尴尬的局面出现了：

会的人不想用，想用的人不会用。

当然，时代变了。我们通过通用大模型AI，可以帮助我们解决一部分门槛问题：HLS工程源码的构建和迭代。

---

# HLS的性能

HLS生成代码的质量虽然远超很多简单的自动生成工具，但是不如优秀工程师手写代码。

HLS基于高抽象层级代码C生成低抽象层级代码HDL，其需要补足大量C语言中不存在的物理信息。因此为了保证语义和功能一致，HLS需要结合实际HDL语法特性，对C代码的硬件实现方式进行补足。

这种补足不会比人工直接描述逻辑功能来得更精确，因此HLS生成代码的性能、功耗、面积通常都不如人手写。

硬件设计的本质是速度与资源之间的平衡。如果需要逼近人类手写的性能，那么往往就需要付出更大的面积。

但是，在FPGA上，这样的权重关系发生了变化，也带来了特殊的工程价值。

RAIN

# HLS的优势：依然有工程价值

在当前时代，我们通过AI生成HLS-C/C++代码后，可以回避大量手写RTL带来的二次开发问题，同时整体仿真性能与手写RTL之间的差距，在部分工程场景下可以被资源开销抹平。

正如英语是世界上的通用语言，C语言则近乎程序员界的通用语言。

借由C作为中转站，将模型拉到C层级不仅为C生成HDL提供了前置条件，同时C到HLS-C的过程由于有AI的分析和参与，也存在对代码进行二次优化和精炼的空间。

上述门槛问题和性能问题能够被缓解，原因如下。

---

# AI的加持

随着Codex的出现和通用大模型的迭代，AI对于C代码的生成能力和优化能力已经超过了一般的软件工程师。

而HLS的门槛问题，也可以通过以下链路进行缓解：

AI读指令集 → AI修改C代码 → AI建立工程 → AI阅读报告 → AI自我迭代。

这一链路的思路来源于论文《A2H-MAS: An Algorithm-to-HLS Multi-Agent System for Automated and Reliable FPGA Implementation》。

借由通用大模型的自我迭代能力实现工具的使用，再借助HLS相对稳定可靠的综合能力，回避AI直接生成HDL带来的大量二次开发问题，这是AI时代的红利。

---

# FPGA的场景

尽管HLS的PPA不如手写，但是在FPGA的场景下，我们作为开发者，更多关注的是FPGA做什么，而不是FPGA内部每一个细节怎么做。

因此，在HIL场景下，对性能的敏感程度要远高于对面积和功耗的敏感程度。HLS的优化策略中，可以让AI更关注性能，也就是单步运行速度，从而花费更多资源去让代码运行速度接近手写。

通常情况下，在复杂HDL工程中，对比IC设计工程师手写RTL，HLS会带来一定的额外资源量开销。

但FPGA板卡本来就有充足的冗余资源，不用白不用。因此在我们的HIL场景下，HLS的性能问题不再是绝对关键问题。

真正关键的是：

能不能满足实时步长。  
能不能跑通闭环。  
能不能在板卡资源范围内完成部署。  
能不能减少工程师手写RTL的时间成本。

---

# HLS的原理

HLS的底层原理较为深奥，其前置需要计算机工程（Computer Engineering）、数字电路、编译原理和体系结构等基础。

推荐书目：

《High-Level Synthesis Blue Book》  
《Vivado Design Suite User Guide: High-Level Synthesis》

本文不深入讨论HLS底层原理。这里更关心的是，在AI时代，HLS能否作为AI生成C代码到FPGA硬件部署之间的中间桥梁。

admin

RAIN 发表于 2026-5-12 21:44
# HLS的优势：依然有工程价值

在当前时代，我们通过AI生成HLS-C/C++代码后，可以回避大量手写RTL带来的二 ...

校长的RT Manager需要FPGA的us级实时仿真能力，RAIN大神给出个主意，怎么样的技术架构能够快速实现FPGA与CPU的通信和协作，升级为us级别实时仿真机。

RAIN

admin 发表于 2026-5-12 22:12
校长的RT Manager需要FPGA的us级实时仿真能力，RAIN大神给出个主意，怎么样的技术架构能够快速实现FPGA与C ...

校长，us级别的仿真需要两个能力，一个是通信够快，一个是算法够快。
通信
us级仿真锁死了PCIE架构，FPGA要用PCIE可以通过AXI，IP核外封AXI协议，AXI外封PCIE。PCIE+AXI会有大量的资源损耗，选型需要从KU060向上兼容，有更为充足的资源兼容协议和算法。
算法
us级别步长的仿真能力取决于算法结构，算法结构对代码结构的影响分为两种：“机器视觉算法”及“工程闭环算法”，前者是串流，后者存在是自迭代。前者依赖Array partition指令吃BRAM，但是可以近乎无限的并行。后者存在数据依赖，需要判断假性依赖，并使用门级pipeline设计（Matlab的子系统级pipeline不行），通过HLS对固定算法做优化。

admin

RAIN 发表于 2026-5-13 10:40
校长，us级别的仿真需要两个能力，一个是通信够快，一个是算法够快。
通信
us级仿真锁死了PCIE架构，FPGA ...

开关产品，要求几十K，几百KHz，这种只要FPGA计算就可以了，不需要计算时同时跟CPU通信。这种方式直接使用Simulink的Block生成HDL语言综合部署到FPGA是不是可行？

RAIN

admin 发表于 2026-5-13 10:43
开关产品，要求几十K，几百KHz，这种只要FPGA计算就可以了，不需要计算时同时跟CPU通信。这种方式直接使 ...

原理上能跑，但是可能存在时序问题需要修。