硬件总线基础04：LPC & eSPI总线（2）

说在开头：关于关于科学是什么（2）

大家都听说过弗洛伊德，我上大学时看过他的《梦的解析》，弗洛伊德经常将患者的梦境与童年经历、性经历联系在一起；患者无论说梦到什么，他都能很有道理的跟这些扯到一起来。波普尔的父母跟弗洛伊德的姐妹是很好的朋友，所以波普尔很小就接触了弗洛伊德的学说，但他并没有被弗洛伊德的大名所吓倒，反而很快就发现了他的问题：这种解释的确不会和现实产生任何矛盾，但谁又能确定它是对现实的真实反映呢？所以波普尔提出了一个检验科学理论的重要标准：可证伪性。

我们判断这个理论是否是科学理论，其中的关键标准就是：这个理论有没有可以被证伪的可能。即，科学理论必须能提出一个可供证伪的事实，假如这个事实一经验证，便承认该理论是错的。那如果暂时没人能证明它是错误的，那它就暂时是真的。举个栗子：“所有的天鹅都是白色的”，这是一个可证伪的命题，只要找到一只天鹅的颜色不为白色，那就能说明这个命题是错误的；那么既然我们还未找到不是白色的天鹅，那么目前为止这个命题就是暂时正确的。换句话说，所有的科学理论都是一种假说，科学没有办法证实任何一种科学理论，但是科学理论必须给别人提供验错的机会，而在被检验出错误之前，姑且相信这个这个科学理论是正确的。

休谟又说了：归纳法不可靠啊。证伪主义回答说：是的，用归纳法总结出的科学结论似乎是不可靠的，我们的应对办法是：在被证明不可靠之前，先凑合着用吧。在形而上学统治下的科学观下，人们认为存在着一个绝对真理，我们在形而上学的指导下，带着科学大踏步朝真理前进。但证伪主义的科学观认为：人类提出的各种科学理论有点像基因突变，科学家们头脑风暴出各种充满想象力的假说。证伪就像是在自然环境中对基因进行筛选，经不住考验的都被淘汰，而留下来的都是经得住实践检验的，暂时正确的科学理论。

同时对暂时留下来的科学理论，科学家们也在不断尝试着证伪，一旦证明是错误的，就进行修改，如此科学理论就会越来越完善，而这个试错、修改、完善的过程是无止境的，科学也能因此越来越接近真理（如之前介绍的相对论和量子论各种理论发展，是不是就是遵循了这条道路呢？）。所以证伪主义说：检验正确并不能为科学做贡献，只有检验出科学理论是错的，才是真正为科学做贡献。

如此，我们在日常生活中可以利用这个标准，方便地将巫术、迷信和科学区分开。算命对个人做出预言，从来都是说一些模棱两可的描述：“最近一段时间要遇贵人”，但又不能具体到日期到几点几分几秒，以如何的方式相遇，贵人的年龄、性别、性命、体重、身高呢。这样如何能做检验呢？过了一个月，我又问他怎么没遇贵人呢？他说：你心不诚啊。如此，这个预言就变得无法证伪，也就不可信了。同时宗教理论也都是不可证伪的，神的存在我们无法去证实也无法去证伪，因为人类无法主动检测到神，所以我们无法设计一个实验来证明神是否存在。还有关于一些哲学命题，举个栗子：我们生活在无法感觉到异常的虚拟世界中（类似黑客帝国），科学不可证伪，所以该问题也毫无意义。

但我们需要知道的是：不可证伪的命题并不一定是错误的，而是属于无法用经验检验的命题。如果你是不相信客观经验而喜欢主观臆断的人，那么是可以相信不可证伪的命题；但你坚持“未经检验的理论不可信”，如同苏格拉底一样的怀疑论，那么不可证伪的命题就等同于“没有意义的问题”。讨论这些不可能得出什么有用的结果，将它们丢到一边不去理他，是最好的办法。

那么从证伪主义出发来看真理会得到什么结论呢？它认为：没有永恒不变的真理，所有的理论都可能是错的。但对于形而上学来说，追求的是绝对真理，而绝对真理恰恰是不可证伪的：因为“可证伪”则意味着“可能会错”，就不可能是“绝对真理”。所以无论你说任何一个命题，只要你说“肯定是真的”，那从证伪主义者看来，就是毫无意义的，跟算命和巫术一样，毫无讨论的必要。（参考自：林欣浩-哲学家们都干了些什么）

