Vitis HLS 学习笔记--通道的FIFO/PIPO选择

已于 2024-05-31 11:46:45 修改
阅读量840 收藏 12
点赞数 19
分类专栏： Vitis HLS 文章标签： 学习 笔记 fpga开发 HLS c++
于 2024-05-30 23:25:39 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/DongDong314/article/details/139310769
版权

目录

1. 简介

2. 代码详解

2.1 FIFO 通道示例

2.1.1 配置默认通道

2.1.2 kernel 代码 

2.1.3 综合报告

2.1.4 depth = 32 解析

2.1.5 FIFO 通道分类

2.2 PIPO

2.2.1 配置默认通道

2.2.2  kernel 代码 

2.2.3 综合报告

2.2.4 PIPO 通道分类

3. 综合对比

3.1 数据类型和接口

3.2 数据流和数据流控制

3.3 计算函数和计算方式

4. 总结

1. 简介

本文通过调整 Vitis HLS 编译器的默认设置，选择FIFO或者PIPO作为通道缓存。首先，我们来复习一下这两种缓存的区别：

想象一下，你在一家快餐店，FIFO 缓冲器就像是排队等候的顾客队伍。第一个进入队伍的顾客会是第一个得到服务的人。这个系统的好处是，顾客（生产者）一旦排队，厨师（使用者）就可以开始准备他们的食物。但如果厨师做饭的速度赶不上顾客排队的速度，或者反过来，就会造成混乱，有可能导致整个队伍停滞不前，这就是所谓的“死锁”。

现在，让我们来看看乒乓缓冲器。这就像是有两个窗口的快餐店。当一个窗口正在为顾客准备食物时，另一个窗口就在接待新的顾客。一旦一个窗口的食物准备好了，顾客就可以从那里取餐，而厨师则转到另一个窗口继续工作。这样，即使顾客来得很快，也不会有人等得太久，因为总有一个窗口是在准备食物的。

PIPO 缓冲器的工作方式类似于一个自动调节的快餐店，无论顾客来得多快，厨师都能以相同的速度做饭，确保每个人都能及时得到食物，不会有任何拥堵或延误。

在这两种情况下，无论是 FIFO 还是 PIPO，关键点都是顾客（生产者）将订单（数据块）传递给厨师（使用者）。订单可以是一个汉堡包（单个值），也可以是一整个家庭套餐（一组 N 个值）。订单越大，厨师需要的准备空间就越多。

本文内容会参照《Vitis HLS 学习笔记--控制驱动TLP-处理deadlock_vitis hls数据流处理-CSDN博客》中对于 FIFO /PIPO 类型的分类。

2. 代码详解

2.1 FIFO 通道示例

2.1.1 配置默认通道

首先配置 FIFO 缓存，可以通过如下指令进行设定：

# Create a solution
open_solution -reset solution1 -flow_target vitis
config_dataflow -default_channel fifo -fifo_depth 2

或者通过 UI 界面设置：

2.1.2 kernel 代码 

#include <hls_stream.h>
#include <hls_vector.h>

extern "C" {

void diamond(hls::vector<uint32_t, 16>* vecIn, hls::vector<uint32_t, 16>* vecOut, int size) {
// The depth setting is required for pointer to array in the interface.
#pragma HLS INTERFACE m_axi port = vecIn depth = 32
#pragma HLS INTERFACE m_axi port = vecOut depth = 32

    hls::stream<hls::vector<uint32_t, 16>> c0, c1, c2, c3, c4, c5;
    assert(size % 16 == 0);

#pragma HLS dataflow
    load(vecIn, c0, size);
    compute_A(c0, c1, c2, size);
    compute_B(c1, c3, size);
    compute_C(c2, c4, size);
    compute_D(c3, c4, c5, size);
    store(c5, vecOut, size);
}
}

void load(hls::vector<uint32_t, 16>* in, hls::stream<hls::vector<uint32_t, 16>>& out, int size) {
Loop_Ld:
    for (int i = 0; i < size; i++) {
#pragma HLS performance target_ti = 32
#pragma HLS LOOP_TRIPCOUNT max = 32
        out.write(in[i]);
    }
}

void compute_A(hls::stream<hls::vector<uint32_t, 16>>& in, hls::stream<hls::vector<uint32_t, 16>>& out1,
               hls::stream<hls::vector<uint32_t, 16>>& out2, int size) {
Loop_A:
    for (int i = 0; i < size; i++) {
#pragma HLS performance target_ti = 32
#pragma HLS LOOP_TRIPCOUNT max = 32
        hls::vector<uint32_t, 16> t = in.read();
        out1.write(t * 3);
        out2.write(t * 3);
    }
}

