PCIe物理层LTSSM状态机解析

2024-09-02 05:48

本文主要是介绍PCIe物理层LTSSM状态机解析,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

目录

1、Detect

2、Polling

3、Configuration

4、L0

5、Recovery

6、L0s/L1/L2

7、Hot Reset

8、Disabled

9、Loopback


在PCIe链路可以正常工作之前,需要对PCIe链路进行链路训练,在这个过程中,就会用LTSSM状态机。LTSSM全称是Link Training and Status State Machine。这个状态机在哪里呢?它就在PCIe总线的物理层之中。

LTSSM状态机涵盖了11个状态,包括Detect, Polling, Configuration, Recovery, L0, L0s, L1, L2, Hot Reset, Loopback, Disable。这11个状态之间转换的逻辑,如下图,

这11个状态大致可以分为4大类:

  • PCIe链路训练相关。正常的PCIe链路训练状态转换流程依次是,Detect->Polling->Configuration->L0. L0是PCIe链路可以正常工作的电源状态。
  • PCIe链路重新训练相关。这个状态也称为Recovery。Recovery是一个非常重要的链路状态,进入这个状态的因素也很多,比如电源状态的变化,PCIe链路速率的变化等。
  • 电源状态相关。PCIe总线的电源状态主要有两部分的内容。
  1.  一是基于软件控制的PCI-PM电源管理机制,是系统软件通过修改寄存器中的电源管理字段,使PCIe设备进入D状态:D0,D1,D2,D3.
  2.  二是基于硬件控制的ASPM(=Active State Power Management)电源管理机制,是基于硬件自主控制的链路电源管理机制,只有在PCIe设备处于D0状态是才可以启动ASPM机制,另外,与ASPM有关的链路状态有L0s,L1(包括L1.1和L1.2).
  • 其他相关。比如Hot Reset, Link Disable, Loopback等。

接下来对这11个状态分别作一个简单的介绍。

1、Detect

这是物理层的初始状态,仅在Gen1 2.5 GT/s速率下使用,或是从数据链路层转换而来,或是在reset之后,或者从其他状态(Disable, Polling, Configuration,Recovery等)转换。总之,Detect状态是PCIe链路训练的开端。此外,Detect,顾名思义,需要实现检测工作。因为在这个状态时,发送端TX需要检测接收端RX是否存在且可以正常工作,如果检测正常,才能进入其他状态。Detect状态主要包含了两个子状态:Detect.Quiet和Detect.Active.


(1) 从其他状态或者Reset之后,物理层从Electrical Idle开始,此时,处于Detect.Quiet;

(2) 当超过12ms或者所有Lane均退出Electrical Idle时,则从Dectect.Quiet转换进入Detect.Active。在这个状态就会开启检测RX工作。


判断RX是否存在的逻辑比较简单,就是通过一个“Detect logic”电路比较RC时间常数的大小。

(1) 当RX不存在时,RC时间常数较小。

(2) 当RX存在时,RC时间常数较大。

2、Polling

这个状态的目的是"对暗号",实现无障碍沟通。进入这个状态后,TX和RX之间通过发送TS1、TS2 OS序列来确定Bit Lock, Symbol Lock以及解决Lane极性反转的问题。

Bit Lock: 在Bit传输过程中,RX PLL锁定TX Clock频率,这个过程称为RX实现"Bit Lock"。

Symbol Lock: RX端串并转化器知道如何区别一个有效的10-bit Symbol,这个过程称为“Symbol Lock”. 这里用到的是COM控制符。

Polling状态主要包含了三个子状态:Polling.Active, Polling.Configuration, Polling.Compliance.

(1)  Polling.Active:这是链路从Detect退出后进入的状态,在这个状态下,发送端需要在所有Lane至少发送1024个TS1序列,因为接收端需要通过接收到的TS1序列来实现Bit/Symbol Lock. 由于发送端和接收端不是同时退出Detect状态,所以,TS1序列交流可能不会同步。此时,链路出于Gen1(2.5GT/s), Symbol time=4ns(10b/2.5Gb/s), 发送1024个TS1序列(16 symbols)至少需要64us(1024*16*4ns).

(2)  Polling.Configuration: 当发送端TX发送完至少1024个TS1并且接收端RX连续收到8个TS1或者TS2,此时TS1和TS2中的Link/Lane区域由PAD填充, 那么,链路进入Polling.Configuration状态。处于此状态,发送端停止发送TS1序列,改为发送TS2序列,此时Link/Lane区域仍然由PAD填充,这个过程也会完成极性反转的问题,为进入下一个状态作准备。

(3)  Polling.Compliance: 这个状态主要是通过发送不同的Pattern来测试发送端以及设备连接是否符合Spec要求。