二，eSPI总线协议

我打了一个响指，时间转眼来到了2016年，随着CPU技术的持续发展，LPC经历了十几年的风光，终于也要跟不上时代的步伐了，而它当年对标的PCI总线早已淹没在滚滚时代潮流里，PCIe早已替代了PCI总线已经发展到了PCIe3.0和PCIe4.0，PCIe5.0也早已在酝酿之中。Intel提出了eSPI（Enhanced Serial Peripheral Interface）总线来替代LPC总线；所以eSPI并非是SPI的增强版，而是LPC的加强版（挂SPI的头，卖LPC的肉！）。

LPC总线落伍的原因是：1，LPC 3.3V的I/O技术，增加芯片的制造成本；2，LPC只支持33MHz总线时钟，带宽为133Mbps，不能满足新设备的带宽需求，但使用USB3.0/PCIe这类高速接口，成本又太高；3，CPU芯片组与EC，BMC以及SIO等外设存在大量的边带通信需求，会占用大量的管脚，导致管脚资源成本高。LPC总线架构如下图所示。

eSPI总线借鉴和复用了SPI总线的电气时钟规范（1.8V接口），但是在协议层使用了全新的定义，所以二者无论是从功能还是从应用上完全不同。除了全面兼容LPC总线的作用和功能外，eSPI总线还把OOB（out of band）的SMBUS和Side-Band的GPIO都转化给可以在eSPI Bus上传递的In Band Message（在eSPI的不同channel中实现），除此以外，还可以和chipset实时共享flash。eSPI总线新架构如下图所示。

初这么一看，似乎eSPI和SPI总线是可以共用的。我们首先要明确的是：这是一个错觉；虽然两者在接口电气规范上是兼容的，但我们接下来即将看到的协议，两者是完全不同的。SPI总线协议相对是简单的（如上一章所述），eSPI则相比LPC更加复杂，有更多的管理控制、不同数据类型事务以及错误校验等内容（还包括了部分X86系统带外管理的功能），复杂度介于LPC和PCI。那么，Intel搞出这么一个更加复杂的玩意（eSPI总线）又有啥好处呢？

1. 低功耗：

1，eSPI总线接口电平降低为1.8V；

2，eSPI总线可以在X86的S0~S5下都保持工作状态，为了达到功耗要求，总线在S3~S5状态下的总线功耗非常低。

——如果有胖友不知道S0~S5是啥意思，而且也没有搞X86的打算，建议可以跳过本章。

2. 减少管脚数量：

1，eSPI管脚数量要少于LPC；

2，将BMC/EC/SIO通信的带外管理总线（SMBUS）功能用eSPI带内来实现，去掉带外管理总线（SMBUS）管脚的数量。

3. 更高带宽：相比于LPC有更高的带宽，同时允许在不同的应用场景调整带宽，用于优化功耗性能比；

——带宽的调整可以通过调整频率或改变数据管脚数来实现；

4. eSPI总线基本可以平滑替代LPC总线；

5. Flash实时共享：支持基于可分区内存映射的flash实时共享；允许芯片组（chipset）和slave设备对共享Flash的实时操作。

——注意：Flash实时共享，并非是将SPI Flash同Slave设备（BMC/EC）一起挂在eSPI总线上，两者都对Flash进行操作；如之前所说，SPI Flash是不可以直接下挂在eSPI总线上的。

接下来我们来简单了解下eSPI总线，如有刚好要用到eSPI总线，需要深入学习的胖友，请参考《Enhanced Serial Peripheral Interface (eSPI) Interface Base Specification. Revision 1.0》（Intel官网可以下载）。

1，eSPI系统拓扑架构

eSPI可以工作在Master/Slave模式下，Master通过控制Slave的CS#（Chip Select）管脚来实现它们之间的控制命令和数据流；在任意时刻Master只能有一个CS#被使能，而且只允许与该使能CS#的Slave进行通信。对于一条eSPI总线来说只允许存在1个Master，但允许存在1个或多个Slaver。

——同其它总线一样，CS#信号只允许Master控制输出。

Single Master-Single Slave配置下，一个eSPI Master只连接一个eSPI Slave；在某种配置中，eSPI Slave可以产生eSPI Reset#输出给Master；当然在正常情况下，是Master输出Reset#给Slave的。所以有两种Single Master-Single Slave的拓扑结构，如下图所示。