void compute_B(hls::stream<hls::vector<uint32_t, 16>>& in, hls::stream<hls::vector<uint32_t, 16>>& out,
               int size) {
Loop_B:
    for (int i = 0; i < size; i++) {
#pragma HLS performance target_ti = 32
#pragma HLS LOOP_TRIPCOUNT max = 32
        out.write(in.read() + 25);
    }
}

void compute_C(hls::stream<hls::vector<uint32_t, 16>>& in, hls::stream<hls::vector<uint32_t, 16>>& out,
               int size) {
Loop_C:
    for (unsigned int i = 0; i < size; i++) {
#pragma HLS performance target_ti = 32
#pragma HLS LOOP_TRIPCOUNT max = 32
        out.write(in.read() * 2);
    }
}
void compute_D(hls::stream<hls::vector<uint32_t, 16>>& in1, hls::stream<hls::vector<uint32_t, 16>>& in2,
               hls::stream<hls::vector<uint32_t, 16>>& out, int size) {
Loop_D:
    for (unsigned int i = 0; i < size; i++) {
#pragma HLS performance target_ti = 32
#pragma HLS LOOP_TRIPCOUNT max = 32
        out.write(in1.read() + in2.read());
    }
}

void store(hls::stream<hls::vector<uint32_t, 16>>& in, hls::vector<uint32_t, 16>* out, int size) {
Loop_St:
    for (int i = 0; i < size; i++) {
#pragma HLS performance target_ti = 32
#pragma HLS LOOP_TRIPCOUNT max = 32
        out[i] = in.read();
    }
}

数据流说明：

  • load：读取数组 vecIn -> c0;
  • compute_A：从流 c0 读取数据，计算后写入 c0 × 3 -> c1, c0 ×3 -> c2;
  • compute_B：从流 c1 读取数据，计算后写入 c1 + 25 -> c3;
  • compute_C：从流 c2 读取数据，计算后写入 c2 × 2 -> c4;
  • compute_D：从流 c3 和 c4 读取数据，计算后写入 c3 + c4 -> c5;
  • store：数组 c5 -> vecOut。 

2.1.3 综合报告

查看综合后的报告：

================================================================
== HW Interfaces
================================================================
* M_AXI
+------------+------------+---------------+---------+--------+----------+-----------+--------------+--------------+-------------+-------------+
| Interface  | Data Width | Address Width | Latency | Offset | Register | Max Widen | Max Read     | Max Write    | Num Read    | Num Write   |
|            | (SW->HW)   |               |         |        |          | Bitwidth  | Burst Length | Burst Length | Outstanding | Outstanding |
+------------+------------+---------------+---------+--------+----------+-----------+--------------+--------------+-------------+-------------+
| m_axi_gmem | 512 -> 512 | 64            | 64      | slave  | 0        | 512       | 16           | 16           | 16          | 16          |
+------------+------------+---------------+---------+--------+----------+-----------+--------------+--------------+-------------+-------------+

具有较大的位宽，512bit，符合 hls::vector<uint32_t, 16> 定义，512=32*16。

* SW-to-HW Mapping
+----------+---------------+-----------+----------+------------------------------------+
| Argument | HW Interface  | HW Type   | HW Usage | HW Info                            |
+----------+---------------+-----------+----------+------------------------------------+
| vecIn    | m_axi_gmem    | interface |          |                                    |
| vecIn    | s_axi_control | register  | offset   | name=vecIn_1 offset=0x10 range=32  |
| vecIn    | s_axi_control | register  | offset   | name=vecIn_2 offset=0x14 range=32  |
| vecOut   | m_axi_gmem    | interface |          |                                    |
| vecOut   | s_axi_control | register  | offset   | name=vecOut_1 offset=0x1c range=32 |
| vecOut   | s_axi_control | register  | offset   | name=vecOut_2 offset=0x20 range=32 |
| size     | s_axi_control | register  |          | name=size offset=0x28 range=32     |
+----------+---------------+-----------+----------+------------------------------------+

vecIn 和 vecOut 均是绑定到 m_axi_gmem 的 AXI 主接口。 

2.1.4 depth = 32 解析

