做FPGA图像处理的朋友，早晚都得面对DDR3这堵墙。流水线里做个缩放、sobel都还好说，一旦视频源有两个、分辨率上到1080P60，板上那几颗DDR3就成了绕不开的硬骨头。我这次做的是一个纯Verilog的DDR3多通道读写控制器，不依赖厂家的MIG生成器，专门拿来给多路图像数据做帧缓存和搬运。文章里会把我自己设计这个控制器时的架构思路、DDR3时序要点、仲裁策略、Verilog实现细节、仿真调试方法以及布线层面的坑都拉出来聊一遍，如果你正在做FPGA图像采集、视频拼接、多窗口叠加这类项目，这篇应该能给你省下不少查资料的时间。
1. 这个DDR3控制器到底要解决什么问题
1.1 多通道图像数据的真实压力
先算一笔账。一路1080P60灰度图像，数据量大概是1920108060，约124MB/s。如果是RGB888，乘个3，就是373MB/s。两路720P60的RGB画面再加一路OSD叠加层，轻松超过500MB/s。
DDR3芯片的理论带宽看起来很吓人，16bit位宽跑到800MT/s也有1.6GB/s，但实际可用带宽要打折。因为DRAM要刷新、预充电、行切换，命令与命令之间还有各种时序间隔。如果控制器写得粗糙，频繁换行、频繁bank冲突，实际带宽能掉到理论值的一半以下。这个时候多通道之间就开始互相抢时间，表现就是画面撕裂、帧率上不去、写入丢数据。
我这次做的控制器，核心目标就是把这500MB/s级别甚至更高的多路图像数据流，稳定地搬进DDR3里，再按需读出来。控制器提供多个独立的读写通道，每个通道接口统一，上层图像模块不需要关心DDR3的bank、行、列、刷新这些事。
1.2 为什么不用MIG，非要自己“纯Verilog”造轮子
Xilinx的MIG生成器很好用，但碰上多通道自定义场景也会别扭。第一个问题是接口风格受限，MIG的用户接口本质是“读写命令+数据”的单通道流，你要多路视频流，还得自己在外面包一层仲裁和FIFO。第二个问题是时序封闭和引脚锁定由MIG说了算，想移植到别的板卡或者换个DDR3颗粒，经常要重新生成、重新跑。第三个问题是我自己的私心：MIG内部被包得严严实实，出了问题只能看波形猜，很难真正理解DDR3协议。
所以这次项目决定自己写控制器。注意，我这里说的“纯Verilog”是指控制逻辑完全自己写，命令状态机、仲裁调度、数据通路、FIFO管理这些全都用Verilog实现。物理层要上FPGA的专用IO资源，ISERDES、OSERDES、IDELAY这些还是得调原语，不然DDR3这种高速双沿接口很难在一个普通周期里稳定工作。这不丢人，反而说明你清楚哪些事情该自己做，哪些事情必须交给硬件原语。
自研控制器最大的收益是接口完全可控。我可以在每个通道上定义自己想要的AXI-Lite风格请求应答，也可以简化成“写请求+数据”、“读请求+返回数据”两套握手。对图像模块来说，只需要管自己的像素时钟域，把数据往FIFO里一塞，然后发起读写，剩下的事情控制器全包。
1.3 模块划分和总体数据流
整个控制器的模块划分按数据流方向分成四层。最顶层是ddr3_multi_ch_ctrl，对外暴露多通道用户接口和DDR3物理引脚。第二层是通道适配层，每个通道带异步FIFO，解决图像模块自己的时钟域和控制器公共时钟域的跨时钟问题。第三层是核心的仲裁调度和命令生成模块，负责把多个通道的读写请求转成DDR3命令序列。最底层是DDR3物理层，包含命令/地址输出、数据读写、DQS处理、数据延迟对齐。
图像通道0 ──> 写FIFO ──┐ 图像通道1 ──> 写FIFO ──┤ 通道0读取 ──> 读FIFO ──┤──> 写/读仲裁器 ──> 命令状态机 ──> DDR3 PHY ──> DDR3颗粒 通道1读取 ──> 读FIFO ──┘这样的结构有个很明显的好处：软件上层不需要看到DDR3细节。你要送一帧图像进来，就告诉控制器“目标地址在0x1000，长度是512个突发，数据来了”，控制器自己判断最近哪个bank是可用的、要不要先预充电、要不要插一笔刷新。如果哪路OSD要读数据，也走同样的通道接口，互不干扰。
实际码代码的时候，我会把通道接口设计成跟AXI4比较接近的“ADDR通道+写数据通道+读数据通道”三通道分离方式，只是砍掉了地址突发信号，因为图像应用基本不需要任意长度突发，固定长度一次发64字节到128字节就够用了。
2. DDR3协议里那些绕不开的时序约束
2.1 命令、bank状态和关键时序参数
DDR3不像SRAM那样给地址就出数据。一次完整的读操作，基本流程是激活（ACT）打开某个bank的某一行，然后等tRCD，再发读命令（RD），CAS延迟之后数据才出来。写类似，发写命令后要等tWR和后续时序。整个流程里最核心的是维护好bank行状态表。
举个实际例子，控制器工作时钟假设是200MHz，DDR3颗粒工作在1600MT/s，内存时钟400MHz，指令周期和用户时钟周期就是1.25ns和5ns的关系。颗粒的关键时序参数大约是这样：
| 参数 | 含义 | 典型值 | 折算到200MHz时钟周期 |
|---|---|---|---|
| tRCD | 激活到读写命令间隔 | 13.75ns | 3个周期 |
| tCL | CAS潜伏期 | 11个内存时钟 | 换算到用户时钟需要额外处理 |
| tRP | 预充电时间 | 13.75ns | 3个周期 |
| tRAS | 激活到预充电最短间隔 | 35ns | 7个周期 |
| tRC | 同一bank两次激活最小间隔 | 48.75ns | 10个周期 |
| tRFC | 刷新所需的阻塞时间 | 160ns | 32个周期 |
从表格能看出一个设计要点：同一bank的操作间隔被tRC锁死了。比如连续读同一个bank的不同行，必须先预充电再激活再读，光是命令上的开销就要十几个周期。如果好几个通道的图像数据正好落到同一个bank的不同行，控制器效率会非常难看。所以后来我在地址映射上动了心思，不同通道的起始地址尽量分散到不同bank，靠bank并行来隐藏tRAS和tRP。
控制器内部需要给每个bank维护至少三个状态：空闲、行已激活、预充电中。我用一个二维寄存器数组bank_row_open[8]保存当前打开的行号，再用一个bank_state[8]表示状态机的运行状态。仲裁器在选择下一个命令时，要根据目标bank状态做判断，能直接发读写命令就发，不能就插一笔预充电或者激活。
2.2 刷新策略不能只想着定时
DDR3要求64ms内完成8192次刷新，折算下来刷新间隔约7.8us。在很多demo工程里，大家做法就是起一个计数器到时间就插一笔刷新命令。这在普通读写压力下没问题，但图像数据是高强度持续读写，刷新命令一旦插入，必须等tRFC走完，命令通道和data总线全部暂停，对带宽影响不小。
我做的处理方式是“提前插空”加“紧急抢占”。平时仲裁器空闲时，立刻把已到期的刷新补掉。如果刷新时间快到了，仲裁器会优先把当前突发送完，然后在bank刚好预充电完成的时候插入刷新，避免刷新过程中还要额外等待tRP。实际代码里维护一个refresh_timer，到阈值附近就提高刷新请求优先级，这样既不会丢刷新窗口，也不会让图像通道出现明显的帧停顿。
还有个小细节，DDR3的刷新分REFRESH和REFRESH_PB，设计中可以结合bank状态尽量安排在bank空闲时刷新。自研控制器的好处就在这里，你可以把刷新当成一个普通的仲裁请求，让它跟读写命令一起排队，灵活度比厂家IP高很多。
2.3 用户接口与DDR3命令的映射关系
用户在上层看到的是“逻辑地址”，而DDR3物理地址由bank、row、column组成。芯片内部可以自动完成地址映射，控制器则需要自己算。我通常采用这样的映射：
- 地址低位映射到column，宽度由突发长度决定，BL8一次访问8个内存字，低3位需要保持为0；
- 中间位自然散列到bank，保证连续图像数据在不同bank之间轮转；
- 高位映射到row，代表这一行在bank里的行地址。
这样设计以后，连续写入一帧图像，数据会均匀分布在8个bank里。控制器在写下一段时，bank已经处于打开状态的概率就高，能尽量减少预充电和激活次数。实测下来，同样总吞吐量，这个映射比“bank在低位不散列”的版本，效率要提高将近15%。
3. 多通道读写调度器设计
3.1 先分清每路的实时性要求
多通道图像应用里，各通道对延迟和带宽的要求不一样。实时采集进来的图像写DDR3，最怕丢数据，比如CMOS传感器的数据一帧接一帧连续来，FIFO深度又有限，写请求不能被耽搁太久。显示输出从DDR3读数据，最怕断流，一旦读不到数据，屏幕上就会出现闪烁或者花屏。而像OSD图层这类，更新频率很低，带宽要求不高，但一旦发起请求也希望能尽快完成，免得和主画面抢时间。
所以仲裁器不能简单做成完全平等的轮询。我定义了三级优先级：
| 优先级 | 通道类型 | 说明 |
|---|---|---|
| 高 | 实时写入通道 | 数据来自传感器，几乎不可暂停 |
| 高 | 实时读通道 | 显示输出需要稳定数据流 |
| 中 | 普通读写通道 | 处理模块的中间结果 |
| 低 | 配置/后台通道 | 寄存器读写、帧统计等 |
高优先级通道之间用时间片轮转，避免某一帧数据量特别大时饿死其他高优先级通道。中低优先级通道则在高优先级空闲时插入执行。为了不让低优先级通道等太久，我加了一个starve_timer，超过一定时间没被调度到就强制插队一次。
这里的取舍很关键。如果你把所有通道当成同一优先级，图像传输可能抖动；如果你把某一通道优先级拉太高，另外几路就会出问题。实际调试时我用ILA抓仲裁器输出，发现有一路高分辨率视频写入时，另一路读通道的r_valid长时间拉不低，后来就是加上starve_timer解决的。
3.2 轮询、优先级和时隙三种方案怎么选
仲裁策略有几种常见方案。最简单的固定优先级，代码好写，但低优先级通道容易饿死，不推荐用在多路视频流上。纯轮询（Round Robin）实现也不复杂，每个通道平均分配带宽，但实时性差的通道会拖慢别人。还有一种时间片仲裁，把DDR3带宽按比例预分配，比如通道0拿60%、通道1拿30%、通道2拿10%，实现上稍微复杂，但最贴近图像应用的带宽需求。
我最终用的是“优先级+轮询+饥饿保护”的混合仲裁。每一轮仲裁开始时，先检查有没有高优先级请求；如果有，就在高优先级请求集合里轮询。如果只有中低优先级请求，依然轮询，但记录等待周期数，等待过久的请求会临时提升优先级。这样既保证了实时通道的低延迟，也避免了某一非实时通道永远等不到的问题。
代码上我用了一个很朴素的req_array和grant_id，每一拍更新仲裁结果。仲裁器不直接下发DDR3命令，只负责选出一个待执行请求，然后交给命令状态机去处理。状态机如果判断目标bank需要预充电，就先插入预充电；需要激活，就先插入激活。仲裁器和状态机分离，好处是逻辑清晰，后期想改调度策略不用动DDR3时序相关代码。
3.3 刷新命令怎么插入调度
上面说过刷新不能简单定时。我在仲裁器里把刷新也当成一个虚拟请求，优先级设为最高，但有一个小技巧：当refresh_timer快到期时，仲裁器会优先选一个bank状态为空闲的刷新请求；如果所有bank都忙，那就先让当前命令完成，同时把预充电命令提前发出去，确保在刷新前bank都已经回到idle状态。
实际工程的坑在于，tRFC长达160ns，折合200MHz时钟就是32拍。如果刷新期间正好有图像数据涌进来，FIFO就可能溢出。我的做法是给每个写通道的FIFO深度留够，按最大写带宽乘刷新阻塞时间再加上余量，动态计算深度。比如某通道突发吞吐率是200MB/s，刷新阻塞约190ns（再加上前后切换时间），中间最多有约38字节数据积压，FIFO至少留64字节才安全。你别小看这个计算，很多丢数据问题根本不是带宽不够，而是FIFO深度没cover住刷新周期。
4. 核心Verilog实现细节
4.1 顶层接口定义
顶层接口设计时我刻意让它简单直白，图像模块只认识“写请求/写数据/写应答”和“读请求/读返回”。每个通道带上独立的FIFO接口，上层只管按自己的像素时钟读和写。
module ddr3_multi_ch_ctrl #( parameter NUM_CH = 4, parameter ADDR_W = 27, parameter DATA_W = 64, // 内部数据总线宽度 parameter STRB_W = 8 )( input wire ctrl_clk, // 控制器公共时钟 input wire ctrl_rst_n, // 通道写地址/数据接口 output wire [NUM_CH-1:0] aw_ready, input wire [NUM_CH-1:0] aw_valid, input wire [NUM_CH*ADDR_W-1:0] aw_addr, input wire [NUM_CH*8-1:0] aw_len, output wire [NUM_CH-1:0] w_ready, input wire [NUM_CH-1:0] w_valid, input wire [NUM_CH*DATA_W-1:0] w_data, input wire [NUM_CH*STRB_W-1:0] w_strb, input wire [NUM_CH-1:0] w_last, // 通道读地址/数据接口 output wire [NUM_CH-1:0] ar_ready, input wire [NUM_CH-1:0] ar_valid, input wire [NUM_CH*ADDR_W-1:0] ar_addr, input wire [NUM_CH*8-1:0] ar_len, output wire [NUM_CH-1:0] r_valid, output wire [NUM_CH-1:0] r_last, output wire [NUM_CH*DATA_W-1:0] r_data, output wire [NUM_CH-1:0] r_error, // DDR3物理引脚 inout wire [15:0] ddr3_dq, output wire [13:0] ddr3_a, output wire [2:0] ddr3_ba, output wire [2:0] ddr3_bg, output wire [1:0] ddr3_cke, output wire [1:0] ddr3_cs_n, output wire [1:0] ddr3_odt, output wire [3:0] ddr3_dm, inout wire [3:0] ddr3_dqs_p, inout wire [3:0] ddr3_dqs_n, output wire ddr3_ck_p, output wire ddr3_ck_n, output wire ddr3_reset_n );这里内部数据总线取了64bit，对应BL8一次读8个16bitDDR字。用户接口的地址我统一用“内部数据宽度对齐”，就是说aw_addr的低3位必须为0，一个aw_len单位代表64字节。图像模块如果只写32bit像素，上层要做一次拼包，把两个像素拼成64bit再发过来。别嫌麻烦，拼包逻辑很便宜，换来的却是内部数据通路的整洁。
4.2 命令状态机的关键实现
命令状态机是整个控制器的心脏。我在设计时把它分出几个主状态：IDLE、ACT、RD、WR、PRE、REF、WAIT。仲裁器每次给状态机一个目标命令，状态机结合当前bank状态决定走哪条路径。
localparam S_IDLE = 4'd0, S_ACT = 4'd1, S_RD = 4'd2, S_WR = 4'd3, S_PRE = 4'd4, S_REF = 4'd5, S_WAIT = 4'd6; reg [3:0] state, next_state; always @(posedge ctrl_clk or negedge ctrl_rst_n) begin if (!ctrl_rst_n) state <= S_IDLE; else state <= next_state; end always @(*) begin next_state = state; case (state) S_IDLE: begin if (refresh_req && refresh_allowed) next_state = S_REF; else if (arb_grant_valid) begin if (arb_is_write) next_state = S_WR; else next_state = S_RD; end end S_WR: begin if (write_cmd_done) next_state = S_PRE; end ... endcase end写命令下发的时候，必须确认写数据已经在数据总线上准备好。DDR3要求写数据与写命令之间有一定对齐关系，控制器要向数据通路发出wr_data_launch信号。我这边数据通路的做法是，写FIFO输出数据先在用户时钟域组装成64bit，命令状态机在S_WR状态下同时拉高ddr3_cs_n、ddr3_we_n、ddr3_cas_n、ddr3_ras_n，形成写命令，并同步拉高数据有效信号，驱动OSERDES把数据在内存时钟的上升沿和下降沿分别送出。
读取命令则要特别注意CAS潜伏期。为了简化，我没有做前置重排序，而是固定采用一个“命令发出后N拍读数据返回”的模型。实际使用时，这个N要通过训练确定。在FPGA上我用了一个rd_latency_cnt计数器，读命令发出后开始计数，计数到预置值时从ISERDES的输出寄存器里锁存数据。只要DQS和时钟的相位关系校准好，这个固定延迟模型非常稳定。
4.3 写数据通路与字节掩码处理
图像数据进入DDR3前要过异步FIFO，把像素时钟域搬到控制器时钟域。异步FIFO我建议自己实现或者例化厂商FIFO，关键是写侧时钟和读侧时钟差别很大，一个几十MHz一个200MHz，FIFO深度必须留足。之前说过刷新阻塞的问题，在这个环节体现得最明显。我一般把写FIFO深度设为512到1024，按64bit宽度算，每个FIFO能存4KB到8KB数据，足够扛住两三次刷新窗口了。
字节掩码在图像场景经常被忽略。比如把一块小图贴到已有背景上，或者做画中画叠加，往往只需要覆盖目标区域的一部分字节。DDR3写命令自带DQM信号，可以在突发写时屏蔽不需要的字节通道。我在写数据通路里把每个通道的w_strb直接映射到DDR3的DQM引脚，这样上层做像素混合时可以直接利用DDR3的写入屏蔽，省掉先读后改的一次搬运。
有个细节是端序。来自CMOS的RAW10数据经常是打包成20bit一个像素，拼到64bit总线上时，字节顺序和DDR3内部bank存储顺序容易搞反。我Debug时遇到过显示画面颜色通道错位的现象，查半天发现是拼包时高低字节反了。这种问题纯看波形很难立刻定位，建议在上层设计时就固定好字节序约定，比如以大端方式把左边像素放高字节，并写在接口文档里。
4.4 读数据通路与DQS相位对齐
DDR3读路径上最麻烦的是DQS数据选通信号的相位对齐。DDR3在读取时，颗粒会把DQS和数据一起返回，但DQS相对内存时钟的相位并不固定。FPGA内部需要用IDELAY把DQS调整到数据眼图中心，再通过ISERDES在DQS上下沿采集数据。
这个部分是整个设计里我最不想“手撸”的地方。如果你的FPGA平台支持，我建议DQS延时用IDELAYCTRL和IDELAY原语，然后写一个简单的查找表训练流程。启动后先读一段训练用pattern，比如0xAAAA、0x5555或地址回环数据，扫描IDELAY的tap值，找到采样窗口最稳定的区间，再把这个tap值固定下来。
时序训练完成后，读数据会有一个固定的延迟，我把它折算进rd_latency_cnt。这个延迟值甚至可以通过读寄存器动态调整，但并不需要在每次上电都做二次训练。普通场景下，只要板卡电压和环境温度不是极端变化，固定tap值完全够用。
读数据返回还有一个对齐问题。第一次接DDR3时，我发现读回来的数据总是整帧循环右移一个64bit。原因很隐蔽：读数据经过ISERDES后，在DDR接口时钟域里多了一拍，我的读FIFO写使能没跟着多延一拍，导致第一个数据被丢掉。后来用ILA抓到读数据总线上第一个有效拍和FIFO写使能的相对位置，发现差了一拍，修正后问题消失。这个坑很多新手会踩，建议调试时先不要看DDR3内容，直接观察读数据总线在r_valid拉高前后的几个周期，把延迟建模搞准。
5. 仿真验证和硬件调试
5.1 搭建DDR3仿真模型，验证仲裁和状态机
写DDR3控制器，一定不要拿到板子上才调试。DDR3颗粒都有丰富的仿真模型，比如Micron的ddr3_model，可以直接在ModelSim或者Vivado Simulator里跑。
我会搭一个简单的测试bench，例化控制器和DDR3模型，然后写多个c测试任务，分别模拟两路写、两路读，以及读写并行。测试时重点看三件事：第一，写数据是否按地址正确落到DDR3；第二，读请求发出后，返回数据是否与写入内容一致；第三，连续威胁性的读写压力下，刷新命令能否正常插入且不丢数据。
仿真阶段最值得做的是“随机地址+随机长度”的压力测试。别只按顺序地址跑，图像数据在实际场景里是分块存储的，地址跳变很频繁。随机测试能暴露仲裁器对bank冲突处理的缺陷，也能暴露命令状态机在临界时序下卡死的问题。我有一版仲裁逻辑就是在随机测试里发现会连续给同一个bank发命令，导致tRC违例，仿真直接报warning，后来修改调度条件才通过。
5.2 用ILA抓取控制器内部信号的技巧
上板调试时ILA是神器。但别把ILA例化在顶层，padding整个DDR3总线，那样代价大、触发也不方便。我建议例化在仲裁器输出和命令状态机入口处，观察grant_id、target_bank、state、refresh_timer这几个信号就够了。
写过aw_valid、aw_ready这类握手信号时同样要留意。ILA里看控制器的响应是否及时，能直接发现“某通道请求一直得不到grant”的问题。我调试多通道画面撕裂时就遇到过，一路写通道占了grant很长时间，另一路读通道被拖到断流。从ILA波形上看，grant_id长时间停在通道0，加上饥饿保护后才恢复轮询。
如果设计里还有r_error信号，在调试版本里可以把它接到一个GPIO或者LED。同步到用户逻辑后，一旦DDR3读写出错就能立刻知道，省得整块板子跑半天才从画面上猜问题。
5.3 时序约束和DDR3布线规则
这部分的最后一块拼图是硬件层面。FPGA工程的时序约束对DDR3接口极其重要。控制器内部可以跑200MHz，引脚上却是400MHz双沿，IO时序余量很紧张。需要在XDC里正确创建合成时钟，把DDR3的ddr3_ck_p/ck_n约束为400MHz时钟，输入输出延迟约束按DDR3规格和PCB走线长度估算。
DDR3布线规则我这里划几个重点。DQS差分对内要做到严格等长，一般配对长度差控制在5mil内。DQ每一组字节通道和对应DQS要尽量等长，整组长度差控制在20mil内。地址、命令、控制信号最好与DQS组长度匹配，至少做到同层参考地完整。末端匹配电阻、VREF电容、去耦电容和电源纹波这些细节，直接决定你上板之后能不能一眼过时序训练。
有条件的板卡还会给DDR3做电阻端接或者片上ODT设置。FPGA里ODT模式可以通过配置引脚或者写MR寄存器选择，默认设置不懂的时候别乱改。我遇到过一块板子，DDR3颗粒是x16的，但SDRAM的ODT配置没对上，导致读数据眼图很差，后来翻芯片手册逐位确认才解决。
6. 常见问题与排查技巧
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 读回来的数据整体错位 | 读返回延迟建模不对，ISERDES输出少打一拍 | ILA抓读数据总线和FIFO写使能，检查首拍对齐 |
| 某通道写入丢数据、画面卡顿 | 写FIFO深度不足，刷新或bank切换期间溢出 | 减少FIFO写使能频率，观察FIFO几乎满信号 |
| 写数据后读出来有一个字节错位 | 拼包字节序不一致 | 用固定pattern写入，读回后和发送端比对 |
| 多通道中某路长期得不到调度 | 仲裁策略没有饥饿保护 | 在仲裁器添加等待计数，超时强制提升优先级 |
| 上板后DDR3训练始终失败 | 板级时序不满足，ODT/端接配置不对 | 检查DQS和DQ等长、VREF电压、IDELAY扫描范围 |
| 刷新期间FIFO溢出 | 刷新和仲裁配合不够默契 | 让刷新请求提前仲裁，把刷新放在bank空闲时插入 |
| 顶层时序无法收敛 | 跨时钟域处理不当，或者命令状态机逻辑过长 | 检查异步FIFO同步，优化仲裁器组合逻辑流水 |
你看，很多问题其实在仿真阶段就能提前暴露，剩下的才需要上板熬夜查。我个人的习惯是“仿真跑不通过绝不上板”，虽然是笨办法，但能省下大量调板时间。
这里再分享一个很实用的自校验技巧。在工程里我加了一个测试寄存器，能往DDR3的任意地址写入一串伪随机数，然后读回来做CRC校验。这个自校验模块平时不参与工作，需要时通过UART触发。这样调试的时候不需要依赖完整的图像通路，只要控制器本身能稳定读写DDR3，基本可以放心去查上层图像逻辑。
做这个控制器的过程中，我最大的体会是DDR3控制器的难点不在某个单一模块，而在“所有模块必须同时正确”这件事上。仲裁策略稍有瑕疵，可能只是偶发卡顿；DDR3时序差一拍，画面立刻花掉；FIFO深度不够，压力峰值一来就丢数据。每一个设计决定都会在最终的系统稳定性上体现出来。如果你也在做类似的东西，建议先把模块接口定义清楚，再一步一步从仿真到上板推进，不要一上来就想把多通道、刷新、训练全部一次做对。分阶段验证，踩的坑会少很多。