——Reset#是双向的，总线两侧的eSPI接口都会被复位。

在Single Master-Multi Slave配置下，多个SPI和eSPI Slave可以连接到同一组eSPI总线接口上，一个eSPI总线接口可以支持的设备数量取决于总线负载和信号走线长度。在这种配置下，时钟与数据引脚由多个SPI和eSPI Slave共享，每个eSPI Slave有自己独立的Chip Select#和Alert#引脚。

——在包含多个Slave的eSPI总线配置中，eSPI Master可以支持2个eSPI Reset#引脚：一个方向为从eSPI Slave到eSPI Master，另一个方向为从eSPI Master到eSPI Slave，如下图所示。在这种情况下，只有当所有Slave的eSPI接口被复位之后，eSPI Master的eSPI接口才会复位。

——如下图所示，eSPI总线上接了Flash（Non-eSPI Slave），这并不是说Flash工作在eSPI协议上，只是eSPI总线和SPI总线复用了这些管脚信号（电气特性相同）。即：eSPI协议规范允许类似于Flash和TPM这类的SPI Slave和eSPI Slaves同享同一组时钟和数据引脚。eSPI Master可以使用专用的片选信号选中 Non-eSPI slave ，然后在eSPI总线上使用特定的SPI协议与这些Non-eSPI Slave进行通信。

如左下图所示，在Single Master-Single Slave配置下，单个eSPI Master可以存在多个Host Bridge，而且单个eSPI Slave中可以存在多个eSPI Endpoints。当Master和Slave进行数据传输时，其本质上是Host Bridge和Slave endpoint之间的通信：Host Bridge通过特定的channel和Endpoint进行通信。

——使用Channel便利之处在于：允许eSPI Master和eSPI Slave在同一组总线上相互传输多组彼此独立的命令/数据流，而且这些命令/数据流之间彼此并没有Ordering Requirement。每个Channel各自独享响应的资源，包括流控和命令/数据队列等。

举个栗子，如右上图所示为eSPI Host Bridge通过Channel 0和对应的eSPI Endpoint通信；边带引脚通过Channel 1转化为带内信息；SMB OOB Message通过Channel 2转化；Flash的访问事务通过Channel 3完成。eSPI Master和EC/BMC/SIO之间不同Channel的传输都共享同一组CS#、数据和时钟引脚。

如下图所示为Single Master-Muti Slave配置，多个独立分离的eSPI Slave可以挂载在同一组eSPI总线上。每个eSPI Slave都应该拥有一根专用的片选信号。每个Slave在Master侧都存在一个对应的Host bridge去驱动相应的片选信号。

——在任意时刻都只有一个CS#使能，相应的Host Bridge和Endpoint之间进行数据通信。

2，eSPI信号管脚定义

eSPI复用了SPI总线的电气规范和I/O Buffer，所以从管脚本身的电气性能来说，eSPI和SPI总线是可以共用信号线的。如上所述eSPI总线的Reset#管脚是双向的，Reset#可以由Master输出给Slave，也可以由Slave输出给Master；当eSPI的Reset#信号有效时，Master和Slave设备的eSPI接口必须进入高阻态（三态）：

1. CS#（片选）和I/O信号管脚需要弱上拉；

2. SLK#（串行时钟）信号管脚需要弱下拉；

3. Alert#信号：如果是推挽输出（具体啥叫推挽，参考《电平基础》相关章节）则不需要使用上拉，如果是OD门输出则需要弱上拉。

——所有的弱上/下拉均要在Master Buffer内部或则主板上，不可在Slave上进行弱上/下拉处理。

3，eSPI总线基本协议

所有在eSPI总线上传输的数据必须是8bit（Byte）的整数倍，Master在串行时钟还未低的时候发出第一个数据，Slave在时钟的第一个上升沿采样；随后Master在时钟下降沿发出数据，而Slave在上升沿采样。而在Slave发时，是在时钟的下降沿发出数据。

如下图所示eSPI Master发起一次事务过程，可以看到eSPI总线协议由如下几个部分构成：

1. 由Master驱动的Command Phase：由一个CMD、一个可选的Header（HDR）、可选的DATA和一个CRC 构成；

2. 一个Turn Around Phase（TAR）

3. 一个由Slave驱动的Response Phase：由一个RSP、一个可选的Header（HDR）、可选的数据、一个Status和一个CRC。

