首先选择合适的HLS工具链，如Xilinx Vitis HLS或Intel HLS，编写可综合的C++代码，避免动态内存分配、递归和复杂指针操作，使用ap_int、ap_fixed等HLS专用数据类型及#pragma指令优化循环、数组和流水线；通过C/C++功能仿真验证算法正确性后，利用HLS工具生成RTL IP核及协同仿真环境，构建C++测试平台与RTL模块的接口适配层，实现C/RTL协同仿真；在此过程中，通过比对C++与RTL输出结果、分析波形、检查接口信号与内部节点、结合断点断言及HLS综合报告，定位并解决软硬件行为不一致问题；该方法核心价值在于加速验证迭代、提早发现设计缺陷、降低调试复杂度，并打通软硬件验证鸿沟，确保C++算法在硬件实现中的功能一致性与性能最优。
配置C++与FPGA协同设计环境，特别是要搞定HLS（高层次综合）和RTL（寄存器传输级）的协同仿真，说白了，就是要把你写好的C++算法，通过工具“翻译”成硬件能懂的语言（RTL），然后让这个“翻译”出来的硬件模块，跟你的C++测试代码一起跑起来验证功能。这个过程的核心在于打通软件和硬件的验证链路，确保C++层面的逻辑在硬件实现后依然正确无误。
解决方案
要搭建这样一个环境，我们通常会遵循一套相对固定的流程，但其中细节和选择会影响最终的效率和体验。
首先，选择合适的HLS工具链是基础。目前主流的FPGA厂商都有自己的HLS解决方案，比如Xilinx的Vitis HLS（以前叫Vivado HLS）和Intel（Altera）的Intel HLS（集成在Quartus Prime中）。选定工具后，你需要在C/C++层面编写你的算法代码。这里有个关键点：你写的C++代码必须是“可综合”的，这意味着你不能随意使用所有的C++特性，比如动态内存分配（
new
/
malloc
）、递归、复杂的指针操作等。通常，你需要使用HLS工具提供的特定数据类型（如
ap_int
,
ap_fixed
用于定点数运算）和编译器指示（Pragmas），来指导工具如何将你的C++代码映射到硬件结构上，例如循环展开（
UNROLL
）、流水线（
PIPELINE
）、数组分区（
ARRAY_PARTITION
）等，这些都是优化硬件性能的关键。
C++代码编写完毕并经过初步的C/C++仿真验证（确保算法逻辑在软件层面是正确的）后，下一步就是通过HLS工具进行综合，生成RTL代码。这个RTL代码通常会以IP核的形式存在，并带有标准的接口，比如AXI（Advanced eXtensible Interface），这是ARM定义的一种高性能总线协议，在FPGA设计中非常常见。
立即学习“C++免费学习笔记（深入）”；
最关键的协同仿真部分来了。HLS工具在生成RTL的同时，也会为你生成一个C/RTL协同仿真的环境。这通常意味着HLS工具会创建一个适配层，将你的C++测试平台与生成的RTL IP核连接起来。你的C++测试代码会像调用一个普通函数一样调用这个IP核，但实际上，它的输入会通过适配层传递给RTL仿真器，RTL仿真器执行IP核的硬件逻辑，然后将结果通过适配层返回给C++测试代码。你可以在C++测试代码中比较HLS综合前后的结果，确保一致性。这种协同仿真允许你使用C++的高效调试能力来验证硬件行为，同时也能在RTL层面观察信号波形，定位硬件实现引入的问题。
HLS与RTL协同仿真的核心价值是什么？
说实话，我觉得HLS与RTL协同仿真，它最大的魅力在于“快”和“准”。我们做硬件设计的，时间成本是实打实的。传统的RTL开发和验证周期很长，一旦算法在RTL层面发现问题，改动起来那是牵一发而动全身。但有了协同仿真，它给我们提供了一个在更早阶段、更高抽象层次发现问题的机会。
它能做到：
加速验证迭代： C++代码跑起来比RTL仿真快太多了。一个复杂的算法，在C++层面可能几秒钟就跑完了，而在RTL层面可能需要几分钟甚至几小时。协同仿真让你能在C++环境中快速测试算法的不同输入和边界条件，大大缩短了验证周期。提早发现设计缺陷： 在HLS综合出RTL之前，你可以在C++层面充分验证算法的正确性。协同仿真则进一步验证了C++到RTL的转换是否符合预期。很多时候，HLS工具对C++代码的解释可能与你的直觉不符，或者某些C++特性在硬件上实现起来效率不高甚至不可行，协同仿真能帮你尽早暴露这些“坑”。降低调试复杂度： 调试C++代码远比调试复杂的RTL波形要直观。在协同仿真中，如果发现C++测试结果与预期不符，你可以先在C++层面进行调试，确定是算法本身的问题还是HLS转换的问题。如果确定是HLS转换导致的问题，再深入到RTL波形中去分析，目标性更强。打通软硬件验证鸿沟： 对于那些需要CPU与FPGA协同工作的系统，协同仿真提供了一个非常自然的验证桥梁。你可以用C++编写驱动FPGA IP的测试程序，就像将来CPU会做的那样，提前验证整个软硬件交互的逻辑。
在C++编写HLS代码时，有哪些常见的“坑”和优化策略？
我个人觉得，C++写HLS代码，最容易踩的“坑”就是用软件思维去写硬件代码，这俩本质上差异太大了。
常见的“坑”：
动态内存分配和复杂指针：
new
、
malloc
这些在HLS里基本就是禁区，因为硬件资源是静态分配的，你不能在运行时凭空变出更多存储单元。复杂的指针操作，比如多级指针、函数指针，也会让HLS工具无从下手。即使是数组的指针，也得小心使用，确保它能被映射到一块连续的硬件存储区域。标准库依赖： 别指望所有的C++标准库都能直接综合。
iostream
、
string
、
vector
（除非是特定为HLS优化的版本或用法）这些往往是不可综合的。你需要使用HLS工具提供的特定数据结构，比如
ap_int
、
ap_fixed
，或者自己用数组和循环实现类似的功能。递归： 硬件是并行的，递归这种依赖调用栈的结构，在硬件上实现起来非常困难，几乎不可综合。浮点数运算： 虽然HLS支持浮点数，但标准的
float
和
double
在硬件上实现起来非常消耗资源，而且速度慢。如果你对精度有要求，但又想节省资源，定点数（
ap_fixed
）通常是更好的选择。隐式循环和数据依赖： 有时候你写的一个简单循环，HLS工具可能无法完全并行化，因为循环内部存在数据依赖。这会导致流水线中断或资源浪费。
优化策略：
善用Pragmas： 这是HLS设计的灵魂。
#pragma HLS PIPELINE
: 让循环内部的操作像流水线一样连续执行，提高吞吐率。
#pragma HLS UNROLL
: 完全展开循环，实现最大程度的并行，但会增加资源消耗。
#pragma HLS ARRAY_PARTITION
: 将数组拆分成更小的块，甚至完全拆分成独立的寄存器，以增加并行访问能力。
#pragma HLS DATAFLOW
: 允许函数或循环之间以数据流的形式并行执行，非常适合多阶段处理的算法。使用HLS专用数据类型：
ap_int
和
ap_fixed
是为硬件优化而生的。它们允许你精确控制位宽和精度，从而有效管理资源。模块化和接口设计： 将大算法拆分成小的、可独立综合的函数，并通过明确的接口（如AXI Stream或AXI Lite）连接。这有助于HLS工具更好地优化，也方便后续集成。优化内存访问模式： 尽量实现连续的、可预测的内存访问模式，避免随机访问，这有利于HLS工具将内存映射到块RAM（BRAM）或分布式RAM（LUTRAM）上，并实现高效的突发传输。考虑数据流架构： 对于复杂的算法，可以将其分解为一系列顺序处理的阶段，每个阶段作为一个独立的进程，通过FIFO或其他通道进行通信。这能有效提高整体的吞吐量。
如何有效调试HLS生成的RTL与C++测试平台？
调试这事，不管软件硬件，都是个磨人的活儿。在HLS和RTL协同仿真这个语境下，它其实是分层次的，你需要根据问题的表现来选择不同的调试手段。
C/C++功能仿真先行： 这是最基础也是最重要的一步。在HLS综合之前，确保你的C++算法在纯软件环境下是完全正确的。使用标准的C++编译器（如g++）和调试器（如GDB），像调试普通C++程序一样，确保算法逻辑、输入输出、边界条件都符合预期。这一步能排除掉算法本身的逻辑错误，避免把软件bug带到硬件层面。
C/RTL协同仿真中的波形分析： 当C/C++功能仿真通过，但C/RTL协同仿真出现问题时，你需要深入到RTL层面。HLS工具生成的协同仿真环境，通常会与一个RTL仿真器（比如Vivado Simulator, ModelSim, QuestaSim）集成。当协同仿真运行出错时，你可以打开RTL仿真器的波形查看器。
关注接口信号： 首先检查HLS IP的输入输出接口信号（比如AXI接口的握手信号、数据信号）。看看数据流是否正确，握手协议是否符合预期。很多问题都出在接口的误解或时序不匹配上。内部信号追踪： 如果接口看起来没问题，但输出仍然错误，你可能需要查看HLS IP内部的关键信号。HLS工具通常允许你选择在综合过程中保留哪些信号以便于调试。通过观察这些内部信号，你可以判断算法的哪个部分在硬件上没有按预期工作。
C++测试平台与RTL行为的对照： 协同仿真的一个强大之处在于，你可以在C++测试平台中打印出中间变量的值，同时在RTL波形中观察对应信号的值。通过比对这两者，你可以精确地定位C++代码的哪一行，对应到RTL的哪个部分出现了偏差。比如，你的C++代码计算出一个中间结果是X，但在RTL波形中，对应信号的值却是Y，那么问题就出在从X到Y的这个转换过程中。
断点和断言： 在C++测试平台中设置断点，当程序执行到特定位置时暂停，检查变量状态。在RTL仿真器中也可以设置断点，当特定信号满足条件时暂停仿真。此外，在C++代码中加入断言（
assert
），在RTL代码中也可以使用SystemVerilog的
assert
语句，它们能在运行时检查条件，一旦不满足就报错，这对于快速发现问题非常有帮助。
HLS报告分析： HLS工具在综合完成后会生成详细的报告，包括资源利用率、时序报告、数据流分析等。这些报告可以帮助你理解HLS工具是如何将你的C++代码映射到硬件上的。如果协同仿真结果不对，结合报告，你可能会发现某个循环没有被完全流水线化，或者某个数组被映射到了不理想的存储器类型上，这些都可能导致性能或功能问题。
以上就是怎样为C++配置FPGA协同设计环境 HLS与RTL协同仿真的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1471674.html
微信扫一扫 
支付宝扫一扫 
