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 工程师下场继续修。

四、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。

也就是：

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

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上，这样的权重关系发生了变化，也带来了特殊的工程价值。

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硬件部署之间的中间桥梁。

第一部分：MIL-基于场景需求进行系统级建模与功能拆分

一、MBD、HIL 与 AI 的关系

MBD 工程开发好比中华武术。

武是实力，是个人的强壮程度，也就是力量。
术是方法，是把力量打出去的手段。

放在工程场景下，武就是工程师对模型的理解，体现为自身的架构能力；而术则是工程师的代码能力、硬件调适能力。

AI 好比一把绝世利器，能够大幅度提高术的杀伤能力。

MBD 是 HIL 的武，HIL 是 MBD 的术，AI 是强化术的兵器。

也就是说，HIL 并不是单纯把模型烧进硬件里跑起来，而是要建立在前期系统级建模、功能拆分和模型验证的基础上。

如果没有 MBD，HIL 很容易变成单纯的硬件调试。
如果没有 HIL，MBD 又容易停留在离线仿真阶段。
如果没有 AI，工程效率依然会受限于人工建模、人工改代码、人工测试和人工分析。

所以，AI 的价值不在于把工程师变没，而在于把工程师从大量重复性的术里面解放出来。

模型怎么拆，系统边界怎么定，物理机理是否正确，最终仍然要回到工程师判断。

二、AI 与自动化建模

MBD 的起点在于模型。

然而，随着 AI 时代的到来，各家系统级仿真软件都开始推出自己的 MCP 工具，建模行为从过去的人工手动建模，逐渐转变为 AI 辅助自动建模。

老板说过一句话：

“凡是人工能操作的，AI 一定能干。如果 AI 干得不够好，那肯定是人工给的输入不到位。”

因此，AI 时代的建模流程，不再只是工程师手动拖模块、连线和调参数，而是逐渐变成：

人工给信息
    ↓
AI 建模
    ↓
AI 测试
    ↓
AI 分析
    ↓
回到人工判断

这里的关键不在于 AI 是否能够完全替代工程师，而在于工程师能不能把需求、边界、输入输出、模型结构和验证标准讲清楚。

AI 本质上是一个放大器。

工程师给出的信息越具体，AI 的输出就越接近可用模型。
工程师给出的信息越模糊，AI 就越容易自由发挥，最后生成一个看似完整，但实际偏离工程目标的模型。

此处将基于 Codex + ChatGPT 5.5，进行后续 AI 相关工作。

三、成功的 AI 建模

很多工程师在最初接触 AI 的时候，都会遇到一个问题：

“我描述了我的需求，但是 AI 给出了一个不准确的答案。后续我对需求不断修正，AI 不断为模型做出负优化，导致生成结果风马牛不相及，越做越偏离主线。”

这个问题的原因主要有两点：

1. 大模型在长对话中容易受到最新上下文和局部修正的影响，导致最初的建模约束被弱化。
2. 最初的建模约束不够具体，在存在多种实现路径的情况下，AI 会自行判断，最终生成的模型可能并不是工程师真正想要的模型。

举一个最简单的例子。

1. 模糊需求

我需要一个 SVPWM 模型。

这个需求本身没有错，但是太宽泛。

AI 不知道你需要的是算法模型、控制模型、逆变器控制模型，还是用于实时仿真的工程模型。

它也不知道输入是什么、输出是什么、是否需要载波、是否需要过调制、是否需要内部信号可观测、是否需要和逆变器模型连接。

因此，AI 只能根据通用理解自行补全。

一旦 AI 自行补全，就会引入大量不受控的工程假设。

2. 结构化需求

我需要一个 SVPWM，其结构包括 PARK 变换、CLARK 变换、扇区判断计算、Tcm 计算、过调制处理，以及合适的三角载波。

输入信号为内置的 3 相幅值为 311、相位差为 120° 的对称电压源。

输出结果为用于控制逆变器的 S1-S6 信号。