void diamond(vecOf16Words* vecIn, vecOf16Words* vecOut, int size) {
#pragma HLS INTERFACE m_axi port = vecIn depth = 32
#pragma HLS INTERFACE m_axi port = vecOut depth = 32

    hls::stream<vecOf16Words> c0, c1, c2, c3, c4, c5;
    assert(size % 16 == 0);

#pragma HLS dataflow
    load(vecIn, c0, size);
    compute_A(c0, c1, c2, size);
    compute_B(c1, c3, size);
    compute_C(c2, c4, size);
    compute_D(c3, c4, c5, size);
    store(c5, vecOut, size);
}

#pragma HLS INTERFACE m_axi port = vecIn depth = 32 指令用于设置接口属性。这里的 depth=32 是一个指令选项，它指定了AXI接口的深度，也就是FPGA与外部内存交互时可以访问的数据量。这个数值应该与设计打算在单次事务中处理的数据量相匹配。由于 TB 中的 std::vector 容器 test 和 outcome 的大小都被初始化为32，这表明设计打算在一个事务中处理32个向量，因此 depth 被设置为32。

这个深度值对于优化数据传输非常重要，因为它影响了接口生成的FIFO缓冲区的大小，以及FPGA与外部内存之间的突发传输能力。正确设置深度可以帮助提高性能，减少延迟，并确保数据的连续流动。

2.1.5 FIFO 通道分类

FIFO 有三种类型：

  • Streams (including hls::streams and streamed arrays)，用户创建。
  • Scalar propagation FIFOs，工具推断。
  • Streams of blocks，用户创建。

对照 Dataflow 报告，本 kernel 的 FIFO 通道有两种类型 Stream 和 ScalarProp，从变量的名字也可以看出，c0、c1、c2、c3、c4、c5是由用户创建的，而其余的变量则由 HLS 工具推断生成。

2.2 PIPO

2.2.1 配置默认通道

首先配置 PIPO 缓存，可以通过如下指令进行设定：

# Create a solution

open_solution -reset solution1 -flow_target vitis

或者通过 UI 界面设置：

2.2.2  kernel 代码 

void diamond(unsigned char vecIn[100], unsigned char vecOut[100]) {
    unsigned char c1[100], c2[100], c3[100], c4[100];
#pragma HLS dataflow
    funcA(vecIn, c1, c2);
    funcB(c1, c3);
    funcC(c2, c4);
    funcD(c3, c4, vecOut);
}

void funcA(unsigned char* in, unsigned char* out1, unsigned char* out2) {
Loop0:
    for (int i = 0; i < 100; i++) {
#pragma HLS pipeline rewind
#pragma HLS unroll factor = 2
        unsigned char t = in[i] * 3;
        out1[i] = t;
        out2[i] = t;
    }
}

void funcB(unsigned char* in, unsigned char* out) {
Loop0:
    for (int i = 0; i < 100; i++) {
#pragma HLS pipeline rewind
#pragma HLS unroll factor = 2
        out[i] = in[i] + 25;
    }
}

void funcC(unsigned char* in, unsigned char* out) {
Loop0:
    for (unsigned char i = 0; i < 100; i++) {
#pragma HLS pipeline rewind
#pragma HLS unroll factor = 2
        out[i] = in[i] * 2;
    }
}

void funcD(unsigned char* in1, unsigned char* in2, unsigned char* out) {
Loop0:
    for (int i = 0; i < 100; i++) {
#pragma HLS pipeline rewind
#pragma HLS unroll factor = 2
        out[i] = in1[i] + in2[i] * 2;
    }
}

数据流说明：

  • compute_A：计算后写入 vecIn × 3 -> c1, vecIn ×3 -> c2;
  • compute_B：计算后写入 c1 + 25 -> c3;
  • compute_C：计算后写入 c2 × 2 -> c4;
  • compute_D：计算后写入 c3 + c4 × 2 -> vecOut.

2.2.3 综合报告

