拓冰建站拓冰建站
首页 / 资讯中心 / 正文

FPGA配置失败排查:CONF_DONE不拉高的完整调试思路与实操指南

上电之后等了半天板卡上的DONE灯不亮JTAG链也认不到器件万用表一量——CONF_DONE引脚停在0V。这个现象我在项目里见过太多次尤其是在新板卡调试、批次更换电子料、升级配置文件之后最容易冒出来。CONF_DONE没有拉高本质上是在告诉你FPGA这次启动没有走完配置流程。问题是导致配置流程中断的环节太多了电源、时钟、模式引脚、配置文件、上拉电阻、甚至焊接每一环都可能是凶手。这篇文章不是教你怎么背手册而是从实际的调试现场出发把排查思路和工具用法讲透让你能从现象反推故障层少走弯路。1. 先别急着换芯片CONF_DONE为什么这么重要1.1 CONF_DONE不是“配置完成指示灯”CONF_DONE很多工程师习惯叫它“DONE信号”是一个开漏输出引脚内部驱动管在配置未完成时把电平拉低配置成功并完成初始化后驱动管释放引脚被外部上拉电阻拉到高电平。所以严格来说它不是一颗“指示灯”而是FPGA配置状态机对外暴露的一个握手信号。许多板卡把CONF_DONE接一个LED到电源灯亮就代表配置结束这是一种电路设计上的读取方式但你不能只依赖灯来判断灯的亮度、电阻选值都可能掩盖问题。关键点CONF_DONE是开漏结构高电平不是FPGA“推”出来的而是上拉电阻“拉”出来的。如果外部上拉电阻没焊、虚焊、阻值过大或者被后端负载比如LED、逻辑门、FPGA I/O灌电流拉低那么就算内部已经配置成功引脚也可能表现出“未拉高”的假象。我在调试中见过几次这种情况FPGA其实已经跑起来了功能都正常但DONE就是低整个团队围着电源和配置源排查了一整天最后发现是LED接法设计错了。怎么区分断开后端负载直接量引脚电压或者用一个10kΩ电阻手动上拉到对应VCCIO看电平是否能起来。如果手动上拉后CONF_DONE能到高说明FPGA内部驱动没问题问题大概率在板级电路如果手动上拉后还是低那FPGA要么没配置成功要么配置成功后又因为某种原因被复位了。这个实测动作成本极低但能把排查范围缩小一半。1.2 配置状态机与CONF_DONE的时序位置理解CONF_DONE最好把FPGA的配置过程当成一个状态机复位Reset、配置Configuration、初始化Initialization、用户模式User Mode。以Intel Cyclone系列为例上电后nCONFIG为低时FPGA保持在复位状态CONF_DONE被拉低外部或配置器件把nCONFIG拉高后FPGA释放nSTATUS此时nSTATUS应该被外部上拉拉高开始等待配置数据DCLK按协议翻转数据一位一位地进去当配置位流全部接收完毕FPGA自动进行CRC校验校验通过后释放CONF_DONE外部上拉使其变高随后进入初始化阶段初始化完成后DONE保持高同时用户I/O解锁整个芯片开始跑用户逻辑。这个时序里CONF_DONE拉高发生在“配置数据全部接收且校验通过”之后但注意它并不是配置数据流结束信号的瞬间而是数据校验完成后、初始化之前。所以在排查时CONF_DONE未拉高可以聚焦到几个阶段数据没有完整到达、数据到达但校验失败、校验成功后初始化卡住、或者初始化完成后又被外部复位拉回。每一种情况对应的波形特征不一样后面的实操部分我会详细说怎么用示波器区分。对使用Xilinx器件的朋友DONE引脚以及PROG_B、INIT_B引脚的作用类似只是命名和时序参数不同但开漏结构、外部上拉、配置后释放等核心逻辑是一致的排查思路完全可以平移过来。2. 系统性排查流程从硬件到软件一层层过这一章重点讲排查步骤我建议顺序是电源、模式引脚、配置文件、上拉负载、焊接器件。这个顺序的核心逻辑是从“共性环节”到“个性环节”。电源和接地是所有配置工作的前提只要电源不对配置一定失败先排查共性再排查与具体设计方案相关的环节。2.1 上电后先量电压域电源问题占了四成FPGA是多电源域器件即使一颗小规模的Cyclone IV也有VCCINT内核、VCCIOIO、VCCA/VCCD_PLLPLL模拟、VCCBAT备份电池如果不用可以接地等多路电源。配置相关引脚的电平参考主要看配置相关bank的VCCIO内部配置电路的工作电压则由VCCINT提供。任何一路电源没起来、电压偏低、纹波过大都可能让配置状态机直接罢工。我的排查习惯是先拿万用表直流档依次确认每路电源对地电压和设计值对比正常情况偏差不应超过3%。然后再用示波器看启动瞬间的波形重点看两点一是上电时序比如某些系统要求VCCINT先于VCCIO到达或者两者的差值不能超过指定阈值具体看器件手册的Power-Up Sequence章节如果反了可能导致IO引脚闩锁或配置失败二是启动过程中的欠压毛刺很多电源模块在输出建立过程中会有几百毫伏的下冲如果恰好落在FPGA的上电复位阈值附近就会出现概率性配置失败。另外一个容易被忽略的点VCCIO分多个bank配置引脚所在的bank供电要特别确认。比如用AS模式通过EPCS加载时配置引脚的IO标准由所在bank的VCCIO决定如果该bank没供电配置引脚的输入阈值就不正常可能一直读不到高电平。检查时可以顺手把配置bank的VCCIO、MSEL引脚所接的上拉/下拉电阻两端的电压都量一下。2.2 MSEL配置模式检查模式错了一切白搭FPGA上电时会采样MSEL引脚的电平组合Intel器件一般有MSEL[2:0]或更多决定本次配置使用哪种协议AS、PS、FPP、JTAG等。MSEL引脚通常被上拉或下拉电阻固定有些板卡用拨码开关实现。问题往往出在拨码开关被人拨过、电阻虚焊、PCB走线被覆铜短路、或者软件里指定的配置方式与硬件模式不一致。典型例子硬件设计采用AS模式FPGA上电后从外部EPCS Flash加载但MSEL[2:0]的电平组合被画反了导致FPGA等待的是PS模式。这时外部主机比如CPU又没往FPGA发配置流CONF_DONE自然一直拉不起来看起来像“配置失败”实际上FPGA只是在空等。同理如果你在Quartus里生成的是.jic文件但硬件模式其实是JTAG常驻上电后没有任何配置源主动加载那CONF_DONE也不会拉高除非通过JTAG命令手动配置一次。检查MSEL最靠谱的方法不是看拨码开关的位置而是直接量引脚电压把板卡重新上电在MSEL引脚上量到的高/低电平与设计表格比对。注意MSEL可能在配置完成后变成普通IO或弱驱动状态所以测量要在上电后尽快进行最好在复位状态nCONFIG为低时量此时MSEL的电平最稳定。必要时可以结合JTAG读取器件的实测模式Quartus里能报告当前检测到的配置模式可以辅助判断。2.3 配置文件与下载链路别忽略最简单的地方有相当比例的CONF_DONE失败最后定位到的是配置文件本身有问题或者加载路径中断。先说文件层面JTAG调试时直接用.sofAS模式烧写Flash时要用.jic或.pof用错格式、文件损坏、版本不匹配都会导致配置过程无法完成。我建议在烧写完成后从Flash回读校验一下而不是只看着烧写软件报告“成功”。有的烧写器在写Flash时遇到坏块或电源抖动会静默出错校验能帮你少踩好多坑。下载链路层面需要检查连接器、排线、下载器本身。JTAG链连接器10pin/14pin的TMS、TCK、TDI、TDO焊点是否牢固排线是否氧化下载器固件是否过旧这些都是低级但常见的坑。还有一种情况多片FPGA串联成JTAG链中间某一颗器件的TDO到下一颗TDI的走线断开会导致整条链识别不全。识别不全时你连IDCODE都读不到但如果识别到了IDCODE却下载失败可能是TDO/TDI虚焊或信号质量差。配置时钟DCLK的幅值和驱动能力也是检查点用示波器量一下DCLK是否干净、幅度是否达标原则上配置阶段DCLK的边沿不能有过大的振铃否则数据采样会出错。2.4 上拉电阻检查CONF_DONE被“卡”在地上的典型原因刚才已经提到CONF_DONE是开漏输出高电平依赖外部上拉。上拉电阻的取值通常参考器件手册常见范围是1kΩ到10kΩ具体看配置bank VCCIO电压和负载。理论上是电阻越小拉高能力越强、上升沿越快但静态电流也越大电阻越大静态电流小但抗负载能力差。假设VCCIO3.3V、上拉10kΩ负载等效灌电流如果超过330μA引脚电平就被拉低到0V这个公式很重要——很多设计在DONE引脚上挂了不止一个LED、缓冲器和接收门累计负载一算10kΩ根本扛不住。排查时断电状态下用万用表量CONF_DONE到对应VCCIO之间的电阻确认上拉电阻阻值、是否断路或虚焊再量CONF_DONE到GND是否短路。上电且未配置状态下CONF_DONE应该呈现被上拉到高的特性此时测量电压接近VCCIO如果本来就低优先怀疑上拉缺失或者外部负载把电平拉低。还有一种隐蔽情况上拉电阻接到了错误的电源上例如接了VCCINT而不是VCCIO导致高电平幅度不对接收端一直判断为低。这块建议和外电路图逐点核对。3. 核心实操用示波器抓配置时序定位到具体环节当你排除完电源、模式、文件、上拉这些“静态检查”后如果问题还没解决就该上示波器看“动态行为”了。配置过程是多个信号按协议要求翻转的时序过程不同的失败特征会直接告诉你卡在哪个环节。3.1 接线与时序测量准备建议至少抓四个信号nCONFIG、nSTATUS、CONF_DONE、DCLK。使用四通道示波器探头都打到10:1衰减通道间的地线夹要夹在就近的GND测试点避免过长的地线形成环路干扰。示波器触发方式设置为“普通触发”触发电平设在nCONFIG上升沿时基根据实际配置源选择AS模式配置一个中等规模的FPGA通常在几十到几百毫秒内完成可以用50ms/div如果用JTAGUSB-Blaster配置速度相对较慢可以用100ms/div甚至200ms/div先观察全过程。测量时要注意探头负载效应。FPGA配置引脚的驱动能力并不强如果探头补偿不合适或使用过长的高阻线可能把信号压扁导致误判。建议选用10MΩ输入阻抗的探头并且尽量在测试点测量不要直接戳在芯片引脚上既容易短路又不稳定。有条件的话可以用有源差分探头测DCLK和nSTATUS没条件的话普通无源探头也够用关键是第一步先“看到轮廓”再决定要不要精细化。另外一个建议把配置文件换成一个最小工程只含一个灯闪烁的逻辑排除用户逻辑对IO的影响。有些FPGA在进入用户模式后如果某个IO被外部短路会让整板保护或复位间接导致CONF_DONE被拉低这种情况和配置本身无关。最小工程可以帮你把“配置阶段”和“用户模式阶段”分开观察。3.2 解读正常配置波形与异常波形正常配置波形长什么样以AS模式、Intel Cyclone系列为例上电后nCONFIG维持在低外部配置控制器或配置器件把nCONFIG拉高约几十微秒后nSTATUS从低变高接着DCLK开始翻转数据从DATA[0]进入配置数据接收完毕CONF_DONE从低变高CONF_DONE拉高后再经过一小段初始化时间nSTATUS保持高用户I/O解除三态。整个过程里只要有一个信号不符合协议位置关系就要怀疑对应的环节。再看三种典型的异常波形第一种nCONFIG拉高后nSTATUS一直不拉高。这说明FPGA没有准备好进入配置状态大概率问题在FPGA本身VCCINT电压不对、时钟电路异常、器件处于复位、或者JTAG链把芯片锁在某种测试模式。也有可能是nCONFIG拉高的幅度不够比如由开漏信号驱动却没有上拉电平只到1V左右FPGA不认为这是有效高电平。第二种nSTATUS拉高了DCLK不翻转。AS模式下DCLK通常由FPGA内部产生PS模式下DCLK由外部主机提供。如果nSTATUS拉高但DCLK没有时钟要么是FPGA没能成功启动内部时钟生成要么是外部时钟线路有问题。可以量一下FPGA的时钟输入引脚如果有专门晶振输入是否有振荡。第三种DCLK在翻但CONF_DONE一直低。这是最常见的失败模式之一。可能性包括配置文件校验失败下载到Flash的bit流损坏、DCLK频率超过上限导致采样错位、配置数据线上的信号质量差振铃、串扰、以及MSEL模式与数据源不匹配导致FPGA一直在等数据。遇到这种波形不要急着动硬件先把配置文件重新生成并回读校验一次很多时候问题就出在文件本身。3.3 多die与菊花链场景的测量注意点规模大一点的FPGA比如多die封装的器件内部有多个配置域每个die的配置数据在同一个位流里按顺序排布。如果某一个die的配置数据损坏或对应电源域异常整个器件的配置过程都不会完成CONF_DONE不会拉高。此时抓波形会看到DCLK一直在翻转但CONF_DONE始终为低通过对比不同die的电源域电压、检查位流中对应的分段才能定位到具体是哪个区域出了问题。对于支持Partial Reconfiguration的平台配置时只加载部分区段CONF_DONE的状态和全配置时又有区别这块需要查阅具体器件的配置手册不要照搬经验。多片FPGA菊花链配置时上游器件的CONF_DONE会作为下游的配置使能信号之一。如果第二颗FPGA配置失败它的nSTATUS会拉低反过来可能让整条链停留在等待状态。排查时不要只盯着第一颗器件的CONF_DONE要分别测量每颗器件的nSTATUS和CONF_DONE逐级检查。注意链上提前配置完成的器件会进入用户模式并释放自己的IO如果下游器件IO刚好与之冲突也可能造成电平异常这种问题通常发生在级联设计中。4. 高频故障场景与解决实录这一章我按实际项目里碰到的高频场景整理一下都是真实案例的脱敏总结。4.1 场景AJTAG能识别IDCODE但AS模式配置失败现象USB-Blaster连接正常jtagconfig能列出FPGA但上电后CONF_DONE不拉高AS模式从EPCS加载不成功。排查过程先量EPCS的供电正常量MSEL模式确实是AS再把示波器探头搭在DATA[0]和DCLK上发现DCLK有翻转但DATA[0]信号几乎没有活动。进一步检查发现EPCS的片选引脚到FPGA的nCSO连接虚焊FPGA发了读命令但Flash没有响应。飞线补焊后配置恢复正常。这个案例说明一个问题JTAG能识别IDCODE只代表FPGA的JTAG TAP控制器工作正常它与AS配置路径完全是两回事。JTAG口和AS口的物理链路、所用引脚、依赖的电源域都不完全重叠所以不能因为JTAG正常就排除配置链路故障。排查AS失败时一定要把nCSO、DATA[0]、DCLK这三个信号和EPCS的连接逐一测通阻值和通断都检查。另外还有一个常见变体EPCS的MISO和MOSI接反。很多板卡把FPGA的DATA[0]输出配置数据接到Flash的DIDATA[1]读回数据接到Flash的DO如果原理图上标反了或者PCB布线时调换了配置文件就永远读不对。检查方法很简单用万用表蜂鸣档顺着网络标号走一遍或者参照数据手册确认命名。4.2 场景B配置偶尔成功低温或长时间运行后必失败这个场景特别折磨人通常出现在环境试验或老化测试中。现象常温下配置成功率还行但环境温度降低到一定程度或者板卡运行一段时间后重新配置CONF_DONE就拉不起来了。我遇到的几个典型案例原因各不相同。第一例配置bank的VCCIO电压偏低常温下刚好在阈值边缘温度变化后电源芯片输出漂移掉出FPGA配置电气阈值范围配置自然失败。解决方式是调整电源反馈电阻把电压提升到规格书推荐的中值并实测低温下的输出。第二例DCLK信号走线过长、过孔过多信号边沿变缓叠加温度对接收阈值的影响采样出错。解决方式是降低配置时钟频率在Quartus工程里把配置速率如从20MHz降到10MHz重新生成烧写文件同时也把Flash烧写时的DCLK频率调低。别小看这个操作很多量产板卡的偶发失败都是靠降频压下去的。第三例Flash芯片批次更换或老化后读写时序变差。如果EPCS/EPCQ选型与FPGA要求的配置时钟频率不匹配或者Flash本身存在坏块也会出现概率性配置失败。这时候优先回读Flash内容与原始文件比对如果回读数据有差异基本可以锁定Flash问题。4.3 场景C升级版板卡批量不启动场景上一版板卡好好的这一版只是改了布局、换了电源芯片结果批量上电后CONF_DONE全都不拉高。这种“全板都挂”的情况通常是设计变更引入了系统性问题排查方向不是单个板卡的焊接而是设计差异。最常见的是电源上电顺序改变换了不同启动时间特性的电源芯片导致VCCINT和VCCIO的上电顺序不满足FPGA要求或者去耦电容容量变化导致启动瞬间电压建立时间变长超过了配置复位窗口。另一个高发原因是MSEL引脚的默认电平被改动了。布局调整时工程师可能把原本接上拉到VCCIO的MSEL改成了悬空或下拉FPGA上电采样的模式就变了AS配置模式失效。这种问题光看波形都不容易发现最好的办法是直接对比新旧版原理图把配置相关引脚nCONFIG、nSTATUS、CONF_DONE、MSEL、DCLK、DATA的接法逐个核对必要时在样机上用飞线把MSEL临时改回正确的电平验证后再修正设计。这类批量性问题往往不是“某颗料坏了”而是“设计勘误”。我建议新板卡回板后不要急着写应用逻辑先写一个空的LED工程把配置流程跑通、确认CONF_DONE稳定拉高再往上叠加功能。这个习惯能帮你把硬件问题限制在最小范围内后续软件调试也会轻松很多。4.4 故障特征与排查动作速查表这里整理一张表方便大家现场对照。故障特征可能原因第一排查动作CONF_DONE一直为低nCONFIG也低配置启动信号没释放 / 外部控制逻辑拉低测量nCONFIG电平查复位控制电路nCONFIG拉高nSTATUS一直低FPGA未进入配置状态电源/时钟/芯片问题量VCCINT、VCCIO确认CLK输入换一颗样片验证nSTATUS拉高DCLK不翻转时钟链路断开 / 配置模式不匹配量DCLK查MSEL查晶振起振DCLK翻转但CONF_DONE持续低配置文件损坏 / 数据线信号质量问题 / 时钟频率过高回读Flash校验降配置频率重新生成文件CONF_DONE瞬间拉高又掉低上拉电阻过大 / 负载过重 / 用户模式IO冲突计算上拉能力断开后端负载测量电流冷态必失败温度升高后正常电源阈值漂移 / 信号边沿过缓 / Flash老化低温实测电源降低DCLK频率检查Flash型号批次JTAG正常但AS加载失败AS链路断开nCSO/DATA/DCLK万用表测通路配合示波器看Flash读响应这张表不是万能药但能给你一个起点。现实中的故障经常是多个因素叠加比如电源偏低加配置文件损坏同时存在所以排查时不要做完一项就急着改板尽量把所有异常都列出来合并分析。5. 一些不好写进文档的经验5.1 调试顺序建议与工具准备做FPGA配置失败排查工具是必要保障。我的调试包里常备一台四通道示波器带宽至少100MHz带深存储一个万用表必须支持通断蜂鸣和直流电压精确测量一个USB-Blaster或类似下载器另外还会准备几个飞线、镊子和一个可调电源。如果现场有逻辑分析仪用来同时抓多路配置信号会方便很多没有的话示波器的多通道也够用。调试顺序建议是观察现象、静态测量、动态抓波形、对照手册分析、修改验证。不要一上来就抓波形很多问题在没有示波器时就能通过电压测量定位。比如CONF_DONE本来就是0V你先量量是不是被短路到地了翻翻原理图上拉电阻是不是漏焊了。静态测量零成本、速度快应该优先做光。另外学会读取FPGA厂商工具的信息。Quartus的jtagconfig能显示JTAG链上的设备quartus_pgm命令行可以执行配置和回读操作Vivado的hardware manager也有类似功能。熟练掌握这些命令行工具能让你在GUI之外快速批量操作尤其是在产线或现场排查时效率差好几倍。5.2 遇到CONF_DONE未拉高的七次实战教训最后说几个我踩过的坑每次都是血泪教训。第一个JTAG下载线劣质或过长。USB-Blaster的排线超过30cm后TCK信号质量会明显下降偶尔能识别IDCODE但下载总失败。换一根短线问题当场消失。所以排查时先换一根公认好用的下载线排除掉线材因素。第二个电脑USB口供电不足。笔记本连了一个USB Hub再接USB-Blaster下载器供电不够FPGA配置一半就停了CONF_DONE死活拉不高。后来把USB-Blaster直接插主板口就好。第三个配置引脚网络和别的信号共用。有人图省事把nCONFIG直接接在FPGA配置控制器的GPIO上但该GPIO默认状态是弱下拉导致上电后nCONFIG没有被拉高需要控制器固件主动输出。调试时固件没写自然配置失败。这种“状态依赖固件”的设计不是不行但一定要清楚上电瞬间的默认态。第四个FPGA的VCCBAT接了地设计本来如此但某批次芯片对VCCBAT要求不同导致配置失败。换新批次芯片后问题消失。电子料批次兼容性这种坑只能靠物料认证和样本验证来规避。第五个用示波器探头点CONF_DONE时不小心短路到相邻引脚直接烧坏了配置电路。从此以后我测量之前都会先看一眼引脚间距和旁边信号避免探头滑针。第六个回读校验发现Flash内容确实和原文件一致但配置还是失败最后发现是Flash写进去的起始地址偏移了4KB核心数据没写对。烧写工具的地址设置要仔细核对。第七个某板卡放在金属机箱内配置失败拿出来裸板就正常。查了半天是机箱螺丝压到了板边的配置引脚走线造成对地短路。装配环节引起的硬件故障电气排查反而容易漏掉遇到“装机必坏、裸板正常”的现象先怀疑装配应力。如果只记一条我个人的体会CONF_DONE未拉高先别怀疑FPGA坏了把它当成一张协议时序图沿着nCONFIG到nSTATUS到DCLK到CONF_DONE逐级查绝大多数问题都能在一次示波器测量里定位。工程上九成的配置失败是电源、上拉、模式设置、线缆这类“低级”问题真正需要动烙铁换芯片的少之又少。
分享:

看完干货,该让你的企业上线了

免费需求沟通 · 48 小时内出具建站方案 · 河南本地可上门