这段描述虽然仍然可以继续细化，但已经具备了基本的工程约束。

它告诉了 AI 模型结构、关键算法模块、输入信号、输出信号和工程用途。

两者的区别不在于有没有使用 AI，而在于有没有把工程约束说清楚。

AI 不是不能建模，而是不能在缺少约束的情况下，稳定地猜中工程师真正想要的模型。

在 MATLAB、MWORKS 等系统级建模软件中，都会有对应的 AI 接口或辅助建模工具。具体使用方式可以参考校长的帖子，或者对应软件的使用说明书。

本帖最后由 RAIN 于 2026-5-15 21:37 编辑

五、两种更工程化的 AI 建模思路

1. 模型物理公式 + 库模型指定建模。
2. C 代码 + 流程图建模。

1. 模型物理公式 + 库模型指定建模

第一种方式是：

物理公式 + 明确的库模型指定。

这种方式适合物理机理明确、模块边界清楚的场景。

例如，在搭建电机、逆变器、DC/DC、LLC、滤波器等模型时，不能只告诉 AI：

我要一个电机模型。

或者：

我要一个逆变器模型。

更好的方式是直接给出：

物理公式
输入输出定义
参数表
模型层级结构
需要调用的软件库模块
模型验证方式

这样做的好处是，AI 不需要自行猜测物理机理，也不需要自行发明模块结构。

工程师把物理边界和库模型边界定义清楚，AI 只负责把这些信息转化为可执行的建模过程。

这种方式的核心是：

人负责定义物理正确性，AI 负责提高建模效率。

2. C 代码 + 流程图建模

第二种方式是：

C 代码 + 流程图建模。

这种方式适合算法逻辑清晰、工程实现路径明确的场景。

很多控制算法本身已经存在 C 代码，或者可以通过伪代码、流程图描述清楚。

此时不一定要让 AI 从自然语言直接生成模型，而是可以先让 AI 读取 C 代码和流程图，再根据代码逻辑反向生成模型结构。

这种方式的优势在于：

C 代码已经包含明确的执行顺序
流程图可以补充算法结构和模块关系
AI 更容易判断模块边界
生成模型后更容易和原始代码进行一致性验证

对于 MBD 工程来说，这种方式尤其适合从已有算法向模型迁移，或者从模型向代码实现反推结构。

它的核心是：

不让 AI 凭空理解需求，而是给 AI 一个已经具备工程逻辑的中间表达。

这也是后续基于 Codex + ChatGPT 5.5 开展 AI 建模工作的基本逻辑。

第二部分：完成 MIL 仿真，对控制逻辑和对象模型进行初步验证

一、AI 构建激励源与测试场景

在模型搭建完成后，工程师往往需要构建模型应用场景，以进行 MIL 测试。

测试激励源和测试场景是可以由 AI 构建的。

其方式可以是自然语言生成、脚本生成、边界工况组合生成，也可以是基于历史测试数据的自动扩展。

在传统 MBD 工程中，MIL、SIL、PIL、HIL 任何一环的推进都离不开验证。

尽管存在自动化工具，工程师仍然需要一定的跨领域能力，去构建对应不同层级的测试例。

而在 AI 介入的工程中，验证工作的重点可以前移。

这里的“前移”并不是指后续 SIL、PIL、HIL 不再需要验证。

而是指：

在 MIL 阶段尽可能提前构建测试场景、输入输出基准和功能判据，为后续 SIL、PIL、HIL 提供统一的验证标准。

也就是说，MIL 不能替代 SIL、PIL、HIL。

MIL 能够提前固化的是功能逻辑、对象模型和测试基准。

SIL 仍然需要验证 C 代码和模型语义是否一致。
PIL 仍然需要验证代码在目标处理器、编译器和运行环境下是否一致。
HIL 仍然需要验证实时性、IO 接口、采样周期、量化误差、板级通信和闭环稳定性。

