FPGA Debug:PCIE XDMA没有Link up(驱动检测不到xilinx PCIE设备)使用LTSSM定位问题

FPGA Debug:PCIE XDMA没有Link up(驱动检测不到xilinx PCIE设备)使用LTSSM定位问题

问题现象:

与驱动联调:驱动无法扫描到Xilinx的PCIE设备

通过ila抓取pcie_link_up信号:发现link up一直为低

问题分析:

        出现这种情况,在FPGA中搭建测试环境,使用XDMA+BRAM的形式,减少其它模块的影响,框架如下:

1 检查PCIE的时钟

时钟,必须使用原理图上的GT Ref 差分时钟,通过IBUFDSGTE转为单端时钟

2 检查PCIE 复位

复位:PCIE复位信号有要求--上电后,PCIE_RESTN信号需在电源稳定后延迟一段时间再释放,通常是100ms以上

而这100ms的时间,系统主要做以下的事情:

  • 电源稳定时间
  • 参考时钟稳定时间
  • PCIe IP核的复位和初始化时间
  • 链路训练时间

// 典型的100ms时间分配:
0-10ms   : 电源稳定 (Power Stable)
10-20ms  : 参考时钟稳定 (Refclk Stable)  
20-30ms  : 复位释放和PLL锁定 (Reset Release & PLL Lock)
30-50ms  : 物理层初始化 (PHY Initialization)
50-70ms  : 链路训练 (Link Training)
70-100ms : 设备配置 (Device Configuration)

        所以为了避免这个问题,建议在程序中添加这么一段复位控制,但是有的时候你不添加也没有关系,因为有的时候硬件的复位时序可以满足这个100ms的要求,但是保险起见还是加上

3 LANE检查

      检查你的LANE约束,一般XDMA IP核生成的时候会自带一个约束文件,约束每个LANE的对外接口,但我们也可以自己约束,保证端口与原理图匹配即可。

这些确认无误,还是无法link up的,先将PCIE降速为1.0 X1,看看情况

4 PCIE降速

如果还是不行,那我们需要检测pcie的相关的几个状态。

5 具体问题定位(PCIE LTSSM状态)

这里我们需要查看PCIE的LTSSM状态机,那什么是LTSSM状态机呢?

      是一种常用于PCI Express(PCIe)接口的状态机,它可以控制PCIe总线的传输流程。LTSSM由多个状态组成,每个状态都代表了不同的总线传输阶段。

一般大家会找不到,按照如下的方式

5.1 给LTSSM信号添加debug

首先:勾选配置界面的Use Class Code Lookup Assistant这个选项

此时还是无法在端口显示出LTSSM信号,不要着急,按照你的流程生成IP核,执行完Run Syn操作,然后点击Set up debug

在这里搜索LTSSM的“小写”,就能找到ltssm_state的信号,将其添加到debug里面正常的综合实现就可以了。

5.2 LTSSM状态说明

       LTSSM状态机根据厂商不同会有微小的差异,我们使用的是瑞芯微的,我的状态卡在了08即Lane顺序检测。意味着是lane的问题。


那我们通过这个方式监控的除了LTSSM信号以外,还有几个关键信号

5.3 其余关键信号说明

phy_rdy_n:物理层就绪,一种存在性检查,0:表示物理层就绪  1:表示异常

                     时钟是否存在?

                     复位序列是否正常?

                     PLL是否正常锁定?

                     电源是否power good

cfg_cuurent_speed_o:协商的速率,PCIE1.0/2.0/3.0 分别对应1/2/3 

link_width:协商的宽度

6 故障点说明及解决

我的故障就是:

phy_rdy_n为0,说明物理层就绪,时钟和复位是正常的

LTSSM卡在了0x08,且Link_width为0,说明是LANE的异常导致的。

        重新检查电路,发现主机的TX端,没有放置电容,而使用的是电阻,导致的AC耦合问题,将电阻更换为电容,链路问题解决

可以看到Link up拉起,驱动可以正常检测到PCIE设备。

Read more

论文阅读:MiniOneRec

github仓库:https://github.com/AkaliKong/MiniOneRec 技术报告论文:https://arxiv.org/abs/2510.24431 找了一个论文阅读辅助工具:https://www.alphaxiv.org/ 代码 https://github.com/AkaliKong/MiniOneRec SFT在做什么 前置:数据集 代码路径:MiniOneRec/data.py 类Tokenizer:给普通的分词器多包装了一层,可以处理连续的bos/eos的特殊字符串。 SidSFTDataset 多样化的指令 任务:输入用户最近交互过的item列表,预测用户下一个交互的item SidItemFeatDataset sid2title或者title2sid任务 FusionSeqRecDataset 带意图识别的商品推荐 代码 代码入口:MiniOneRec/sft.py 1、

