做信号处理板卡这些年我最深的一个感受是需求工程这个说法很多硬件工程师一听就头大觉得是“搞软件/搞管理的人”才需要干的事画原理图、写HDL才是硬功夫。可真到板卡流片回来、整机联调跑不通的时候回头一查十有八九的问题根源不在电路设计而在需求本身——要么系统指标没细化到板级要么板级需求写得含糊没法验证要么需求条目直接缺了一整块。今天这讲我就拿一块典型的军用信号处理板卡来拆把需求工程怎么一步步落地成一份能指导设计、能指导测试的板级需求规格书掰开揉碎讲清楚。这篇文章比较适合三类人看一是刚从“画板子”往“做系统”转的硬件工程师二是做FPGA/DSP开发但总被需求文档坑的软件向工程师三是需要评审需求文档、但自己也拿不准“好需求”长什么样的项目经理和技术负责人。我会结合雷达信号处理、PCI数据捕获与信号处理这类典型场景把从系统需求分解到板级需求条目、再到验证闭环的完整套路讲透最后附上我踩过的坑和排查经验。1. 为什么板级需求规格书总在“翻车”三个典型症状先不急着讲怎么写我们先聊聊为什么很多项目里板级需求规格书要么根本不存在要么写出来跟没写一样。我把它归纳成三个典型症状大家可以对照一下自己项目里有没有。1.1 症状一系统需求直接“跳”到原理图中间少了一层很多项目组拿到系统级需求规格书之后硬件负责人看完觉得“哦就是要做一块采集板”然后直接开始选型、画原理图、写FPGA逻辑。中间最关键的“板级需求规格书”这一层被完全跳过了。结果就是系统级写着“完成中频信号采集与处理”板卡上到底采集什么频点、带宽多少、采样率多少、数据送给谁、接口是什么协议、时序要求多高全靠硬件工程师自己脑补。脑补的后果就是等到软件工程师来驱动这块板卡的时候发现寄存器地址跟人家预先约定好的对不上结构工程师把板卡装进机箱的时候发现连接器高度差了2mm测试工程师去写验收用例的时候发现根本没法证明“采集功能正常”到底算通过还是算不通过。这些问题全都要等到实物阶段才暴露改一版板子三个月联调现场天天救火。1.2 症状二需求条目写得“像散文”没法验证有些项目也写了需求文档但看下来更像散文而不是工程输入。比如这么一条“板卡应具备良好的信号处理能力能够满足雷达信号实时处理要求。”这句话听起来没什么不对但你让设计 FPGA 的人怎么落地“良好”是多好“实时”是几毫秒处理多少点数据资源占用上限是多少需求条目写不清楚是板级需求规格书最常见的死法。为什么会有这种情况因为写的人自己也没想清楚指标或者怕写具体了到时候实现不了担责任就用模糊语言糊弄过去。但需求文档一旦含糊它就失去了作为“设计和验收依据”的意义。后面开发和测试各干各的谁都觉得自己没错最后只能靠开会扯皮来解决。1.3 症状三需求、设计、测试三条线各走各的追溯链断裂很多项目不是没有文档而是文档之间互相“不认识”。需求规格书里有一条ADC采样率指标原理图设计里选的ADC芯片实际采样率是这个值的两倍测试用例里却没有测这个指标——三条线完全对不上。这就是典型的追溯链断裂。正规的工程做法里需求追溯矩阵(RTM)应该是贯穿项目始终的。每条需求从哪来往上追溯到系统需求或用户需求、落到哪往下追到设计实现、怎么证对应到测试用例全部要能对上。但实际项目里很多人只是在评审前临时补一个追溯表评审完了就再也不管了。等需求变更的时候改了一个指标设计改了、代码改了测试用例忘了改最后测出来跟需求不一致又是一场事故。2. 需求工程方法论怎么落到一块板卡上关键步骤拆解聊完了问题我们来聊解法。需求工程的方法论不管是 ISO/IEC/IEEE 29148、GJB 2786A 还是 GJB 5000B落到一块具体的信号处理板卡上其实就是四个环节需求获取、需求分析、需求定义、需求确认与验证。我用做板卡的实际场景一个个说。2.1 需求获取先从“上游文档”和“利益相关方”两层找全输入需求获取的第一个误区是只看系统级需求规约。真实项目里板级需求的来源远不止这一份文档。以一块雷达信号处理板卡为例你至少还要吃透下面这些输入系统级需求规格书分系统需求定义了板卡在整机里的功能角色、性能指标、接口关系接口控制文件ICD定义了板卡与外部之间的电气接口、机械接口、软件接口、通信协议这一份对硬件设计尤其重要任务剖面与使用场景定义了板卡在什么环境下工作是连续开机几小时还是边工作边振动这直接决定降额设计和散热设计环境适应性要求GJB 150系列温度、湿度、振动、冲击、盐雾、霉菌每一项都要落到板级电磁兼容性要求GJB 151B传导发射、辐射发射、敏感度等这会影响电源滤波设计、层叠设计和屏蔽设计可靠性/维修性/测试性要求MTBF指标、可测试性设计(DFT)要求等。利益相关方这块很多硬件工程师容易忽略。实际上需求获取不是对着文档抄而是要跟不同角色的代表确认各自的真实诉求。系统总体关心的是板卡能否满足整机性能软件工程师关心的是寄存器接口好不好驱动、中断机制清不清楚结构工程师关心的是板卡外形、安装孔位、连接器高度工艺工程师关心的是可制造性、可维修性用户代表关心的是操作界面、故障指示是否友好。每一类人都能给你提供文档里没有的信息。2.2 需求分析功能、性能、接口、约束四类需求分开理拿到一手输入之后接下来要做的是分析而不是急着写文档。我习惯把板级需求分成四大类来理这样不容易乱功能需求板卡要“做什么”比如采集、下变频、脉冲压缩、数据封装、上报性能需求做到什么程度比如采样率、位数、通道数、处理延迟、吞吐率、资源占用率接口需求跟谁连、怎么连包括电源接口、时钟接口、数据接口、控制接口、机械接口约束需求不能做什么、必须遵守什么包括环境条件、电磁兼容、标准化要求、安全性要求、降额要求。为什么要分开理因为功能需求和性能需求在实现和验证上完全不是一回事。功能需求决定的是“做什么模块”性能需求决定的是“选什么芯片、什么架构”。接口需求往往要有独立的 ICD 支撑约束需求则决定了很多设计底线。混在一起写后面评审和追溯都会很痛苦。2.3 需求定义把“分析结论”写成“可验证条目”需求分析做完得到的是需求清单和关键指标接下来才是把它写成正式的板级需求规格书。这一步的核心不是文笔而是“可验证性”。你写的每一条需求都应该能回答一个问题我怎么证明这条需求被满足了如果不能回答那这条需求就不合格。我曾经评审过一份需求文档其中有一条“板卡应能在复杂电磁环境下正常工作”。当时我直接问什么叫复杂电磁环境是多强的场强什么频段持续多长时间满足什么判据算正常写这条需求的同事当场愣住。后来我们一起把这条拆成了三条可验证的需求连续波敏感度场强XX V/m、频率范围XX MHzXX GHz、测试中误码率为0。这样测试工程师拿到就能直接写用例了。3. 写出一份能指导设计的板级需求规格书结构与条目模板需求分析是脑力活需求文档是体力活但体力活也有讲究。这一节我给你一套可以直接套用的章节结构和条目编写模板都是我实际用下来比较顺手的。3.1 板级硬件需求规格书的推荐目录结构很多公司有自己模板但如果你要从零组织一份我建议参考下面这个目录。它兼顾了GJB 438B的格式习惯和硬件板卡的特点范围产品标识、用途、文档范围引用文件列出所有引用的标准和上层文件需求定义 3.1 功能需求 3.2 性能需求 3.3 接口需求 3.4 环境适应性需求 3.5 电磁兼容性需求 3.6 可靠性、维修性、测试性需求 3.7 安全性需求验证方法需求追溯这个结构的核心思想是“先分大类、再逐条编写、最后给验证途径和追溯关系”。我不建议把性能指标和功能描述混在一个章节里因为评审的时候功能讨论的是“做没做”性能讨论的是“够不够”逻辑完全不一样分开写评审效率最高。3.2 需求条目“五要素”编号、类型、描述、验证方法、来源一份好的需求条目不是一句话就完了。我用的模板是五要素要素说明示例需求编号全局唯一便于追溯R-PRF-001需求类型功能/性能/接口/环境/可靠性等性能需求描述一句完整陈述主语明确、谓词可测ADC有效位数≥12 bit验证方法测试/分析/检查/演示测试使用信号源输入标准正弦波采集数据后做FFT分析来源上游需求或ICD的编号追溯至SYS-ADC-003这里我要多说一句描述怎么写。好的需求描述要满足“单义”“完整”“可验证”三个条件。“单义”就是一句话只表达一个需求别把“采样率≥250MSPS且量化位数≥16bit”拆成两条因为哪怕其中一个不满足你也没法判断这条需求到底是过还是不过。“完整”就是关键条件要写全比如“当输入信号幅度在XX dBm时”“在-40℃环境下”这种限定条件必须写进去。“可验证”就是不能出现“良好”“支持”“尽可能”这类主观词。3.3 从模糊描述到可验证条目一个改造实例我举个实际例子。某项目最初的系统级需求写的是“板卡应支持PCI数据捕获和信号处理功能”这根本没法直接指导板卡设计。经过需求分析后我把它拆成了多条板级需求R-INT-001接口板卡应提供PCIe Gen2 x4接口作为从设备与主处理器通信接口应符合PCI Express 2.0规范验证方法为“测试使用协议分析仪抓取链路训练与数据传输过程”。R-CAP-001功能板卡应具备对输入中频信号的连续采集能力采样率可配置配置范围≥100MSPS250MSPS验证方法为“测试逐档配置采样率并采集已知频率信号验证”。R-CAP-002性能板卡ADC无杂散动态范围(SFDR)在输入信号频率为190MHz、采样率250MSPS时SFDR≥70dBc验证方法为“测试频谱仪测量”。R-PRC-001功能板卡FPGA应实现数字下变频(DDC)、脉冲压缩、杂波抑制和数据封装功能验证方法为“测试分析注入标准测试序列比对输出”。R-DMA-001性能板卡PCIe DMA连续写入主存储器速率应≥800MB/s验证方法为“测试上位机软件打流并计算吞吐率”。你看同样一个“PCI数据捕获和信号处理”拆成五条有编号、有类型、有量化指标、有验证方法的需求条目设计和测试就都有的放矢了。4. 实战示例一块雷达信号处理板卡的需求分解全流程前面讲的是方法和套路这一节我用一块虚构但非常典型的雷达信号处理板卡完整走一遍从系统需求到板级需求规格书的分解过程。这块板卡的场景可以想象成一个分布式阵列雷达的一个通道处理单元既要完成中频信号采集捕获也要完成高速信号处理还要通过PCIe接口把结果交给后端处理机——正好对上了当前分布式阵列信号处理的热点需求。4.1 系统需求与指标计算采样率、带宽、数据率怎么定先给一个简化版的系统需求雷达中频信号中心频率190MHz信号带宽40MHz需要完成单通道采集与实时处理处理结果通过PCIe接口输出至主处理器。从这个需求出发板级硬件工程师要做的第一件事就是计算核心性能指标。这里我带大家算一遍这也是需求规格书里每一条性能指标的“为什么”所在。第一步定采样率。根据带通采样定理采样率至少要大于信号带宽的两倍也就是Fs 2×40MHz 80MSPS。实际工程中为了给抗混叠滤波器留过渡带我们通常取信号带宽的46倍再加上ADC时钟源可能有抖动以及后续DDC抽取滤波器需要过采样比这里取Fs 250MSPS。这个值对普通12/14bit ADC来说是比较成熟的区间也方便后续做数字下变频。第二步算数据率。假设ADC量化位数16bit包含增益控制字信息实际有效位数可能12bit左右单通道数据率 250M × 16bit 4Gbps 500MB/s。这是进入FPGA的原始数据率。如果直接把这个速率往PCIe上扔对后端存储和软件处理都是巨大压力所以在FPGA里必须做数字下变频和抽取处理。第三步定接口速率。假设DDC抽取倍数为8输出带宽降至5M10M量级数据率降到 250M/8 × 32bitI/Q各16bit 1Gbps 125MB/s。再加上系统还需要传输状态信息、参数配置和原始数据旁路通道PCIe需留足余量最终接口需求定为PCIe Gen2 x4理论带宽2GB/sDMA持续传输要求≥800MB/s实测余量4倍左右。这里我特别想提醒一句指标不是拍脑袋定的每个数字背后都有计算逻辑。规格书里的性能指标如果不经过计算只是抄别人产品说明书那后面所有设计都会建立在流沙上。建议每个关键指标都附一个简短的推导说明或引用依据哪怕只在评审时口头讲清楚也比没有强得多。4.2 功能需求到硬件资源分解ADC、FPGA、DSP、存储怎么配指标算完接下来是把功能需求映射到硬件资源上。我称之为“资源预算”这个过程也应该反映到需求规格书中。还是以上面这块板卡为例ADC选型满足250MSPS、14bit以上的高速ADC输出接口为JESD204B或LVDS这个选型直接对应R-CAP系列需求FPGA选型要承担DDC、脉冲压缩、杂波抑制、数据封装一片中等规模FPGA就够了以Kintex-7 XC7K325T为例它大概有326K逻辑单元、840个DSP Slices、16Mb BRAM资源占用率控制在70%左右既满足当前功能又留升级余量存储资源板载DDR3 SDRAM容量1GB位宽32bit用于数据缓存和处理中间结果的暂存接口资源PCIe硬核、千兆网口调试用、JESD204B接口、GPIO、RS422调试串口等。资源预算为什么要写进需求规格书因为这个预算本身就是需求——它约束了设计方案的选型空间。我见过很多项目需求文档没写资源占用率结果FPGA工程师实现完功能一布局布线时序收敛不了只能换更贵的芯片。如果需求里写上“FPGA逻辑资源占用率不超过75%、DSP Slices使用率不超过60%”设计阶段就会主动做资源规划。从阵列信号处理的角度来说如果这块板卡后续要扩展为多板级联还要在需求里规定板间同步机制。比如多板同步采集时采样时钟相位差≤XXX ps、触发同步精度≤XXX ns这些都要写进接口需求。不要等系统联调时才想到那时候板子已经改不了了。4.3 环境与可靠性需求的落地不是抄标准是细化到板卡环境与可靠性需求是军用板卡需求规格书里最容易被“抄作业”的部分。很多人直接复制粘贴GJB 150的温度范围、振动等级也不管自己的板卡到底是什么功耗、什么安装方式。但环境需求恰恰是最需要在板级细化的。我举一个温度需求的例子。系统级要求“设备工作温度范围-40℃70℃”落到板级不能只写这一句。因为板卡实际工作时板上芯片结温、散热器温度、机箱内环境温度完全不是一回事。合理的板级温度需求应该写成R-ENV-001板卡在环境温度-40℃70℃范围内应能正常工作验证方法为“测试按GJB 150.4A高低温试验方法执行”R-ENV-002板卡在正常工作条件下FPGA芯片结温应≤100℃DDR颗粒壳温应≤85℃验证方法为“分析测试热仿真FTP温度实测”R-ENV-003板卡应通过GJB 150.16A规定的振动试验试验条件见XX验证方法为“测试”。大家注意R-ENV-002才是真正能指导散热设计的需求。光写“在70℃能工作”是没法设计的因为芯片能不能工作取决于结温而结温取决于功耗、散热路径和环境温度的综合。把芯片结温需求写清楚结构工程师才知道要不要加散热片、要不要设计风道硬件工程师才知道芯片布局密度要控制在什么水平。可靠性需求也是同理不要只写MTBF≥XXX小时。要细化为降额设计需求电阻功率降额≥50%、电容耐压降额≥70%、半导体结温降额≥25℃这些是设计阶段可以执行、评审阶段可以检查的需求条目。5. 需求验证与追溯把文档和测试闭环接起来写规格书不是终点写完之后怎么证明需求被满足、怎么管理需求变更才是需求工程真正“落地”的体现。这一节讲验证方法和追溯矩阵这两个核心工具。5.1 四类验证方法测试、分析、检查、演示怎么选需求规格书里的每条需求都要指定验证方法。标准做法是四选一测试Test通过仪器测量、软件运行等实测手段验证。适用于大多数性能指标比如ADC的SFDR、接口速率、处理延迟分析Analysis通过建模仿真、理论计算、热仿真等方式验证。适用于无法直接实测或实测成本过高的需求比如芯片结温、MTBF、FPGA资源占用率检查Inspection通过审查设计文件、图纸、物料清单等方式验证。适用于设计约束类需求比如降额设计、标准化要求演示Demonstration通过操作设备、演示功能来验证。适用于功能可运行但难以量化的需求比如人机交互流程、故障指示功能。我在实际项目里的体会是性能指标尽量写“测试”设计约束尽量写“检查”仿真能够覆盖的不盲目承诺测试。因为测试是要花时间花成本买样机的如果对每条需求都写“测试”最后测试团队会骂死你。5.2 需求追溯矩阵从系统需求到测试用例的链式追踪追溯矩阵说白了就是一张表把“上游需求→板级需求→设计实现→测试用例”以映射关系串起来。我建议用一张多列表格来维护系统需求编号板级需求编号设计实现文件测试用例编号验证结果SYS-CAP-01R-CAP-002原理图Sheet 3、ADC驱动TC-ADC-001待执行SYS-PRC-02R-PRC-001FPGA工程/PulseComp.vTC-PRC-001待执行SYS-INT-03R-INT-001PCIe硬核配置、DMA驱动TC-INT-001待执行我强烈建议用专门的配置管理工具比如DOORS、Reqtify或者简单点的Excel/在线表格来维护这张表因为项目一复杂靠脑子记必死。这张表的更新时机也很关键需求变更时要更新设计更改时要更新测试计划变更时要更新。很多团队的追溯矩阵是在里程碑评审前一次性补出来的没有随项目更新这种表没有任何意义。评审的时候我习惯针对追溯矩阵抽几条做“反向链”审查从测试用例出发问这条用例验证的是哪条需求再问这条需求来自哪里。如果发现某条测试用例对不上任何需求说明测试做了多余的活如果某条需求对不上任何测试用例说明该需求没有验证手段如果某条需求对不上任何设计实现说明这个需求拿到了但没人做。三层核对完项目风险一目了然。5.3 需求评审怎么开不流于形式的三条经验需求评审是需求工程落地最容易翻车的地方因为很多人把评审开成了“朗读大会”——大家对着PPT把需求念一遍然后没人提反对意见就过了。等设计做完了才发现需求有问题。这里分享三条经验第一评审前先把可验证性自检做掉。评审会之前让需求编写人把每一条需求自己用“怎么验证”问一遍答不上来的条目标记出来评审会重点讨论这些条目而不是从头到尾过。第二邀请的人在精不在多。硬件需求规格书评审至少要有系统工程师、FPGA工程师、软件工程师、结构工程师、测试工程师五类角色的代表参加。他们各自的视角完全不同FPGA关心寄存器接口和时序软件关心驱动模型结构关心外形和散热测试关心用例怎么写系统关心指标是否覆盖用户需求。第三评审要留“评审记录”。每条意见必须落到具体需求编号上并明确责任人和闭环时间。不要用“总体可行修改后发布”这种模糊结论。6. 常见问题与避坑经验我踩过的那些坑最后这一章我把做需求工程这几年来碰到的高频问题整理成一个速查表再补几条独家心得。这些都是常规培训不会讲、但实际项目里非常要命的细节。6.1 常见问题速查表症状根因处理办法需求条目出现“支持/良好/尽可能”等模糊词编写者没想清指标或怕担责评审时逐条质问“如何验证”逼出量化指标需求粒度过细写了上千条把设计和需求混了需求讲“做什么/做到什么程度”设计讲“怎么做”划清界限需求文档和ICD不一致版本管理混乱需求规格书里引用ICD编号ICD变更走变更控制流程需求频繁变更无人评估影响缺少变更控制机制建立CCB配置控制委员会变更必须更新RTM测试反映需求“测不了”指标定得脱离可测性指标要结合现有仪器能力制定特殊高指标要提前说明测试方法环境需求直接抄GJB条目不细化到板卡拆分出芯片结温、安装方式、散热路径等板级细化条目需求评审走形式评审人没提前看文档评审前发文档评审只讨论有异议条目标题这里面我想重点展开两条。第一条是“需求密度”问题。有一次我接手一个项目看需求清单有2487条当时就觉得不对。细看发现很多所谓“需求”其实是设计决定比如“R-CLK-001板卡应使用100MHz温补晶振作为参考时钟”。这应该是设计文档里的事不是板级需求。需求文档一旦写成了设计说明书就失去了独立评审的意义而且会限制设计人员的优化空间。正确的做法是写“R-CLK-001板卡参考时钟频率稳定度应优于XX ppm”至于用温补晶振还是恒温晶振那是设计的自由。第二条是“测试可行性”。需求指标定得再好看如果测试手段跟不上就是空中楼阁。比如你写“ADC有效位数≥12bit”但实验室现有的信号源相位噪声很差根本测不到12bit水平那这条需求基本等于写了白写。所以需求编写阶段就要跟测试工程师沟通这个指标打算怎么测需要什么设备实验室有没有。没有的话要么换指标定义要么提前申购设备。6.2 实操心得编号规则、版本管理和需求入库几个细节经验算是白送给大家的。需求编号规则我强烈建议从一开始就定好命名空间。用“R-类型-序号”三段式注意不要用纯数字流水号因为你没法从编号里看出需求的类别。比如用R-FUNC-001、R-PERF-001、R-INT-001、R-ENV-001、R-REL-001这样的规则后期排序、筛选、审查都方便。我自己还会在“类型”后面加上“部门或板卡标识”比如R-FPGA-PERF-001多板项目里很好使。需求版本管理最好纳入配置管理库SVN/Git按里程碑打标签。不要用“需求规格书_最终版_v3_改2.doc”这种命名方式我保证最后一定会有“_真最终版”出现。用配置工具管理每次变更留痕这个习惯能帮你在审查时避免很多麻烦。需求条目入库在项目规模大时特别有用。像DOORS、Reqtify这种专业工具虽然贵但对重载型项目值得投入。中小项目用Jama Connect或者直接用Excel管理也不是不行关键是坚持维护RTM表和变更记录工具只是辅助。6.3 从需求规格书到设计文件需求怎么“传导”下去需求规格书写完不能锁在柜子里。要让它真正指导设计我建议你在项目的每个设计阶段都做一次“需求分配”动作。原理图设计阶段原理图评审时逐页核对这页电路满足哪些需求编号比如ADC前端设计是不是覆盖了R-CAP-002的SFDR需求电源设计有没有满足R-PWR-XXX的纹波需求评审时直接把需求编号写在原理图评审记录的对应栏里。FPGA设计阶段把需求编号写进代码注释和模块说明。比如一个脉冲压缩模块文件头注释里写明它对应R-PRC-001、输入输出接口对应R-INT-002这样代码维护的人不用翻文档就知道这段逻辑的来龙去脉。软件驱动设计阶段寄存器定义表里每一条寄存器都标注对应需求编号。寄存器ID、偏移地址、位域定义、读写属性、对应需求编号五列齐全软件工程师才能在没有硬件的时候就开始写驱动框架。测试阶段就更不用说了测试用例设计必须逐条挂接需求编号。测试报告里的每一条结论都要能反向追溯到具体需求。这样做下来你会发现整个项目的信息流是通的需求变更了顺着追溯矩阵就能看出哪些设计文件、哪些代码模块、哪些测试用例需要同步改。这才是板级需求规格书真正的价值所在——它不是一个文档交付物而是整个研发链条的“锚点”。我自己在写板级需求规格书时还有一个很小的习惯每写完一章我会把自己代入三个角色分别读一遍——代入FPGA工程师想着拿到这条需求我能不能直接开始写代码代入测试工程师想着拿到这条需求我能不能直接写用例代入结构工程师想着拿到这条需求我知不知道怎么散热怎么固定。三个角色都能给出肯定回答这一章才敢放入正式版本。这个习惯帮我挡掉了不少后期返工分享给大家做需求工程的人都可以试试。