FPGA教程系列-Vivado AXI4-Stream Data FIFO核解读测试

FPGA教程系列-Vivado AXI4-Stream Data FIFO核解读测试

FPGA教程系列-Vivado AXI4-Stream Data FIFO核解读测试

image

FIFO depth (FIFO 深度): 定义了 FIFO 能存储多少个数据字(Data Words)。

注意:实际占用的存储资源取决于深度乘以数据宽度(TDATA width)。

Memory type (存储器类型):​Auto

  • 决定用 FPGA 内部的哪种资源来实现 FIFO。
  • Auto: 让 Vivado 综合工具根据 FIFO 的大小自动选择(通常小 FIFO 用分布式 RAM/LUTRAM,大 FIFO 用块 RAM/BRAM)。
  • Block RAM: 强制使用 BRAM。
  • Distributed RAM: 强制使用 LUT 搭建的 RAM。
  • UltraRAM: 针对 UltraScale+ 系列的特殊大容量 RAM。

Independent clocks (独立时钟):​No

  • No (同步 FIFO): 写入侧(Slave)和读取侧(Master)使用同一个时钟信号 (s_axis_aclk)。这消耗资源较少,延迟较低。
  • Yes (异步 FIFO): 启用跨时钟域功能。输入和输出可以使用不同频率的时钟。此时界面左侧的端口图会显示 s_axis_aclk​ (写时钟) 和 m_axis_aclk (读时钟)。

CDC sync stages (跨时钟域同步级数):​3(灰色不可选)

只有当选择了 “Independent clocks: Yes” 时才有效。它定义了用于同步信号的寄存器级数,通常用于防止亚稳态。

Enable packet mode (启用包模式):​No

  • No: 普通 FIFO 模式。只要 FIFO 里有数据,Master 端就会尝试输出。
  • Yes: FIFO 会等到接收到一个完整的数据包(即收到 TLAST 信号)后,才开始向 Master 端输出数据。这用于防止数据包在传输中间断流(Underrun),但会增加延迟。

ACLKEN conversion mode:​None​,用于控制时钟使能信号的处理方式。通常保持默认 None 即可。

Enable ECC (启用 ECC 校验):​No,是否启用错误检查和纠正(Error Correction Code)。启用后会增加逻辑资源,用于检测和修复位翻转错误。


TDATA width (bytes) (数据位宽):​1

  • 定义主要数据总线 TDATA​ 的宽度。设为 1 byte,也就是 8 bits。这意味着每个时钟周期传输 8 位数据。

Enable TSTRB (启用 TSTRB 信号):​No,TSTRB (Strobe) 用于指示哪些字节是有效的位置选通信号。对于纯数据流通常不需要。

Enable TKEEP (启用 TKEEP 信号):​No,TKEEP (Keep) 用于指示数据流中的哪些字节是有效的(通常用于处理非对齐的数据包尾部)。

Enable TLAST (启用 TLAST 信号):​No,TLAST 用于指示一个数据包(Packet)的结束。

设为 No,意味着这个 FIFO 认为数据是无限连续的流,没有“包”的概念。如果需要划分帧或包,必须选 Yes。

TID / TDEST / TUSER width (bits):​0

  • 这些是 AXI-Stream 的边带信号(ID、Destination、User data)。
  • 设为 0 表示不使用这些信号,它们不会出现在 IP 核的端口上,也不会被 FIFO 缓存。
image

Write flags(写入侧标志位)

Enable write data count (启用写入数据计数):​Yes​, 勾选后,IP 核会增加一个输出端口 axis_wr_data_count。 这个信号会实时输出 FIFO 中当前存储了多少个数据字(Data Words)。写入侧的逻辑可以读取这个值,精确判断 FIFO 里还有多少空间。

Enable almost full (启用“将满”信号):​Yes​, 勾选后,IP 核会增加一个输出端口 almost_full​。当 FIFO 只剩下一个写入位置时,这个信号就会变高。它是一个紧急警告信号,告诉前级电路“再写一个我就满了”,通常比标准的 TREADY 变低(表示已满)提前一个周期提示。