3、Configuration

这个状态工作内容很简单,就是通过发送TS1、TS2来确定Link/Lane number. 如下图,Configuration包含了6个子状态

Configuration.LinkWidth.Start,Configuration.LinkWidth.Accpet,Configuration.Lanenum.

Wait,Configuration.Lanenum.Accpet,Configuration.Complete, Configuration.Idle.

由于Configuration状态下,发送端和接收端已经确认可以正常通信,所以,我们结合实例来看一下Downstream和Upstream的状态转换过程。

(1) Link Number Negotiation

Downstream在TS1中设定Link number, 此时Lane number=PAD,并发送给Upstream.

而Upstream回的第一个TS1中,Link num仍然是PAD。此时,Upstream也处于Configuration.LinkWidth.Start状态。

之后Upstream回的TS1中Link number则是设定值,此时, Upstream率先进入Configuration.LinkWidth.Accept状态。

 

到这里,Link Number Negotiation就完成了。

(2) Lane Number Negotiation

当Downstream看到Upstream返回的TS1中Link number已经是设定值,那么就认为Link num已经协商成功,然后就开始准备设定Lane number,此时Downstream链路也接着进入Configuration.LinkWidth.Accept状态. 由于在录这个Trace时有过滤重复的TS序列,所以,我们看到一个TS1序列对应了三个状态:Configuration.LinkWidth.Accept,Configuration.LaneNum.Wait,Configuration.LaneNum.Accept. 这个三个状态发送的TS1序列一样,Link number和Lane number都已设定。

当Upstream收到Downstream设定Lane number的TS序列之后,也很快进入了Configuration.LaneNum.Accept状态。

与Lane number相关的三个状态之间相互转换逻辑如下:Downstream Vs Upstream.

到这里,双方Lane number协议就完成了。

(3) Confirm Lane/Link Number

最后一步,过程就很简单了,双方通过发送TS2序列,对之前设定的Link/Lane number进行确认,这个过程,LTSSM处于Configuration.Complete. 确认没有问题之后,就准备进入下一个状态。

4、L0

当进入这个状态时,PCIe链路就可以愉快的开始正常工作了。这个状态可以传输TLP,DLLP等报文。

5、Recovery

当PCIe链路需要重新训练时,进入Recovery状态。主要有以下几种情况:

  • PCIe链路信号发现error,需要调整Bit Lock和Symbol Lock;
  • 从L0s或者L1低功耗电源状态退出;
  • Speed Change。因为第一次进入L0状态时,速率是2.5GT/s. 当需要进行速率调整5.0GT/s或者8.0GT/s时,需要进入Recovery状态进行Speed Change. 这个阶段,Bit Lock、Symbol Lock等都需要重新获取;
  • 需要重新调整PCIe链路的Width;
  • 软件触发retrain操作;
  • 仅在Gen3和Gen4,需要重新进行Equalization。

Recovery子状态转换逻辑如下图:

我们结合一个上电过程中Gen1提速至Gen3的时序来解读一下Recovery状态的转换,如下图:


a. Downstream率先进入Recovery.RcvrLock状态, 之后向Upstream持续发送TS1并且将speed_change bit设置为1;

b. Upstream端看到TS1进来之后,也跟着进入Recovery.RcvrLock状态,同时回传TS1序列,不过此时,speed_change bit仍为0. 当Upstream接收达到连续8个TS1且speed_change bit设置为1,这时,Upsteam回传的TS1、TS2中speed_change bit设置为1,并告诉Downstream建议工作速率,接着进入Recovery.RcvrCfg状态;

c. Downstream收到Upstream建议的速率反馈之后,也返回TS2序列,并发送EIOS序列,准备进入Electrical Idle. 此时,LTSSM处于Recovery.RcvrCfg状态;

d. 之后,Downstream和Upstream相继进入Electrical Idle, LTSSM处于Recovery.Speed状态;

e. 经过一段时间timeout(Spec要求至少800ns, 小编这个Trace中是~8us),Upstream发送EIEOS, 退出Electrical Idle, 尝试跑最高速率8GT/s;

f. 接着Downstream也退出Electrical Idle, 尝试跑试跑最高速率8GT/s;

g. 最后,双方开始进行EQ。EQ之后,PCIe链路就可以回到正常工作状态。


6、L0s/L1/L2

这三个状态,主要是低功耗电源管理状态,在这里不再展开了,具体可以参考Spec.

7、Hot Reset

当某个PCIe设备发生错误时,我们有时候需要通过软件的方式对设备进行复位,这个方式就是Hot Reset。可以通过设置Bridge Control寄存器中的Secondary Bus Reset来触发Hot Reset.

Hot Reset的指令是在TS1序列中体现,如下图,

