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

苍穹外卖(前端)

苍穹外卖(前端)

前端环境搭建: 技术选型: 使用的前端技术栈:node.js、vue、ElementUI、axios、vuex、vue-router、typescript 代码结构: 核心目录 / 文件: 目录 / 文件说明apki封装 Ajax 请求的文件目录components公共组件存放目录views视图组件存放目录App.vue项目主组件、页面入口文件main.ts整个项目的入口文件router.ts路由配置文件 环境准备: 安装依赖包(生成 node_modules 目录): npm install 启动前端项目(需同时启动后端 Java 服务): npm run serve 员工管理: 员工分页查询: 需求分析和接口设计: 代码开发: 步骤一:制作页面头部 <div> <label> 员工姓名:

By Ne0inhk

Java Web请求处理链路剖析(从Filter到HandlerInterceptor的完整流程图解)

第一章:Java Web请求处理链路概述 在Java Web应用中,客户端发起的HTTP请求需经过一系列组件协同处理,最终返回响应。这一完整的链路贯穿了从网络通信到业务逻辑执行的多个层次,理解其结构对开发高性能、可维护的Web系统至关重要。 请求进入容器 当客户端发送HTTP请求时,首先由Web服务器(如Tomcat)接收。服务器基于配置的端口监听请求,并将原始HTTP数据封装为 HttpServletRequest 对象,同时创建 HttpServletResponse 用于输出响应。 Servlet生命周期管理 请求被映射到指定的Servlet进行处理。容器根据web.xml或注解配置确定目标Servlet,并确保其实例已初始化。典型的处理流程如下: * 执行 init() 方法完成初始化(仅一次) * 调用 service() 方法分发请求至 doGet() 或 doPost() * 由具体方法生成响应内容并写入输出流 * 容器自动关闭响应,发送数据回客户端 过滤器与拦截机制 在请求到达Servlet前,可配置多个 Filter 实现横切关注点处理,如日志

By Ne0inhk

JavaWeb学习笔记:动静态Web、URL、HTTP

Web Web是在互联网上,用浏览器访问的一种信息服务。可以简单理解成,我们打开一个网络链接,展示的一个个网页,就是Web。 Web有动态Web和静态Web: * 静态Web:是指开发者提前写好Web网页(HTML),所有人看到的网页内容都是一样的Web。早期的Web是静态Web,是使用HTML将网页内容写好放在服务器中,所有人访问网页,都是看到这个HTML的内容。静态Web的特点是所有人看到相同的内容,网页内容、数据都是写在HTML里,不与数据库交互。静态Web的业务流程大致如下: * Web开发者编写好HTML,保存到服务器某目录。 * 用户从浏览器打开网页,比如www.xxxx.com/index.html。 * 服务器接受到请求,从文件目录中找到这个index.html文件,发送给用户。 * 用户浏览器接收到HTML,渲染成网页展示给用户。 * 动态Web:是指开发者并非提前写好Web网页,而是在用户访问时,动态生成网页HTML内容,每个人看到的网页内容都是不一样的Web。现代Web几乎都是动态Web,每个人看到的Web内容都可能不一样,比如有

By Ne0inhk
LazyLLM 多 Agent 应用全流程实践:从源码部署到可视化 Web 调试的低代码方案

LazyLLM 多 Agent 应用全流程实践:从源码部署到可视化 Web 调试的低代码方案

LazyLLM 多 Agent 应用全流程实践:从源码部署到可视化 Web 调试的低代码方案 前言:为什么选择 LazyLLM 构建多 Agent 大模型应用? LazyLLM 作为低代码构建多 Agent 大模型应用的开发工具,可大幅降低大模型应用的开发与部署门槛。本文聚焦其在豆包模型的落地实践,将从源码部署豆包文本模型的完整配置步骤入手,延伸至官方 WebModule 启动可视化 Web 界面的实操流程,并配套精准性、简洁度等多维度的部署测试说明,为开发者提供可直接对照的实操指南,助力高效完成豆包模型在 LazyLLM 框架下的部署与验证。 LazyLLM 整体架构解析:三层联动的多 Agent 运行体系 LazyLLM 的架构分为三层级递进结构,各层级分工明确且联动协同,实现从应用开发到落地执行的全流程覆盖:上层(LazyPlatform AI 大模型应用开发平台):核心含应用编排平台以可视化编排、发布、回流、调优的闭环完成应用构建迭代与平台管理模块通过租户、权限管理支撑多用户运维,是开发者的高效开发管理入口中层(

By Ne0inhk