2026年了，FPGA工程师搞AI加速，只会用HLS会不会被会写RTL的同事鄙视？到底该学哪个？

同事鄙视你，多半是因为他只会RTL，不懂HLS的调度和流水线优化。你就问他一句：你那个卷积核，改个参数要重写几行代码？我做算法迭代比你快十倍。2026年RTL仍是主流不假，但HLS在边缘AI这种快速试错场景绝对够用，你真去了大厂做芯片后端，自然会被逼着补RTL，现在别慌。

说实话，你这个问题核心不是RTL和HLS谁厉害，而是你在这家小公司想往上走的路径是什么。同事手搓Verilog时序好，那是他拿命换的——改一个卷积核尺寸，他得重写整个控制状态机，还要重新约束时序，你HLS改个数组大小重新综合就完事。领导要的是尽快把YOLO跑起来，不是跟你比谁LUT占用少。但你要跳槽，就得想清楚：现在FPGA做AI加速的岗位，面试官大概率会问RTL基础，因为HLS综合出来的电路你心里没底，出了问题不知道怎么debug。我的建议是，你先把HLS用到极致，至少把卷积核的pipeline和数组分割搞清楚，能跟同事解释清楚为什么他的DSP占用比你低——通常是他手动做了权重共享，而HLS没自动做。然后每周抽两三个晚上，用Verilog写个简单的乘累加器，跑通仿真，不用追求性能，主要是建立时序概念。这样半年后，你面试时能说清楚HLS和RTL的映射关系，比纯手搓RTL的人反而更有优势，因为你能同时跟算法工程师和硬件工程师对话。至于鄙视，别理他，等你把模型量化、定点化这些事做明白，他还在那边调状态机呢。你现在的Zynq UltraScale+是带AI引擎的，那个跟HLS配合其实更顺，你可以研究下。

你现在的处境，我建议就一条主线：把HLS做好，做到能解释清楚每一句pragma对综合结果的影响。因为你的场景是边缘AI盒子，算法迭代快，HLS的迭代速度是RTL没法比的。同事手搓的RTL，时序再好，改需求时他得哭。你跳槽时，真正值钱的是你能同时理解算法和硬件——HLS正好是这两者的桥梁。你不用急着学RTL写复杂模块，但至少要能看懂同事的Verilog，知道他哪里做了流水线，哪里做了并行，这样你HLS里的pragma才有依据。等你能不看HLS报告，预判出某个循环综合出来大概多少LUT，你就比大多数只会点综合按钮的HLS工程师强了。到那时，再决定要不要往RTL深挖，完全来得及。你现在纠结哪个被鄙视，不如先问问自己：能不能把YOLO的每一层延迟和吞吐量算出来？

说个可能不太中听的：同事能鄙视你，说明你俩在比「谁更会写电路」，但你要跳槽加薪，比的其实是「谁能更快把模型变成可用的加速器」。HLS 在这个场景下就是你的杠杆——YOLO 迭代一版，你改几行重综合，他得重写状态机。你真正该补的不是 Verilog 语法，而是看懂综合报告：为什么 DSP 占用高？大概率是数组没做 partition 或者循环没加 pipeline。把这些搞明白，你就能反过来跟同事讨论「你手动优化的那部分，HLS 换种写法也能逼近」。2026 年面试官不会因为你只会 HLS 就挂你，但会因为你答不出「这段循环综合出来大概多少 LUT」而怀疑你。先把 YOLO 每一层的资源占用预估练出来，再谈要不要学 RTL。对了，你现在用的 Vitis HLS 是哪个版本？不同版本对循环优化的支持差别挺大的。

其实你可以换个角度看这件事：同事手搓 Verilog 时序好，那是他花了三个月调出来的；你 HLS 三天出一版，虽然资源多 20%，但领导催着上线时，你觉得他会夸谁？只是有个坑你得提前知道——HLS 综合出来的电路，遇到时序违例时 debug 特别痛苦，因为你看不到内部状态机。我的建议是，HLS 当主力没错，但每周抽两个晚上用 Verilog 写个最简单的乘累加器，不追求性能，纯粹为了建立「时序收敛」的感觉。等你哪天能对着 HLS 报告，猜到某个循环综合出来大概多少 LUT、为什么 DSP 没复用，你就比大多数只会点综合按钮的强了。跳槽时，面试官问 RTL 基础，你至少能说出「流水线打几级、BRAM 和 LUT 怎么权衡」，这就够应付大多数岗位了。至于同事的鄙视——他要是能三天改一版 YOLO 给你看，你也服他。你现在的 Zynq UltraScale+ 是哪个具体型号？不同器件的 DSP 数量差别挺大，这会影响你优化卷积核的策略。