——与SPI和LPC不同的是：对于所有的eSPI 总线事务来说，CRC生成是强制的，所以无论何时都可以在Command Phase和Response看到CRC Byte；但是在复位之后，CRC校验默认是关闭的，需要通过SETCONFIGURATION命令开启，当CRC校验被关闭，接收方不会理会CRC Byte。

Slave也可以通过发出一个Alert#信号事件去发起一次eSPI总线事务，有两种方式：

——只有当CS#为高时（说明此时总线空闲），Slave才能发出信号申明一个Alert事件。

1. 在Single Master – Single Slave配置下，Slave可以通过IO[1]管脚去申明一个Alert事件（也可以通过Alert#管脚来实现Alert事件），如下图所示；

——此时Slave将IO[1]从高阻态切换为低电平，一直保持直至Master使能CS#管脚信号；而一旦Master使能CS#管脚，Slave立即释放IO[1]管脚（弱上拉），然后Master发出Get Status命令给Slave以找出Alert事件的原因，并为请求提供服务。

2. 在Single Master – Multi Slave配置下，Slave需要专用的Alert#管脚；如下图所示。

——Alert#管脚被Slave从高电平切换为低电平，直到Master使能CS#管脚信号，此时Slave必须将Alert#管脚驱动为高（推挽结构输出高电平，OD门结构则靠外部上拉驱动高），然后Master发出Get Status命令给Slave以找出Alert事件的原因，并为请求提供服务。

3.1 Command Phase

Command Phase由 eSPI Master发起，用于向Master发起一次transaction或响应Slave的Alert事件；由一个 CMD、一个可选标头 (HDR)、可选 DATA 和一个 CRC 组成。

Command字段由Command Opcode（CMD）构成，如下图所示；它用于标识Channel特定的命令和沟通链路管理事件。

1. eSPI总线传送的Channel特定命令包含对应Channel的： Command Put 和Command Get；

——Posted/Non-Posted header and Data；

2. 链路管理事件包括：GET_STATUS、GET_CONFIGURATION 和SET_CONFIGURATION。

Command Opcode为8bit，如果Slave接收到一个未定义的CMD数据包，那么将不会响应这次事务；总线上默认响应（NO_RESPONSE）并终止此次eSPI 事务。CMD的定义请参考eSPI总线规范 Table3：Command Opcode Encodings。

3.2 Turning Around（TAR）

在Command Phase的最后一bit数据发送到数据线上之后，数据线就进入到Turn-Around（TAR）窗口； eSPI Master需要在 Turn-Around 窗口的第一个时钟将所有数据线驱动为逻辑“1”，然后将数据线置于高阻态。 Turn-Around 窗口的时钟数是固定的 2 个串行时钟，与 eSPI的 I/O 模式（单、双或四 I/O）无关。如果Slave需要额外的时间来采样命令并准备响应，Slave可以在任何 eSPI 事务的 TAR 窗口之后插入 WAIT_STATE Response Code。

在所有 eSPI的I/O 模式（单、双、四 I/O）中的响应阶段之前，eSPI Slave不得驱动I/O[n:0]。特别是在单 I/O 模式下，Slave在响应阶段之前不得驱动 IO[1] (MISO)。它必须在TAR到期后立即驱动总线上的Response Phase，如下图所示。

——另外，可以选择允许Slave在 Turn-Around 窗口结束时（在第二个时钟的上升沿）提前半个时钟打开总线上的驱动器，以准备在随后的时钟下降沿按照eSPI协议的要求驱动Response Code； 在 Turn-Around 窗口期间，数据线将被弱上拉拉高。

3.3 Response Phase

Response Code是由 eSPI Slave驱动的，以响应 eSPI Master发起的命令；它由 ：RSP 操作码、可选标头 (HDR)、可选数据、状态和 CRC 组成。 RSP 操作码是一个 8 位字段，由Response Code和Response Modifier组成。

1. Response Code：指示请求是成功（Successful）、延迟（Deferred）、以错误响应（Responed with error）还是等待状态（Wait State）；

2. Response Modifier：为 GET_STATUS 定义的 2 bit字段，仅用于 ACCEPT 响应；对于所有响应必须始终为“00”，但 NO_RESPONSE 为“11”；

——Response Modifier指示是否将peripheral (channel 0) completion、virtual wire (channel1)数据包或flash access (channel 3) completion附加到 GET_STATUS 响应阶段；其中，flashaccess (channel 3) completion仅在支持slave attached flash sharing时适用。

