用于在可扩展存储器系统协议中调节包传输的系统及方法与流程

本申请案是主张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.25x10¹⁵个字节。以相同方式，如果Window3的最小传送大小是128个字节，那么Window3可支持～3.6x10¹⁶个字节。因而，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，那么接受组件可传输指示1x10¹⁰个包的成功的应答位及指示错误的1个包。有效地，接受组件可能已发送大约1x10¹⁰个位来指示一个错误。

为了减少在总线内流动的位的数量，接受组件可不针对每个接收到的包发送应答包。而是，传输组件可假设所发送的包已被接收，除非接受组件另外通知。在图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个位显著低于用于指示1x10¹⁰个包中的一个错误而发送的1x10¹⁰个位，且因此是指示地址错误包的更高效方式。应注意，上述数据序列号可识别错误包。有关数据序列号及其可如何产生的额外细节将在下文参考图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消息可正确地识别传输变为不成功的精确点。在另一实施例中，与2^N字节相比，针对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的以下描述将被论述为由存储器SoC22(即，传输/请求组件)执行，但应理解，作为存储器装置14的部分的任何处理器可执行方法70中描述的操作。

现参考图9，在框72处，存储器SoC 22可接收将被传输的数据操作的指示。数据操作可包含将被发送的消息、读取操作、写入操作或类似操作。在框74处，存储器SoC22可识别对应于数据操作的事务类型。在某些实施例中，请求数据操作被执行的软件可指定事务类型。替代地，存储器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值的位值后，存储器SoC22可在框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可为20×8位分道宽度或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可识别新包的起始位。因而，主机SoC12可监测位流，直到其接收到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可接收来自传输组件(例如，存储器SoC22)的若干包。接收到的包可大体上包含被请求由主机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，那么可能存在飞行状态中的5x10⁷个响应，其可使用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可被设置为每秒1x10⁹个请求。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

记住这点，可如何基于通道的业务调节背压函数的实例可包含定义通道最大值(例如，每秒1x10⁹个请求)、定义背压函数何时可开始(例如，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无法接受包而被拒绝。因而，传输组件可确定总线业务延迟的原因。

虽然本文中描述的实施例可具有各种修改及替代形式，但是特定实施例已在图式中通过实例展示且已在本文中予以详细描述。然而，应理解，本发明并不希望限于所揭示的特定形式。而是，本发明涵盖落于如由以下所附权利要求书定义的本发明中描述的技术及系统的精神及范围内的所有修改、等效物及替代。