AI 的作用，是让同一套测试场景能够被快速迁移到不同平台。

MIL 测试场景
    ↓
形成标准输入输出数据
    ↓
迁移到 C 代码测试
    ↓
迁移到 HDL 测试
    ↓
迁移到板级 IO 测试
    ↓
对标同一套 golden data

通过这种方式，AI 可以基于同一套测试数据，生成不同平台的测试例，大幅提高后续工程落地效率。

二、一切的起点：标准 MIL 测试例构建

MIL 是整个 AI + MBD 流程中最重要的起点。

人工需要在 MIL 环节开始时，对 AI 生成的模型及测试例进行一次判断。

这是工程师最基本的能力。

判断的目的，不是简单看模型能不能跑通。

而是确认：

顶层设计是否符合实际工程场景
模型结构是否符合需求
输入输出边界是否清晰
控制逻辑是否正确
对象模型是否具备基本机理
测试结果是否满足最终验收指标

测试的执行、分析和自迭代工作，可以大量交给 AI。

但是，第一轮测试结果的判断，以及后续迭代完成的条件，必须由工程师在最初阶段给出。

换句话说，工程师需要把自己期望的“宏伟蓝图”传递给 AI。

AI 很擅长执行。

AI 也很擅长根据已有模型做测试、补脚本、分析曲线、生成报告。

但是 AI 判断的基准，大部分来自于：

“结果是否符合当前模型的运行逻辑。”

这并不等于：

“模型的物理机理一定正确。”

如果模型在搭建阶段缺少关键机理、关键参数或关键边界条件，那么 AI 仍然可能判断测试通过。

因为在 AI 看来，执行结果与当前模型描述是自洽的。

但“模型自洽”不等于“模型正确”。

这也是 AI 参与 MBD 工程时最容易出现的问题。

AI 能够判断一个模型是否按照它已有的结构正常运行，却不能天然判断这个模型是否符合真实对象的物理机理。

因此，一个成功的 MIL 构建，本质上是将 AI 的黑盒行为约束到固定的、明确的、可追溯的工程场景中。

三、测试数据的继承

在 MIL 阶段，经过 AI 在线测试生成的结果，一旦被人工认定合理且标准，就需要将该结果作为后续 SIL、PIL、HIL 的预期结果保存下来。

这套数据可以称为 golden data。

但是 golden data 不能只理解成输出曲线。

它至少应当包括：

测试输入
模型参数
初始状态
采样周期
求解器配置
输出结果
版本信息
允许误差范围

如果只保存输出结果，而没有保存对应的测试条件，那么后续阶段很容易出现结果对不上的情况。

例如：

步长不一致
初始状态不一致
solver 不一致
参数版本不一致
随机激励源不一致
浮点 / 定点误差不一致
IO 延迟没有对齐

这些问题都会导致后续 SIL、PIL、HIL 的结果与 MIL 对不上。

此时问题未必出在代码生成，也未必出在硬件实现，而可能只是测试基准没有被完整继承。

所以，MIL 阶段形成的 golden data，不应该只是一个结果文件。

它应该是一套完整的测试资产。

这套测试资产本身，将作为后续 MBD 开发过程中任何设计的测试例。

它可以被调用为：

模型测试例
C 代码测试例
HDL 代码测试例
板级 IO 收发测试例
闭环 HIL 测试例

在后续阶段中，AI 可以基于固定测试例数据，大量执行如下动作：

测试源构建
    ↓
平台封装
    ↓
对标 golden data
    ↓
误差分析
    ↓
自迭代修正

这样一来，AI 每次执行生成动作之后，都可以基于同一套标准数据进行自我验证。

四、golden data 的本质

需要强调的是，MIL 阶段形成的 golden data，并不代表物理世界的绝对真理。

它代表的是：

在当前工程需求、模型参数、测试条件和验收标准下，经过人工确认后的工程认可基准。

这一点非常重要。

因为 AI 从原理上只能提高结果的置信度，而不能保证结果一定正确。