================================================================
== HW Interfaces
================================================================
* M_AXI
+------------+------------+---------------+---------+--------+----------+-----------+--------------+--------------+-------------+-------------+
| Interface  | Data Width | Address Width | Latency | Offset | Register | Max Widen | Max Read     | Max Write    | Num Read    | Num Write   |
|            | (SW->HW)   |               |         |        |          | Bitwidth  | Burst Length | Burst Length | Outstanding | Outstanding |
+------------+------------+---------------+---------+--------+----------+-----------+--------------+--------------+-------------+-------------+
| m_axi_gmem | 512 -> 512 | 64            | 64      | slave  | 0        | 512       | 16           | 16           | 16          | 16          |
+------------+------------+---------------+---------+--------+----------+-----------+--------------+--------------+-------------+-------------+
* SW-to-HW Mapping
+----------+---------------+-----------+----------+------------------------------------+
| Argument | HW Interface  | HW Type   | HW Usage | HW Info                            |
+----------+---------------+-----------+----------+------------------------------------+
| vecIn    | m_axi_gmem    | interface |          |                                    |
| vecIn    | s_axi_control | register  | offset   | name=vecIn_1 offset=0x10 range=32  |
| vecIn    | s_axi_control | register  | offset   | name=vecIn_2 offset=0x14 range=32  |
| vecOut   | m_axi_gmem    | interface |          |                                    |
| vecOut   | s_axi_control | register  | offset   | name=vecOut_1 offset=0x1c range=32 |
| vecOut   | s_axi_control | register  | offset   | name=vecOut_2 offset=0x20 range=32 |
| size     | s_axi_control | register  |          | name=size offset=0x28 range=32     |
+----------+---------------+-----------+----------+------------------------------------+

报告中 HW Interface 与 Mapping 具有相同的内容，这里不再赘述。

2.2.4 PIPO 通道分类

PIPO 有三种类型：

  • PIPO，用户创建。
  • Task Level FIFOs (TLF)，工具推断。
  • Input and output ports to the upper level，用户创建。

对照 Dataflow 报告，本 kernel 的 PIPO 通道类型只有一种：PIPO，c1、c2、c3、c4均由用户创建。变量 vecOut_c 则由 HLS 工具推断生成为 FIFO 类型。

 

3. 综合对比

3.1 数据类型和接口

第一段代码：

  • 使用 hls::vector<uint32_t, 16> 类型来表示向量。
  • 使用 hls::stream 数据结构来处理数据流。
  • 显式指定 AXI 主接口。

第二段代码：

  • 使用基本的 unsigned char 类型的数组，每个数组包含 100 个元素。
  • 没有使用 hls::stream，而是使用普通的数组传递数据。
  • 输入输出接口使用普通的 C-style 指针和数组，没有显式的接口设置。

3.2 数据流和数据流控制

