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

YOLOv8n机器人场景目标检测实战|第一周工作笔记1

核心完成项:基于Conda搭建Ultralytics8.0+PyTorch2.1专属环境,完成COCO2017机器人场景子集筛选(8000张,7000训+1000验),跑通YOLOv8n基础训练(epoch=50),小障碍物mAP≥65%,模型可正常输出推理结果,满足周验收全部目标。 环境说明:全程使用Conda进行包管理与环境隔离,无pip命令使用,规避版本兼容问题;模型选用YOLOv8n(轻量化版本,适配机器人端算力限制),替代原计划YOLOv9n,核心实操逻辑一致。 一、本周核心目标与执行思路 1. 核心目标 1. 掌握YOLO系列核心创新与轻量化模型适配逻辑,聚焦机器人室内小场景(室内小障碍物/桌椅/行人/台阶)检测需求; 2. 搭建稳定可复现的Ultralytics+PyTorch训练环境,规避版本冲突; 3. 筛选并整理符合YOLO格式的机器人场景自定义数据集,完成基础标注与训练集/验证集划分; 4. 跑通YOLOv8n基础训练流程,验证数据集与模型兼容性,获取基础精度、参数量、

【具身智能】具身机器人VLA算法入门及实战(一):具身智能系统及VLA

【具身智能】具身机器人VLA算法入门及实战(一):具身智能系统及VLA

具身机器人VLA算法入门及实战(一):具身智能系统及VLA * 一、常见具身智能系统 * 二、具身智能数据获取方式 * 三、具身智能-感知系统 * 四、具身智能学习方式 * 五、工业机器人及应用需求 * 六、VLA架构及开源项目 * 6.1 VLA架构 * 6.2 开源项目 * 七、机器人操作案例 一、常见具身智能系统 二、具身智能数据获取方式 数据获取平台: Isaac Sim, Isaac Gym, Mujoco, 桃园 2.0 数据增强平台: RoboVerse, Genie Studio, DexMimicGen 三、具身智能-感知系统 四、具身智能学习方式 五、工业机器人及应用需求 六、VLA架构及开源项目 6.

阿里云的moltbot机器人使用钉钉的Stream流式接入

注意 1. 这个不需要工作流 2. 这个不需要开放外网 具体方法: 1.check代码https://github.com/DingTalk-Real-AI/dingtalk-moltbot-connector 2.package.json增加如下代码 "moltbot": { "extensions": ["./plugin.ts"], "channels": ["dingtalk-connector"], "installDependencies": true } 3.安装插件 moltbot plugins install dingtalk-moltbot-connector 4.增加钉钉配置~/.moltbot/moltbot.json;如果有了进行提花 { "channels"

无人机消防通道占用巡检识别 消防通道占用目标检测数据集 智慧消防场景中违规占用行为自动监测与预警 智慧城市治理巡检第10456期

无人机消防通道占用巡检识别 消防通道占用目标检测数据集 智慧消防场景中违规占用行为自动监测与预警 智慧城市治理巡检第10456期

消防通道占用目标检测数据集 数据集核心信息表 类别数量类别名称数据总量格式种类核心应用价值1消防通道551YOLO 格式用于训练消防通道占用识别模型,助力智慧消防场景中违规占用行为的自动监测与预警 数据集关键要素说明 1. 类别设计 * 聚焦消防场景核心检测需求,仅设置 “消防通道” 单一类别,避免冗余标注干扰模型学习; * 类别定义明确,围绕消防通道的物理特征标注,确保模型能精准定位目标区域。 往期热门主题 主页搜两字"关键词"直达 代码数据获取: 获取方式:***文章底部卡片扫码获取*** . 覆盖了YOLO相关项目、OpenCV项目、CNN项目等所有类别, 覆盖各类项目场景: 项目名称项目名称基于YOLOv8 智慧农业作物长势监测系统基于YOLOv11 人脸识别与管理系统基于YOLOv26 无人机巡检电力线路系统PCB板缺陷检测(基于YOLOv8)智慧铁路轨道异物检测系统(基于YOLOv11)基于YOLOv26 102种犬类检测系统基于YOLOv8 人脸面部活体检测无人机农田病虫害巡检系统(基于YOLOv11)水稻害虫检测识别(基于YOL