——默认情况下，Response Modifier处于禁用状态；可以通过 SET_CONFIGURATION 启用，方法是将通用功能和配置寄存器中的Response Modifier Enable bit设置为“1”。

3. 当Slave驱动Response Phase时，RSP 操作码的保留 （RSV）字段必须驱动为全 0；它保留供规范将来使用，出于向后兼容的目的，保留 （RSV）字段必须被Master忽略。

3.4 Status

Status 字段占16bit的空间，用于提供来自Slave的信息，例如是否存在新挂起请求、队列（queue）是否空闲等。对于与未启用的Channel相关的状态位，或如果Channel已启用但未准备好，或与不支持的功能相关的状态位，这些位会被 eSPI Master忽略，Slave将保留的状态位驱动为“0”。

Status Field反映了当Status Field在总线事务时Slave的实时状态； AVAIL 和FREE 反映的是将这次事务中正在接收/发送的命令纳入考量后的队列状态。但是，由于收到的命令是在CS#置低后才解码的，因此如果所发送的命令（比如说SET_CONFIGURATION）是去修改queue status bit，那么这次修改将不会反映在当前事务的Status 字段中。Status 字段如果有发生变化，将由Slave通过 ALERT# 发出信号，并反映在后续事务的Status 字段中。具体定义参考eSPI总线规范 Table5：Status Field Encodings。

3.4 Alert Phase

如上所述，Alert Phase是由Slave发出的，用来向Master以请求服务；Master可以向对应的Slave发出GET_STATUS命令来查询Alert事件的原因，通过此种方式响应Slave发出的Alert。然后Master做出相应的反应以服务Slave。

Slave可能由于以下的这些原因会产生Alert事件：

1. Slave有新的服务请求：Posted，Non-Posted，Deferred Completion，Virtual Wire messages，OOB messages 或则 Flash Access服务请求；

2. 自上次状态更新返回slave buffer space为非空闲后，slave buffer space又变为空闲。

触发Alert事件的每个原因在 STATUS 寄存器中都有相应的bit位，当 STATUS 寄存器的状态与前一个Response Phase返回的 STATUS 不同时，Slave将产生一个新的Alert事件。

——STATUS 寄存器中的差异表明发生了一个新事件，从而需要Master提供服务。

下图说明了总线两侧Slave的状态寄存器的流程和跟踪的一个示例，更多栗子，具体参考eSPI总线协议。

3.5 Get Status Command

GET_STATUS 是一个独立于Channel的命令，用于查询状态寄存器的内容，状态寄存器的状态将在Response Phase返回。 此命令通常用于eSPI Master响应来自 eSPI Slave的Alert事件，以确定Alert事件的原因并随后为Slave服务。

GET_STATUS 的响应阶段允许一个peripheral （channel 0） completion，一个virtual wire（channel 1）数据包或flash access（channel 3）completion的挂起信息附加到Response[7:6]（Response Modifier）中，如上Response Modifier所示，只允许将其中一个附加到GET_STATUS 响应。附加的peripheralor flash access completion可以是对应于先前发往Slave的non-posted transaction的部分或完全完成。

3.6 Get_Configration and Set_Configration Command

SET_CONFIGURATION 和 GET_CONFIGURATION 命令是独立于Channel的命令，用于设置 eSPI Slave端的Channel能力和配置寄存器，仅支持 DWord 访问。由于没有字节使能，如果修改少于一个完整的双字，则需要软件执行读取-修改-写入访问。 SET_CONFIGURATION 和 GET_CONFIGURATION 命令永远不能被deferred，必须在同一个周期内完成。

GET_CONFIGURATION 命令用于读取 eSPI Slave上的通道能力和配置寄存器；GET_CONFIGURATION 命令阶段由一个 8 位命令操作码、一个 16 位地址和一个 8 位CRC 组成。响应阶段包括：一个 8 位响应、1 个 DW 数据、一个 16 位状态和一个 8 位CRC。如下图所示。

SET_CONFIGURATION 命令用于在 eSPI Slave上写入通道能力和配置寄存器。SET_CONFIGURATION 命令阶段由一个 8 位命令操作码、一个 16 位地址、1 个 DW 数据和一个 8 位 CRC 组成。响应阶段包括一个 8 位响应、一个 16 位状态和一个 8 位 CRC。如下图所示。