By Ne0inhk

数字电路FPGA原型验证平台搭建快速理解

FPGA原型验证:从零搭建高效数字电路“设计沙盒” 你有没有遇到过这样的场景? 写完几千行Verilog代码,功能仿真跑通了,心里正得意——结果一上板,系统莫名其妙卡死、数据错乱,ILA抓出来的波形像谜语人一样毫无头绪。更糟的是,项目deadline就在下周,流片预算已经批下来了…… 这不是危言耸听,而是每个数字前端工程师都可能踩过的坑。而解决这类问题最有效的手段之一,就是 在FPGA上搭一个原型验证平台 ——它就像一个“硬件模拟器”,让你的设计提前暴露真实世界中的各种边界情况。 今天我们就来拆解这个关键环节:如何快速理解并搭建一套实用的FPGA原型验证环境。不讲空话,只聚焦真正影响开发效率的核心技术点。 为什么仿真不够用了? 在SoC设计日益复杂的今天,纯软件仿真(比如用ModelSim跑RTL)越来越显得力不从心。哪怕是一颗中等规模的处理器子系统,全速仿真一天也未必能跑完一次完整的启动流程。更别说要覆盖所有中断、异常和外设交互路径。 而FPGA的优势在于: 它是真正的并行执行硬件 。你的状态机、总线仲裁、DMA搬运,全部在同一时刻物理运行,速度轻松达到MHz级别——比

By Ne0inhk
【Part 4 XR综合技术分享】第一节|技术上的抉择:三维实时渲染与VR全景视频的共生

【Part 4 XR综合技术分享】第一节|技术上的抉择:三维实时渲染与VR全景视频的共生

《VR 360°全景视频开发》专栏 将带你深入探索从全景视频制作到Unity眼镜端应用开发的全流程技术。专栏内容涵盖安卓原生VR播放器开发、Unity VR视频渲染与手势交互、360°全景视频制作与优化,以及高分辨率视频性能优化等实战技巧。 📝 希望通过这个专栏,帮助更多朋友进入VR 360°全景视频的世界! Part 4|XR综合技术分享 最后一Part了,我将分享一些关于当前常用的XR综合技术,内容涵盖三维实时渲染与全景视频的共生、多模态交互体验的融合,以及AI如何深度赋能XR应用,推动智能化发展。同时畅想通向全感知XR智能沉浸时代的未来,探索如何通过更先进的技术不断提升用户体验。毕竟,360°全景视频仅是XR应用中的冰山一角。 第一节|技术上的抉择:三维实时渲染与VR全景视频的共生 文章目录 * 《VR 360°全景视频开发》专栏 * Part 4|XR综合技术分享 * 第一节|技术上的抉择:三维实时渲染与VR全景视频的共生 * 1、VR内容形态的分化与融合 * 1.1 三维实时渲染的发展 * 1.2

By Ne0inhk
近五年体内微/纳米机器人赋能肿瘤精准治疗综述:以 GBM 为重点

近五年体内微/纳米机器人赋能肿瘤精准治疗综述:以 GBM 为重点

摘要 实体瘤治疗长期受制于递送效率低、肿瘤组织渗透不足以及免疫抑制与耐药等问题。传统纳米药物多依赖被动累积与扩散,难以在肿瘤内部形成均匀有效的药物浓度分布。2021–2025 年,体内微/纳米机器人(包括外场驱动微型机器人、自驱动纳米马达以及生物混合机器人)围绕“运动能力”形成了三条相互收敛的技术路线: 其一,通过磁驱、声驱、光/化学自驱等方式实现运动增强递药与深层渗透,将治疗从“被动到达”推进到“主动进入”; 其二,与免疫治疗深度融合,实现原位免疫唤醒与肿瘤微环境重塑; 其三,针对胶质母细胞瘤(glioblastoma, GBM)等难治肿瘤,研究趋势转向“跨屏障递送(BBB/BBTB)+ 成像/外场闭环操控 + 时空可控释放”的系统工程。 本文围绕“运动—分布—疗效”的因果链条,总结 2021–2025 年代表性研究与关键评价指标,讨论临床转化所需的安全性、

By Ne0inhk