第一段代码：

  • 使用 HLS dataflow pragma (#pragma HLS dataflow) 来启用数据流优化
  • 显式指定使用 hls::stream 作为函数间的通信方式，函数之间的数据通过流进行传递。

第二段代码：

  • 同样使用 HLS dataflow pragma (#pragma HLS dataflow) 来启用数据流优化，但数据传递是通过普通的数组来进行。
  • 函数间的数据通过数组传递，没有使用 hls::stream。

3.3 计算函数和计算方式

第一段代码：

  • 函数更为通用，接受 hls::vector 类型的数据，并且处理过程中使用了 HLS 的各种特性如 pipeline 和 unroll。
  • 每个函数处理 hls::vector<uint32_t, 16> 类型的数据，并将结果写入另一个 hls::vector。

第二段代码：

  • 函数接受基本类型的指针和数组作为输入输出，处理过程中使用 pipeline 和 unroll 进行优化。
  • 每个函数处理 unsigned char 类型的数据，并将结果写入另一个 unsigned char 数组。

4. 总结

本文对比了在 Vitis HLS 编译器中配置 FIFO 和 PIPO 缓冲器的方法和效果。通过两段代码示例，我们展示了使用这两种通道缓存的不同实现方式。

在 FIFO 示例中，代码使用 hls::vector<uint32_t, 16> 和 hls::stream 数据结构，通过 AXI 主接口进行数据传输，并用 #pragma HLS dataflow 启用数据流优化，每个函数通过流进行通信。这种方式更通用，但需要显式指定流和接口设置。

在 PIPO 示例中，代码采用 unsigned char 数组进行数据传递，使用 C-style 指针和数组，没有显式接口设置，通过数组传递数据，同样使用 #pragma HLS dataflow 启用数据流优化。这种方式更简单直接，但缺乏流的灵活性。

PIPO 缓冲器可以自动调节，确保任务之间的重叠执行，而不会出现死锁。而显式手动串流的 FIFO 通道虽然可以更快地开始重叠执行，但需要小心调整队列大小，以避免死锁问题。

综合来看，FIFO 适用于复杂的通用数据处理场景，而 PIPO 更适合简单的数据传递需求。正确选择和配置这两种缓冲器，可以优化系统性能，减少延迟。本文帮助读者理解 FIFO 和 PIPO 的适用场景和配置方法，从而在设计中做出最佳选择。

hi94
关注
专栏目录
Vitis HLS入门指南
PolarSnow
01-11 1326
Vitis HLS入门指南
Xilinx Vitis HLS教程1--Vitis HLS概述[01/12]
B10030607的博客
08-11 4593
Xilinx Vitis HLS教程[01/10]前言1. Vitis HLS简介1.1 软件工程师的设计原则1.1.1 简介1.1.2 吞吐量和性能1.2.3 架构问题1.2.4 FPGA编程的3大范式1.2.4.1 生产者-消费者范式1.2.4.2 流式数据范式1.2.4.3 流水线范式1.2.5 3种范式结合 前言 项目中使用到Xilinx Zynq UltraScale+ MPSoC ZCU102 开发板，领导指示研究"xilinx软件自带的c语言综合器"。对于一个硬件一窍不通的我来说，甚至不知道
pipe和FIFO
u011403897的专栏
07-28 1259
首先来看pipe： pipe用于具有相同祖先的进程（最简单的情况：父子进程）之间的通信。 在进程中调用pipe函数创建管道。这个管道是由内核创建并管理的。     #include     int pipe(intfiledes[2]); 该函数返回一个文件描述符数组fd[]，fd[0]用于读管道，fd[1]用于写管道。如下图： 与 FIFO" title="pipe 
进程间通信(FIFO管道)
qq_41606926的博客
08-19 418
FIFO常被称为命名管道，以区分pipe，pipe只能用于“有血缘关系”的进程间通信。但通过FIFO，不相关的进程也能交换数据。 FIFO是linux基础文件类型中的一种（文件类型为p，可通过ls -l查看文件类型），但FIFO文件在磁盘上没有数据块，文件大小为0，仅仅用来标识内核中一条通道。进程可以打开这个文件进行read/write，实际上是在读写内核缓冲区，这样就实现了进程间通信。 创建FIFO管道 进程间通信流程 进程A 创建一个fifo文件，使用mkf...
进程间的通信—管道pipe和fifo
风清扬
09-24 810
进程间的通信管道的学习笔记
进程间通信(二) FIFO
longjiang321的博客
04-01 1111
FIFO是用来标识一段内核空间，区别于pipe, 可以实现非血缘关系进程间通信的伪文件。
Xilinx Vitis HLS教程1--Vitis HLS概述[02/12]
B10030607的博客
08-12 5106
Xilinx Vitis HLS教程[02/10]1.2 Vitis HLS简介总结 1.2 Vitis HLS简介 总结 提示：这里对文章进行总结： 例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。 ...
Xilinx Vitis HLS教程1--Vitis HLS概述[03/12]
B10030607的博客
08-12 2519
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档 Xilinx Vitis HLS教程1--Vitis HLS概述[03/12]3. Vitis HLS流程概述3.1 使能Vivado IP流3.2 使能Vitis内核流一、pandas是什么？二、使用步骤1.引入库2.读入数据总结 solution: 解决方案 synthesis: 综合 simulation: 模拟 3. Vitis HLS流程概述 Vitis HLS是基于项目的，可以包含多种称为"解决方案"的变体，以推动综合和模拟。
c-ug1399-vitis-hls c-ug1399-vitis-hls
11-02
总之，C-UG1399-Vitis-HLS用户指南是学习和掌握Vitis HLS的关键资源，无论是初学者还是经验丰富的FPGA开发者，都可以从中获得宝贵的知识和实践经验。通过理解并应用这些知识，用户能够更高效地利用FPGA的优势，设计...
Vitis Vision - 利用Vitis HLS tcl shell 一键跑通视觉加速例程
03-18
### Vitis Vision - 利用Vitis HLS tcl shell 一键跑通视觉加速例程 #### 背景介绍 随着高性能计算与嵌入式视觉技术的发展，FPGA（Field Programmable Gate Array）作为高性能计算的重要组成部分，在图像处理领域...
最初Unix IPC包括：管道、FIFO、信号 ,
12-26 135
管道打开，都要同时打开写端与读端，不然会在open函数产生阻塞！！！ 无名管道 pipe•创建 –int pipe (int fd[2]) –返回0表示成功；fd[0]带回管道出口，fd[1]带回管道入口； –fd[0], fd[1]通过文件描述符来表示pipe的出口与入口，进程可以从fd[0]读，并向fd[1]写。 –     -1,出错 •销毁 –close(fd[0]) 关闭读...
进程间通信IPC之--无名管道（pipe）和有名管道（fifo）
嵌入式软硬件设计/方案设计
07-31 635
转载于：http://blog.chinaunix.net/uid-25365622-id-3059840.html 每个进程各自有不同的用户地址空间，任何一个进 程的全局变量在另一个进程中都看不到，所以进程之间要交换数据必须通过内核，在内核中开辟一块缓冲 区，进程1把数据从用户空间拷到内核缓冲区，进程2再从内核缓冲区把数据读走，内核提供的这种机制称为进程间通信（IPC，InterPro
进程间通信IPC之--无名管道（pipe）和有名管道（fifo）(转)
weixin_30621711的博客
03-08 111
进程间通信IPC之--无名管道（pipe）和有名管道（fifo）2012-01-17 22:41:20 分类：C/C++ 每个进程各自有不同的用户地址空间，任何一个进 程的全局变量在另一个进程中都看不到，所以进程之间要交换数据必须通过内核，在内核中开辟一块缓冲 区，进程1把数据从用户空间拷到内核缓冲区，进程2再从内核缓冲区把数据读走，内核提供的这种机制称为进程间通信（...
linux中的pipe和fifo的区别
u012138828的专栏
08-05 2807
linux中的pipe和fifo的区别 在linux进程间通信(IPC)可以通过信号量、文件系统、消息队列、共享内存还有管道来实现的。其中消息队列、内存管理是在System V中提出的。 进程通信间涉及到了管道，而且管道在shell命令中也大有用处。那就简要说说管道： 管道顾名思义，你可以将其理解为日常生活中的管子，一边流入，一边流出。它可以有半双工和全双工。半双工就
HLS进阶技巧——反压fifo
菜鸟乱学
12-19 3274
在Vitis HLS设计中，由于只能获取到fifo的empty、full信号，而不像RTL设计中还能拿到write/read count，所以在dataflow中，只能通过empty、full信号来进行数据驱动。反压fifo是通过fifo的full信号来控制程序的运行。下面介绍两种笔者涉及到的反压技巧。 技巧1 下图所示为dataflow中一个最基本的结构，在反压设计中，backPressStrm指定depth=2，那么Producer写入两个数后，如果Consumer没读取，则Producer会hang住
PIPO管道通信范列（linux）
徐权的博客
07-21 1430
PIPO，管道，linux
Linux编程—系统编程（进程通信）
qq_52380197的博客
03-24 146
进程通信IPC InterProcess Communication 多个进程间的交互 方式： 1.管道（无名管道和命名管道）pipo FIFO 2.消息队列 3.共享内存 4.信号 5.信号量 6.还有Socket 、Streams用于不同主机间两个进程的通信 管道 1.无名管道：半双工，具有固定读写端。用于具有情缘关系的父子进程或兄弟进程。它可看作特殊文件，对其的读写使用系统调用的read/write,注意它不属于任何文件系统，只存在于内存中。 原型：int pipe(int pipefd[2]);成
【嵌入式linux】进程间通信的几种方式
NBDR_YL的博客
05-06 877
管道： 无名管道PIPO 只能用于亲缘关系的进程间通信 半双工的通信模式。 有名管道 FIFO 可以用于互不相关的两个进程间通信 先进先出规则 信号 内核产生信号，用户注册信号处理函数，来进行信号事件的处理 共享内存 最高效的进程间通信方式，进程可以直接读写内存，不需要任何数据的拷贝 多进程通信过程中。内核分配有共同的内存区，需要访问的进程可以将其映射到自己的私有地址空间。 但是需要依靠互斥锁或者信号量来保证同步性。防止阻塞。 共享内存实现： （1）、创建共享内存 ...
Vitis HLS 学习笔记--控制驱动任务示例
最新发布
hi94的博客
05-21 1353
本文对《Vitis HLS 学习笔记--抽象并行编程模型-控制驱动与数据驱动-CSDN博客》中的控制驱动任务示例进行了详细解析，重点分析了 kernel 代码的并行处理机制及各模块的实现。通过查看综合报告、Schedule Viewer 和 Dataflow Viewer，确认了 funcB 和 funcC 的并行执行和 vecOut 的 FIFO 设置。并介绍了 Vitis IDE 的关键设置，包括数据文件加载、Flow Target 配置及 FIFO 深度调整。
Vitis HLS移植指南：从Vivado HLS到Vitis平台
"Vitis HLS开发手册ug1391是中文版的Xilinx Vitis高层次综合(HLS)移植指南，适用于2020.1版本。文档详细介绍了如何将基于Vivado HLS的内核模块迁移到Vitis HLS平台，涵盖了行为差异、不支持的功能以及已弃用的Tcl...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值