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

AI入门第一课:人工智能基础概念全解析 - 从零开始理解这个改变世界的技术

AI入门第一课:人工智能基础概念全解析 - 从零开始理解这个改变世界的技术

目录 * 为什么要了解人工智能? * 什么是人工智能?从图灵测试说起 * 人工智能的三次浪潮:从幻想到现实 * 第一次浪潮:符号主义的黄金时代 * 第二次浪潮:机器学习的崛起 * 第三次浪潮:深度学习的革命 * 机器学习的三大范式:监督学习、无监督学习和强化学习 * 监督学习:有老师指导的学习 * 无监督学习:自己发现规律的学习 * 强化学习:通过试错来学习 * 深度学习:模仿人脑的神经网络 * 神经网络的基本结构 * 从感知机到深度神经网络 * 卷积神经网络:专门为图像设计的网络 * 循环神经网络:处理序列数据的高手 * 人工智能的应用领域:改变世界的力量 * 医疗健康:AI医生的崛起 * 自动驾驶:重新定义出行方式 * 金融科技:智能理财的新时代 * 教育培训:个性化学习的新模式 * 娱乐媒体:内容创作的新可能 * 人工智能的局限性和挑战:理性看待AI * 数据依赖:AI的"食粮"问题 * 可解释性:

IDEA 集成 GitHub Copilot 指南:解锁 10 倍编码效率的全链路实战

IDEA 集成 GitHub Copilot 指南:解锁 10 倍编码效率的全链路实战

一、GitHub Copilot核心底层逻辑 GitHub Copilot是GitHub与OpenAI联合打造的生成式AI编码助手,基于代码专属优化的大语言模型构建,也是目前开发者生态中普及率最高的AI编码工具。它并非简单的代码补全插件,而是通过深度理解代码上下文与自然语言语义,实现全场景的编码辅助。 1.1 核心工作原理 Copilot的工作流程可拆解为5个核心环节,全程毫秒级响应,实现与IDEA的无缝协同: * 上下文采集:实时读取IDEA内当前文件代码、打开的关联文件、光标位置、注释内容、项目结构与命名规范,最大程度还原开发语境 * 预处理过滤:对采集的上下文进行脱敏、格式标准化与冗余信息过滤,降低推理干扰,同时过滤敏感信息避免数据泄露 * 模型推理:将处理后的上下文传入代码大模型,基于海量开源代码训练数据与语义理解能力,生成符合语境的代码逻辑 * 代码校验:对生成的代码进行语法校验、格式规范匹配,过滤存在明显语法错误的建议 * 交互反馈:将最终建议渲染到IDEA编辑器中,同时收集用户的接受/拒绝行为,持续优化生成效果 1.2 与IDEA原生补全的核心差异

LiuJuan20260223Zimage镜像文档精读:从ZEEKLOG博客说明到本地环境精准复现

LiuJuan20260223Zimage镜像文档精读:从ZEEKLOG博客说明到本地环境精准复现 1. 引言:从镜像描述到动手实践 最近在ZEEKLOG星图镜像广场上,一个名为 LiuJuan20260223Zimage 的镜像引起了我的注意。它的描述很直接:一个基于Z-Image的LoRA模型,专门用于生成“LiuJuan”风格的图片。对于喜欢探索特定风格AI绘画的朋友来说,这无疑是一个有趣的工具。 但官方的博客说明往往比较简洁,只告诉了你“是什么”和“怎么点按钮”。作为一个技术实践者,我更关心的是:这个镜像背后到底是怎么运行的?如果我想在本地复现或者深入理解它的工作流,该从哪里入手?这篇文章,我就带你一起“精读”这个镜像的文档,并尝试在本地环境中一步步复现其核心服务,让你不仅会用,更能懂它。 我们的目标很明确:通过Xinference部署这个文生图模型服务,并用Gradio搭建一个可交互的Web界面。整个过程,我会尽量用大白话解释清楚每一步在做什么。 2. 镜像核心解析:它到底是什么? 在动手之前,我们先得搞清楚我们要部署的是什么。根据镜像描述,我们可以提炼出几个

Z-Image-Turbo真实体验:高分辨率AI绘画太震撼了

Z-Image-Turbo真实体验:高分辨率AI绘画太震撼了 最近在ZEEKLOG星图镜像广场试用了预置Z-Image-Turbo的文生图环境,说实话——第一张图生成出来的时候,我下意识放大到200%,盯着屏幕看了足足半分钟。不是因为画得有多“完美”,而是那种1024×1024分辨率下依然清晰锐利的细节、自然流动的光影过渡、以及9步推理就完成的丝滑感,彻底打破了我对“快”和“好”必须二选一的认知。这不是又一个参数堆出来的模型,而是一次真正面向创作者工作流的工程突破。 它不靠牺牲质量换速度,也不用拉长等待时间保细节。它就站在那里,安静地告诉你:高分辨率AI绘画,本该这么顺。 1. 开箱即用的真实体验:从启动到出图,不到45秒 很多人以为“开箱即用”只是宣传话术。但这次,我连终端都没来得及多敲几个命令,就已经在看第一张生成图了。 我选择的是RTX 4090D实例(24G显存),镜像已预置全部32.88GB权重文件——这点太关键了。没有下载进度条,没有缓存校验卡顿,没有“正在加载分片001/127”的焦虑。只有三步: 1.