——只有eSPI Slave宣称支持的功能才可以被配置，通过 SET_CONFIGURATION 配置eSPI Slave并不支持的功能，将导致未定义的行为，这与特定实现相关，并且超出了规范的范围。

3.7 Non-Posted Transaction

Posted和Non-Posted两种事务模式，应该是借用了PCI总线上的这两种事务概念。PCIE Spec将Requester和Completer之间一次完整的信息传递过程称为事务（Transaction），一次Transaction需要进行一次或者多次数据包传送。这些事物可以分为非报告事务（Non-Posted Transaction）和报告事物（Posted Transaction）。

在PCIE结构体系中，对于Non-Posted 事务而言，Requester发送一个TLP请求数据包给Completer。稍后，Completer返回一个TLP完成数据包给请求者。IO空间的数据访问都是要求得到Devcie相应的，Memory Read也要求立即返回得到的数据，所以IO Write和Read/Memory Read都是属于Non-Posted 事务。对于Posted 事务而言，Requester发出一个TLP请求数据包给Completer，但是Completer不返回TLP完成数据包给Requester。为了提高Memory的写性能，Memory Write不需要等到上一笔的回复就可以写下去，所以Memory Write是Non-Posted 事务。（后续《PCIe总线基础》中详细介绍）

eSPI Master发起的Non-posted 事务可以终止为Connected 或 Deferred completion（延迟完成）。当数据和生成响应所需的所有信息立即可用时，eSPI Master发起的Non-posted 事务作为Connected completion而终止。 Non-posted 事务因连接而终止的有效响应包括： ACCEPT with either a successful，Unsuccessful completion，FATAL ERROR以及NONFATAL ERROR。

如果 eSPI Master发起了一笔Non-posted 事务，但是Slave无法立即回复所需的数据和信息，则Non-posted 事务以“DEFER”响应终止；而当数据或信息最终可用时，deferred completion可以在将来的某个时间段内返回。

——只要保持排序规则，总线就可以在Deferred completion返回之前用于其他transaction。

当Deferred completion返回时，唯一有效的响应是ACCEPT with either a successful 或则Unsuccessful completion。对于将因错误而终止的non-posted 事务，Slave需要以FATAL ERROR 或 NONFATAL ERROR 作为已连接响应，而且不可以Defer这笔事务。

eSPI Slave可以通过多个Connected 或Deferred split completions完成Non-posted command。有关Split completions的情况，请参考协议第 5.1.3 节。如果其中一个Split completions状态为Unsuccessful completion状态，则不会返回其余Split completions。

3.8 Posted Transaction

eSPI master 发起的posted 事务的有效响应是： ACCEPT、FATAL ERROR 和NON-FATAL ERROR。posted 事务的 DEFER 响应是无效的。

对于长度为 1、2 或 4 byte的请求，eSPI 支持从Master到Slave的Short posted transactions，这些请求具有较少的开销，因此效率更高。唯一的Opcode表示Short posted transaction和请求长度。标头仅包含地址，并且Opcode隐含了Transaction的地址字节数。

具体关于Posted和Non-Posted事务的详细介绍，请参考eSPI总线协议。

3.9 Wait Status

Wait Status的功能和协议内容同LPC类似，在响应阶段，所有 eSPI transaction都支持 eSPI Slave的 WAIT_STATE。在 2 个时钟周转 (TAR) 窗口之后，允许 eSPI Slave在以 ACCEPT、DEFER、NON-FATAL ERROR 或FATAL ERROR 终止transaction之前以 WAIT_STATE 响应代码进行响应。

eSPI Slave可以在响应阶段开始时插入一个或多个 WAIT_STATE 响应代码，直至 eSPI Master配置的最大 WAIT_STATE 值。 eSPI Master不需要检查是否接收超过最大WAIT_STATE 。 eSPI Slave有责任确保插入的 WAIT_STATE 响应代码的数量不超过允许的最大 WAIT_STATE。

WAIT_STATE 响应码提供的额外延迟为 1 个字节时间，分别对应于 Single I/O 模式下的 8 个串行时钟、Dual I/O 模式下的 4 个串行时钟或 Quad I/O 模式下的 2 个串行时钟。WAIT_STATE 响应代码不包括在 CRC 计算中，它是用与所有其他响应代码编码相比至少有 2 位差异的编码定义的， eSPI Master需要在收到 WAIT_STATE 响应代码时处理等待状态。