Vivado驱动LED矩阵：从时序焦虑到硬件确定性的实战手记
去年调试一块32×32单色LED点阵板时，我卡在“第17行总不亮”整整三天。示波器测IO电平正常，逻辑分析仪看数据流也对得上，可只要帧率超过85 Hz，那一行就像被施了隐身咒——直到某天深夜翻Vivado的timing_summary.rpt，发现row_driver_reg[4] → led_row[4]路径的WNS是-0.42 ns。那一刻我才真正明白：FPGA不是写完代码就能跑的MCU，而是你每行HDL都在和硅片签对赌协议——赌的是时序、是布线、是工具链里那些藏在报告深处的数字。
这篇文章不讲Vivado菜单怎么点，也不列IP核参数表。它是我用Basys3、Nexys4、Zybo Z7实打实焊过五块LED板、烧过七版比特流后，把Vivado揉碎了咽下去再吐出来的经验。我们以最朴素的8×8共阴极矩阵为切口，聊透一个工程师如何用Vivado把“想让LED亮”变成“每一纳秒都可控的物理现实”。
行扫描的本质：不是计数器，是时间契约
新手常以为LED矩阵驱动就是写个for(i=0;i<8;i++)循环扫行——但FPGA里没有“循环”，只有状态机与时序契约。
你写的这行Verilog：
always @(posedge clk_i or negedge rst_ni) begin if (!rst_ni) row_cnt <= 4'd0; else if (row_en) row_cnt <= row_cnt + 1'b1; end在Vivado综合后，实际生成的是4个触发器（FF）加1个进位链LUT。而真正决定LED是否稳定显示的，是row_cnt更新后，信号经过组合逻辑到达led_row[3:0]管脚所需的最大传播延迟。
我在Basys3上实测过：当系统时钟设为100 MHz（周期10 ns），若未加约束，Vivado默认布线可能让某条行线延迟达9.2 ns——这意味着在下一个时钟沿到来前，新行地址还没稳定，驱动芯片（如74HC138）就会锁存错误的行码，造成跳行或鬼影。
破局关键不在代码，而在XDC里这一行：
set_output_delay -max 1.5 -clock [get_clocks clk_sys] [get_ports led_row[*]]这个1.5 ns不是拍脑袋定的。它来自74HC138的建立时间（Tsu=1.2 ns）+ PCB走线裕量（0.3 ns）。Vivado实现阶段会强制将所有led_row网络布线长度控制在等效延迟≤1.5 ns内——这才是硬件确定性的起点。
💡 真实体验：在Vi