尤其在涉及 AI 跨平台生成时，不同人给出的提示词不同，不同工具链生成的结果不同，不同编译器和硬件平台的执行细节也不同。

从最终结果上看，它们应该殊途同归。

但是从中间实现上看，它们可能完全不同。

这就会带来一个问题：

AI 生成的代码、测试脚本和封装逻辑，往往可读性较差，不便于人工逐行进行机理判断。

因此，人工不应该把所有精力放在逐行阅读 AI 生成物上。

更合理的方式是：

将涉及 AI 的流程视作黑盒，对结果进行判断。

而 golden data，就是判断这个黑盒是否可信的标准。

只要输入条件一致，输出结果能够在允许误差范围内对齐，那么当前生成结果就可以被认为满足该阶段的工程预期。

五、AI 参与下的 MBD 可追溯性

传统 MBD 流程中的可追溯性，来自于模型、代码、测试和报告之间的人工管理。

而 AI 参与之后，可追溯性的核心应当转移到测试基准上。

也就是说，AI 可以生成不同层级的模型、代码和测试脚本。

但所有结果都必须回到同一套 golden data 上进行判断。

MIL：确认模型和功能逻辑
    ↓
SIL：确认 C 代码与模型一致
    ↓
PIL：确认目标处理器执行结果一致
    ↓
HIL：确认硬件 IO、实时性和闭环行为一致

每一环都可以由 AI 辅助生成测试、执行测试、分析误差和修正问题。

但每一环的判断标准，都必须来源于 MIL 阶段经过人工确认的测试资产。

因此，在 AI 参与的 MBD 流程中，人工的角色并没有消失。

人工的角色从“逐个手工搭模型、写代码、造测试例”，转变为：

定义需求
约束边界
判断机理
确认基准
设置误差
管理追溯

AI 负责提高效率。

工程师负责保证方向。

这才是 AI 参与 MBD、HIL 工程时更合理的分工。

第三部分：进行 FPGA 侧算法结构优化和实时性优化

在此处主要讨论基于HLS高阶综合技术为大前提的代码生成手段，以Xilinx HLS 2024.1为例。

工具安装可参考如下流程：

https://blog.csdn.net/sunshine_atk/article/details/144216065

VitisHLS 是安装FPGA开发环境Vivado的附赠品。

一、HLS工程的起点

回到我们最初的思路，以及问题的大前提：

1.将问题拉到AI更擅长的C语言领域解决。手段多种多样，可以是手写，可以是AI写，可以是模型建模生成。

2.存在测试用例的输入和输出,用于保证AI的黑匣结果

前者保证了HDL生成代码的设计，而后者保证了HDL生成代码的验证

二、HIL场景下：HLS与HDL Coder的优劣

HLS是FPGA厂商提供的向上游（MIL/SIL）环节兼容的工具。

HDL Coder是Matlab厂商提供的向下游FPGA烧录兼容的工具

二者的能力都是承上启下。

参考论文：《Comparison of Different Design Alternatives for Hardware-in-the-Loop of Power Converters》

其结论很简单：

1.浮点数算法中，HLS占绝对优势，无论是占用资源还是生成的HDL延迟。

2.定点数算法中，在小规模HIL的串流式算法的设计中，HLS总体占较大优势。

3.定点数算法中，在大规模的，存在算法数据域复用/闭环写回的逻辑中，HDL Coder占优势。但文中未讨论基于HLS对算法进行数据流重构，该方法可通过回避假性数据依赖大幅加快HLS工程性能。

4.在以大规模矩阵为主体的算法中，HLS占绝对优势。

5.所有工程的迭代中，HLS的迭代和修改速度为"Medium"，开发效率高于手写的“Very High”和HDL Coder的“High”。

三、HLS的场景

以笔者的经验来说，HLS在POC模型阶段，和异构算法架构时，是非常合适的，如三环PMSM电机模型，LLC逆变器模型等迷你场景。

