目录
1. 简介
在这篇博文中《Vitis HLS 学习笔记--AXI_STREAM_TO_MASTER-CSDN博客》，我分享了关于 AXI Stream 接口的实际应用案例。然而，尽管文章中提供了代码示例，对于代码中使用的编码格式并未进行深入探讨。例如，其中使用了 do-while 循环，但我们需要进一步思考：这个循环是否是必须的？我们如何理解硬件电路是如何实现一个无边界的循环呢？
这一问题的探讨将有助于读者更好地理解硬件描述语言（HDL）与软件编程之间的差异，以及如何在硬件层面有效地利用循环结构。
2. 极简的对比
请仔细对比一下两段代码：
- 代码一，包含 do-while
#include <complex>
#include "ap_axi_sdata.h"
#include "hls_stream.h"
typedef hls::axis<std::complex<short int>, 0, 0, 0> data_t;
typedef hls::stream<data_t> mystream;
void example_1(mystream &A, mystream &B) {
#pragma HLS INTERFACE axis port=A
#pragma HLS INTERFACE axis port=B
data_t tmp_a;
do {
tmp_a = A.read();
data_t tmp_b;
tmp_b.data.real(tmp_a.data.real() + 5);
tmp_b.data.imag(tmp_a.data.imag() + 1);
B.write(tmp_b);
} while (!tmp_a.last);
}- 代码二，不包含 do-while
#include <complex>
#include "ap_axi_sdata.h"
#include "hls_stream.h"
typedef hls::axis<std::complex<short int>, 0, 0, 0> data_t;
typedef hls::stream<data_t> mystream;
void example_2(mystream &A, mystream &B) {
#pragma HLS INTERFACE axis port=A
#pragma HLS INTERFACE axis port=B
data_t tmp_a;
tmp_a = A.read();
data_t tmp_b;
tmp_b.data.real(tmp_a.data.real() + 5);
tmp_b.data.imag(tmp_a.data.imag() + 1);
B.write(tmp_b);
}从软件调用的角度来理解：
在 example_1 中，使用了一个 do-while 循环，它会一直执行直到 tmp_a.last 的值为真。这表示在读取完所有输入数据后才会停止循环。
在 example_2 中，没有使用循环结构，而是直接从输入流 A 中读取一个数据，处理后写入输出流 B。因此，它只执行一次读取、处理和写入操作。
从软件调用的角度来看，以上的分析没有错，但是我们的代码会被硬件来实现，怎么会容忍硬件“只能被调用一次”？
在软件中，我们很容易理解并执行一次性的操作，例如在 example_2 中所示。然而，在硬件描述中，情况稍有不同。
在硬件中，一般情况下，每个操作都会对应一个硬件电路的状态变化或者时钟周期。因此，虽然在软件中我们可以简单地想象每个函数被调用一次，但在硬件中，我们需要考虑每个操作如何在时钟周期内完成。
这里提出一个出人意料的结论：尽管两端代码在软件层面看起来有所不同，但对应的硬件实现功能却完全相同。
3. 硬件模块的多次触发
对于example_2函数，当提到它“只能处理单个数据项”，意思是在一个函数调用中，它只从输入流A读取并处理一个数据项，然后将处理后的数据写入输出流B。在硬件实现上，这意味着它被设计为一次处理一个数据项的操作。
然而，硬件模块本身是可以被多次触发的，可以持续给这个模块喂数据，每次喂一个数据项，模块就处理一次。这是通过在硬件设计中实现一个接口，允许数据连续流入模块，并在每个数据项到来时触发处理逻辑。
在连续运行的情况下，example_2的硬件实现可以看作是一个流水线的单元，每接收到一个新的数据项，就处理这个数据项，并将结果输出。因此，尽管在单次函数调用中，它只处理一个数据项，但在连续运行时，它可以连续处理多个数据项，每次处理一个。
当持续给这个硬件模块喂数据时，模块将会在每个时钟周期（或多个时钟周期，取决于模块的设计和优化）处理一个数据项。
如果模块设计为非阻塞且具有足够的吞吐率，它将能够连续不断地处理流入的数据项，每处理完一个就准备接收下一个。
如果数据到达速度超过模块处理能力，或者模块设计中存在阻塞操作，可能需要引入缓冲机制或调整设计以确保数据可以被有效处理。
4. 进一步探讨 do-while
在这个《Vitis HLS 学习笔记--AXI_STREAM_TO_MASTER-CSDN博客》博文中，有一段示例代码如下：
...
void getinstream(hls::stream<trans_pkt>& in_stream,
hls::stream<data>& out_stream, hls::stream<int>& out_counts) {
int count = 0;
trans_pkt in_val;
do {
#pragma HLS PIPELINE
in_val = in_stream.read();
data out_val = {in_val.data, in_val.last};
out_stream.write(out_val);
count++;
if (count >= MAX_BURST_LENGTH || in_val.last) {
out_counts.write(count);
count = 0;
}
} while (!in_val.last);
}
void example(hls::stream<trans_pkt>& inStreamTop, ap_uint<64> outTop[1024]) {
#pragma HLS INTERFACE axis register_mode = both register port = inStreamTop
#pragma HLS INTERFACE m_axi max_write_burst_length = 256 latency = 10 depth = 1024 bundle = gmem0 port = outTop
#pragma HLS INTERFACE s_axilite port = outTop bundle = control
#pragma HLS INTERFACE s_axilite port = return bundle = control
#pragma HLS DATAFLOW
hls::stream<data, DATA_DEPTH> buf;
hls::stream<int, COUNT_DEPTH> count;
getinstream(inStreamTop, buf, count);
streamtoparallelwithburst(buf, count, outTop);
}软件层面的 do-while 循环，它实际上映射了一个硬件状态机的概念。
而这里的循环最重要的功能，就是实现对 count 变量的操作。count 被初始化为 0 后，就进入状态机中执行，直到 count >= MAX_BURST_LENGTH || in_val.last 条件满足，输出 out_counts，被再次清零。
然而清零后并不意味 do-while 循环终止，这段“代码”代码将会继续执行，没有终点。
5. 总结
example_2在硬件中可以被设计为连续处理数据的模块，尽管其代码表面上看只处理一次数据。重要的是要理解硬件设计和软件逻辑之间的差异：硬件模块可以被设计为重复触发，以连续处理数据流，而不仅仅是单个数据项。
