用于在可扩展存储器系统协议中传输包的系统及方法相关申请案的交叉参考
本申请案是主张2014年6月2日申请的标题为“用于可扩展存储器系统协议的系统
及方法(Systems and Methods for a Scalable Memory System Protocol)”的第62/006,
668号美国临时专利申请案的优先权的非临时申请案，所述美国临时专利申请案以引用的
方式并入本文中。本申请案也涉及2015年5月28日申请的标题为“用于改进存储器系统的效
率的系统及方法(Systems and Methods for Improving Efficiencies of a Memory
System)”的第14/724,558号美国专利申请案，所述美国专利申请案也以引用的方式并入本
文中。
技术领域
本发明大体上涉及一种存储器系统协议，其用于使用存储器装置执行数据操作
(例如，读取、写入)。更具体来说，本发明涉及一种基于包的可扩展协议，其启用若干存储器
及处理组合，提供位高效的数据传送操作，且所述协议与多种总线类型(例如，电总线、光学
总线)协调。
背景技术
本章节希望向读者介绍可能与本发明的各种方面相关的本领域的各种方面，所述
方面在下文中予以描述及/或主张。据信，此论述有助于为读者提供背景信息以促进更好地
理解本发明的各种方面。因此，应理解，这些陈述应在此背景下阅读且并非作为现有技术的
认可。
常规协议通常在存储器装置之间以与其前身相比相对较低的故障率传输包。然
而，因为行业旨在使在存储器装置与其它组件之间移动数据包所涉及的能量的量最小化，
期望使用使用最小量的能量高效移动数据包，同时维持包传输的完整性的协议。
附图说明
在阅读以下详细描述及在参考附图时可更好地理解本发明的各种方面，其中：
图1说明根据实施例的计算系统的实例的框图；
图2说明根据实施例的可作为图1的计算系统的部分的存储器装置的实例的框图；
图3说明根据实施例的可在图1的计算系统内传输的包的包层级图；
图4说明根据实施例的可在图1的计算系统内传输的包的详细包层级图；
图5说明根据实施例的用于为作为图2的存储器装置的部分的各种类型的存储器
指派事务窗的方法的流程图；
图6说明根据实施例的针对高延时读取操作的两阶段响应的实例；
图7说明根据实施例的针对高延时直接存储器存取操作的单阶段响应的实例；
图8说明根据实施例的其中可扩展协议将两个18位请求包封在一起的分道包封实
例；
图9说明根据实施例的用于产生包用于传输的方法的流程图；
图10说明根据实施例的描绘可根据分道包封方案传输的若干包的框图；
图11说明根据实施例的用于根据分道包封方案接收包的方法的流程图；
图12说明根据实施例的用于由接收包的组件执行的重新排序操作的方法的流程
图；
图13说明根据实施例的展示如何参考图12的方法将包重新排序的框图；
图14说明根据实施例的用于由接收包的组件执行的重新排序操作的另一方法的
流程图；
图15说明根据实施例的用于调慢从传输组件发送的请求的传输速率的方法的流
程图；
图16说明根据实施例的描绘线性调慢曲线的曲线图；及
图17说明根据实施例的描绘非线性调慢曲线的曲线图。
具体实施方式
下文将描述一或多个特定实施例。为了提供这些实施例的简洁描述，本说明书中
未描述实际实施方案的所有特征。应了解，在任何此实际实施方案的研发中，如在任何工程
或设计项目中，必须作出许多实施方案特定决策以实现可随实施方案的变化而变化的研发
者的特定目标，例如符合系统相关及业务相关的限制。此外，应了解，此研发努力可能是复
杂且耗时的，但对于受益于本发明的一般技术人员来说，所述研发努力仍将是常规设计、制
作及制造任务。
可扩展存储器系统协议
如将在下文详细论述，本发明大体上涉及可扩展存储器系统协议。即，可扩展存储
器系统协议可基于被传送的数据包(例如，请求、响应)的特性而调整某些操作。在一个实施
例中，可扩展存储器系统协议(“可扩展协议”)可为基于包的协议，其实现数据包在存储器
装置、计算装置及类似物之间的高效(例如，功率高效、位高效)传输。可扩展协议可实施为
与各种类型的存储器及处理器的若干组合，例如自动机(Automata)处理器、存储器中处理
器(Processor-in-Memory)、网络装置、存储设备、分层存储器、抽象化存储器及类似物。如
本文中所使用，处理器可包含能够在相应电装置上执行可执行指令的任何适当处理器。可
扩展协议也可促进宽范围的装置，其包含数据中心交换机/路由器、网络路由器、移动装置、
存储装置、自动机处理器、流处理器、存储器中处理器、任务移动处理器、大数据(Big
Data)、大图形(Big Graph)、安全存储器、虚拟网络、一般抽象化存储器(例如，动态随机存
取存储器(DRAM)、NAND及新兴存储器)及类似物。
在某些实施例中，可扩展协议可经设计以促进数据包在各种存储器与处理器之间
的传达，同时维持最低的合理的可扩展协议额外开销。换句话来说，可扩展协议可经设计以
提供数据包的位高效传送，其中，经由可扩展协议传送的多数(如果不是所有)位直接作为
被传输的对应数据包的部分。例如，如将在下文更详细论述，可扩展协议可使请求包能被包
封在一起而无需用与相应包无关的零填充信号，借此使经由总线的传输通道传送的数据包
的位效率最大化。
除提供用于传送数据包的位有效机构外，可扩展协议可与若干总线类型(例如电
或光学总线)协调。此外，可扩展协议可能够提供有关相应总线的各种操作，包含编码、分道
(lane)计数、通道(channel)计数、速度、风格、系统的例示计数及类似物。
可扩展协议
记住上述内容，可扩展协议可经优化以提供成功事务，使得包故障是罕见的(例
如，<1e-6)。可扩展协议也可提供包传输类型、大小与可处置的不同包大小的数目之间的仔
细权衡。
如上文论述，行业更注重使数据移动能量最小化。即，在存储器装置之间移动数据
包所消耗的能量应被最小化。因而，可扩展协议可合理地消除可从其它位或消息辨别或可
能另外是不必要的某些位及消息。举例来说，可扩展协议可免除对传输有关可能已被接收
器所知的信息的数据的装置的需要。
此外，为了提供高效的数据移动操作，可扩展协议可促进“被发送到存储器”的事
务。可扩展协议也可用外部控制操作传送局部操作，其中内部数据流量与外部控制操作相
比相对较低。此外，可扩展协议可实施错误控制策略，所述错误控制策略使用基于在相应包
中被传输的数据量(例如，有效负载)调整的动态字段大小使额外开销最小化。
可扩展协议也可经设计以使用最分数目个字段来传达数据。因而，可扩展协议可
允许字段大小调优及灵活性，这是因为每个包无法利用所有可用字段。
可扩展协议也可经设计以促进低延时数据与高延时数据的共存。举例来说，可扩
展协议可提供使低延时数据的传输在传输高延时数据之间交错的能力。
可扩展协议的设计可被特性化为简单及一般的，其中可变包大小可在相应包的单
个字段中确定。此外，可扩展协议可维持其操作方面的简单性，同时仍能够执行复杂的事务
及操作。此外，可扩展协议可足够灵活来实现其当前可能未经设计以提供的未来功能。
在某些实施例中，可扩展协议可限制使用局部排序方案发送包的顺序。即，可扩展
协议无法强制执行某些全局同步排序规则或类似物。为了坚持可扩展协议保持抽象的理
念，可扩展协议可用特殊装置或用不同类型的通道性质促进操作。
记住上述内容，本发明描述若干系统及技术，所述系统及技术可在可扩展协议内
实施以提供上述优点。虽然下文详述的某些系统或技术是相对于其它系统或技术独立描
述，但是应注意本文中描述的系统及技术中的每一者可用也在本文中描述的各种其它系统
及技术实施。
使用可扩展协议的计算系统及存储器系统
现转到图式，图1说明可采用本文中描述的各种技术及系统的计算系统10的框图。
计算系统10可为多种计算装置中的任何者，例如计算机、传呼机、蜂窝电话、个人记事簿、控
制电路等等。计算系统10可包含芯片上主机系统(SoC)12，芯片上主机系统(SoC)12可耦合
到若干存储器装置14。主机SoC 12可为集成电路(IC)，其将计算机或其它电子系统的所有
组件集成到单个芯片中。因而，主机SoC 12可包含一或多个处理器，例如微处理器，所述一
或多个处理器可控制计算系统10中的系统功能及请求的处理。
如上所述，主机SoC 12可耦合到存储器装置14。在某些实施例中，主机SoC 12可经
由通道16耦合到存储器装置14。通道16可包含总线、电布线或类似物。
图2描绘存储器装置14的实施例的框图。存储器装置14可包含经设计以留存数字
数据的任何存储装置。存储器装置14可涵盖各种各样的存储器组件，其包含易失性存储器
及非易失性存储器。易失性存储器可包含动态随机存取存储器(DRAM)及/或静态随机存取
存储器(SRAM)。此外，易失性存储器可包含若干存储器模块，例如单列直插存储器模块
(SIMM)或双列直插存储器模块(DIMM)。
非易失性存储器可包含将结合易失性存储器使用的只读存储器(ROM)，例如EPROM
及/或快闪存储器(例如，NAND)。此外，非易失性存储器可包含高容量存储器，例如磁带或磁
盘驱动存储器。如将了解，易失性存储器或非易失性存储器可被视为用于存储代码(例如，
指令)的非暂时性有形机器可读媒体。
如图2中所展示，在某些实施例中，存储器装置14可包含芯片上系统(SoC)22，芯片
上系统(SoC)22可为任何适当处理器，例如存储器中处理器(PIM)或计算机处理器(CPU)，其
紧紧地耦合到存储于存储器装置14上的存储器组件。通常，存储器SoC 22可与存储器装置
14的存储器组件处在相同硅芯片上。通过将处理组件及存储器组件合并到存储器装置14
中，存储器SoC 22可管理在存储器组件与主机SoC 12之间传输及接收数据请求及响应的方
式。在某些实施例中，存储器SoC 22可控制存储器组件之间的业务以减小延时及增大带宽。
如将了解，在根据本文中描述的实施例控制存储器组件与其它装置之间的传输时，主机SoC
12及存储器SoC 22可采用可扩展存储器系统协议。因而，可扩展存储器系统协议可在存储
器装置14与主机SoC 12之间的通道16，以及在存储器组件与存储器SoC 22之间的通道29上
操作。
在某些实施例中，存储器装置14也可包含缓冲器23。缓冲器23可存储由存储器SoC
22接收的一或多个包。有关存储器SoC 22可如何使用缓冲器23的额外细节将在下文参考图
15到17进行描述。举例来说，存储器装置14可包含例如NAND存储器24、减小延时动态随机存
取存储器(RLDRAM)26、双倍数据速率第四代同步动态随机存取存储器(DDR4)28及类似物的
存储器类型。
在某些实施例中，主机SoC 12及存储器SoC 22可基于经由存储器组件、寄存器及
类似物提供的计算机可执行指令执行各种操作。存储器组件或存储装置可为可充当用于存
储存储器可执行代码、数据或类似物的媒体的任何适当制品。这些制品可代表计算机可读
媒体(即，任何适当形式的存储器或存储装置)，所述计算机可读媒体可存储由主机SoC 12
或存储器SoC 22使用来执行当前揭示技术的处理器可执行代码。存储器及存储装置也可用
于存储数据、数据分析及类似物。存储器及存储装置可代表非暂时性计算机可读媒体(即，
任何适当形式的存储器或存储装置)，所述非暂时性计算机可读媒体可存储由主机SoC 12
或存储器SoC 22使用来执行本文中描述的各种技术的处理器可执行代码。应注意，非暂时
性仅指示媒体是有形的且并非是信号。
虽然有关可扩展协议的各种方面的以下描述在本文中被描述为相对于主机SoC
12及存储器SoC 22执行，但是应注意，本文中描述的所有系统及技术可使用任何适当装置
执行。即，可扩展协议可促进任何两个装置之间的通信，例如两个处理器、两个存储器模块、
处理器与存储器模块及类似物之间的通信。
可扩展协议中的包的包层级图
为了在传输涉及存储器组件的请求及响应时采用可扩展存储器系统协议，存储器
SoC 22可发送根据图3中所说明的包30的包层级图构成的数据的包。如图3中所展示，包30
可包含事务类型字段32、有效负载字段34及错误控制代码(ECC)字段36。事务类型字段32可
包含指示传输类型、被传输的包的类型或两者的数据。事务类型字段32也可指示用于指示
数据有效负载中位的数目及ECC字段中位的数目的包大小，借此指示整个包中位的数目。在
某些实施例中，事务类型字段32可以间接方式指示有效负载字段34及ECC字段36的大小。举
例来说，存储于事务类型字段32中的数据可充当查找表的索引。查找表可提供有关有效负
载字段34及ECC字段36的大小的信息。因而，在一个实例中，存储器SoC 22可接收包30且将
存储于事务类型字段32中的数据用作可存储于存储器装置14中的查找表的索引，以确定有
效负载字段34及ECC字段36的大小。
在某些实施例中，事务类型字段32可基于包是在可包含通道16、通道29或类似物
的请求总线Q或响应总线S上传输而指定不同类型的包。通常，请求总线Q及响应总线S可为
单独的、单向的或共同输入/输出。请求总线Q大体上包含q个分道，且响应总线S大体上包含
s个分道。
在请求总线Q上传输的包30的实例事务类型字段32可包含读取操作(例如，
8uRead、8uRead2、varRead，其中u可为8位单元或9位单元或可能为数据的非整数单元大
小)、消息数据(例如，消息)、读取-修改-写入(RMW)操作(例如，RMW1A、RMW2A、RMW3A、
RMW4A)、数据集(例如，32uData、64uData、128uData、256uData)、模式写入操作(例如，
8uPatternWrite、16uPatternWrite)、写入启用操作(例如，8uWriteWithEnables、
16uWriteWithEnables)，写入操作(例如，8uWrite、16uWrite、32Write、48uWrite、64Write、
80uWrite、96uWrite、112uWrite、128Write、256Write)及类似物。提供32Write操作及
64Write操作可为系统设计者在挑选最大包大小时提供更大灵活性。在一个实施例中，可扩
展协议可具有256Unit的限值，但使用较小最大包大小可帮助系统延时。应理解，32uWrite
与32Write之间的差异在于32uWrite是单个固定大小，且TransactionSize未包含于包中。
另一方面，32Write包含TransactionSize，且因此可涉及额外32U数据块，而非仅在原始请
求包中包含的32U块。注意上文针对请求总线Q所列的事务类型实例，经由请求总线Q传输的
包30可包含总共26个原生事务(例如，8uRead、消息、RMW1A等等)，其中的每一者可使用针对
全局(即，包含许多CPU模块及/或许多存储器装置模块的系统，其中包可在单元之间被中
继)或局部系统(即，包含较少模块的系统，其中包在单元之间点到点移动，而无中继)的5位
字段表示。因而，在一个实施例中，请求总线Q上的包30的事务类型字段32可为5个位。
以相同方式，在响应总线S上传输的包30的实例事务类型字段32可包含消息数据
(例如，消息)、数据集(例如，8uData、16uData、32uData、48uData、64uData、80uData、
96uData、112uData、128uData、256uData)及类似物。此外，注意上文针对响应总线S的所列
事务类型实例，经由响应总线S传输的包30可包含总共11个原生事务(例如，消息、8uData等
等)，其中的每一者可使用针对局部系统的4位或5位字段表示。因而，在一个实施例中，响应
总线S上的包30的事务类型字段32可为4个位。
由于26个请求总线Q事务类型及11个响应总线S事务类型包含5个相同事务类型
(例如，消息、128uData、256uData)，所以由请求总线Q及响应总线S使用的事务类型的总数
目可为32个。这32个事务类型因此可在5位字段中予以表示。有关事务类型的额外细节将在
下文进一步论述。
再次参考图3，包30也可包含有效负载字段34及错误控制代码(ECC)字段36。如上
所述，有效负载字段34及ECC字段36的相应大小可基于事务类型字段32中的数据确定。举例
来说，有效负载字段34可近似在45个位与2093个位之间，且ECC字段36可近似在6个位与37
个位之间。有效负载字段34可包含代表分别经由请求总线或响应总线发送的请求或响应的
数据。
ECC字段36可包含用于确定由接收组件接收的包30是否包含任何错误的错误控制
代码。因而，错误控制代码可包含各种算法，例如将冗余数据或校验数据添加到消息，使得
即使当在传输的过程期间或在存储器上引入若干错误时，原始数据仍可由接收组件恢复。
通常，错误控制代码可提供检测代码的限值内的错误且当检测到错误时，指示进一步行动
(例如重新传输出错包)的能力。
事务类型字段
如上所述，可扩展协议可使用具有事务类型字段的包以更有效地执行各种类型的
操作。通常，可扩展协议可使抽象化存储器架构能利用任何存储器类型及并入使用单个抽
象化协议的各种类型的数据处理。记住这点，事务类型字段32可为一条有用的数据以允许
可扩展协议执行各种类型的数据处理，这是因为事务类型字段32提供两条不同的信息。即，
为了协议中的最小可能位计数占用，事务类型字段32将两个数据字段(即，类型及大小)组
合成一个。
如下文将展示，可扩展协议可为了传输效率而支持可变大小包。因而，向接收组件
指示包的大小以防止系统变得不同步可能是有用的。在此，事务类型字段32可提供单个字
段，所述单个字段识别被执行的系统事务的类型且可凭借事务类型隐式地定义包大小。换
句话来说，事务类型字段32可指示被传输组件请求的事务的类型且接收组件可接着基于指
定的事务类型确定对应包的大小(例如，有效负载字段34及ECC字段36)。因而，事务类型字
段32可为双重目的字段，其被可扩展协议用于提供传达信息的位有效方式。
在某些实施例中，事务类型字段32也可指示有关可在有效负载字段34中提供的数
据的额外信息。例如，基于事务类型字段32的值，事务窗信息(窗)、地址信息(地址)、间接层
级(层级)信息、消息类型信息、原始数据及其它类型的信息可被确定为有效负载字段34的
部分。有关可作为有效负载字段34的部分的信息的细节将在下文更详细论述。
可扩展协议可在具有一或多个请求总线Q事务及一或多个响应总线S事务的系统
中采用。虽然请求总线Q及响应总线S已在上文被描述为分别具有5位字段及4位字段，但是
应注意，请求总线Q及响应总线S可被设计为具有多种不同的位大小。举例来说，请求总线Q
事务可使用5位字段(例如，00000、00001、…、11110、11111)指示，使得可与5位字段相关联
的可能事务类型如下(其中数据单元u大小是8个位)：
01011-8uRead-8B数据读取操作，提供额外字段(例如，有效负载字段34内的子字
段)：Window、Address、Levels(间接层级)
01101-varRead-可变数据大小读取操作，提供额外字段：TransactionSize、
Window、Address、Levels
00000-消息-一般消息，提供额外字段Window、MessageType、Data(数据仅受限于
字段大小，例如，Nack消息类型的数据可包含DataSequence、
OriginatingTransactionType、OriginatingWindow)
01110-RMW1A-读取-修改-写入请求，其中并入单个地址，提供额外字段：
TransactionSize、Window、Address、OpCode、ImmediateData
01100-8uRead2-两个8B数据读取操作，提供额外字段：First_Window、First_
Address、First_Levels、Second_Levels、Second_Address
10110-8uWrite-包含8B数据的写入请求，提供额外字段：Window、Address、
Levels、8B数据
10010-8uWriteP-包含将写入一次或更多次的8B数据的写入请求，提供额外字段：
Window、Address、TransactionSize、Levels、8B数据
01111-RMW2A-读取-修改-写入请求，其中并入两个地址，提供额外字段：
TransactionSize、First_Window、First_Address、OpCode、ImmediateData、Second_
Window、Second_Address
10100-8uWriteEn-用WriteEnableBits及8B数据写入，提供额外字段：Window、
Address、Levels、8启用位、8B数据
10000-RMW3A-读取-修改-写入请求，其中并入三个地址，提供额外字段：
TransactionSize、First_Window、First_Address、OpCode、ImmediateData、Second_
Window、Second_Address、Third_Window、Third_Address
10111-16uWrite-包含16B数据的写入请求，提供额外字段：Window、Address、
Levels、16B数据
10011-16uWriteP-包含将写入一次或更多次的16B数据的写入请求，提供额外字
段：Window、Address、TransactionSize、Levels、16B数据
10101-16uWriteEn-用WriteEnableBits及16B数据写入，提供额外字段：Window、
Address、Levels、16启用位、16B数据
10001-RMW4A-读取-修改-写入请求，其中并入四个地址，提供额外字段：
TransactionSize、First_Window、First_Address、OpCode、ImmediateData、Second_
Window、Second_Address、Third_Window、Third_Address、Fourth_Window、Fourth_Address
00011-32uData-扩展数据包，提供额外字段：Window、32B数据。注意，数据序列号
未被显式传输，这是因为扩展数据包按顺序传输，因此接收器可附加序列。如果需要随后
NACK，那么隐式序列号被用作参考。
11000-32Write-包含32B数据的写入请求，提供额外字段：Window、Address、
Levels，32B数据，TransactionSize
11001-48uWrite-包含48B数据的写入请求，提供额外字段：Window、Address、
Levels，48B数据
00101-64uData-扩展数据包，提供额外字段：Window、64B数据。注意，数据序列号
未被显式传输，这是因为扩展数据包按顺序传输，因此接收器可附加序列。如果需要随后
NACK，那么隐式序列号被用作参考。
11010-64Write-包含64B数据的写入请求，提供额外字段：Window、Address、
Levels、64B数据、TransactionSize
11011-80uWrite-包含80B数据的写入请求，提供额外字段：Window、Address、
Levels、80B数据
11100-96uWrite-包含96B数据的写入请求，提供额外字段：Window、Address、
Levels、96B数据
11101-112uWrite-包含112B数据的写入请求，提供额外字段：Window、Address、
Levels、112B数据
01001-128uData-扩展数据包，提供额外字段：Window、128B数据。注意，数据序列
号未被显式传输，这是因为扩展数据包按顺序传输，因此接收器可附加序列。如果需要随后
NACK，那么隐式序列号被用作参考。
11110-128Write-包含128B数据的写入请求，提供额外字段：Window、Address、
Levels、128B数据、TransactionSize
01010-256uData-扩展数据包，提供额外字段：Window、256B数据。注意，数据序列
号未被显式传输，这是因为扩展数据包按顺序传输，因此接收器可附加序列。如果需要随后
NACK，那么隐式序列号被用作参考。
11111-256Write-包含256B数据的写入请求，提供额外字段：Window、Address、
Levels、256B数据、TransactionSize
所列实例事务类型按随后的包大小的顺序提供(不含任何无意的排序错误)，假设
5位事务类型、4位事务类型、3位窗、48位地址、7位数据序列号及针对每一事务类型具体说
明的数据字段中的额外位。此外，如上所述，包30可包含ECC字段36，其如在常规协议中可为
固定大小。然而，如将了解，在某些实施例中，ECC字段36可为可变大小，如将在下文更详细
论述。
记住上述内容，响应总线S事务可使用4位字段(例如，0000、0001、…、1110、1111)
指示。然而，如果事务类型字段32是5个位，那么事务类型字段32可简单包含额外前补零。响
应总线S事务的实例4位事务类型可包含：
0000-消息-一般消息，提供额外字段：Window、MessageType、Data(注意，存在许多
消息类型，例如Completion、ReOrder、NACK及其它)
0001-8uData-8B数据响应，提供额外字段：Window、8B数据
0010-16uData-16B数据响应，提供额外字段：Window、16B数据
0011-32uData-32B数据响应，提供额外字段：Window、32B数据
0100-48uData-48B数据响应，提供额外字段：Window、48B数据
0101-64uData-64B数据响应，提供额外字段：Window、64B数据
0110-80uData-80B数据响应，提供额外字段：Window、80B数据
0111-96uData-96B数据响应，提供额外字段：Window、96B数据
1000-112uData-112B数据响应，提供额外字段：Window、112B数据
1001-128uData-128B数据响应，提供额外字段：Window、128B数据
1010-256uData-256B数据响应，提供额外字段：Window、256B数据
如同上文针对请求总线Q事务所列的实例事务类型，上文的实例响应总线S事务按
随后的包大小的顺序列出，假设请求总线Q上的5位事务类型，响应总线S上的4位事务类型，
4位事务大小，3位窗，48位地址，7位数据序列号及针对每一事务类型具体说明的数据字段
中的额外位。
如上所展示，每一事务类型可取决于个别字段大小假设而与不同长度包相关联。
因此，可扩展协议可避免使用额外字段来指示包大小。相反地，在具有8位微片(flit)的协
议中，请求总线Q包的微片计数将为事务类型的顺序，如下：8、8、9、11、13、16、16、17、18、21、
24、25、26、27、41、57、73、89、105、121、132、138、260、266。此协议可接着包含包大小字段，其
大小可为9个位以指示每一包的微片计数。替代地，包大小字段大小可为5个位以区分24个
不同长度中的每一者，且接着可使用转换函数确定准确微片计数。与常规协议不同，可扩展
协议可能不采用包大小字段。而是，系统可使用转换函数以基于事务类型确定包的大小，且
可接着保存协议位。
事务窗
除提供有关错误控制代码的经改进位效率外，可扩展协议可根据其相应事务类型
组织包，且基于其相应事务类型根据特定顺序传输经组织包。在常规协议中，请求可根据其
被传输的时间来排序。在此情况中，如果第一请求涉及高延时，且后续请求(即，第二请求)
涉及低延时，那么即使第二请求可能比第一请求更快地完成，第二请求仍可能必须等待第
一请求结束。因此，第一请求可阻塞总线。换句话来说，即使低延时请求可能比较高延时请
求更快地被解析，第一请求仍可阻止总线响应于相对较低延时请求。
为了提供在总线内混合不同类型的事务请求的更高效方式，可扩展协议可使用事
务窗来确定请求被送达的顺序。事务窗可为使用虚拟地址空间实施的虚拟通道。每一事务
窗可与相应存储器装置相关联，例如NAND及DRAM。因而，单个事务窗可与一个存储器或具有
相同特性(例如延时、带宽、粒度、持久性及类似特性)的若干存储器相关联。
通常，事务窗可提供有关针对每一特定事务的一组特定接合规则的信息。如上所
述，事务窗数据可指定用于针对特定事务传输及接收包的物理总线的一组分道(例如，通道
29)。由事务窗指定的所述组分道可被称作虚拟通道，其可由存储器装置14存取。应注意，本
文中描述的通道29包含其中可传送数据的一或多个分道。使用事务窗数据来特性化有关包
的传输或接收的某些特征(例如，排序)，可扩展协议可更好地管理包在处理器之间的传输。
例如，由于每一类型的存储器装置具有不同的延时，所以基于相应存储器装置的
相应延时管理总线业务在各种类型的存储器装置14与主机SoC 12之间的流动可能是有利
的。举例来说，DRAM装置通常具有快延时(例如，来自随机请求的50ns)，而NAND装置通常具
有慢延时(例如，500us)，其在随机请求之后进行错误校正。SRAM缓冲器具有10ns的较快延
时。记住这点，可扩展协议可指定每一存储器装置的事务窗。在一个实施例中，可扩展协议
可使用两个字段来指定每一事务窗：48位地址及3位窗(即，对窗0到7寻址)。图4说明描绘指
定包30中的事务窗的两个字段的框图。如图4中所展示，事务窗字段42及地址窗字段44可为
有效负载字段34的部分。事务窗字段42可指定指定的事务窗，且地址窗字段44可指定与指
定的事务窗相关联的48位地址。48位地址可为指派给虚拟通道(即，窗)的虚拟地址。在一个
实施例中，虚拟地址空间可指代定位在硬盘驱动器或某种其它存储装置上的物理地址。因
而，存储器装置可具有存储比物理可用的数据更多的数据的能力。
除事务窗字段42及地址窗字段44外，包可包含起始位46及间接层级字段48。起始
位46可指示位流中包的开始。间接层级字段48可为有效负载字段34的部分，且可提供指示
相应事务可包含的间接层级数目的值。有关起始位字段46及间接层级字段48的额外细节将
在下文的其它章节中予以更详细论述。
通常，每一类型的存储器装置可被指派给不同的事务窗。举例来说，DRAM0可被指
派给Window0中，DRAM1可被指派给Window1中，DRAM2可被指派给Window2中，NAND0可被指派
给Window3中，NAND1可被指派给Window4中，且SRAM缓冲器及控制寄存器可被指派给
Window7中。记住这点，实例事务集合可根据以下序列发送：
(1)Read.Window0.AddressA
(2)Read.Window3.AddressB
(3)Read.Window0.AddressC
(4)Read.Window0.AddressD
(5)Read.Window0.AddressE
(6)Read.Window0.AddressF
(7)Read.Window3.AddressG
(8)Read.Window0.AddressH
(9)Read.Window0.AddressI
如上所展示，事务1、3到6、8及9是Window0的部分，其对应于DRAM存储器装置。另一
方面，事务2及7是Window3的部分，其对应于NAND存储器装置。在接收到上述请求时，接收组
件可使用根据针对每一事务指定的相应事务窗建立的排序规则响应于接收到的请求。因
而，接收组件可使用事务窗来提供传输组件与接收组件之间的局部排序协议。
在一个实施例中，针对特定事务窗指定的排序规则可为基于与相应事务窗相关联
的相应延时。即，在响应于具有较长延时的请求之前，接收组件可首先响应于涉及较低延时
的请求。由于接收组件可能知道每一事务窗之间的延时差异，所以接收组件可根据其窗指
定决定接收事务。因而，再次参考上文描述的实例事务，实施可扩展协议的接收组件可响应
于上述请求如下：
(1)Data.Window0.AddressA
(3)Data.Window0.AddressC
(4)Data.Window0.AddressD
(5)Data.Window0.AddressE
(6)Data.Window0.AddressF
(8)Data.Window0.AddressH
(9)Data.Window0.AddressI
(2)Data.Window3.AddressB
(7)Data.Window3.AddressG
如上所展示，在响应于Window3的较高延时请求之前，接收组件可首先响应于
Window0的低延时请求。即，长延时请求可比短延时请求迟传输。因此，送达请求的系统总线
不受阻于相同总线上不同类别的存储器的存在，而不增加各种周密的协议复杂性，例如为
字段增加请求优先级(REQUEST PRIORITY)。以此方式，可扩展协议以相对简单方式提供使
用最小数目个位的复杂系统操作。
在另一实例中，接收组件可基于针对每一事务指定的对应事务窗采用局部排序方
案。对于以下事务：
(1)Read8b.Window1.AddressA
(2)Read8b.Window2.AddressB
(3)Read8b.Window1.AddressC
接收组件可首先接收事务(1)且确定AddressA是否可用。如果AddressA较忙，那么
接收组件可将事务(1)存储于队列中且等待AddressA变为可用。同时，接收组件可接着接收
事务(2)，且在AddressB可用的情况下执行读取操作。接收组件可接着接收事务(3)，且由于
其和事务(1)与相同的窗相关联，所以接收组件可确定是否存在有关在事务(1)前执行事务
(3)的任何排序冲突，这是因为其是相同事务窗的部分。以相同方式，接收组件可忽略与事
务(2)的任何潜在的排序冲突或任何潜在排序冲突的确定，这是因为其是不同事务窗的部
分。因而，事务窗可提供在不同事务被执行的同时执行数据操作的更高效方式。即，由于事
务窗允许操作与相关操作或存储器装置逻辑分组在一起，所以操作可按多种顺序执行，借
此提供完成事务的灵活方式。相比之下，常规协议通常强制根据事务被发送的顺序执行数
据操作的严格顺序，即使不同事务可按多种顺序执行，或可基于含有在专门的协议字段中
发送的优先级信息而处理事务。
在一个实施例中，可扩展协议可提供为每一窗指派最小事务大小的能力(例如，
Window0.Size＝8字节、Window3.Size＝128B)。举例来说，如果Window0的最小传送大小是8
个字节，那么针对48b地址字段，Window0可存储2^48*8个字节＝～2.25x1015个字节。以相同
方式，如果Window3的最小传送大小是128个字节，那么Window3可支持～3.6x1016个字节。因
而，Window0及Window3两者支持明显比地址空间暗示的字节更多的字节。
与事务窗相关联的另一特征包含其它空间(例如Window0SRAM及系统控制寄存器)
的简单系统层级可寻址性，而不在协议中创建额外命令。即，SRAM及系统控制寄存器可通过
简单使用Window0而寻址。另一方面，先前协议可使用额外命令(例如register.read及
register.write)以与这些类型的存储器交互。在针对这些存储器类型指定事务窗的情况
下，用于其它存储器装置的相同读取及写入命令也可用于SRAM及系统控制寄存器。即，读取
及写入命令可简单指向合适的窗。因而，可扩展协议可采用更少命令，借此减少协议中所使
用的位的数目。
通过根据事务类型组织数据事务，多个事务窗可提供对相同存储器类型的多个存
取途径。举例来说，典型的DDR3DRAM可包含八个库，且内部总线可包含八个此类DRAM。记住
这点，八个DRAM可经组织，使得Window1表示八个DDR3DRAM的群组的库0且Window2提供对此
相同群组的库1的存取。以此方式，每一窗可指定每一DRAM的特定虚拟地址空间。记住这点，
明显可获得若干适当的分组方法，这是因为可能存在在锁步(lock-step)操作中分组的任
何数目个DRAM，其各自具有页、库及等级。以相同方式，NAND也可用页、平面及块分组。此外，
多通道装置可依据通道及其各种聚合进一步分离。通常，分组选项可基于逻辑芯片设计的
复杂性确定。
通过支持具有多个虚拟地址空间及虚拟通道的多个事务窗，可扩展协议可使用事
务窗来在含具有不同延时的存储器的系统中建立可预测的数据排序。因此，可扩展协议可
支持高优先级请求及低优先级请求，而无指定高优先级请求及低优先级请求如何排序的显
式协议字段。
记住上述内容，图5说明用于为作为存储器装置14的部分的各种类型的存储器指
派事务窗的方法50的流程图。虽然方法50按特定顺序描绘，但是应注意，方法50可按任何适
当顺序执行，且因此不限于图中描绘的顺序。另外，为了论述目的，方法50的以下描述将被
描述为由存储器SoC 22执行。因而，可以通信方式耦合到各种类型的存储器的任何适当处
理器可执行方法50中描述的操作。
现参考图5，在框52处，存储器SoC 22可接收来自存储于存储器SoC 22本身内的寄
存器或其它存储器组件的初始化信号。在一个实施例中，初始化信号可在通电时或在存储
器装置14初次接收电力时由存储器SoC 22接收。
在框54处，存储器SoC 22可确定其能够存取的存储器类型。即，存储器SoC 22可扫
描其通信分道(例如，通道29)，且识别可能可以通信方式耦合到存储器SoC 22的不同类型
的存储器。重新参考图2中描绘的实例存储器装置14，存储器SoC 22可确定RLDRAM 26、DDR4
28及NAND 24存储器类型耦合到存储器SoC 22。
在框56处，存储器SoC 22可确定在框54处识别的存储器类型中的每一者的能力。
存储器类型的能力可包含存储器类型的容量、使用存储器类型的读取操作的预期延时、使
用存储器类型的写入操作的预期延时及类似能力。可由存储器SoC 22识别用于指派事务窗
的其它能力可包含读取延时、写入延时、带宽、最小读取事务大小、最小写入事务大小、装置
循环时间、可就地写入与否、字节写入能力与否及类似能力。在某些实施例中，每一不同类
型的存储器可与不同组能力相关联。不同类型的存储器与所述不同组的能力之间的关联性
可被存储于存储器SoC 22的寄存器中或可由每一相应存储器类型提供。
在确定存储器类型的能力后，存储器SoC 22可在框58处基于每一存储器类型的相
应能力将事务窗指派给在框54处识别的每一存储器类型。通常，存储器SoC 22可将每一类
似存储器类型指派给相同事务窗。即，由于每一类似存储器类型具有类似能力，所以存储器
SoC 22可将存储器类型指派给相同事务窗。举例来说，再次参考图2的实例存储器装置14，
存储器SoC 22可将两个DDR4 28存储器指派给相同事务窗，这是因为其是相同的存储器类
型。以相同方式，如果两个不同的存储器类型具有特定数目的类似能力，那么存储器SoC 22
也可将两个存储器类型指派给相同事务窗。
在一个实施例中，存储器SoC 22可基于存储器SoC 22的期望操作将存储器类型指
派给对应事务窗。例如，如果存储器SoC 22期望所有读取操作都具有至少特定延时，那么存
储器SoC 22可将每一经识别存储器类型指派给满足此延时阈值的第一事务窗中，或指派给
不满足此延时阈值的第二事务窗中。
在将事务窗指派给每一经识别存储器类型之后，存储器SoC 22可继续进行到框
60，将每一事务窗的性质存储于存储装置中。存储装置可包含能够存储数据的任何适当装
置。因而，存储装置可包含局部寄存器、表或某种其它信息存储单元。以此方式，存储器SoC
22可根据如上所描述的排序规则针对每一存储器类型执行操作。在一些情况中，所存储性
质可详述每一事务窗的特定能力连同有关每一事务窗的操作的其它相关信息。
可编程的间接层级数目
虽然包30已在上文中被描述为具有事务类型字段32、有效负载字段34及ECC字段
36，但是在某些实施例中，可扩展协议可将其它任选字段包含到包30中以调节请求，例如读
取、写入、移动、读取-修改-写入及类似物。一种此状况可包含指示应用到请求的间接层级
数目。
间接层级可指示请求与所请求数据之间的指针的数目。鉴于在计算系统中可用的
巨量数据(例如大数据)，数据通常经由多个表索引且被存储于一个位置中。即，在大数据系
统中，针对特定数据集的请求可包含指向第二指针(例如，链路列表)的指针，所述第二指针
指向第三指针，等等。最后，指针序列中的最后指针可指向所请求数据集的地址。每一指针
到指针链路可被称作间接层级。通过每一间接层级识别所请求数据集的过程通常被称作
“指针追逐(pointer chasing)”。
从请求组件的角度来看，请求组件可最初用第一指针发送针对特定数据集的请
求。响应于具有第一指针的请求，请求组件可接收第二指针。因而，请求组件可接着用第二
指针发送针对特定数据集的第二请求。此过程可继续直到请求组件接收到特定数据集。相
应地，请求总线Q上的业务可涉及在实际接收由一个单个初始请求请求的数据集前的多个
请求。
为了减少有关各种间接层级类型请求的总线业务量，可扩展协议可在专用集成电
路(ASIC)、存储器SoC 22、主机SoC 12或实施可扩展协议的类似物的设计内指定请求组件
在实际接收所请求数据之前可接收的指针数目的指示。因而，实施可扩展协议的存储器系
统可识别原始请求与数据的位置之间的指针链，且可基于来自请求组件的初始请求将请求
送达到所请求数据。即，一个请求(其涉及来自请求组件的任何数目个间接层级)可致使接
收包含所请求数据的仅一个响应。
记住这点，指示间接层级数目的任选字段可包含2个位。在一个实施例中，二进制
00可指示无间接层级或请求中的所供应地址是期望操作数的实际地址。二进制01可指示1
个间接层级或由请求内的地址指定的位置处的数据实际上是指针的地址(例如，最后地
址)，且期望操作数地址含在所述指针中。举例来说，在具有1个间接层级的读取请求中，由
请求组件执行的实际功能可首先包含读取请求中所含的地址的内容。在此实例中，地址的
内容可为Address2。实施可扩展协议的存储器系统可接着读取Address2的存储器位置处的
内容，且Address2的存储器位置的内容被供应为读取请求的结果。
以相同方式，二进制10可指示2个间接层级。在此，所供应地址可指向Address2，所
述Address2可为指针。即，Address2可包含指向Address3的指针。Address3处的数据内容可
接着被供应到请求组件作为读取请求的结果。
二进制11可指示3个间接层级。因而，所供应地址可指向Address2，Address2可指
向Address3，Address3可指向Address4，Address4可包含数据内容。实施可扩展协议的存储
器系统可将数据内容提供到请求组件作为读取请求的结果。
在写入请求的实例中，由实施可扩展协议的存储器系统执行的过程可与所描述的
读取实例相同。例如，在间接层级字段被设置为二进制11的情况下，存储器系统可通过首先
读取写入请求的地址(例如，Address2)而执行写入操作。在知道间接层级字段是11的情况
下，存储器系统可继续读取Address2的内容，所述内容可涉及Address3。存储器系统可接着
读取Address3的内容，所述内容可涉及Address4。存储器系统可接着将写入请求的数据写
入到Address4的存储器中。因而，在此实例中，写入请求可包含写入之前的3个读取，但3个
读取中的每一者由单个写入请求起始。虽然间接字段已被描述为具有两个位，但是应注意，
间接字段可包含任何数目个位以指示任何数目的间接层级。
如上所述，间接层级可在有效负载字段34的间接层级字段48内指定，如图4中所说
明。间接层级字段48内指定的间接层级数目对应于存储器系统在检索存储器位置的内容时
可预期遭遇的间接层级数目。
在一个实施例中，由间接层级字段48使用的位的数目(例如，大小)可基于由主机
SoC 12提供的优先级确定。例如，在通电时，主机SoC 12可发现存储器SoC 22且使用本文中
描述的可扩展协议确定存储器SoC 22正在操作。因而，主机SoC 12可确定其在不损及其性
能的情况下，可能能够适应的间接层级的最大数目。间接层级的最大数目可基于主机SoC
12的写入及/或读取延时或主机SoC 12的其它操作参数确定。如果例如主机SoC 12确定间
接层级的最大数目为3，那么其可指定存储器SoC 22将2位字段用作间接层级字段48。在一
些实例中，主机SoC 12可能无有关涉及任何数目个间接层级的操作的优先级。在此情况中，
主机SoC 12可指定存储器SoC 22不包含间接层级字段48。
在准备包30用于传输时，存储器SoC 22可确定包30被传输的原因。因而，存储器
SoC 22可确定什么软件命令用于包30的传送。产生包的软件命令可例如对应于查找指针的
指针的命令。存储器SoC 22可将此命令解译为具有两个间接层级，且因此可在准备包30用
于传输时在间接层级字段48中提供10二进制值。
间接层级可用于各种类型的操作。举例来说，任意维度的数组可在不增加不必要
的业务到相应总线的情况下，使用间接层级来协助请求组件识别其相应请求的内容。例如，
3维数组可使用三个指针来存取数据。一些经界定结构的记录可使用指针。此记录的一个实
例可包含具有针对列表中的每个结构的首指针及尾指针的链路列表。对于链路列表，间接
层级的抽象化可使链路列表的解析能更高效地发生。即，通过知道开始的地址及所请求数
据位于作为列表的第8个元素或涉及8个间接层级的目的地处，存储器系统可使用由请求组
件提供的单个请求检索所请求数据或列表的第8个元素。在此，存储器系统可解析8个间接
层级中的每一者以确定所请求数据的位置。在识别所请求数据的位置时，存储器系统可为
请求组件提供所请求数据，因此将总线业务限于来自请求组件的一个请求及来自所请求数
据的位置的一个响应。
不应答接收到的包
用于减小总线业务的另一技术可包含不应答接收到的包。即，在常规协议中，已被
接受组件接收的每一包可将应答包发送回到传输组件。由于绝大多数被传输包由对应的接
受组件接收，所以发送应答包可能增加相应总线上的业务，而不提供太多益处。
例如，如果响应于接收到每个成功包而发送应答位，且考虑传输具有在非常高速
的接口中常见的1e-12的位错误率(BER)，那么大量不必要位被传输来指示每一包已被接
收。记住这点，且假设平均包包含100个位，且平均包错误率为大约1e-10，那么接受组件可
传输指示1x1010个包的成功的应答位及指示错误的1个包。有效地，接受组件可能已发送大
约1x1010个位来指示一个错误。
为了减少在总线内流动的位的数量，接受组件可不针对每个接收到的包发送应答
包。而是，传输组件可假设所发送的包已被接收，除非接受组件另外通知。在图6及图7中说
明未针对每一接收到的包发送应答包的实例。参考图6，请求总线Q可发送2千字节的读取请
求。在接收到读取请求时，响应总线S可传输指示2KB消息已准备好用于读取的包。请求总线
Q可接着重新传输读取请求，其可导致响应总线S在不同包中发送所请求数据。如图6中所展
示，在接收到数据的每一包时，请求总线Q不发送指示包被成功接收的应答包。在此，由于请
求总线Q可用高延时读取操作进行操作，所以响应总线S可包含两个操作阶段。即，响应总线
S可指示消息已准备好，且接着响应总线S可发送有关读取请求的对应数据。
以相同方式，高延时直接存储器存取子系统可针对各种写入操作采用单阶段响
应。例如，图7说明其中读取-修改-写入请求在请求总线Q上传输且用读取-修改-写入请求
完成的消息响应的实例。
记住上述内容，接受组件仍可接收具有错误的包。因而，接受组件可通过发送NOT_
ACKNOWLEDGE包到传输组件而通知传输组件包尚未被接收或接收到的包含有错误。除指示
被发送包尚未被接收外，NOT_ACKNOWLEDGE包可指示最新的已知良好的总线事务。因而，当
经由ECC子系统检测到错误时，具有错误的包应被重新传输。接受组件可识别最新的成功总
线事务的传输组件作为参考，而使得重新传输可发生。
在某些实施例中，可扩展协议可使用4个相关字段来向传输组件指示最后已知良
好的总线事务的标识符。相关字段包含窗、地址、事务及任选数据序列号。这四个字段可识
别系统中的任何请求/响应。在某些实施例中，额外ECC字段可用于检测传输中的错误(例
如，被保证检测传输包中1个、2个、3个、4个或5个随机错误的存在的代码，也被称作HD6码，
如将在下文更详细描述)。
在检测到错误时，接受组件可发送NOT_ACKNOWLEDGE消息到传输组件。此包的大小
可为许多可能的字段大小。例如，NOT_ACKNOWLEDGE消息可为4位事务类型、3位窗、48位地
址、7位数据序列号及5位原始事务类型，总共67个位。接着，可添加15位ECC字段，由此使总
数变为82个位。重新参考上述实例，82个位显著低于用于指示1x1010个包中的一个错误而发
送的1x1010个位，且因此是指示地址错误包的更高效方式。应注意，上述数据序列号可识别
错误包。有关数据序列号及其可如何产生的额外细节将在下文参考图12到14论述。
在检测到系统中的错误时，传输器组件应重新发送数据。然而，由于在检测错误时
存在一定延时，所以在接受组件确定错误存在于接收到的包中之前，传输组件可能已传输
其它包。由于可扩展协议包含使用上文描述的数据包封技术发送的可变包大小，所以先前
传输错误可能导致接受组件具有错的包长度，且因此误译含错误的包之后的每个数据包。
因而，接收组件可向传输组件指示到接受组件的最新的已知良好的总线事务的标识符。传
输组件及接收组件可接着返回到错误的包已被接收的点且阻止任何动作在潜在错误包及
其后的包上发生。
归因于涉及最后已知良好的总线事务的此规则，接受组件可准确地向传输组件指
示重新传输可能发生的正确点。然而，当不存在良好事务(例如，从通电或复位不成功开始
的第一事务)时，接受组件可并入上述规则的一个例外。在此情况中，接受组件可用0填入所
有字段，使得系统的所有组件将0的字段解译为“第一事务”。
如上所述，可扩展协议可包含任选的数据序列号字段。此字段可支持期望比由协
议支持的最大响应包大的事务。举例来说，考虑窗中的最小事务为128个字节及指定事务的
大小的被称作大小(Size)的另一字段，总事务大小可被确定为2^Size*
windowMinTransactionSize。如果大小是3位字段，那么最大事务可为2^7*128＝16,384个
字节。为了防止任何总线被一个请求占用太长时间，由协议支持的最大单个包可为128B的
数据。因此，16,384字节事务可由每一128B的128个数据包满足。在一个实施例中，任选的数
据序列号字段可包含7个位，其涉及此128个数据包中的任一个。以此方式，如果NOT_
ACKNOWLEDGE消息发布，那么NOT_ACKNOWLEDGE消息可正确地识别传输变为不成功的精确
点。在另一实施例中，与2N字节相比，针对TransactionSize 0到15的8B的最小
TransactionSize可为8个字节、16个字节、32个字节、48个字节、64个字节、80个字节、96个
字节、112个字节及128个字节以节省下限的位。
数据包封
记住上述内容，为了提供灵活的通信总线，可扩展协议可在使用任何类型的总线
通信传输包时采用数据包装技术。通常，由于包大小是基于被发送的请求或响应的类型、被
发送的数据、被请求的操作等等而确定，所以在知道有关包的更多细节前可能难以预期使
用什么类型的数据通道。因而，可扩展协议可经设计以通过在不如常规协议所做用零填充
每一个别包的情况下，通过将被传输数据包包封在一起而使可用通道的使用最大化。如本
文中使用，术语“不填充”意味着在数据包传输之间，零(即，具有零值的位)未跨越相应通道
传输。而是，准备好被传输的下一调度包将在紧接在前一个包被传输之后的时钟循环上传
输。
举例来说，考虑包含10个信号分道的请求总线Q及包含8个信号分道的响应总线S。
本实例假设不存在数据编码且事务仅包含简单位传输(即，无符号传输)。如果Q总线上的占
用大小是：4.3、7.3、9.7、13.5、14.3、14.9、20.0、20.1、21.6、33.0、36.2、58.8、65.2、105.4、
110.5及123.0，那么常规协议可填充具有与其相关联的分数分量的值。即，常规协议可将零
添加到每一分数值的其余部分，使得Q总线上的占用的大小分别变为5、8、10、14、15、15、20、
21、22、33、37、59、66、106、111及123。在一些情况中，可将多达9个零添加到传输，其可能不
利地影响总总线利用效率，这是因为被传输的零并非真实代表被传输的数据。以此方式，这
些零利用总线而不传达信息，由此减小总线利用效率。
在一个实施例中，取代填充被传输数据，可扩展协议可允许请求被包封在一起。总
线信号因此无填充的零。举例来说，图8说明其中可扩展协议将两个18位请求包封在一起的
分道包封实例61。参考图8，可扩展协议可将传输视为符号而非位。在图8的实例中，一个位
可代表一个符号。由于图8中的总线62包含12个分道(即，可在一个微片中传输12个位)，所
以可扩展协议可通过将请求包封在一起而传输两个18位请求。即，第二18位请求66可紧接
在第一18位请求64之后传输。因而，传输总线不含废位(例如，填充的零)。
在某些实施例中，为了保证接收组件可识别被包封在通道中的新包的起始，传输
组件可用起始位起始每一新包30，所述起始位可在起始位字段46中指定，如上所述。因而，
当接收组件接收到位流形式的被包封数据包时，其可基于何时检测到起始位而识别每一包
的起始。记住这点，被传输的每一包可包含起始位(例如，1值)以指示新包的存在。以此方
式，当接收组件接收到被包封在一起的包时，其可识别每一新包的开始，基于事务类型字段
32确定包的事务类型，基于事务窗字段42确定事务窗，基于地址字段44确定操作的地址，基
于间接层级字段48确定间接层级数目及基于ECC字段36确定错误校验代码。
记住这点，图9说明用于产生包用于传输，使得包可使用上文描述的分道包封方案
传输的方法70的流程图。为论述的目的，方法70的以下描述将被论述为由存储器SoC 22
(即，传输/请求组件)执行，但应理解，作为存储器装置14的部分的任何处理器可执行方法
70中描述的操作。
现参考图9，在框72处，存储器SoC 22可接收将被传输的数据操作的指示。数据操
作可包含将被发送的消息、读取操作、写入操作或类似操作。在框74处，存储器SoC 22可识
别对应于数据操作的事务类型。在某些实施例中，请求数据操作被执行的软件可指定事务
类型。替代地，存储器SoC 22可接收来自软件的命令且从可由存储器SoC 22本地存取的查
找表或存储单元确定对应事务类型。即，存储器SoC 22可咨询查找表，所述查找表可包含根
据可被请求的若干可能的数据操作索引的若干事务类型。
在框76处，存储器SoC 22可基于与所请求数据操作相关联的存储器类型确定事务
窗。即，存储器SoC 22可确定在执行数据操作时什么类型的存储器将被存取，且使用查找表
或类似物基于存储器的类型确定相应事务窗。除事务窗外，存储器SoC 22可确定存储器地
址，所述地址指代有关数据操作及事务窗的数据的位置。举例来说，针对读取操作，地址可
指代将从指定存储器读取的数据的位置。
在框78处，存储器SoC 22可确定对应于所请求数据操作的间接层级数目。如上文
论述，间接层级数目可由数据操作本身或由请求执行数据操作的软件指定。
在框80处，存储器SoC 22可针对包30产生错误控制代码(ECC)值。ECC值可被接收
组件用于保证包30在无错误的情况下被接收。因而，存储器SoC 22可首先确定合适的错误
控制代码(ECC)算法来用于对包30编码。在一个实施例中，请求传输的软件应用程序可指定
ECC来进行算法使用。替代地，主机SoC 12或存储器SoC 22可指定特定ECC算法以用于对所
有被传输及被接收的包编码及解码。在任何情况中，包30的ECC值可基于在事务类型字段32
及有效负载字段34中提供的位而确定。
在确定表示上述事务类型、事务窗、间接层级数目及ECC值的位值后，存储器SoC
22可在框82处根据在框72、74、76及80处确定的值产生包30。在产生包30时，存储器SoC 22
可最初针对起始位字段46提供1以向接收组件指示新包正被传输。在将1插入起始位字段46
后，存储器SoC 22可提供代表在74处于事务类型字段32中识别的事务类型的值。
存储器SoC 22可接着使用在框76处确定的事务窗及地址及在框78处确定的间接
层级数目产生包30的有效负载字段34。即，存储器SoC 22可在事务类型字段32后输入事务
窗值，且将事务窗值输入事务窗字段42中。存储器SoC 22可接着将数据操作的地址输入地
址字段44中及将间接层级数目输入间接层级字段48中。
在包30产生后，存储器SoC 22可在框84处取决于包30的目的地而经由通道16、通
道29或类似物传输包30。在所产生包30被传输后，存储器SoC 22可继续进行到框86且确定
下一待传输包是否已准备好用于传输。通常，用于传输的下一包可根据上文关于框72到82
描述的过程产生。如果下一包已准备好用于传输，那么存储器SoC 22可再次继续进行到框
84，且紧接在先前包被传输之后传输下一包。通过紧接在另一包被传输之后传输每一随后
包，存储器SoC 22可根据包封通道方案传输包，这不涉及在未利用总线的所有通道时在总
线上填充零。
为了更好地说明可如何根据包封通道方案传输数据包，图10说明可根据本文中描
述的包封分道方案传输的若干包。如图10中所展示，在总线62上传输的第一包92包含起始
位(1)、针对事务类型字段32的5个位、针对有效负载字段34的45个位及针对ECC字段36的6
个位。在第一包94被传输之后，立即在总线62上传输第二包94。因而，在位时间3处的位分道
9中，紧接在第一包92的ECC字段36的最后位之后，存在起始位(1)。此外，其余位分道(即，位
分道10到15)包含与第二包94相关联的数据。
与其它包传输方案相比，总线62无位分道填充有零或不用于包的传输。即，在其它
包传输方案中，由于第一包92仅占据可用的16个位分道中的9个，所以其余位分道(即，位分
道10到15)将填充零，且第二包94将在位时间4处开始被传输。以此方式，存储器SoC 22可将
用于发送包的总线的效率最大化。
应注意，仍存在当存储器SoC 22仍可在发送包之间传输零的实例。例如，重新参考
图9的框86，如果下一包未准备好用于传输，那么存储器SoC 22可继续进行到框88，且在下
一可用位分道中传输零。即，由于总线62连续操作，所以存储器SoC 22可能无法使总线62停
止运作，且因此可在总线62上传输零，直到下一包准备好用于传输。因而，在存储器SoC 22
在下一可用位分道中沿着总线传输零后，存储器SoC 22可返回到框86，且再次确定下一包
是否准备好用于传输。此案例也在图10中进行了说明。
再次参考图10，在第二包94被传输后，存储器SoC 22可能未使另一包准备好用于
传输。因而，在位时间8处，存储器SoC 22可开始传输零，直到第三包96准备好用于传输。因
而，存储器SoC 22可在位时间8处在位分道6到15上传输零，直到第三包96在位时间9处准备
好用于传输。为了保证接收组件不会将填充在总线中的零误译为数据，接收组件可连续接
收来自存储器SoC 22的位且确定有效包在接收下一包的一个位或起始位后被传输。
在某些实施例中，如果另一包未准备好用于传输，那么存储器SoC 22可将总线62
断电，直到下一包准备好用于传输。在此情况中，存储器SoC 22可在总线62未用于传输包时
节省用于给总线62供电的能量。
为了说明使用分道包封方案传输包的效率，提出以下实例。10分道总线上的传输
序列可包含以下总线活动：73个位，接着652个位，接着73个位，接着652个位。此4个请求的
群组包含总共1450个位，其包含总线上刚好145个信号间隔(被正式称作单位间隔或UI)而
无废位。UI可指代一个定时群组的数据，其包含特定数目个位。例如，在8位总线或8分道链
路上，经由8分道链路传输的数据的一个微片可对应于一个微片。一个微片接着可被称作一
个UI，其包含8位的数据。因而，UI可用于评估总线被利用的效率。即，通过将包位计数(其包
含StartBit、事务类型字段32、有效负载字段34及ECC字段36)除以8b的总线宽度而计算包
的UI占用。因而，如果8分道链路用于发送6位的数据，那么UI是0.75(6/8)。
记住上述内容，下文提出的实例假设以下状况是存在的：ECC汉明距离(Hamming
Distance)3；事务类型字段32包含请求总线Q及响应总线S两者上的5个位；
dataSequenceNumber是7个位；8位单元大小；4位transactionSize；3位窗；48位地址；2位
levelsOfIndirection；24位RMWopcode+数据；4位消息类型。在这些设置大小假设下，可能
出现在响应总线S上的11个样本事务类型可包含79b、83b、144b、273b、401b、530b、658b、
786b、914b、1043b及2067b的包大小。这些包大小包含事务类型字段32、有效负载字段34及
ECC字段36，但不含上述StartBit。在常规8b总线中，零填充将被添加以使每一包高到偶数
8b边界，且将无需StartBit。因而，用于在添加零填充后传输这11个事务类型的总线微片的
数目或单位间隔的数目将分别为10(79/8)、11(83/8)、18(144/8)、35(273/8)、51(401/8)、
67(530/8)、83(658/8)、99(786/8)、115(914/8)、131(1043/8)及259(2067/8)。即，对于79个
位的第一包，一个零将被填充到包的最后8个位上，使得10个8分道链路将被用于发送79位
包。
然而，使用本文中描述的技术，例如添加StartBit及将响应包封在一起，用于传输
相同包的UI数目分别是10(80/8)、10.5(84/8)、18.125(145/8)、34.25(274/8)、50.25(402/
8)、66.375(531/8)、82.375(659/8)、98.375(787/8)、114.375(915/8)、130.5(1044/8)及
258.5(2068/8)。因而，针对随机选择的包大小的平均节省是每个事务0.5UI，因此位节省随
分道数目增加而增大。此实例指示请求总线Q或响应总线S的任何宽度，不管其是两个总线
上的相等还是不相等宽度。为了使可扩展协议能如上文描述那样包封分道，主机SoC 12或
任何其它接收器可使用以下传输/接收方案：接收包30；解析包30的内容以识别事务类型、
有效负载的大小及ECC字段36在包30内的位置；基于ECC验证包30的正确性，及接着确定地
作用于传输。
以此方式，接收到的传输包在其内容被解析之前可整体被捕获于接收器缓冲器
(例如，缓冲器23)中。此外，接收器可能不使用接收到的包，除非包被验证为无错误。缓冲器
23可被操作为先进先出(FIFO)，其具有在检测到传输错误的情况下选择性清空的额外能
力。可扩展协议可包含可变位长度能力，其用于将数据拉出缓冲器23，且用于包位移位。如
上文参考图3论述，包30的开始可包含事务类型字段32，其可基于事务类型字段32中所指示
的事务类型指定包大小。因而，事务类型字段32包含可扩展协议可用于确定包大小(其包含
包30内ECC字段36的大小及相对位置)的信息。在ECC被校验后，采用可扩展协议的接收器可
确定包30是否无错误。如果包被认为无错误，那么接收器可知道事务类型被适当地编码且
包大小被正确地解译。接收器可接着继续进行到紧接在最新解析包之后接收的下一包。此
可扩展协议可结合任何总线变动使用，无论是全双工或半双工，不管大小、长度、编码/解码
方法及类似物。在接收组件接收到根据通道包封方案包封的包后发生的过程的额外细节将
在下文参考图11论述。
为了参考，可扩展协议可包含长度变化的传输。即，在请求总线Q上，可扩展协议可
使用16个不同长度。举例来说，请求总线可包含43、73、97、135、143、149、200、201、216、330、
362、588、652、1054、1105及1230的长度位计数，其中无填充以形成任何特定优化长度，例如
全为8的增量或类似物。以相同方式，响应总线S可包含8个不同长度，例如33、42、85、101、
167、297、555及1069的长度位计数，再次无填充。
解析包以用于数据包封
如上所述，可扩展协议可经设计以促进最大位效率。因而，在某些实施例中，包30
可具有任意大小，其未对应于所利用物理总线的整数倍。任意大小包的传输通过将包紧实
地包封在一起而维持位效率，使得每一后继包紧接在前一包之后被传输，而不用零填充任
一包。然而，为了使接收器(例如，主机SoC 12)确定第一包在何处结束及第二包在何处开
始，接收器可实施本文中描述的用于解析接收到的包的某些技术。在某些实施例中，可扩展
协议可指定接收器对接收到的包所采用的解析方法。此解析方法可包含移位操作、错误检
测及缓冲器管理作为在系统实施方案中所利用的逻辑操作的头部处的管线操作。
记住上述内容，下文描述进入方向上单向的8个位及在外出方向上8个位的物理总
线的实例(全双工)以阐明解析方法的某些方面。在此实例中，一个微片被视为存在于总线
上的数据的一个单位间隔。即，一个微片可包含经由总线传送的8位数据。此外，具有地址
36b、窗3b及59位的汉明密度(HD6)错误涵盖率的最小包可包含5位事务类型、41位数据有效
负载及13位ECC。假设经类似设置大小的小包的无限流可被包封在一起，不留位间隙，传输
可反映以下序列，针对被传输的第一包，从分道0开始，且行进到分道7：(name.0表示那个字
段的位0)
第二包可接着被设置为从微片8，分道3开始，如下：
第三包可接着在微片16，分道6中开始，如下：
记住上文说明的三个实例包，传入位一旦被接收器接收，就可被放置到接收FIFO
中。由于在上文实例中，存在8个分道，所以位可一次移动8个。然而，由于传入总线可能极快
(例如，太快而无法循环FIFO)，所以FIFO也可被制作为显著较宽，且数据可被连续发送到
FIFO的每一连续8b宽度，直到到达最后的宽度单元。此时，FIFO地址根据通常FIFO操作递
增，且填充在FIFO分道0到7处再次开始，接着8到15等等，直到再次接收到最后的宽度单元。
这允许较慢逻辑跟上非常快的串行化器/解串行化器(SERDES)组件(例如，40Gb/s SERDES
具有25ps的单位间隔)。如果使用2GHz的逻辑时钟，那么FIFO可为20x8位分道宽度或160位
宽。因而，ECC逻辑可使用针对每一块的XOR门自然内建于160位块中(例如，块0过程位0到
159，块1过程位160到319等等，使得ECC块的总数可为14个，其中每一ECC块可包含2-输入
XOR栅极的不同互连)。
由于上文描述的三个包中的每一者被连续传输，且由于位到达接收器不包含任何
帧化信息，所以由接收电路(例如，主机SoC 12)负责首先确定包的长度，使得包可被适当地
帧化。再次参考上文实例，接收器可首先接收可立即从FIFO获得的160位值。在上文描述的
特定实例中，整个第一包驻留在那个160位区内。
如上所述，包30的第一部分可包含指示包30的开始的起始位字段46。包30的下一
部分可包含事务类型字段32，事务类型字段32可包含0到31的值。事务类型字段32的值可用
于索引指示数据有效负载的大小及ECC的大小(按位计)的表。在某些实施例中，接收器可出
于相同目的使用简单逻辑函数。虽然未立即知道所有接收到的位是无错误的，但是接收器
可初步假设其将使用事务类型字段32中指定的事务类型。接收器可接着在管线阶段中校验
ECC以确定接收到的包是否是无错误的。在一个实施例中，为了校验ECC，事务类型字段32的
事务类型及有效负载字段34的有效负载可在ECC块中被检验，使得传入ECC位被提供到所有
ECC块。在一个实施例中，ECC块可使用例如采用汉明距离算法的可扩展错误控制代码算法
校验ECC。举例来说，ECC块可采用具有6的汉明距离(HD6)的错误控制代码算法。因而，ECC块
可提供59位的错误涵盖率(5b TransactionType、41b数据有效负载、13b ECC)。即，ECC块可
提供59个已知正确位。有关可扩展错误控制算法及使用汉明距离的算法的额外细节将在下
文更详细描述。
在接收器验证包是无错误后，接收器可接着确定地知道事务类型值是正确的，且
因此接收器可具有接收到的包的适当帧化。59个已知正确位可接着被转发到下一管线阶段
用于进一步包处理(即，确定所作出的精确请求且处理所述请求)。在确定59位第一包是正
确后，及在转发59位第一包用于进一步处理后，接收器可接着使160位宽FIFO的其余101个
位桶形移位以对准到位0，且重复上述过程。
在一些情况中，接收器可能具有太少可用于解析的数据(即，从事务类型字段32到
有效负载字段34及ECC字段36的所有事物应可用)。在此，接收器可继续提取信息直到其都
可用。虽然大包可能超过单个160位区段，但是由于接收器从事务类型知道ECC在何处起始
及结束，所以接收器可将ECC位转发到合适的ECC逻辑块。此外，由于事务类型是在包的标头
处，所以接收器容易地知道查找其。此外，接收器可确定有效负载字段34包含事务类型字段
32与ECC字段36之间的所有事物。在识别有效负载字段34时，接收器可将数据有效负载发送
到合适的ECC逻辑块。在某些实施例中，取代物理MOVE，ECC逻辑可取决于物理布局优化使用
而就地实施于暂时存储数据的寄存器位处。
上文描述的技术的优点包含支持错误消息的快速产生。因而，如果ECC检测到错
误，那么逻辑信号被传递到外出队列管理器，且错误消息被公式化且在合适的通道上传输。
记住上述内容，图11说明可由根据上述分道包封方案接收包的接收组件(例如，主
机SoC 12)采用的方法100的流程图。虽然方法100的以下描述被描述为由主机SoC 12执行，
但是应注意，方法100可由任何适当接收组件执行，所述接收组件接收已根据本文中描述的
实施例予以分道包封的包。
现参考图11，在框102处，主机SoC 12可经由总线62、通道16或类似物接收位流。如
图10中描绘，主机SoC 12可基于在总线62上可用的位分道的数目一次接收若干位。
在接收到位流时，在框104处，主机SoC 12可识别新包的起始位。因而，主机SoC 12
可监测位流，直到其接收到1。举例来说，在位时间0处，主机SoC 12可检测起始位且开始解
析第一包92。
在框106处，主机SoC 12可基于起始位后的五个位确定第一包92的事务类型。如上
文论述，主机SoC 12可使用查找表或咨询存储于本地存储组件中的密匙以基于在事务类型
字段32中接收的二进制值确定与第一包92相关联的事务类型。
在确定相应包的对应事务类型后，在框108处，主机SoC 12可识别相应包的有效负
载字段34及ECC字段36。即，相应包的事务类型可向主机SoC 12指示有效负载字段34及ECC
字段36中预期的位数目。因而，主机SoC 12可将事务类型字段32后的第一数目个位指定为
有效负载字段34，且将有效负载字段34后的第二数目个位指定为ECC字段36。
在接收包的ECC字段36后，主机SoC 12可在框110处基于ECC字段36中提供的数据
验证接收到的包是否无错误。即，主机SoC 12可使用ECC字段36中提供的数据以校验在事务
类型字段32中提供的数据及在有效负载字段34中提供的数据的准确性。
在框112处，主机SoC 12可确定相应包是否是无错误。如果主机SoC 12验证相应包
是无错误，那么主机SoC 12返回到框102且继续接收位流。然而，如果主机SoC 12确定相应
包并非无错误，那么主机SoC 12可继续进行到框114，且将NOT_ACKNOWLEDGE包发送回到传
输相应包的组件。如上文论述，NOT_ACKNOWLEDGE包可指示最新的已知良好的总线事务。因
而，NOT_ACKNOWLEDGE包可指示最新成功接收到的包的事务类型及地址。由于传输组件知道
每一包被传输的顺序，所以传输包可接着紧接在在NOT_ACKNOWLEDGE包中涉及的包之后重
新发送包。
为了保证传输器组件能够在接收到NOT_ACKNOWLEDGE包时重新发送特定数目个
包，在某些实施例中，传输组件无法将所发送包从其缓冲器忽略、删除、擦除或写入，直到在
相应包已被传递后已过去特定时间量。换句话来说，在包已被传输后，传输组件(例如，存储
器SoC 22)可在其将被传输包从其缓冲器组件删除前等待特定时间量。
传输组件在传输每一包之后、在将其从其缓冲器中删除之前可等待的时间量可随
包的不同而变化。由于每一包可包含不同数目个位，所以传输包及作为响应接收NOT_
ACKNOWLEDGE包所涉及的时间量可针对每一包而不同。通常，传输组件可等待的时间量可取
决于包跨越总线62传输的最坏情况滞后时间，接收组件检测到包上的错误的最坏情况滞后
时间及传输组件接收NOT_ACKNOWLEDGMENT包的最坏情况滞后时间。上述每一情况的最坏情
况滞后时间可基于操作被执行的预期时间及通过将预期时间的某一百分比添加到预期时
间以在预期时间计算中提供错误裕度而确定。
确定上文描述的各种操作被执行的预期时间所涉及的一些因素包含被传输包的
大小、请求总线Q及响应总线S上分道的数目、将跨越每一总线传输的数据的UI的时间量、在
接收组件验证接收到的包是无错误之前在接收组件中预期的管线延迟数目、传输组件中队
列的最大深度、有关用于发送紧急消息(例如，是被放置在队列前方的紧急消息)的传输组
件的政策的信息及类似物。应注意，上文所列因素被提供作为实例，且不限制可用于确定各
种操作被执行的预期时间的因素的范围。
数据重新排序操作
虽然事务窗可用于指示给定事务窗的顺序，但是在一些实例中，根据相应事务窗
的顺序执行事务操作可能是非所要的。举例来说，DRAM可能涉及刷新操作，其不可被其它
DRAM操作延缓。另一实例可包含当NAND存储器可能置乱数据以准备用于擦除操作。在此，如
果事务操作正试图存取相同范围的地址，那么与被置乱的数据相关联的地址范围可能暂时
不可用。因而，可扩展协议将操作重新排序而不管根据事务窗的指定顺序可为有利的。
在常规系统中，使用各种技术来允许排序。例如，系统可用请求操作发送事务识
别。响应操作可接着包含相同的事务识别。事务识别可为8个位，其意味着用每个请求发送
额外8个位，且再用每个响应发送额外8个位。因而，有关请求总线Q及响应总线S两者上的额
外开销位与未用每个请求及响应发送事务识别相比可能相对较大。
记住上述内容，在某些实施例中，可扩展协议可保持根据事务窗指定的顺序，直到
确定在重新排序的情况下，可更有效地执行事务操作为止。一旦可扩展协议(例如，接收组
件)作出此确定，其即可发送重新排序消息，所述重新排序消息将新的相对顺序赋予给特定
事务区。所述事务区可包含被发送的所有事务操作的子集。在接收到重新排序消息时，传输
组件可根据由重新排序消息提供的新相对顺序对事务操作重新排序。新相对顺序可指示其
中每一事务操作可相对于被执行的其它事务操作执行的顺序。包含经重新排序事务操作的
相应事务区可接着维持新顺序直到被另外重新排序。
如上所述，接收组件可在期望背离自然响应序列时发送数据重新排序消息。在一
个实施例中，接收组件可基于事务类型字段32中指示的事务类型确定重新排序可能是优选
的。即，事务类型字段32可固有地指示重新排序是优选的。伴随事务类型字段32的可能是64
位消息，其包含16x4位顺序识别符。如果存在16个待决响应，那么这些标识符可指示接下去
的16个响应的顺序。
当在正常流量下操作时，接收组件可按根据给定事务窗的命令的顺序传输响应。
当接收组件确定将接收到的请求重新排序可能是优选时，接收组件可等待直到可能保持有
序的所有响应在发送重新排序消息前首先被发送。如果系统期望按0、1、2、3、4、5、6、7、8、9、
10、11、12、13、14及15的序列的下一群组的响应，那么重新排序消息可改变那个序列内的任
何事项。举例来说，1、2、3、4、5、6、7、0、8、9、10、11、12、13、14、及15的新顺序可能是优选的，
使得每一值用相应4位值表示。如果存在少于16个待决响应，那么不存在的未来响应可按顺
序列出。即，再次参考上文实例，如果0到7是待决的，且响应0优选被延迟直到所有其它之
后，那么位8到15的顺序可在最后保持，只要0在所有其它之后被提供。
在一个实施例中，重新排序消息可在新排序是优选的任何时间被发送。再次参考
上文实例，如果响应按1、2、3、4、5、6、7及0的顺序被发送，且接着确定其余项目无法按预期
顺序发送，那么可发送新的重新排序消息。在此，紧跟的下一响应将是响应0，非响应8，这是
因为顺序计数器在重新排序消息被发送的任何时间被复位为零。因而，在发送新的重新排
序消息时，0到15的新相对顺序可根据最有利的排序确定。在无任何重新排序消息的情况
下，所有数据可为每个窗接收的请求的“自然”顺序。在任何情况中，通过在未定期传输请求
识别或响应识别的情况下在系统中支持数据重新排序，可扩展协议可节省另外在常规协议
中使用的大量额外开销。
记住上述内容，图12说明可由接收组件(例如，主机SoC 12)用于与包希望被传输
组件(例如，存储器SoC 22)传输的原始顺序相比较，将待传输到接收组件的包重新排序的
方法120的流程图。方法120的下列描述将参考图13的图式140论述。图式140被提供来帮助
说明在方法120的各种阶段发生的操作。出于论述的目的，方法120的以下描述将被描述为
由主机SoC 12执行，但应理解，任何适当接收组件可执行本文中描述的操作。
首先参考图12，在框122处，主机SoC 12可接收来自传输组件(例如，存储器SoC
22)的若干包。接收到的包可大体上包含被请求由主机SoC 12按优选顺序执行的操作。传输
组件(例如，存储器SoC 22)可按特定顺序发送对应于数据操作的包，其可反映操作的优选
顺序。图13的图式140说明由主机SoC 12按行142接收的包的实例原始顺序。如图13中所展
示，由传输组件传输的十个包可初始被编号为1到10。
在框124处，主机SoC 12可确定接收到的包中所指示的操作是否应按不同顺序执
行。即，举例来说，如果主机SoC 12出于一些原因而无法执行特定操作(例如，被请求存储器
地址忙、不可用等等)，那么主机SoC 12可代替地在执行前一个请求操作之前执行后一操
作。如果主机SoC 12确定操作不应按不同顺序执行，那么主机SoC 12可进行到框126，且按
优选顺序执行接收到的包的操作(例如，如由传输组件传输)。
如果主机SoC 12确定操作不应按优选顺序执行，那么在框128处，主机SoC 12可确
定新顺序来执行所请求操作。为了按不同顺序执行操作，主机SoC 12可识别对应于无法按
所请求顺序执行的操作的特定包。主机SoC 12可接着确定任何随后操作是否取决于所识别
操作的结果。即，主机SoC 12可确定在稍后时间执行所识别操作是否可能导致将执行的任
何其余操作中的错误。在某些实施例中，主机SoC 12可评估每一包的事务窗以确定操作是
否可被重新排序。例如，如果具有事务窗的顺序是如下：Win2、Win2、Win2、Win3、Win3、Win2
及Win3，那么主机SoC 12可延迟第三Win2请求以执行第一Win3请求，这是因为其涉及不同
事务窗，且因此可能在不同存储器类型上操作。使用每一包的事务窗，主机SoC 12可接着确
定新顺序来执行所请求操作。
在确定新顺序以执行操作后，在框130处，主机SoC 12可将在紧接着与所识别操作
对应的包之前的包后接收到的若干包重新命名。在一个实施例中，主机SoC 12可根据其在
队列中的当前位置将包重新命名。例如，再次参考图13，如果主机SoC 12将原始包5识别为
含有应在稍后时间执行的操作的包，那么主机SoC 12可根据其在队列中的当前位置将包4
之后的包重新命名。因而，包5到10可被重新命名为包0到5，如图式140的行144中所说明。以
此方式，其余包可根据其在队列中的相对位置重新命名。
在将其余包重新命名后，在框132处，主机SoC 12可产生重新排序消息，所述重新
排序消息可指示其中其余包将由主机SoC 12寻址或根据将由主机SoC 12执行的对应操作
的顺序寻址的新顺序。重新排序消息可基于在框128处确定的新顺序及根据如在框130中提
供的经重新命名包确定。例如，再次参考图13中的实例，如果主机SoC 12确定原始第5个包
操作应在原始第7个包操作后执行，那么重新排序消息可被呈现为1、2、3、0、4、5，如行146中
所展示。行146根据经重新命名包指示新操作顺序。为说明目的，行148指示重新排序消息指
定其余包操作将根据其原始包编号的顺序。
在框134处，主机SoC 12可将重新排序消息传输到传输组件。因而，传输组件可使
用重新排序消息来调整从主机SoC 12传输的响应包与相应请求包相关联的顺序。即，传输
组件可根据重新排序消息中所指示的经重新命名相对顺序关联在重新排序消息之后接收
到的每一响应包。
通过将对应于最后实施操作的包之后的包重新命名，主机SoC 12可将参考顺序提
供到传输组件，所述顺序是相对于将由传输组件接收的其余响应包而言。因而，由于主机
SoC 12及传输组件可能知道包已被发送的顺序，所以根据其相对顺序重新命名的包使主机
SoC 12能关联响应包，而无需用每一包发送包识别号，借此提供更具有位效率的通信方案。
在存在多个请求及响应总线的情况中，可扩展协议可确定事务操作被执行的顺
序，如下。如果存在与4个相应响应总线相关联的4个请求总线，那么相关联的一对请求及响
应总线可由可扩展协议命名为通道。因而，在一个实施例中，事务操作可被定义为
“channel.window.address”。在此，排序可接着被定义为
“channel.window.dataSequenceNumber”。通常，仅一个数据可为事务操作的部分，使得对
于比最大所支持包大小大的事务请求，保存数据序列号通常是不重要的。否则，可扩展协议
可遵循channel.window内的排序。即使当两个通道使用相同窗时，可扩展协议可能仍无法
在它们之间并入任何排序。而是，可扩展协议可提供每一channel.window组合内的顺序。因
此，可扩展协议可极大简化系统的操作，这是因为通道具有异步定时相互关系的可能性。通
过根据channel.window将事务操作排序，可扩展协议使排序保持简单，且也减小可执行的
仲裁的次数。此外，此排序技术也可减小已被另外发送的重新排序消息的数目。
数据重新排序操作-高频率
虽然可扩展协议已被描述为能够提供事务操作被发送的新相对顺序，但是可能难
以将此类型的重新排序方案并入可具有高频率的重新排序请求的大型系统中。即，如果按
某一高频率(即，高于某一阈值)发送重新排序消息，那么可能不再有效地使用时间及资源
来发送重新排序消息及将事务操作重新排序。换句话来说，对于一些类型的系统，数据重新
排序的频率可能变得太高使得传输组件与接收组件之间的通信量可能变得低效。对于此类
系统，即使当大量重新排序事件是优选的时，可扩展协议仍可减小事务识别的位业务。
在一个实施例中，接收组件可确定当前重新排序技术是否在低效地操作。例如，传
输组件可确定从接收组件接收重新排序消息的频率。如果频率高于某一阈值，那么传输组
件可确定当前重新排序方案在低效地操作。此时，传输组件可附加每一事务操作的每一事
务识别(ID)以包含新的字段：请求总线Q序列号。由于接收组件可能知道请求被接收的顺
序，那么接收组件可指派循环序列号到每一接收到的请求(即，请求总线Q序列号Qsequence
或Qseq)。请求总线Q序列号可应用于每一请求的相应通道及相应窗的组合。因而，请求总线
Q序列号可被标注为“channel.window.Qseq”，使得Qseq可针对每一相应通道及相应窗按循
环顺序指派，由此通过不传输已知数据而保留带宽。例如，如果请求顺序(都在通道0上)是
如下：Win2、Win2、Win2、Win3、Win3、Win2及Win3，且这些是第一事务，那么由接收器附加的
所指派Qseq号码将分别是：0、1、2、0、1、3及2。即，每一窗可基于每一类型(即，通道/窗)的请
求的接收而与循环Qseq序列相关联。
在接收请求后及当计划在响应总线S上发送响应时，接收组件可用其对应Qseq值
标记每一相应响应。因而，传输组件可将每一接收到的响应与其相应请求相关联。如上所展
示，上文描述的技术避免在请求总线Q上传输Qseq值。通过不在Q总线上发送Qseq值，可扩展
协议提供提供位有效传送的额外方式。
记住这点，图14说明用于将由接收组件执行的操作重新排序的方法160。此外，如
上文关于方法120所述，下列方法160将被描述为由主机SoC 12执行。然而，应理解，以下方
法160可由任何适当接收组件执行。
现在参考图14，在框162处，主机SoC 12可确定在某一时间周期内传输到传输组件
的重新排序消息的数目是否超过某一阈值。阈值可与存储器装置14的下降性能、在执行操
作时涉及的平均循环数目、针对每一所请求操作的平均队列深度或类似物相关。
如果重新排序请求的数目不大于阈值，那么主机SoC 12可继续根据上文描述的方
法120发送重新排序消息。但是，如果主机SoC 12确定重新排序请求的数目大于阈值，那么
主机SoC 12继续进行到框164。在框164处，主机SoC 12可根据每一包的事务窗以循环方式
添加序列值到每一接收到的包。传输组件可存储其中每一包已被传输的顺序，使得传输的
顺序可对应于其中每一包被接收的顺序。
在框166处，主机SoC 12可按其相应操作已被执行的顺序发送响应包。响应包可包
含在框164处添加到接收到的包的序列值。由于传输组件知道每一包已被发送的顺序，所以
其可使用添加的序列值来将响应包施加于合适的请求包。与将序列号保持于两个传输上相
比，在使用方法160来传输响应包的情况下，主机SoC 12及传输组件可添加序列号到跨越总
线62传输一次的包。以此方式，可扩展协议可通过利用传输组件所知道的信息(例如包被传
输的顺序)而提供位高效数据传输。
在某些实施例中，在例如要求多个包的长事务的事件中，当所发生错误与管线可
能被清空及管线内的对应包可能被重新发送时，接收组件可使用请求总线Q序列号(Qseq)
及数据序列号(DataSequence)来识别每一包。例如，如果在响应总线S上的包中发生错误，
那么由传输组件接收的最新已知良好的包可在其中包含Qseq号码以用作参考。作为采用此
技术的结果，一些消息现在实际上较短，这是因为未参考事务类型来指示事务。即，为了另
外指示事务类型，包内的事务类型、窗及地址(高达52个位)可用于包含此信息。相比之下，
发送Qseq值及DataSequence值可能涉及23个位(例如，16+7＝23位)，由此进一步改进传送
中的位效率。
与先前描述的重新排序消息技术相比，当重新排序被执行的次数高于某一频率阈
值时，为包附加Qseq值可导致所传输的位总数较低。虽然提供Qseq值的选项已被描述为被
动态并入可扩展协议内，但在某些实施例中，可扩展协议提供Qseq值的能力可为在实施可
扩展协议的SoC被设计时内建到可扩展协议中的静态选择。使用可扩展协议的系统的类型
可提供信息来指示哪个排序方法可提供更高效位传输。
记住上述内容，在一个实施例中，请求总线Q序列号字段可为18位字段，其可用于
识别4千字节事务的每一事务操作。虽然请求总线Q序列号字段已被描述为18位字段，但是
请求总线Q序列号字段的大小可为任何适当值。通常，请求总线Q序列号字段的大小可大到
足以识别特定事务的每一事务操作，且可用于指示请求或响应可被执行的顺序。虽然添加
请求总线Q序列号字段到相应包可增大相应包的相应大小，但是包大小的增大仍比如在常
规协议中执行用每个请求及响应操作发送事务识别更高效。此外，由于请求总线Q序列号字
段的添加可在确定发送重新排序消息低效后完成，所以与如在常规协议中用于每个事务操
作相比，本技术限于在特定实例中使用。
在一些实施例中，当请求已暗示序列号(例如，针对给定channel.window，第一请
求是0，下一个是1，下一个是2等等)时，可扩展协议可不添加请求总线Q序列号字段到事务
操作。即，由于事务操作按自然暗示顺序，所以可扩展协议可通过不传输序列号而保存位使
其不被发送。
然而，如上所述，当响应优选按除自然暗示顺序以外的不同顺序流动时，可扩展协
议可为每一接收到的事务操作附加请求总线Q序列号字段中的相应序列号。在一些情况中，
序列号可潜在地使用大位字段。举例来说，在支持NAND的窗中，响应可能需要0.01秒。在此，
如果包速率是5x10-9，那么可能存在飞行状态中的5x107个响应，其可使用26个位来识别响
应中的每一者。更实用案例预期大约4千字节的较大事务，其中可能存在大约100,000个未
处理事务。在此，每一事务可仅在低于17位内识别。为了允许用小事务实现更好性能，且也
保证无识别混叠，位计数可被向上舍入为18个位。即，数目可模数截断为零，且因此在序列
中存在在任何时间“活跃”的明显间隙以避免混淆。
在任何情况中，当提供重新排序序列时，可扩展协议可添加请求总线Q序列号字段
到对应包。因而，上文描述的字段中的一些可改变。举例来说，在请求总线Q上，不应答命令
可改变，使得其具有相同事务类型及相同事务窗。先前，不应答命令可能已包含地址、数据
序列号及原始事务类型。在一个实施例中，不应答命令现可具有请求总线Q序列号及数据序
列号。因此，不应答命令可为比先前描述小的包。
在响应总线S上，一般消息事务类型可能未改变。然而，包的其余项目可改变如下：
●“完整”消息可具有事务类型、窗、请求序列号及ECC。
●“不应答”(NACK)消息可具有事务类型、窗、请求序列号、数据序列号及ECC。
●“消息”可能未改变，且因此可包含事务类型、窗、8B数据及ECC。
●8uData可包含事务类型、窗、请求序列号及8B数据及ECC。
●16uData可包含事务类型、窗、请求序列号及16B数据及ECC。
●32uData可包含事务类型、窗、请求序列号及32B数据及ECC。
●48uData可包含事务类型、窗、请求序列号及48B数据及ECC。
●64uData可包含事务类型、窗、请求序列号及64B数据及ECC。
●80uData可包含事务类型、窗、请求序列号及80B数据及ECC。
●96uData可包含事务类型、窗、请求序列号及96B数据及ECC。
●112uData可包含事务类型、窗、请求序列号及112B数据及ECC。
●128uData包含事务类型、窗、请求序列号及128B数据及ECC。
●256uData可包含事务类型、窗、请求序列号及256B数据及ECC。
如上所述，虽然数据事务类型的包大小可能已增大了请求序列号的量，但是甚至
在具有高性能NAND的系统中，所产生的序列号可仅为16b。因而，与可添加16位到每个响应
的常规协议相比，针对按高频率重新排序或如此设计的事务操作将事务操作重新排序的当
前揭示技术仍可能是经济的。此外，由于当前揭示技术包含针对每一响应的序列号，所以可
扩展协议可能不发布重新排序消息或包。此外，由于每一事务操作与特定序列号相关联，所
以事务操作可按循环顺序传输以保证已知数据不被传输。
排序工作字段
如上文论述，当一个事务窗中的事务操作优选按顺序时，情况出现，但偏离那个顺
序可能是有利的。记住这点，除用于将上文描述的事务操作重新排序的两种技术外，在一个
实施例中，可扩展协议可提供灵活编程选项用于在系统中排序事务操作或包。灵活编程选
项(例如，排序工作字段)可设置可扩展协议应用于维持事务的原始顺序的一定程度的工
作。即，灵活的排序工作字段可向可扩展协议指示工作应多努力来保证包按顺序传输。因
而，灵活排序工作字段可与对应于按顺序保持每个包的第一值与对应于允许任何事项被重
新排序的第二值之间的值范围相关联。
记住这点，事务窗0可被用作存储器SoC 22的通用控制区域。因而，事务窗0可驻留
于寄存器、SRAM缓冲器、高速缓存SRAM及其它可寻址控制特征中。对于每一事务窗，可扩展
协议可实现可由用户编程的可配置信息。如上所述，一种类型的可配置信息(例如，排序工
作字段)可包含维持原始顺序的一定程度的工作(即，排序工作)。排序工作字段可具有实施
方案的大变化。例如，在2位字段中，排序工作可被特性化如下：
00-允许每次机会的重新排序
01-允许大量重新排序
10-允许一些重新排序
11-不允许重新排序，等待直到资源可用为止
在某些实施例中，可扩展协议可将某些包与特定排序区关联。排序区可指示对应
包将被类似地处理。举例来说，相同排序区中的请求可被预期为按顺序，且如果不可能按顺
序，那么传输组件(例如，存储器SoC 22)可应用排序工作(如由排序工作字段指定)以确定
请求可被乱序传输的程度。
排序区可与通道、系统窗及事务窗的组合(例如，channel.syswin.window)相关。
通道可为从其接收请求的通道号。系统窗可为一对任选字段，其例如指定系统中的哪个SoC
发起请求。
记住上述内容，假设对于排序区来说队列深度是16，在2位字段中指定排序工作的
合理实施方案可如下：
00-允许每次机会的重新排序：允许结果槽在16的队列深度中的任何位置处互换
01-允许大量重新排序：允许结果槽在11的队列深度中的任何位置处互换
10-允许一些重新排序：允许结果槽在6的队列深度中的任何位置处互换
11-无重新排序：不允许互换，允许资源闲置
在某些实施例中，定义排序工作的排序工作函数可包含额外变量，例如请求的使
用期限。举例来说：
00-允许每次机会的重新排序，允许结果槽在16的队列深度中的任何位置处互换
01-允许大量重新排序：如果请求是旧的，那么允许结果槽在8的队列深度中的任
何位置处互换，如果请求是新的，那么允许结果槽在14的队列深度中的任何位置处互换
10-允许一些重新排序：如果请求是旧的，那么允许结果槽在4的队列深度中的任
何位置处互换，如果请求是新的，那么允许结果槽在8的队列深度中的任何位置处互换
11-无重新排序：不允许互换，允许资源闲置
在此，可扩展协议可使请求能被指定为旧或新。例如，如果请求已存在达7个或更
多个请求槽，那么请求可被视为旧的，而如果请求已存在达6个或更少请求槽，那么请求可
被视为新的。
上文列出的实例说明排序工作可在2位字段中量化的可能方式的小子集。可使用
较大大小的排序工作字段指定额外程度的排序工作。在任何情况中，排序工作字段可提供
简单可编程的能力，所述能力使排序工作成为可利于调谐总系统性能的函数。在某些实施
例中，由主机SoC 12采用的排序工作可在主机SoC 12通电时予以确定或指定。即，主机SoC
12可确定其所连接的装置的类型，或其被设计使用的行业的类型及相应地确定排序工作。
总线业务调节的背压函数
背压可指相应总线上有关接收总线业务的缓冲器23(例如，先进先出(FIFO)缓冲
器)的可用容量的总线业务量。因而，当接收总线业务的缓冲器23接近其深度限值时，相应
总线的背压可被视为高。一旦缓冲器23变满，常规系统中的接收组件即可忽略未来传入包
或接受传入包且删除目前在缓冲器23中的包。在这些情况的任一者中，包可能不被处理，且
因此通信链路的完整性可能受损。
记住这点，图15说明用于调低从传输器传输的请求的传输速率的方法180的流程
图。此外，为说明目的，下列方法180被描述为由主机SoC 12执行，但可由任何适当接收组件
执行。
在框182处，主机SoC 12(例如，接收组件)可监测缓冲器23的容量，且确定接收器
的缓冲器23的容量小于或等于某一阈值。如果缓冲器23的容量高于阈值，那么主机SoC 12
可继续进行到框184，且按当前传输速率继续从传输组件接收包。
但是，如果缓冲器23的容量小于或等于阈值，那么主机SoC 12可接着继续进行到
框186。在框186处，主机SoC 12可发送消息到传输组件以减小其发送包的速率。此时，主机
SoC 12及传输组件两者可使用相同背压函数来根据相同的已知数学函数调节包的传输及
接收。因此，总线业务的背压可被减小以适应当前在缓冲器23中的数据包的处理，同时减小
丢失包的可能性。
在一个实施例中，当未处理事务计数接近最大窗值(windowMax)及最大通道值
(channelMax)时，总线业务可被调低。channelMax及windowMax字段可由用户或可扩展协议
独立地设置。channelMax字段可对应于所定义最大传输速率。例如，channelMax可被设置为
每秒1x109个请求。windowMax字段可对应于未处理事务操作的数目。实例背压函数可包含
在windowMax或channelMax处于90％容量后线性减小请求速率。此时，传输速率可为0.900*
Max处的100％，且线性变化到0.995*Max处的0％。图16用图形说明可如何根据上文描述的
线性函数调低传输速率。
除线性调低传输速率外，传输组件也可根据非线性函数调低其传输。举例来说，图
17说明一个可能的非线性曲线，其可由传输组件在调低其传输速率时采用。应理解，传输组
件不限于根据图17中描绘的曲线采用非线性传输速率。在另一实例中，非线性曲线可包含
步降曲线，其由有限步骤按比例缩减传输速率。
在通道上仅存在一个事务窗的情况中，windowMax字段可能不与channelMax字段
相关或可被视为等于channelMax字段。在存在多个事务窗的情况中，可针对每一相应事务
窗界定不同的背压函数。例如，考虑事务窗的以下四个实例，其使用如下文描述的各种不同
存储器类型。
窗0-控制及注册
窗1-最低延时DRAM
窗2-通常DRAM
窗3-NAND
记住这点，可如何基于通道的业务调节背压函数的实例可包含定义通道最大值
(例如，每秒1x109个请求)、定义背压函数何时可开始(例如，RollbackStart 0.9p.u.)及定
义背压函数何时可结束(例如，RollbackEnd 1p.u.)。在此实例中，Rollback函数可应用于
被称作Max的变量，Max可对应于通道max。通常，通道max对应于当通道请求速率小于或等于
0.9*通道max(例如，高达RollbackStart)时，请求(或事务命令)被发送的速率。
以相同方式，每一相应事务窗可采用相应背压函数。例如，上文定义的四个实例事
务窗的背压函数可实施如下：
window0
max的window0max 0.05p.u.
max的window0RollbackStart 0.045p.u.
max的window0RollbackEnd 0.05p.u.
window1
max的window1max 0.9p.u.
max的window1RollbackStart 0.81p.u.
max的window1RollbackEnd 0.9p.u.
window2
max的window2max 0.3p.u.
max的window2RollbackStart 0.27p.u.
max的window2RollbackEnd 0.3p.u.
window3
max的window3max 0.1p.u.
max的window3RollbackStart 0.09p.u.
max的window3RollbackEnd 0.1p.u.
如上所展示，背压函数可在存在许多相互作用的事务窗(即，许多同时过程)时，逐
渐回降请求速率。在任何情况中，通过与使用所传输信号相比，根据函数执行调节操作，可
扩展协议可能与所传输信号是频带内还是频带外无关。此外，由于接收组件及传输组件可
实施相同数学函数而无需传达何时实施函数，所以可扩展协议可进一步减小跨越每一相应
总线传输的位量。
在某些实施例中，背压函数也可考虑每一请求的使用期限。例如，如果较旧请求积
存于事务窗中，那么接收组件可针对那个特定事务窗调整windowMax的值或修改Rollback
限值。
在又一实施例中，背压函数也可考虑队列深度。即，在通电时，存储器SoC 22可具
有基于事务窗或类似物中提供的信息发现连接倒存储器SoC 22的模块的能力的能力。能力
的部分可包含观测连接到存储器SoC 22的接收器的队列深度且可能也可发现所连接通道
的标称包处理速率。虽然存储器SoC 23可能无法追踪接收器的队列，但存储器SoC 22可作
出有关接收器的队列的状态的一些确定。举例来说，如果存储器SoC 22在超过接收组件的
包处理速率的情况下快速连续发送许多包，那么存储器SoC 22可预测接收组件中的队列将
增长。因而，如果存储器SoC 22确定包比接收器的包处理速率更快地被发送，那么存储器
SoC 22可开始应用上文描述的背压函数，而不接收来自接收器的显式反馈。换句话来说，如
果包传输速率超过包间处理速率，那么存储器SoC 22可开始减小包传输速率。以此方式，传
输速率可被减小而不添加消息到通道。在一些实施例中，当接收组件未按其预期速率处理
包时，接收组件可发送消息到存储器SoC 22作为故障保护。
在另一实施例中，接收组件可包含系统故障安全机构以向传输组件指示缓冲器23
即将超出其容量限度或超过其容量。在此，接收组件可发送类似于上文描述的不应答消息
的消息。此消息可具有与不应答消息相同的效应，除其可在传输组件的数据日志中形成输
入项以注明消息归因于缓冲器23无法接受包而被拒绝。因而，传输组件可确定总线业务延
迟的原因。
虽然本文中描述的实施例可具有各种修改及替代形式，但是特定实施例已在图式
中通过实例展示且已在本文中予以详细描述。然而，应理解，本发明并不希望限于所揭示的
特定形式。而是，本发明涵盖落于如由以下所附权利要求书定义的本发明中描述的技术及
系统的精神及范围内的所有修改、等效物及替代。