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

GHCTF2025-WEB题解:如何用SSTI绕过WAF黑名单(附实战payload)

从GHCTF2025实战出发:深度拆解SSTI黑名单绕过策略与高阶Payload构造 最近在GHCTF2025的WEB赛道上,一道看似简单的文件上传题目,却让不少选手陷入了“知道有洞,但payload总被拦截”的困境。这道题表面上是文件上传,实际上却是一场针对SSTI(服务器端模板注入)绕过能力的深度考验。我在实际测试中发现,很多选手能够快速识别出SSTI漏洞的存在,但在面对严格的黑名单过滤时,却往往束手无策,反复尝试的payload都被WAF无情拦截。 这种情况在真实的渗透测试和CTF比赛中并不少见。WAF(Web应用防火墙)的过滤规则越来越智能,传统的{ {7*7}}测试虽然能确认漏洞,但真正要执行命令、读取文件时,那些包含os、flag、__builtins__等关键词的payload几乎都会被第一时间拦截。这道题的精妙之处在于,它模拟了一个相对真实的防御环境——不仅过滤常见敏感词,还对下划线这种在Python反射中至关重要的字符进行了拦截。 本文将从实战角度出发,不局限于GHCTF2025这一道题目,而是系统性地探讨SSTI黑名单绕过的核心思路、技术原理和进阶技巧。我会结

前端通用 Token 全流程操作指南(常见常用版)

前端通用 Token 全流程操作指南(常见常用版) 本文梳理 所有前端框架通用 的 Token 操作逻辑,剥离具体项目/技术栈细节,聚焦「获取→存储→使用→过期→清除」的核心生命周期,每个步骤均标注「通用场景+通用方案+注意事项」,适合所有前端开发场景,可直接作为开发速查表。 前置说明:Token 的核心定位 Token 是后端签发的临时访问凭证,核心作用是: 1. 证明“当前用户是谁”(身份认证); 2. 证明“当前用户有权限访问”(权限校验)。 一、第一步:登录成功获取 Token 通用场景 用户通过账号密码/验证码/第三方登录等方式,向后端发起登录请求,后端验证通过后,在响应体中返回 Token。

前端图片加载失败、 img 出现裂图的原因全解析

在前端开发过程中,我们几乎都遇到过这种情况: 页面中某张图片加载不出来,显示成一个小小的“裂图”图标。 这看似简单的问题,实际上可能由多种原因造成,尤其是在 HTTPS 环境下,混合内容机制(Mixed Content) 是最常见、也最容易被误解的根源之一。 本文将带你系统梳理裂图的各种原因、排查思路,并重点讲清楚混合内容的原理与浏览器行为。 一、什么是“裂图”? “裂图”(broken image)是指浏览器尝试加载 <img> 标签的图片资源失败时的表现形式。 常见表现: * 图片区域显示为灰底、叉号、占位符; * 控制台出现 Failed to load resource 或 Mixed Content 警告; * Network 面板中图片请求状态码为 404 / 403 / blocked。 二、常见的裂图原因汇总

WebRTC / HLS / HTTP-FLV 的本质区别与选型指南

WebRTC / HLS / HTTP-FLV 的本质区别与选型指南

在做系统级直播(而不是自己本地播放)时,很多人都会遇到一个经典问题: WebRTC、HLS、HTTP-FLV 到底有什么区别? 项目中到底该选哪个? 传输协议不同 → 延迟不同 → 兼容性 / 稳定性 / 成本不同 在系统里选哪个,核心看两点: 你要多低的延迟?你要多强的兼容和稳定? 一、简介 * WebRTC:超低延迟(0.2 ~ 1s),适合实时监控、无人机、实时指挥 * HLS(hls.js):最稳、最通用(5 ~ 15s),适合活动直播、课程、公开大并发 * HTTP-FLV(flv.js):中低延迟(1 ~ 3s),适合想比 HLS 低延迟,但不想用 WebRTC 的场景(