Hot Reset触发之后,LTSSM会进入Recovery和Hot Reset状态,之后会到Detect状态,PCIe链路开始重新训练。

8、Disabled

用户可以通过设置修改Link Control寄存器,让PCIe链路出于Disabled状态。

另外,如果我们把设备移除之后,同样也进入Disabled状态。

当退出Disabled状态后,LTSSM回到Dectect,PCIe链路重新训练。

9、Loopback

这个状态仅用于debug测试,一般情况不会遇到,在这里不再展开,有兴趣的话可以参考PCIe Spec

这篇关于PCIe物理层LTSSM状态机解析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1129167

相关文章

Java中Redisson 的原理深度解析

《Java中Redisson的原理深度解析》Redisson是一个高性能的Redis客户端,它通过将Redis数据结构映射为Java对象和分布式对象,实现了在Java应用中方便地使用Redis,本文... 目录前言一、核心设计理念二、核心架构与通信层1. 基于 Netty 的异步非阻塞通信2. 编解码器三、

Java HashMap的底层实现原理深度解析

《JavaHashMap的底层实现原理深度解析》HashMap基于数组+链表+红黑树结构,通过哈希算法和扩容机制优化性能,负载因子与树化阈值平衡效率,是Java开发必备的高效数据结构,本文给大家介绍... 目录一、概述:HashMap的宏观结构二、核心数据结构解析1. 数组(桶数组)2. 链表节点(Node

Java 虚拟线程的创建与使用深度解析

《Java虚拟线程的创建与使用深度解析》虚拟线程是Java19中以预览特性形式引入,Java21起正式发布的轻量级线程,本文给大家介绍Java虚拟线程的创建与使用,感兴趣的朋友一起看看吧... 目录一、虚拟线程简介1.1 什么是虚拟线程?1.2 为什么需要虚拟线程?二、虚拟线程与平台线程对比代码对比示例:三

一文解析C#中的StringSplitOptions枚举

《一文解析C#中的StringSplitOptions枚举》StringSplitOptions是C#中的一个枚举类型,用于控制string.Split()方法分割字符串时的行为,核心作用是处理分割后... 目录C#的StringSplitOptions枚举1.StringSplitOptions枚举的常用

Python函数作用域与闭包举例深度解析

《Python函数作用域与闭包举例深度解析》Python函数的作用域规则和闭包是编程中的关键概念,它们决定了变量的访问和生命周期,:本文主要介绍Python函数作用域与闭包的相关资料,文中通过代码... 目录1. 基础作用域访问示例1:访问全局变量示例2:访问外层函数变量2. 闭包基础示例3:简单闭包示例4

MyBatis延迟加载与多级缓存全解析

《MyBatis延迟加载与多级缓存全解析》文章介绍MyBatis的延迟加载与多级缓存机制,延迟加载按需加载关联数据提升性能,一级缓存会话级默认开启,二级缓存工厂级支持跨会话共享,增删改操作会清空对应缓... 目录MyBATis延迟加载策略一对多示例一对多示例MyBatis框架的缓存一级缓存二级缓存MyBat

前端缓存策略的自解方案全解析

《前端缓存策略的自解方案全解析》缓存从来都是前端的一个痛点,很多前端搞不清楚缓存到底是何物,:本文主要介绍前端缓存的自解方案,文中通过代码介绍的非常详细,需要的朋友可以参考下... 目录一、为什么“清缓存”成了技术圈的梗二、先给缓存“把个脉”:浏览器到底缓存了谁?三、设计思路:把“发版”做成“自愈”四、代码

Java集合之Iterator迭代器实现代码解析

《Java集合之Iterator迭代器实现代码解析》迭代器Iterator是Java集合框架中的一个核心接口,位于java.util包下,它定义了一种标准的元素访问机制,为各种集合类型提供了一种统一的... 目录一、什么是Iterator二、Iterator的核心方法三、基本使用示例四、Iterator的工

Java JDK Validation 注解解析与使用方法验证

《JavaJDKValidation注解解析与使用方法验证》JakartaValidation提供了一种声明式、标准化的方式来验证Java对象,与框架无关,可以方便地集成到各种Java应用中,... 目录核心概念1. 主要注解基本约束注解其他常用注解2. 核心接口使用方法1. 基本使用添加依赖 (Maven

Java中的分布式系统开发基于 Zookeeper 与 Dubbo 的应用案例解析

《Java中的分布式系统开发基于Zookeeper与Dubbo的应用案例解析》本文将通过实际案例,带你走进基于Zookeeper与Dubbo的分布式系统开发,本文通过实例代码给大家介绍的非常详... 目录Java 中的分布式系统开发基于 Zookeeper 与 Dubbo 的应用案例一、分布式系统中的挑战二