Enable programmable full (启用可编程满信号):​No​, 是否启用一个自定义阈值的“满”信号 (prog_full)。

如果选 Yes: 你可以在下方的 Programmable full threshold​ 框中填入一个数字(例如 400)。当 FIFO 里的数据量达到或超过 400 时,prog_full 信号就会变高。这用于需要比“将满”更早进行流控的场景。

Read flags(读取侧标志位)

Enable read data count (启用读取数据计数):​Yes​, 勾选后,IP 核会增加一个输出端口 axis_rd_data_count。 实时输出 FIFO 中当前有多少个数据等待被读取。

注意: 如果使用的是独立时钟(异步 FIFO),write data count​ 和 read data count 分别属于写入时钟域和读取时钟域,数值可能略有延迟差异。如果是同步 FIFO,这两个值通常是一样的。

Enable almost empty (启用“将空”信号):​Yes​, 勾选后,IP 核会增加一个输出端口 almost_empty​。 当 FIFO 只剩下一个数据可读时,这个信号就会变高。提示后级电路数据流即将断档。

Enable programmable empty (启用可编程空信号):​No​, 是否启用一个自定义阈值的“空”信号 (prog_empty)。

如果选 Yes: 可以在下方的 Programmable empty threshold 填入数字(例如 10)。当 FIFO 数据量少于等于 10 时,该信号变高。

选项与FIFO很类似,可以参考FIFO的使用。

可以直接打开官方的例程进行仿真:

image

1、写的速度是读的2倍:

这部分主要是因为从的程序:

always @(posedge aclk) begin if(areset) ... else begin s_axis_tready <= ~s_axis_tready; // 核心逻辑:每周期翻转一次 end end 

可以看到,s_axis_tready信号在 0 和 1 之间不断跳变。这意味着接收端一会儿说“我满了”,一会儿说“我可以收”。人为制造总线拥塞(Backpressure)。这强迫上游的 FIFO 必须将数据存入内部 RAM,从而验证 FIFO 的缓存功能和满标志逻辑是否正常工作。

2、tlast 一直为 1 是因为:代码逻辑显式地在复位后将其置 1

image

3、快满以后,读跟写的间隔变为一致。

image

自测

可以直接编写一个testbench:

`timescale 1ns / 1ps module tb_axis_data_fifo(); //------------------------------------------------------------------------- // 1. 信号定义 //------------------------------------------------------------------------- // 时钟与复位 reg clk; reg resetn; // Slave 接口 (写入端) reg s_axis_tvalid; wire s_axis_tready; reg [7:0] s_axis_tdata; reg s_axis_tlast; // Master 接口 (读取端) wire m_axis_tvalid; reg m_axis_tready; wire [7:0] m_axis_tdata; wire m_axis_tlast; // 状态信号 wire [31:0] axis_wr_data_count; wire [31:0] axis_rd_data_count; wire almost_empty; wire almost_full; //------------------------------------------------------------------------- // 2. DUT (Device Under Test) 实例化 //------------------------------------------------------------------------- axis_data_fifo_0 dut ( .s_axis_aresetn (resetn), // input wire s_axis_aresetn .s_axis_aclk (clk), // input wire s_axis_aclk // 写端口 (Slave) .s_axis_tvalid (s_axis_tvalid), // input wire s_axis_tvalid .s_axis_tready (s_axis_tready), // output wire s_axis_tready .s_axis_tdata (s_axis_tdata), // input wire [7 : 0] s_axis_tdata .s_axis_tlast (s_axis_tlast), // input wire s_axis_tlast // 读端口 (Master) .m_axis_tvalid (m_axis_tvalid), // output wire m_axis_tvalid .m_axis_tready (m_axis_tready), // input wire m_axis_tready .m_axis_tdata (m_axis_tdata), // output wire [7 : 0] m_axis_tdata .m_axis_tlast (m_axis_tlast), // output wire m_axis_tlast // 状态信号 .axis_wr_data_count (axis_wr_data_count), // output wire [31 : 0] axis_wr_data_count .axis_rd_data_count (axis_rd_data_count), // output wire [31 : 0] axis_rd_data_count .almost_empty (almost_empty), // output wire almost_empty .almost_full (almost_full) // output wire almost_full ); //------------------------------------------------------------------------- // 3. 时钟生成 (100MHz) //------------------------------------------------------------------------- initial begin clk = 0; forever #5 clk = ~clk; // 周期 10ns end //------------------------------------------------------------------------- // 4. 辅助任务:发送数据包 //------------------------------------------------------------------------- // 参数:发送的数据个数 task write_packet(input [31:0] length); integer i; begin @(posedge clk); // 同步到时钟沿 wait(resetn == 1); $display("[Writer] Start writing packet of length %0d at time %0t", length, $time); for (i = 0; i < length; i = i + 1) begin s_axis_tvalid <= 1'b1; s_axis_tdata <= i[7:0]; // 数据内容就是简单的 0, 1, 2... // 如果是最后一个数据,拉高 tlast if (i == length - 1) s_axis_tlast <= 1'b1; else s_axis_tlast <= 1'b0; // 等待握手成功 (tvalid & tready 均为高) do begin @(posedge clk); end while (s_axis_tready == 1'b0); // 如果 FIFO 满,tready 会拉低,这里会阻塞等待 end // 发送完毕,拉低信号 s_axis_tvalid <= 1'b0; s_axis_tlast <= 1'b0; $display("[Writer] Packet writing finished at time %0t", $time); end endtask //------------------------------------------------------------------------- // 5. 主测试激励 (Stimulus) //------------------------------------------------------------------------- initial begin // 初始化信号 resetn = 0; s_axis_tvalid = 0; s_axis_tdata = 0; s_axis_tlast = 0; m_axis_tready = 0; // 初始状态下不读取数据,为了测试 Full 信号 // 1. 复位序列 $display("--- Test Start: Reset ---"); #100; resetn = 1; #20; // 2. 写入测试:在不读取的情况下写入数据 // 假设 FIFO 深度较小,或者我们只是为了观察 Wr_count 增加 // 此时 m_axis_tready = 0,数据会堆积在 FIFO 中 $display("--- Test Phase 1: Write only (Fill FIFO) ---"); write_packet(16); // 写入 16 个数据 // 观察一段时间状态 #50; $display("Status Check: WR Count = %0d, RD Count = %0d, Almost Full = %b", axis_wr_data_count, axis_rd_data_count, almost_full); // 3. 读取测试:打开读使能,排出数据 $display("--- Test Phase 2: Enable Read (Drain FIFO) ---"); @(posedge clk); m_axis_tready = 1; // 允许读取 // 等待数据读完(简单起见,延时等待) wait(axis_rd_data_count == 0 && m_axis_tvalid == 0); #100; // 4. 并发读写测试 $display("--- Test Phase 3: Concurrent Read & Write ---"); m_axis_tready = 1; // 保持读取开启 write_packet(32); // 再次写入 32 个数据 #200; $display("--- Test Finished ---"); $stop; end //------------------------------------------------------------------------- // 6. 监控模块 (Monitor):打印读出的数据 //------------------------------------------------------------------------- always @(posedge clk) begin if (m_axis_tvalid && m_axis_tready) begin $display("[Reader] Read Data: %h (Last: %b) at time %0t", m_axis_tdata, m_axis_tlast, $time); end end endmodule 

仿真结果:

image

符合预期。其实就是两个AXI接口分别负责读和写,stream相对来说比较简单。

Read more

当前机器人在家庭场景落地难在哪里?

当前机器人在家庭场景落地难在哪里?

当前机器人在家庭场景落地难在哪里? 让机器人成为像电影里那样全能的“家庭保姆”,目前还面临着三大核心挑战:技术瓶颈、成本压力和隐私安全。虽然我们在春晚等场合看到了机器人的惊艳表现,但家庭环境的复杂性和不可预测性,让机器人从“舞台表演”到“入户干活”之间还存在巨大鸿沟。 ⚙️ 技术瓶颈:从“专才”到“通才”的跨越 当前机器人最大的短板在于其“大脑”的泛化能力和“身体”的灵巧度不足,难以应对家庭这种非结构化环境。 1. 续航焦虑:目前的消费级机器人续航时间普遍较短,大约只有 1.5至2小时。这对于需要长时间工作的家务或陪伴场景来说远远不够,机器人可能干一会儿就得去充电,无法满足全天候的需求。 2. 精细操作能力弱:机器人的“双手”还不够灵巧。它们可以完成预设好的简单抓取,但在面对“拿起玻璃杯倒水”、“叠衣服”或处理易碎品等需要精细力控和复杂协调的任务时,往往力不从心。行业数据显示,灵巧手的平均寿命甚至不足2个月,远未达到实用化的标准。 3. 环境适应性差:

企微群机器人发markdown消息支持表格

企微群机器人发markdown消息支持表格

结论 1.V1接口可以圈人,但是无法正确展示表格的markdown语法 2.V2接口可以展示表格的markdown语法,但是无法圈人 3.企微消息有长度限制 前言 今天是日本投降日,写篇技术文档。 企业微信机器人发markdown表格信息+如何艾特人 企微机器人发消息通知,目标是生成数据对比表格,然后艾特到具体的人来跟进事物的变化 1、成果收益 发表格数据,圈人 2、背景 目前机器人通知的内容太单调了,无法满足告警提醒的作用,需要罗列表格进行对比,需要艾特到具体人 3、解决方案 如何支持markdown表格类型 1.企业微信从4.1.38开始支持markdown表格的语法了。可以参看官方文档4.1.38版本新功能介绍 所以企业客户端要升级 2.我们历史使用的是msgtype:markdown,这个还是不支持的 { "msgtype": "markdown", "markdown&

AI绘画新选择:对比Stable Diffusion与Z-Image-Turbo的快速搭建方案

AI绘画新选择:对比Stable Diffusion与Z-Image-Turbo的快速搭建方案 为什么需要快速切换AI绘画模型? 作为一名数字艺术家,我经常需要在不同AI绘画模型之间切换测试效果。传统方式每次都要重新配置环境,不仅耗时耗力,还可能遇到依赖冲突等问题。本文将分享如何通过预置环境快速对比Stable Diffusion和Z-Image-Turbo这两个热门模型。 这类任务通常需要GPU环境支持,目前ZEEKLOG算力平台提供了包含这两个模型的预置镜像,可以快速部署验证。下面我会从实际使用角度,带你了解两种模型的特性差异和部署技巧。 环境准备与快速启动 基础环境要求 * GPU:建议NVIDIA显卡,显存≥8GB(Z-Image-Turbo最低6GB也可运行) * 系统:Linux/Windows WSL2 * 驱动:CUDA 11.7+ 一键启动命令 # 拉取预置镜像(已包含双模型) docker pull ZEEKLOG/ai-painting:sd-zimage # 启动容器(自动挂载输出目录) docker run -it --gpus al

空天地联动 | 一网统飞 | 无人机巡检系统落地方案

空天地联动 | 一网统飞 | 无人机巡检系统落地方案

一、政策需求 国家将低空经济列为战略性新兴产业,“十五五” 规划明确推进一网统飞、低空智治全国覆盖,要求 2026 年前实现地市一级飞行数据全接入、空域审批一体化、低空监管数字化。多部委联合发文,推动低空通信、导航、感知基础设施建设,规范无人机飞行与空域管理,鼓励以统一平台、统一调度、统一数据模式支撑政务巡检、应急救援、生态环保、城市治理等场景规模化落地,加速低空经济从试点走向全域普及。 二、市场需求与行业痛点 1. 空域管理分散,审批效率低:多部门分头审批、流程繁琐,跨区域飞行难,“黑飞”、乱飞风险突出,安全监管压力大。 2. 部门各自为战,资源浪费严重:各单位自建系统、自购设备,重复飞行、重复投入,财政成本高、资源利用率低。 3. 数据孤岛普遍,价值难释放:巡检数据格式不统一、无法共享,难以支撑决策与协同处置。 4.