FPGA+FX3 USB3.0高速采集链路实战：GPIF II与DMA调优到338MB/s

我一直觉得FPGA工程师和USB协议栈之间隔着一道看不见的墙。你让FPGA跑200MHz逻辑、调DDR3、做图像卷积都没问题但一旦接到USB3.0就得跟繁琐的驱动、描述符、DMA队列较劲。前前后后折腾了一个多月总算把这条链路彻底打通FPGA采集数据通过GPIF II接口交给Cypress FX3CYUSB3014再走USB3.0 Bulk传输回上位机实测稳定跑到338MB/s。这个速度是什么概念USB3.0协议层理论极限大概400MB/s出头跑到338MB/s已经接近85%效率基本把这条链路的潜力榨干了。这篇文章不是讲PPT思路而是把整个项目从选型、架构、固件、FPGA逻辑到驱动、上位机测速、性能优化和踩坑实录完整复述一遍。适合两种人看一种是手里有高速ADC、图像Sensor、软件无线电前端想把数据搬到PC上的FPGA开发者另一种是刚接触FX3想知道GPIF II到底怎么配、DMA怎么绕开坑的人。整体篇幅会比较长但每一步都是实际动过手的照着走能省很多时间。1. 整体设计方案选型与架构拆解1.1 为什么偏偏选FPGAFX3而不是Zynq或原生USB3.0 PHY先说选型的思路。很多人的第一反应是既然要做USB3.0直接用带USB3.0 PHY的SoC比如Zynq UltraScale不就行了这话理论上没错但实际落地会碰到三个硬问题第一Zynq UltraScale的USB3.0控制器虽然性能不错但通常要跑Linux或裸机协议栈驱动、设备树、中断处理一大堆对于只想要“把数据搬到PC”这个需求复杂度严重超标。第二原生USB3.0 PHY硬核的License费用和PCB设计难度都不低差分对阻抗、参考时钟、眼图调试任何一个环节出问题都可能让你卡两周。第三USB协议栈本身很“琐碎”枚举、控制传输、批量传输调度、电源管理用FPGA纯逻辑去实现USB3.0协议不是不行但工作量巨大且没有必要。FX3的方案就是把“协议”和“数据”分离。FPGA只负责采集、缓存、按时序把数据递出去FX3内置了USB3.0物理层、ARM926EJ-S内核、DMA控制器和可编程的GPIF II接口Cypress把协议栈全部封装好了你要做的只是配置DMA通道、启动GPIF、然后写一个简单的固件循环。说白了FPGA管“速度”FX3管“规矩”各干各的最后用一条并行总线对接。1.2 整个链路的架构与数据流我的系统比较简单前端是高速ADC采样率100MSPS16bit双通道数据流大概是这样的ADC采样数据 → FPGA内部FIFO缓存跨时钟域 → GPIF II接口Slave FIFO模式 → FX3内部DMA → USB3.0 Bulk IN端点 → 上位机软件读取每一段都有各自的瓶颈调试的时候要分开看。FPGA侧ADC数据率大概是100M×16bit×2通道400MB/s但这个峰值持续不了多久实际是突发式的。FPGA内部用异步FIFO把数据从采样时钟域搬到GPIF接口的PCLK时钟域FIFO深度选了8K×32bit。FX3侧GPIF II接口配置为32bit数据总线PCLK跑100MHz接口理论带宽是400MB/s足够应付USB3.0实际传输上限。USB侧PC主板的xHCI控制器实际上能跑到的Bulk吞吐一般在350MB/s左右实测Intel原生USB3.0口这决定了整个系统的天花板。模块分工我用一张表说明模块职责关键指标ADC前端模拟采样输出LVDS/并行数据采样率、位宽、通道数FPGA数据缓冲、时钟域转换、GPIF时序控制FIFO深度、状态机时序GPIF II接口并行总线协议转换对接FX3内部DMA总线位宽32bit、PCLK 100MHzFX3 DMA数据从GPIF搬移到USB端点DMA描述符数量、Buffer大小USB3.0链路物理传输PC枚举与驱动交互Bulk端点、传输调度PC上位机通过CyUSB驱动读取数据Buffer大小、线程模型这里有个容易被忽略的点FPGA的FIFO深度不能只看平均速率要看最坏情况下的突发长度。USB的Bulk传输是不保证实时的主机侧可能因为调度延迟几十微秒都没有发起读请求这段时间FX3内部FIFO会积压进而通过FLAG信号反压给FPGA。如果FPGA的FIFO太浅一遇到反压就溢出丢数那再怎么优化上层都没用。我最后把FPGA内部FIFO和各种缓冲加起来大概能扛住2ms的连续突发足够应付绝大多数调度抖动。2. FX3端核心配置GPIF II和DMA的实操细节2.1 FX3的内部架构决定了你该关注什么CYUSB3014的内部框图核心是ARM926EJ-S200MHz旁边挂着一堆外设但对我们做数据采集真正重要的是三条USB3.0 PHY、DMA控制器、GPIF II接口。这三者之间的关系可以理解成一个“中转站”USB PHY负责把数据发到线上GPIF II负责从外部FPGA收数据中间所有数据都通过DMA描述符在内存里流转。FX3中有“套接字Socket”和“DMA通道”两个概念。Socket是硬件层面的数据出入口好比物理端口DMA通道是软件创建的逻辑通路决定数据从一个Socket走到另一个Socket。我们做数据采集本质上就是创建一条DMA通道从GPIF II的SocketP端口把数据搬到USB的SocketU端口方向是FPGA→PC所以对应的是USB Bulk IN端点。我自己第一次看FX3固件时最大的障碍是描述符循环队列的描述。你可以把DMA描述符想象成一张张“搬运任务卡”每张卡写明了“从哪取数据、取多少、放到哪个缓冲、下一个任务卡在哪”。FX3的DMA控制器按顺序执行这些任务数据填满一个缓冲就发一个事件通知然后继续执行下一个。好处是CPU不用逐字节搬运坏处是每个人的逻辑都绕在描述符的配置上配置错了数据就乱飞。2.2 同步Slave FIFO模式的时序关键点GPIF II的可编程状态机是FX3最核心也最难啃的部分。好在Cypress提供了一个叫GPIF II Designer的可视化工具可以直接生成状态机配置和C头文件。我用的模式是“同步Slave FIFO”这个模式下FX3相当于一个从设备FPGA侧以PCLK为时钟通过SLWR写使能、SLRD读使能、SLOE输出使能、PKTEND包结束等信号读写FIFO。关键的信号只有这几个SLWR写使能低有效。FPGA在PCLK上升沿采样数据线DQ同时保持SLWR为低数据就被写入FX3的FIFO。PKTEND包结束信号低有效。Bulk传输是分包的FX3内部按512字节、1KB等粒度组包当你想结束当前USB传输并提交给主机时需要拉低PKTEND一拍配合SLWR完成“短包”提交。FLAGA/FLAGBFIFO状态标志可配置为可编程级、空、满等。FPGA通过读FLAG来判断当前能不能写避免覆盖。这里最需要强调的是时序关系。FX3的数据手册上写了SLWR拉低之前数据信号DQ需要建立一段时间而且SLWR撤掉时数据也要保持一段时间。很多人拿FPGA直接怼GPIO时序不满足跑出来的速度忽高忽低。我的做法是在FPGA内部把SLWR和数据信号全部放到PCLK的同一个时钟域然后通过ODDR原语输出保证信号在PCLK上升沿附近变化。对了PCLK一般配置为100MHz这样可以实现400MB/s的接口理论带宽完全够USB3.0用。2.3 固件框架DMA通道、描述符、启动顺序固件这块直接基于Cypress SDK的USB BulkLoopAuto示例改比从零手写靠谱得多。核心就几个函数CyU3PDmaChannelCreate创建DMA通道CyU3PGpifStart启动GPIF状态机CyU3PUsbStart启动USB协议栈。改完以后整个固件的主循环几乎不需要做什么DMA通道会自动把GPIF收进来的数据搬到USB端点。我的DMA通道配置是CyU3PDmaChannelConfig_t dmaConfig; dmaConfig.size 16384; // 每个缓冲16KB dmaConfig.count 8; // 描述符数量8个 dmaConfig.prodSckId CY_U3P_PIB_SOCKET_0; // 生产者GPIF II端口 dmaConfig.consSckId CY_U3P_CPU_SOCKET; // 消费者CPU Socket或者直接U端口 dmaConfig.dmaMode CY_U3P_DMA_MODE_BYTE; // 字节模式 dmaConfig.notification CY_U3P_DMA_CB_PROD_EVENT;等一下上面这个配置是给“CPU中转”版本的适合调试但性能很低。真正跑满带宽应该把DMA通道的生产者和消费者直接接好让数据绕开CPU从GPIF Socket直接流到USB Socket类似这样dmaConfig.prodSckId CY_U3P_PIB_SOCKET_0; dmaConfig.consSckId CY_U3P_UIB_SOCKET_0; // USB端点Socket这样配置以后ARM核只在描述符事件到来时做标记不碰数据本身吞吐率才能上来。Cypress官方示例CyBulkLoopAuto里就是这种“零拷贝”模式。我在这个基础上只改了两处一是把DMA缓冲加大到16KB二是把描述符数量从默认的4个加到8个效果立竿见影Bulk传输吞吐直接提升了一截。启动顺序也有讲究。固件启动时必须先创建DMA通道然后启动GPIF最后启动USB枚举。顺序错了可能出现GPIF已经开始往一个还没配置好的DMA通道里灌数据导致死锁或者数据丢失。我的做法是在CyU3PUsbStart之前先CyU3PGpifStart但DMA通道必须在更早的位置创建好形成一个“先建通道、再启接口、最后上线”的流程。3. FPGA逻辑实现把100MHz的PCLK时序走稳3.1 FPGA逻辑顶层设计与划分FPGA侧的逻辑我分成四个模块adc_ifADC接口负责接收采样数据和采样时钟处理位对齐、字对齐。如果是LVDS接口的高速ADC还要做延迟链校准。fifo_cross跨时钟域异步FIFO把数据从ADC时钟域搬到PCLK时钟域。gpif_ctrlGPIF II写时序控制器核心状态机直接产生SLWR、PKTEND、地址线信号。dbg_uart调试用UART模块方便在板子上打印状态信息。FPGA选型上我用的是Xilinx Artix-7系列不带PCIe硬核的A35T资源完全够。如果你用的是国产高云、紫光或者Intel Cyclone逻辑也差不多只是原语和IP核名称不一样。Artix-7的好处是内置xpm_fifo_async这种现成的异步FIFO原语参数化配置就行省很多事。调试阶段我其实是用UART模块打印状态寄存器的。每次PC端读数速率不对就去读取FPGA里的FIFO空满计数、写字节计数和错误标志通过UART打出来。这就跟热词里“FPGA实现UART_RX接收仿真”是一个道理别小看UART关键时候比逻辑分析仪好用因为不占JTAG通道随时能看内部状态。3.2 GPIF II写时序状态机第一版写时序状态机我踩了不少坑核心代码如下我加了详细注释module gpif_ctrl #( parameter FIFO_DEPTH 2048 )( input wire pclk, // FX3 PCLK 100MHz input wire rst_n, input wire [31:0] data_in, // FPGA内部FIFO读数据 input wire fifo_empty, input wire fifo_rd_en, // 读FIFO使能 output reg [31:0] dq, // 接到FX3 DQ[31:0] output reg slwr, output reg pktend, output reg oe, // 输出使能接FX3 SLOE input wire flaga // FX3 FIFO状态可编程阈值 ); localparam IDLE 3d0; localparam RDFIFO 3d1; localparam HOLD 3d2; localparam SHORT 3d3; reg [2:0] state, next_state; reg [11:0] byte_cnt; // 当前包已传输字节数 reg [511:0] packet_len; // 期望的包长度 always (posedge pclk or negedge rst_n) begin if (!rst_n) begin state IDLE; slwr 1b1; pktend 1b1; dq 32b0; byte_cnt 0; end else begin case (state) IDLE: begin pktend 1b1; if (!fifo_empty flaga) begin byte_cnt 0; state RDFIFO; end end RDFIFO: begin if (fifo_empty || !flaga || byte_cnt packet_len) begin slwr 1b1; state SHORT; // 包长达到或FIFO空结束当前包 end else begin dq data_in; slwr 1b0; byte_cnt byte_cnt 4; // 每个周期4字节 end end SHORT: begin slwr 1b1; pktend 1b0; // 提交当前包短包通知 state IDLE; end default: state IDLE; endcase end end assign fifo_rd_en (state RDFIFO) !fifo_empty flaga; endmodule很多人第一次写这个状态机总是忘了“排队提交”这件事。Bulk传输中如果你连续写了很多数据最后不拉PKTEND主机可能一直等不到完整的包结束标记导致数据迟迟不交付。反过来说也不能每几个周期就PKTEND一次那样会产生大量小包USB效率很低。我一般让FPGA攒够4KB或者当FIFO为空时再提交一次包算下来吞吐率最优。3.3 跨时钟域与背压处理跨时钟域这块千万不能图省事用双触发器打拍。数据是32bit并行从采样时钟域到100MHz PCLK必须用异步FIFO。Artix-7上我用了XPM原语核心只需要配好几个参数xpm_fifo_async #( .FIFO_MEMORY_TYPE (block), .READ_DATA_WIDTH (32), .WRITE_DATA_WIDTH (32), .READ_MODE (fwft), .FULL_RESET_VALUE (0), .CDC_SYNC_STAGES (4) ) u_fifo_cross ( .wr_clk (adc_clk), .wr_en (adc_wr_en), .din (adc_data), .rd_clk (pclk), .rd_en (fifo_rd_en), .dout (fifo_dout), .empty (fifo_empty), .full (fifo_full) );背压处理是整个FPGA逻辑稳定性的核心。FX3这边通过FLAGA通知FPGA“FIFO快要满了”FPGA一旦看到FLAGA无效立刻暂停SLWR和读FIFO数据自然压在FIFO里。如果FIFO也满了那就只能反压到ADC前端要么让ADC暂停要么丢弃数据帧并置标志位。实际项目中我做了一层“可配置丢帧”逻辑允许丢弃整帧图像数据但保证每一帧内部不丢数。这对图像处理场景非常实用具体到你的项目可能是丢掉一段采样数据总比整个系统崩溃强。4. 原厂SDK安装、固件烧录与上位机测速实战4.1 FX3固件烧录与驱动安装固件编译环境是Cypress的EZ-USB FX3 SDK现在叫FX3 SDK需要从Infineon官网下载大概1GB左右。这是个Windows下的集成环境基于Eclipse编译链是ARM GCC。第一次编译BulkLoopAuto工程会生成一个.img文件这个文件可以通过FX3的USB启动模式烧录。注意FX3有几种启动模式靠PMODE引脚选择USB Boot、I2C EEPROM Boot、SPI Flash Boot。我板子上把PMODE配置为“USB Boot优先超时后I2C启动”这样开发阶段直接从USB下载固件跑通了再烧进EEPROM。驱动方面Windows系统装的是Cypress官方维护的CyUSB3.sys。这个驱动有个特点它对VID/PID有白名单机制。如果你的FX3固件换了一个VID/PID而驱动没有对应更新设备管理器就会显示感叹号。最初在“USB3.0 inf”相关搜索里翻到的问题九成都是这个原因。解决办法是专用工具“CyUSB.inf配置向导”生成正确的inf文件或者安装SDK时选择“所有Cypress设备都使用CyUSB3.sys”。驱动装好后用SDK自带的“Control Center”工具可以看到FX3枚举出的Bulk IN/OUT端点。先跑一下SDK里的“BulkLoop”测试确认端点能收发数据如果这一步都不通后面测速没有意义。实测表明SDK自带的BulkLoop工具在默认参数下Bulk IN吞吐就能跑到250MB/s以上这个可以作为系统健康度的基准值。4.2 上位机测速程序与Buffer大小选择Cypress官方C#库CyUSB.dll封装了XferData方法可以很方便地做Bulk读。但测速程序不能写得想当然IO有一点要注意每次读取的缓冲区大小严重影响吞吐率。我写了个简单的C控制台程序用CyAPI库#include CyAPI.h #include chrono #include vector #include iostream int main() { CCyUSBDevice* usb new CCyUSBDevice(); CCyBulkEndPoint* bulkIn nullptr; for (int i 1; i usb-BulkInEndPointCount(); i) { bulkIn usb-BulkInEndPt(i); if (bulkIn) break; } const int BUFFER_SIZE 4 * 1024 * 1024; // 4MB缓冲区 std::vectorUCHAR buf(BUFFER_SIZE); LONG length BUFFER_SIZE; UCHAR* pBuf buf.data(); auto start std::chrono::high_resolution_clock::now(); long totalBytes 0; int iterations 100; for (int i 0; i iterations; i) { length BUFFER_SIZE; bool ok bulkIn-XferData(pBuf, length, true); // 同步读取 if (ok) totalBytes length; else std::cout XferData error at i std::endl; } auto end std::chrono::high_resolution_clock::now(); double seconds std::chrono::durationdouble(end - start).count(); double speedMBps (double)totalBytes / 1024.0 / 1024.0 / seconds; std::cout Speed: speedMBps MB/s std::endl; return 0; }Buffer大小我从64KB到16MB都测过数据如下缓冲区大小实测吞吐率说明64KB约286MB/s频繁调用XferDataIO开销大256KB约315MB/s中等性能1MB约332MB/s稳定推荐日常使用4MB约338MB/s单次传输时间长效率最高16MB约339MB/s提升不明显内存压力大原因很简单每次XferData调用都有一次用户态到内核态的切换缓冲区越大单位字节的调用开销越小。但缓冲区超过4MB以后内存拷贝和时间开销不再线性增长收益变小。所以我的最终推荐是单次Bulk读设置为1MB4MB配合双线程“一读一存”模型可以在不增加延迟的情况下最大化吞吐。4.3 实测数据记录“338MB/s”是怎么跑出来的实测环境是Artix-7板卡 CYUSB3014PC为Intel原生USB3.0口Windows 10 x64FX3固件为BulkLoopAuto改版FPGA不断向GPIF写数据。上位机采用4MB缓冲区循环读取测得稳定速度338MB/s换算一下大概2.7Gbps已经接近USB3.0 Bulk传输的实际极限。测速的时候有几个变量必须固定否则数据说服力不够电脑电源策略设为“高性能”USB控制器省电策略关闭。不插USB Hub直连主板后置USB口。关掉可能抢占带宽的程序比如文件同步、自动更新。每次测速前重启上位机软件避免缓存状态干扰。我还做过一次对比实验同样一套硬件把PCLK降到50MHz、总线位宽改为16bit吞吐直接掉到170MB/s把FX3固件改成CPU中转模式数据先到内存再由USB端点发送吞吐更是只有90MB/s左右。这说明接口位宽和DMA模式的选择比任何软件调优都重要。后面再单独讲优化链路。5. 常见问题与性能排查实录5.1 枚举失败、驱动感叹号与下载不了固件很多人在“FX3”这一关就被卡住了。最典型的故障是设备管理器里看到“Cypress FX3 USB BootLoader Device”但无法加载CyUSB3.sys或者设备跳到“Unknown Device”。排查顺序我建议这样先量一下FX3的复位和PMODE引脚确认板子上电后芯片进入了USB Boot模式。PMODE引脚如果被浮空芯片可能进入SPI Boot模式枚举出来的是AP模式而不是USB Boot模式这时候主机根本识别不到。其次把USB线换成高质量屏蔽线有些USB3.0差分对信号质量差会导致枚举不稳定。最后如果你改过VID/PID一定要用SDK的inf生成向导重新生成驱动。我这里有个独家教训固件下载器比如SDK自带的“CyUSB3.sys”驱动对应的下载工具在某些主板上会卡在“Starting download...”其实不是硬件问题而是Windows对USB控制传输的流量控制机制导致下载超时。解决办法是去设备管理器里把“允许计算机关闭此设备以节约电源”的勾选取消。5.2 速度上不去的定位思路到底是哪一段的瓶颈如果跑不到338MB/s我建议按下面这个顺序逐级排查第一确认PC主板USB控制器的能力。用CrystalDiskMark或者大型U盘测一下同一接口的读写速度如果接口本身只能跑到150MB/s那FPGA和FX3再快也没用。第二确认FX3自身性能。在固件里把GPIF数据源换成内部pattern发生器也就是FX3生成的固定数据流不依赖FPGA直接测Bulk IN吞吐。如果这个测试也上不了300MB/s问题在FX3固件配置如果能上300MB/s问题大概率在FPGA侧时序或GPIF握手。第三确认FPGA侧数据源充足。把FPGA内部的FIFO先人为填满然后观察数据是否能持续输出避免ADC源的数据率不够导致平均吞吐下降。第四检查FLAGA反压是否频繁触发。如果FLAGA经常无效说明FX3内部DMA缓冲没能及时搬运数据到USB需要调大DMA描述符个数或缓冲大小。这一套定位方法用下来基本能把瓶颈锁定在单一段落。我不止一次看到有人优化了一周上位机代码最后发现是FPGA逻辑里一个计数器溢出让数据周期停止白白浪费时间。5.3 数据错位、丢包和偶发异常的处理方法数据错位属于最让人头疼的一类。现象是上位机收到的数据存在偶发的字节错位比如32bit接口上出现4字节偏移。这种问题几乎都是FPGA侧数据线与FX3数据线映射不一致造成的。我调试时用了一个固定pattern发生器比如交替发送0xAAAAAAAA和0x55555555如果上位机收到的序列不是交替的说明数据位映射有错。丢包问题更难排查。可能的原因FPGA FIFO溢出、FX3 DMA通道缓冲不足、USB枚举时重新配置设备导致短暂中断。我的做法是在FPGA内设计一个数据帧计数器每1ms递增一次并把这个值嵌入数据流中。上位机解析时一旦发现计数不连续就知道丢了哪一段数据。再配合USB3.0协议分析仪就很容易分清是链路层丢还是FPGA侧丢。如果发现偶发丢包且伴随FPGA的FIFO满标志触发那就得加大FIFO深度或者优化ADC数据源的突发特性。最极端的情况下可以在FPGA里做一个“丢弃整帧并重新同步”的机制保证链路恢复后数据不再错位这在图像传输中尤其重要。5.4 冲刺338MB/s的优化清单最后把我实测能提升性能的点全部列出来按性价比排序DMA描述符数量和缓冲大小。FX3默认的4个描述符、4KB缓冲属于“能用但跑不快”的配置。我改成8个描述符、16KB缓冲后吞吐率提升约12%是整个系统优化中最有效的一步。GPIF II总线位宽和PCLK频率。从16bit50MHz改到32bit100MHz理论带宽翻4倍实测吞吐率翻倍。这是硬件选型阶段就该定好的后面改代价很大。上位机Buffer大小。从64KB提到4MB吞吐率提升约18%改动成本极低。上位机使用异步读取或多线程流水线。CPU无法同时执行“拷贝数据”和“等待USB数据传输”用双缓冲异步读取可以让USB一直处于忙碌状态吞吐率再提升5%左右。关闭FX3的USB LPM链路电源管理避免链路进入低功耗状态后唤醒带来的延迟。这个可以在固件里通过CyU3PUsbSetLinkPowerMode配置。另外FX3还有一个“几何突发”Burst模式允许GPIF在设置好起始地址和突发长度后连续执行读写每次传输的地址翻转开销被减少。在延续大量数据块读取时这个特性对性能的影响大约有3%~5%。我的固件里开了这个模式配合PCLK 100MHz和32bit总线整体链路才最终稳定在338MB/s。开这个模式时注意一个细节GPIF的地址信号A[1:0]在Burst模式下由FX3内部逻辑自动生成不是FPGA控制。这跟普通的Slave FIFO访问方式完全不同需要同步修改FPGA侧的状态机逻辑否则数据接口会错乱。我当时花了整整一个晚上定位才反应过来希望看到这篇文章的人能少走这个弯路。最后再分享一个小技巧这个项目做完我最深刻的体会是FPGAFX3这套组合真正难的从来不是FPGA逻辑不是固件API而是“时序”和“缓冲”这两个词。GPIF II的时序只要板子布线没问题基本照着手册写就能过DMA描述符配置也不算复杂按Cypress的示例改就是。但“缓冲”这件事从FPGA内部FIFO到FX3描述符队列再到上位机缓冲每个环节都在互相依赖。你单点调优可能毫无效果必须整条链一起看。如果你拿到这套方案准备做产品化我建议后面重点做两件事一是把EEPROM启动固化做好让板子插上USB就能跑不用每次都下载固件二是加一层数据校验在上位机做完整性校验这样能提前发现链路劣化而不是等到客户反馈。另外一个扩展方向是如果数据率超过USB3.0的极限可以考虑多路FX3或者FPGA直接接PCIe但这都是后话了。就先聊到这里。如果你也在调FPGAFX3的USB3.0采集链路欢迎在评论区描述你的现象和配置我看到会回复。踩过坑的人一起聊比一个人翻手册效率高多了。