在异构算法中，我们往往为了保证算法在硬件中的速度，会将需要加速的部分拆出给FPGA运算，此时算法复杂度更低，而运算量更高，也是非常适合HLS的场景。

但是，在复杂程度等同于或大于EMTP完整算法（包含索引分配，大矩阵，多元器件模型，数据流重组）的算例下，不建议使用HLS，尽管它也可以做得很好。

因为此时HLS的门槛更高，为了达到高效率和可重构，工程师需要大量学习算法，C++及HLS底层，“为了解决问题而产生新的问题”是不可取的策略。

四、PMSM电机实时HIL中的异构架构

在通常仿真中，HIL的目的不用和大家多讲，而PMSM用FPGA仿真的好处就是能做到硬实时仿真。

我们考虑PMSM-FOC算法的闭环架构中，高低频侧结合硬件可以分为4个部分：

1.SVPWM部分（低频，MCU）

2.FOC控制部分（低频，MCU）

3.逆变器部分（高频，FPGA）

4.电机本体部分（高频，FPGA）

五、基于AI的FPGA侧算法HLS工程

工程输入如下：

1.FPGA侧的算法C代码，包括电机本体部分及逆变器部分，参考此前的“基于AI完成MIL”

2.基于MIL验证导出的golden data.txt， 即预期的输入和输出结果

工程输出如下：

无时序问题且符合对应板卡资源映射的，端口为自由协议指定的浮点数高精度 HDL IP核。

工程Skill如下：

输入指令：在该目录下建立Vitis_Proj文件夹，在该文件夹内建立Vitis_hls工程，该工程的FPGA型号xc7a35tfgg484-2, clk cycle=10ns, time uncertainty=5%。将顶层目录路径下的PMSM_Inv.c，PMSM_Inv.h文件（包含电机本体及逆变器）算法作为source导入该工程，顶层函数为MM_Selfdrive。AI会通过编写脚本，调用Powershell完成工程的构建，同时编写.tcl脚本借助Xilinx Vitis HLS 2024的控制台进行项目的初始化。

输入指令：将该PMSM算法的C代码进行结构检查优化，确认符合HLS综合需求，保证该电机算法的顶层函数输入接口为逆变器开关信号S0-S5，修改输出信号为电机三相电流Ia，Ib，Ic，wm,Te，theta，IP核接口基于ap_none协议。

AI会将之前的代码在该阶段生成为优化过的HLS-C，同时会尝试进行C-Synthesis确保生成C的格式符合IP核生成需求。但是该步骤只能保证功能成立，通过后续增加约束做二次综合以确保AI的综合结果符合预期。

输入指令：在Vitis_Proj文件夹下的VitisHLS工程编写C Sim流程用测试例，命名为PMSM_Inv_tb.c，该测试例的输入为signalData_tb.c对应的输入，输出结果命名为IaIbIc_HLS.txt，并将输出结果与Goldendata文件夹内的理想输出结果IaIbIc.csv进行对比分析。

通过对goldendata引入，让AI对生成的逻辑进行自查，从而保证生成行为不会偏离预期，用来预防“某些变量在HLS路径中由于算法构建产生了延迟关键路径的行为，AI进行了逻辑重组导致跨周期数据无锁存，连续运行结果出现偏差的情况”。

输入指令：进行综合，对顶层函数使用pragma pipeline，并进行报告分析，接受latency不为1的情况

焚诀。可以理解为对应大部分（几乎所有的）的工程算法的非串流形式。存在自我更新的通用优化策略。往往能够得到一个70分左右的优化结果，此处为双精度浮点HDL IP核生成，单精度速度和资源均能各快一倍，定点化基于自适应定点精度会比单精度再快60%以上，基于AI的浮点+定点混合精度预测本人已申请专利，请自行探索。

输入指令：在工作目录下新建export_IP文件夹，将IP核导出在该文件夹内。

导出IP核，给后面的Vivado工程用