怎样为C++配置FPGA协同设计环境 HLS与RTL协同仿真

首先选择合适的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

ap_int

ap_fixed

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代码，最容易踩的“坑”就是用软件思维去写硬件代码，这俩本质上差异太大了。

居然设计家

居然之家和阿里巴巴共同打造的家居家装AI设计平台

64

查看详情

常见的“坑”：

• 动态内存分配和复杂指针：

  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协同仿真的详细内容，更多请关注php中文网其它相关文章！