掌桥专利:专业的专利平台
掌桥专利
首页

可编程消息检查引擎

文献发布时间:2024-04-18 20:01:23


可编程消息检查引擎

其他申请的交叉引用

本申请要求2022年7月28日提交的、题为PROGRAMMABLE MESSAGE INSPECTIONENGINE的美国临时专利申请第63/392,992号的优先权,该美国临时专利申请出于所有目的通过引用被并入本文中。

背景技术

片上系统(SOC)设备包括硬件功能模块和固件复合体的组合,其中固件在一个或多个处理器模块上运行。尽管一些SOC设备被设计用于与有限和/或固定数量的其他(例如,电子和/或SOC)设备的互操作性,但是一些SOC设备(诸如存储控制器)被预期与各种各样的设备(例如,来自不同制造商、具有不同接口、具有不同(例如,时序)性能等)对接。对于后一种类型的SOC,使它们自身适合于适应性和/或性能改进的新特征和/或组件将是期望的。

附图说明

本发明的各种实施例在以下详细描述和附图中公开。

图1是图示了用于配置和使用消息检查引擎的过程的实施例的流程图。

图2是图示了包括具有一个或多个消息检查引擎的消息路由模块的片上系统(SOC)的实施例的图。

图3是图示了消息检查引擎的实施例的图。

图4是图示了遍及SOC使用的标准化消息格式的实施例的图。

图5A是图示了具有错误字段的消息格式的实施例的图。

图5B是图示了其中消息路由模块执行错误处置的存储控制器的实施例的框图。

图6A是图示了具有序列信息的消息格式的实施例的图。

图6B是图示了存储控制器的实施例的框图,其中消息路由模块执行分组和/或序列相关消息加速。

具体实施方式

本发明可以以许多方式来实现,所述方式包括作为过程;装置;系统;物质的组成;在计算机可读存储介质上包含的计算机程序产品;和/或处理器,诸如被配置成执行存储在耦合到处理器的存储器上和/或由耦合到处理器的存储器提供的指令的处理器。在本说明书中,这些实现或者本发明可以采用的任何其他形式可以被称为技术。通常,可以在本发明的范围内更改所公开的过程的步骤的顺序。除非另有声明,否则被描述为被配置成执行任务的组件(诸如处理器或存储器)可以被实现为被暂时配置成在给定时间处执行该任务的通用组件、或者是被制造以执行该任务的特定组件。如本文中所使用的,术语“处理器”指的是被配置成处理数据(诸如计算机程序指令)的一个或多个设备、电路和/或处理核心。

下面提供了本发明的一个或多个实施例的详细描述连同图示了本发明的原理的附图。结合这样的实施例描述了本发明,但是本发明不限于任何实施例。本发明的范围仅由权利要求来限定,并且本发明包含许多替代方案、修改和等同物。在以下描述中阐述了许多具体细节,以便提供对本发明的透彻理解。这些细节是出于示例的目的而提供的,并且可以根据权利要求来在没有这些具体细节中的一些或全部的情况下实施本发明。出于清楚性的目的,尚未详细地描述与本发明相关的技术领域中已知的技术材料,以便不会不必要地使本发明含糊难懂。

本文中描述了出于多种目的在片上系统中配置一个或多个消息检查引擎的技术的各种实施例。在一些实施例中,(例如,多用途和/或多功能)消息检查引擎(例如,在SOC中的硬件中实现)被配置成执行错误处置,例如,通过标识来自上游功能模块的相关和/或目标错误消息,并为下游功能模块生成输出消息(例如,以开始一些错误恢复或错误响应),而不需要固件复合体的干预。在一些实施例中,消息检查引擎被配置成执行消息加速,例如,通过标识相关和/或目标输入消息并生成输出消息(例如,这需要一些消息内容屏蔽、消息内容变换、消息序列(重新)排序等)而不需要固件复合体的干预。下图描述了用于配置和使用这样的消息检查引擎的一个示例过程。

图1是图示用于配置和使用消息检查引擎的过程的实施例的流程图。在一些实施例中,存在多个(例如,多用途和/或多功能)消息检查引擎,所述消息检查引擎被包括在一些或所有功能模块向其发送它们的所有消息的(例如,集中式)消息路由模块中。

在100处,接收配置信息。在一些实施例中,消息路由模块包括一个或多个消息检查引擎和可编程配置寄存器;配置信息可以从可编程配置寄存器接收或以其他方式获得。在各种实施例中,可编程配置寄存器可以具有默认值,可以在初始化期间被设置(如果默认值是不期望的)等等。

在102处,使用配置信息来配置在片上系统(SOC)中的硬件中实现的消息检查引擎,以获得配置的消息检查引擎。例如,如下面将更详细地描述的,一些消息检查引擎可以被配置成执行错误处置,而其他消息检查引擎可以被配置成执行消息加速(即,从固件复合体卸载消息变换和/或处理)。消息检查引擎在硬件中的实现使能实现比固件复合体更快的处理,并且还从固件复合体卸载了由(多个)消息检查引擎执行的功能和/或处理。

在104处,在配置的消息检查引擎处,接收来自SOC中的上游功能模块的输入消息。在一些实施例中,由上游功能模块输出的消息中的一些或所有以图1中描述的方式来接收和处理。

在106处,使用配置的消息检查引擎来分析输入消息,以确定内容修改计划和目的地控制计划。例如,上游功能模块可生成许多不同类型的消息,并且可能不确定目标消息和/或感兴趣的消息将何时出现,并且因此检查所有消息。注意,消息干预(例如,以内容修改的形式,将输出消息重定向到新的下游功能模块等)不必对所有输入消息执行,并且因此在一些情况下,内容修改计划是“无内容修改”和/或目的地控制计划是“无目的地修改”。

在108处,使用配置的消息检查引擎,至少部分地基于输入消息、内容修改计划和目的地控制计划来生成输出消息,包括通过用由目的地控制计划指定的下游功能模块来填充输出消息。如上面所描述的,在一些情况下,不存在干预和/或修改。

在110处,从配置的消息检查引擎输出输出消息。例如,输出消息可以在SOC中的一些消息总线上发出。在一些实施例中,输出消息在被发送到输出消息中指定的下游功能模块之前被暂时存储在一些出站消息队列中。

图示执行图1的过程的SOC的框图可能是有帮助的。下图示出了一个这样的示例性SOC。

图2是图示了包括具有一个或多个消息检查引擎的消息路由模块的片上系统(SOC)的实施例的图。SOC(200)中的示例性消息路由模块(204)是执行图1的流程图的设备的一个示例。

在这个示例中,SOC(200)包括(例如,硬件)功能模块,包括第一上游功能模块(202)、消息路由模块(204)、第一下游功能模块(206)和第二下游功能模块(208)。SOC(200)还包括固件复合体(210),所述固件复合体继而包括在相关联的处理器模块(214)上运行的固件(212)。

第一上游功能模块(202)生成或以其他方式输出消息,在图中示出为MSG In(216),并且有时在本文中称为输入消息。在各种实施例中,消息是命令消息、状态消息、错误消息等。

由消息路由模块(204)中的第一消息检查引擎(218)根据可编程配置寄存器(220)中的配置和/或设置以及输入消息(216)满足可编程配置寄存器(220)中布置(laid out)的特定(例如,变换、重新路由等)标准的程度,检查、处理、变换和/或重新路由输入消息(216)。例如,如果输入消息(216)满足与重新路由相关联的可编程配置寄存器(220)中指定的一些标准,则输出消息(即,MSG Out(222))被重定向到第二下游功能模块(208),而不是输入消息(216)最初旨在发送到的第一下游功能模块(206)。

在这个示例中,存在生成消息并向消息路由模块(204)发送消息的附加上游功能模块。例如,第二上游功能模块(224)将其消息发送到第二消息检查引擎(226),所述第二消息检查引擎(226)分析传入的消息并如由可编程配置寄存器(220)指定的那样来干预。在一些实施例中,一些或所有硬件功能模块(例如,包括202和224)向消息路由模块(204)发送它们的消息中的一些或所有,所述消息路由模块(204)充当大多数或所有消息通过的(例如,集中式)消息路由模块。这使得消息路由模块(204)(至少在这个示例中)能够检查大多数或所有消息,并如由可编程配置寄存器指定的那样来修改和/或重新路由它们。

替代地,在一些其他实施例中,可以确定(例如,出于设计折衷和/或应用特定的原因)至少一个上游功能模块未将其消息发送到(例如,中央)消息路由模块(例如,204)。例如,其中需要干预的可能性低的建立和/或稳定的功能模块可能不一定将其消息发送到(例如,中央)消息路由模块(例如,204)。例如,这可以减少SOC中的路由的量。

在一些实施例中,消息检查引擎(218)被配置(例如,使用可编程配置寄存器(220))成寻找可以处置和/或重定向而无需固件复合体(210)的干预的错误消息(例如,包括先前未定义和/或未预料的错误的类型的错误消息)。例如,任何原因引起的瞬时错误可以被分类为需要自动重试。消息检查可以将输入消息(Message In)重定向回到消息发起者以进行重试,而不考虑具体的错误情况。否则,该消息将被发送到固件以确定错误分类。当除了发起重试之外不需要附加动作时,将消息发送到固件以进行分类会消耗原本将可用于功能操作的固件资源。换句话说,如果SOC遇到错误消息,则没有消息路由模块(例如,204)的一些其他SOC系统可以将这样的错误消息发送到固件复合体(210)以进行处置,因为固件复合体(210)通常在SOC中具有最多的进程上下文和/或处理能力。例如,固件(212)可以被(重新)写入以增加错误处置能力,使得可以在不必重新制造(即,“重新旋转(re-spin)”)SOC的情况下处置错误。然而,让固件复合体(210)处置错误消息是不期望的,因为对于固件(212)而言通常存在固定量的存储器,并且固件存储器空间可能是有限的。此外,执行错误处置操作可能使固件复合体(210)资源远离更重要和/或时序关键(timing-critical)的操作。

相比之下,可编程配置寄存器(220)可以用来使消息检查引擎(218)标识和处置错误消息,包括通过(作为示例)将输入消息(216)变换或以其他方式重新格式化成适当的输出消息(222)(例如,以在下游功能模块(例如,206或208)处发起适当的错误处置和/或错误恢复),并且如果如此配置的话,则重定向输出消息(222)(例如,到第二下游功能模块(208)),全部通过可编程配置寄存器(220)。让消息路由模块(204)处置错误在许多应用中是期望的,因为它节省了固件复合体(210)资源,以便不干扰更重要和/或时序关键的操作,并且不消耗可能稀缺的固件存储器空间。此外,一些类型的SOC(例如,存储控制器SOC)可以与多种设备(例如,来自不同制造商的不同类型的存储介质)对接,所述设备在时序和/或操作上可能具有差异。与新设备交互可能导致遇到新类型的错误,但是(多个)消息检查引擎的可编程性质允许在没有固件(复合体)干预的情况下处置(至少一些)新错误。此外,配置消息检查引擎可以例如允许系统性能(例如固件的、固态驱动器(SSD)系统等的系统性能)跨不同的介质设备一致,因为每个设备特有的特定错误消息发送可以被统一到下游模块的公共消息编码中。

在一些实施例中,消息检查引擎(218)被配置(例如,使用可编程配置寄存器(220))成加速消息处理和/或处置,否则其将由固件复合体(210)处置。例如,当从SOC中的一个域去往另一域,或者从上游功能模块(例如,202)去往下游功能模块(例如,206)时,如果存在域改变或上下文改变,则输入消息(216)中的一些字段和/或内容可能需要被去除掉或过滤掉,并且新的字段和/或内容可能需要被检索并插入到输出消息(222)中。消息路由模块(204)的这个应用在本文中有时被称为消息加速。与错误处置一样,使用消息路由模块(204)来执行消息加速的好处是,它不消耗固件存储器空间(这可能是稀缺的),不影响由固件复合体(210)执行的其他(例如,更重要和/或时序关键的)操作,并且可能比在固件复合体(210)执行它的情况下更快(例如,因为消息路由模块(204)在通常更快的硬件中实现)。此外,可以使用消息加速来节省硬件资源。在示例使用中,公共资源跟踪模块可以从多种源接收资源使用更新(例如,分配资源、释放资源等)。消息加速器可以从传入消息中提取资源使用信息,并使用适合于资源跟踪模块的数据格式来将相关信息转发到资源跟踪模块。消息加速的这样的应用允许芯片内更大的组件重用,从而节省硬件资源(例如,带宽、路由和/或面积)并最终降低产品成本。下面描述了更详细的消息加速示例。

在这个示例中,消息路由模块(204)在硬件中实现,因此错误处置和/或消息加速比在由固件复合体(210)执行它的情况下更快地执行。

在一些实施例中,存在多个消息检查引擎(例如,218和226),该消息检查引擎中的每个彼此独立地操作,并且可以使用可编程配置寄存器(220)来配置。例如,在易出错和/或嘈杂的环境中,第一消息检查引擎可以被配置成处置第一未预料类型的错误,并且第二消息检查引擎可以被配置成处置第二未预料类型的错误。在较不易出错和/或较不嘈杂的环境中,两个消息检查引擎可以被配置成执行两种类型的消息加速。

为了节省硬件资源(例如,模块之间的信号路由),在一些实施例中,来自上游模块(例如,202和224)的各种消息经由与消息路由模块(例如,204)的公共信号接口被输送至消息检查引擎(例如,218和226)。在一些这样的实施例中,到消息路由模块(例如204)的入站消息(例如216)被发送到包含在消息路由模块内的所有消息检查引擎(例如218和226)。

如在这个示例中所示,在一些实施例中,SOC包括第二上游功能模块(例如,224)和第二消息检查引擎(例如,226),所述第二消息检查引擎使用配置信息(例如,220)来配置,以获得第二配置的消息检查引擎(例如,226);(第一)配置的消息检查引擎(例如218)被配置成分析来自(第一)上游功能模块(例如202)的那些输入消息并忽略来自第二上游功能模块(例如224)的那些输入消息;并且第二配置的消息检查引擎(例如226)被配置成忽略来自(第一)上游功能模块(例如202)的所述那些输入消息并分析来自第二上游功能模块(例如224)的所述那些输入消息。

如在这个示例中所示,在一些实施例中,SOC包括第二上游功能模块(例如,224)和第二消息检查引擎(例如,226),所述第二消息检查引擎使用配置信息(例如,220)来配置,以获得第二配置的消息检查引擎(例如,226);配置的消息检查引擎(例如,218)执行错误处置,包括通过针对一个或多个指定类型的错误消息检验来自上游功能模块(例如,202)的输入消息;并且第二配置的消息检查引擎(例如,226)执行消息加速,包括通过针对一个或多个指定类型的无错误消息检验来自第二上游功能模块(例如,224)的输入消息。

下图示出了消息检查引擎的示例框图。

图3是图示了消息检查引擎的实施例的图。在一些实施例中,图2中的消息检查引擎(218)如所示那样实现。在这个示例中,消息检查引擎(300)输入输入消息(302)并输出输出消息(304)。在这个示例中,标准匹配模块(306)(例如,一旦被配置)检查输入消息(302)的指定部分,并决定(例如,基于输入消息(302)的检查部分和可编程配置寄存器(例如,图2中的220)中的那些检查部分的指定标准)是否干预。

如果标准匹配模块(306)确定对于输入消息(302)不需要干预,则输入消息(302)在没有干预的情况下作为输出消息(304)来输出(例如,没有修改和没有重定向)。

如果输入消息(302)满足相关标准,则标准匹配模块(306)将输入消息传递至内容修改模块(308),在内容修改模块(308)中修改消息的内容(例如,如果如此指定,并以通过可编程配置寄存器(例如,图2中的220)的方式)。下面描述更详细的内容修改示例。

在一些实施例中,内容修改模块(308)改变消息的大小,使得输出消息(304)的大小不一定与输入消息(302)的大小匹配。例如,输入消息(302)可以包含不必要和/或不相关的消息内容(例如,从下游功能模块的角度来看),并且在一些实施例中,内容修改模块(308)提取输入消息(302)的重要和/或相关部分,并且将那个提取的信息包括在输出消息(304)中,使得在内容修改之后大小可以不同。替代地,在一些实施例中,输出消息(304)的大小与输入消息(302)的大小相匹配,并且不必要和/或不相关的消息内容仅仅被屏蔽掉(例如,被设置成全零)或用更相关的信息重写。例如,内容修改模块(308)可以以多种方式来实现(例如,仅仅屏蔽和/或重写对能够删去和/或插入)。

(例如,修改的)消息从内容修改模块(308)被传递至目的地控制模块(310),所述目的地控制模块(310)确定消息的适当目的地。暂时返回到图2,这可以包括将输出消息发送到原始下游功能模块(例如206),或者通过可编程配置寄存器(220)将输出消息重新路由或以其他方式重定向到新的下游功能模块(例如208)。

在一些实施例中,遍及SOC来使用标准化的消息格式。下图示出了标准化消息格式的一个示例。

图4是图示了遍及SOC使用的标准化消息格式的实施例的图。在这个示例中,消息格式(400)包括报头(402)和有效载荷(404)。报头(402)包括多个字段(例如,406a-406c),在这个示例中,所述字段具有固定的预定义大小。在这个示例中,第一字段(406a)用来指定正在交换的消息的类型;取决于在这个第一字段(406a)中指定的消息的类型,随后的字段的含义和/或使用可以变化。可以在第一字段(406a)中指定的消息类型的一些示例包括各种命令消息(例如,其使得下游功能模块执行相关联的命令)或状态消息(例如,包括错误消息,其具有各种子类型)。

示例性消息报头(402)中的第二字段(406b)和第三字段(406c)分别用来指定消息源和目的地。在一些实施例中,在第三字段(406c)中指定的目的地不是消息路由模块,而是消息最终旨在发送到其的下游功能模块。例如,在图2中,第二字段(406b)可以是生成输入消息(216)的上游功能模块(202),并且第三字段(406c)可以是第一(即原始)下游功能模块(206)。注意,如果消息被重定向,则第三字段(406c)可以被改变到输出消息(222)中的第二下游功能模块(208)。

在图2中,消息检查引擎(218)被配置(例如,通过可编程配置寄存器(220)中的设置)成检验报头(402)中的(多个)指定字段(406a-406c)。例如,如上面所描述的,可以存在多个消息检查引擎(218),所述消息检查引擎中的每个独立地操作。执行消息加速的第一消息检查引擎可以被配置成寻找生成被加速的消息的特定源(例如,在图4中的字段2(406b)中)。并行地,执行错误处置的第二消息检查引擎可以被配置成寻找发出感兴趣的错误消息的源或上游功能模块(例如,在图4中的字段2(406b)中)。当然,为了让消息检查引擎进行干预,可能存在必须满足的附加标准。

返回到图4,报头(402)的大小通常是可管理的大小,并且因此在这个示例中,报头(402)中的所有的字段(406a-406c)是可检查的(例如,通过图2中的标准匹配模块(306))。这意味着其中包含的任何信息可以被检验、访问和/或读取,并且(随后并且如果需要的话)被操纵和/或处理(例如,通过图3中的内容修改模块(308)和/或目的地控制模块(310))。

相比之下,有效载荷(404)的大小可能相当大,并且因此为了将消息路由模块(例如,图2中的204)保持到合理的大小,仅有效载荷部分(404)的一部分(在这个示例中,开始部分)(例如,408a-408b)是可检查的(至少在这个示例中)。换句话说,在有效载荷(404)的结束处存在一些不可检查的部分(410)。因为在许多或大多数情况下,上游功能模块被设计成使用固定的和/或预定义的字段格式来放置最重要的和/或相关的信息,所以具有不能检查或以其他方式访问所有的有效载荷的较小模块可能是可接受的折衷。

在这个示例中,可检查部分(408a-408b)被分成固定大小的预定义段(例如,DWORD),包括第一可检查段(408a)、第二可检查段(408b)等等。例如,不同类型的消息可以以不同的方式使用有效载荷,并且因此取决于有效载荷内感兴趣的消息类型和信息,不同的段(例如,408a-408b)可能是感兴趣的。例如,如果有效载荷包含状况或状态信息,则检验或以其他方式检查第一段(408a)可能是足够的,而不必检验第二段(408b)。然而,如果感兴趣的信息较长(例如,到消息检查引擎(例如,图2中的218)将访问以获得存储在其中的数据的存储器位置的链接或地址),则可能需要访问第一和第二段两者(408a和408b)。可以通过可编程配置寄存器(例如,图2中的220)来控制或以其他方式配置要检验或以其他方式检查哪些段。

如在这个示例中所示,在一些实施例中,输入消息包括报头(例如,402),所述报头继而包括多个字段(例如,406a-406c);分析输入消息包括检查由配置信息指定的多个字段中的那些字段;输入消息进一步包括有效载荷(例如,404),所述有效载荷继而包括多个可检查段(例如,408a-408b)和不与多个可检查段重叠的不可检查部分(410);并且分析输入消息进一步包括检查由配置信息指定的多个可检查段中的那些可检查段。

下图描述了消息检查引擎搜索和干预的消息类型的更具体示例。首先,描述了一些错误处置示例。然后,描述了一些消息加速示例。

图5A是图示了具有错误字段的消息格式的实施例的图。在这个示例中,消息格式(500)包括报头(502)和有效载荷(504)。报头(502)中的字段之一(即字段i)是错误字段(例如506a-506c)。在这个示例中,包含在错误字段中的值指示是否存在错误,并且如果有,则错误的类型是什么。

在这个示例中,如果错误字段的值为零(506a),则这对应于“无错误”。如果错误字段的值为一(506b),则检测到或发生了错误,并且这种情况被称为(至少在这些示例中)第一种类型的错误。类似地,如果错误字段的值为二(506c),则检测到或发生了错误,并且在这些示例中将其称为第二种类型的错误。对于第二种类型的错误(506c),上游和/或报告功能模块在有效载荷(504)中包括补充错误信息(508)。例如,补充错误信息(508)可以在能够被消息检查引擎(参见例如图4中的408a-408b)检查或以其他方式检验的一些部分中的有效载荷的开始处。

总结错误字段(506a-506c)的使用,如果错误字段是零值(506a),则不存在错误;如果错误字段是非零值(例如,506b和506c),则存在错误。具有非零错误字段的消息(例如,506b和506c)在本文中有时可以被称为错误消息(例如,因为它们指示或发信号通知错误)。

下图示出了与图5A所示的示例性消息(500)相关的存储控制器中的示例性功能模块。

图5B是图示了其中消息路由模块执行错误处置的存储控制器的实施例的框图。在这个示例中,存储控制器(550)被实现为SOC,并且位于主机(552)和NAND闪存存储装置(554)之间。存储控制器(550)如由主机(552)指示的那样读取和写入到NAND闪存存储装置(554)。

在这个示例中,存储在NAND闪存存储装置(554)上的数据在存储之前被纠错编码,并且因此从NAND闪存存储装置(554)读回的数据在其被传递至主机(552)之前必须由纠错解码器(556)解码。假设纠错解码器(556)不能解码所读取的数据,并输出第一输入消息(即,MSG In 1)(558),其具有设置成一的错误字段(参见例如图5A中的506b)。

在这个示例中,来自纠错解码器(556)的所有消息被传递至消息路由模块(560),并且因此消息路由模块(560)能够检查所有消息,并检测MSG In 1(558)是否具有特定错误代码或报告的错误的类型(例如,图5A中具有值为一的错误字段(506b))。在这个示例中,当纠错解码失败时,纠错解码器(556)输出错误消息(例如,其中错误字段是非零值)。

在一些实施例中,消息路由模块(560)被配置成寻找具有特定类型错误代码(例如,图5A中具有值为二的错误字段(506c))连同补充错误信息(例如,图5A中的508)的特定值的错误消息。

在这个示例中,消息路由模块已被编程或以其他方式配置成(当从纠错解码器(556)检测到那些类型的错误消息时)生成第一输出消息(即,MSG Out 1)(562),所述第一输出消息被发送至NAND闪存接口(564),并且其使得那个下游功能模块执行NAND闪存存储装置(554)的重新读取。重新读取使得新的读取数据被返回,并且然后新的读取数据可以被纠错解码器(556)处理。

在一些实施例中,由NAND闪存存储装置(554)上的NAND闪存接口(564)执行的所有读取是软读取,其中读取值伴有指示报告的读取值正确或与存储的事物匹配的确定性的可能性或置信度值(例如,与其中未报告可能性或置信度值的硬读取相反)。在这样的实施例中,软重新读取具有返回不同读取数据的高可能性,并且因此由纠错解码器(556)的重新尝试的解码将不是徒劳的尝试。

在一些实施例中,由MSG OUT 1(562)发起的重新读取改变了与重新读取相关联的读取配置或设置。例如,如果先前的读取是硬读取,则执行另一硬读取可能是不期望的,因为它可能具有返回基本相同的硬读取数据的高的可能性。在一些实施例中,如果先前的读取是硬读取,则重新读取(与MSG OUT 1(562)相关联)被指定或以其他方式配置成软读取,这可能需要更多时间和/或消耗更多带宽,但是在这种情况下是优选的,因为解码已经失败了至少一次。在一些实施例中,修改一些其他读取设置或参数以由MSG Out 1(562)重新读取。

存储控制器(550)还包括输出MSG In 2(568)的功能模块(566)。在这个示例中,消息路由模块(560)被配置成针对“需要重试”类型的错误消息(例如,具有被设置成特定值的错误字段和/或具有与要求重试相关联的特定补充错误信息)检验输入消息(例如,568)。如果检测到这样的消息,则消息路由模块(560)被配置成生成执行功能模块(566)的重试的MSG Out 2(570)。这样,MSG Out 2(570)被发送回到功能模块(566)并执行功能模块(566)的重试。例如,假设功能模块566实际上是NAND闪存接口(564),但是在上游功能模块容量中起作用。假设功能模块(566)/NAND闪存接口(564)尝试访问NAND闪存存储装置(554),但是它暂时不可用和/或繁忙。在这样的情况下,功能模块(566)/NAND闪存接口(564)可以发送具有“需要重试”类型的错误状态的MSG In 2(568),消息加速器(即,消息路由模块(560))使用MSG Out 2(570)将其重新提交作为重试命令。

注意,两个输入消息(558和568)不一定包含对应输出消息(562和570)最终发送到其的目的地和/或下游功能模块。换句话说,MSG In1(558)可以不一定使其目的地字段(例如,图4中的406c)填充有NAND闪存接口(564);消息路由模块(560)可以组装或以其他方式生成MSG Out 1(562)以在目的地字段中具有NAND闪存接口(564)。类似地,MSG In 1(558)可以不一定使其目的地字段(例如,图4中的406c)填充有功能模块(566);消息路由模块(560)组装或以其他方式生成MSG Out 2(570),其中那个目的地在报头中列出。

在一些情况下,多种类型的错误消息可以分组在一起,并以相同的方式处置。类似地,来自不同的上游功能模块的错误消息可以以相同或类似的方式处置(例如,生成相同的输出消息,但是目的地填充有不同的信息)。

如在这个示例中所示,在一些实施例中,SOC(进一步)包括存储控制器SOC;上游功能模块包括纠错解码器;下游功能模块包括与存储控制器SOC外部的存储介质通信的存储介质接口;并且分析输入消息包括:确定输入消息是否满足错误消息匹配标准(例如,这是否匹配给定消息检查引擎被配置成寻找的一种或多种类型的错误消息);并且在确定输入消息满足错误消息匹配标准的情况下,内容修改计划包括生成与重新读取存储介质相关联的输出消息,并且目的地控制计划包括将与重新读取存储介质相关联的输出消息导向到存储介质接口。

在一些这样的实施例中,内容修改计划进一步包括生成与重新读取存储介质相关联的输出消息,以改变与重新读取存储介质相关联的读取配置。例如,这可以包括从初始或较早的硬读取切换到软重新读取,改变读取阈值,或者改变与重新读取相关联的一些其他参数、设置或更多,使得它不同于初始或较早的读取。

如在这个示例中所示,在一些实施例中,内容修改计划包括生成与重新配置相关联的输出消息。例如,输出消息可以使得(例如,在下游功能模块和/或输出消息的目的地处)一个或多个寄存器设置被重写,导致模式或设置中的一些重新配置或改变(例如,输出消息是具有新的配置或设置值以及被写入的(多个)配置寄存器的位置或地址的写入消息)。在一些实施例中,内容修改计划包括生成与重试相关联的输出消息(例如,使得下游功能模块和/或输出消息的目的地处的重试)。

在一些实施例中,消息路由模块执行消息加速。下图图示了一些消息加速示例。

图6A是图示了具有序列信息的消息格式的实施例的图。在这个示例中,消息格式(600)包括报头(602)和有效载荷(604)。字段之一(606)包括从其接收消息的源或信道。在这个示例中,排序很重要(例如,对于上游功能模块和/或下游功能模块),并且因此有效载荷(604)包括序列信息(608),所述序列信息继而包括序列的开始(610)、序列的结束(例如,指示符或标志)(612)和序列号(614)。序列信息特定于每个源或信道,并且因此一个源或信道可能正在使用一个序列(或者在序列号的公共范围中的一点处),而另一源或信道可能正在使用不同的序列(或者在序列号的公共范围中的不同点处)。序列的开始(610)和序列的结束(612)是标志或指示符(例如,真或假),以指示给定源或信道的序列的(例如,相关的顺序消息的)相应开始和结束。

在一些应用中,消息将以无序的序列号(614)到达(例如,从给定的上游源或信道),并且下游功能模块将要求数据或消息处于(例如,严格递增)相继顺序中。在一些情况下,为了最大效率,期望在将输出消息发送到下游功能模块之前使所有的消息既按顺序又可用。例如,下游功能模块可以是共享资源,并且为了最佳使用,期望能够向下游功能模块“馈送”具有在其正确顺序中的序列号的所有的输出消息,并且在消息之间没有任何等待或空闲时间。总而言之,为了满足功能和/或接口要求和/或优化性能,可能期望:(1)对消息(或它们对应的感兴趣的内容)进行排序,因此序列号处于正确的(例如,升序)顺序中,和/或(2)确保在输出对应的输出消息之前已经接收到序列中的所有输入消息。在其他应用中,可能只需要将消息分组在一起,而与组内的序列顺序无关。例如,图6B中描述的逻辑到物理(L2P)的示例提供了没有显式序列控制的分组的示例。

为此,在一些实施例中,消息检查引擎执行与序列相关的消息加速(例如,确保序列号有序和/或所有的消息或信息按顺序存在)。为此,消息检查引擎(例如)检验源和目的地,以确定输入的消息是否与序列受限操作相关,并且如果相关,则检验序列的开始和序列的结束标志以及序列号,以确保消息在消息输出接口处以正确的序列顺序转发。下图示出了存储控制器SOC中与分组和/或序列相关消息加速相关联的功能模块的示例。

图6B是图示了存储控制器的实施例的框图,其中消息路由模块执行分组和/或序列相关消息加速。在这个示例中,存储控制器(650)被实现为SOC,并且位于主机(652)和NAND闪存存储装置(654)之间。存储控制器(650)如由主机(652)指示那样读取和写入到NAND闪存存储装置(654)。主机(652)使用并引用逻辑地址,而数据以物理地址存储在NAND闪存存储装置(654)上。逻辑和物理地址之间的逻辑到物理(L2P)映射存储在L2P DRAM(656)中,所述L2P DRAM(656)由L2P接口(658)访问和管理。

在这个示例中,可以针对L2P接口(658)的操作之一(例如,“打包”在一条或多条消息中)是比较和交换操作。比较和交换需要将大量的数据发送到L2P接口(658),并且由于实际的消息大小限制,需要多个消息来执行比较和交换。

比较和交换必须原子地进行,这意味着在L2P接口(658)从给定源接收用于给定比较和交换的一系列消息时,不应向L2P接口(658)发送来自其他源的命令和/或消息。

例如,假设第一个源(660a)生成与比较和交换操作相关联的S1MSG(662)。同时,存在其他源(例如,第n个源(660b)),所述源也生成消息(例如,导向到L2P接口(658)的SnMSG(666)),但是所述消息与第一个源(660a)的比较和交换操作不相关。

在这个示例中,消息路由模块(664)接收来自第一个源(660a)的S1MSG(662)以及来自第n个源(660b)的Sn MSG(666)。在这个示例中,当比较和交换消息(668)被发送到L2P接口(658)时,消息路由模块(664)将使得适当的模块保持和/或暂时存储Sn MSG(666),使得比较和交换消息(668)是原子的并且不被Sn MSG(666)中断。

在一些实施例中,为了改进性能和/或利用,在输出对应的比较和交换消息(668)之前,消息路由模块(664)等待从第一个源(660a)接收与比较和交换相关的所有输入消息(662)。例如,这在其中这样的输入消息(662)零星到达和/或其中消息之间具有不可忽略的延迟的应用中可能是期望的。

如果消息路由模块(664)未执行这个(例如,原子的)分组消息加速,则将需要在L2P接口(658)上存在一些锁定协议,以确保比较和交换消息不会被其他请求和/或其他源中断。例如,n个上游模块(例如,660a-660b)将需要实现协作仲裁或锁定机制,以防止在比较和交换消息序列正在进行时发送消息。这样的锁定功能可能是复杂的,并且减少了L2P接口(658)的利用和/或负面地影响上游模块(660a和660b)的大小、复杂性或性能,使得由消息路由模块(664)执行的(例如,原子的)分组消息加速至少在一些应用中是更有吸引力的选项。

在另一示例中,在至少在某些情况下,主机(652)预期导向到主机(652)的回复或通信是按顺序的(例如,涉及与主机相关联的一些序列顺序)。多个源(例如,660a-660b)可能正在生成(例如,最终)旨在针对主机(652)的消息,然而消息(例如,662和666)可能不一定按相继顺序到达。在这个示例中,为了确保遵循正确的排序,消息路由模块(664)被配置成检验相应的传入消息(例如,662和666)中的序列号,并确保在对应的主机回复消息(672)被生成并以正确的相继顺序输出到主机接口(670)(例如,对于给定的主机命令)之前,遵循相应的排序(例如,通过在适当的模块处保持消息或数据在序列中具有间隙,直到丢失的消息或数据到达)。注意,可以对输入消息流(662和666)独立地执行这个序列跟踪和/或监视,因为每个输入消息流具有其自己的、必须遵守的独立序列。

如在这个示例中所示,在一些实施例中,SOC包括存储控制器SOC;下游功能模块包括与由存储控制器SOC控制的L2P存储装置通信的逻辑到物理(L2P)接口;并且分析输入消息包括在对L2P存储装置的原子操作期间确定输入消息是否满足组外匹配标准,其中在确定输入消息满足组外匹配标准的情况下,所配置的消息检查引擎使得与组外匹配标准相关联的一个或多个消息至少暂时被保持。例如,如果第一个源(660a)正在发出与原子比较和交换操作相关联的S1MSG(662),而第n个源(660b)正在并发地和/或同时地输出也被导向到L2P接口(658)的Sn MSG(666),则在执行来自第一个源(660a)的比较和交换的同时,消息路由模块(664)将暂时保留和/或不向L2P接口(658)传递来自第n个源(660b)的消息。

如在这个示例中所示,在一些实施例中,SOC包括存储控制器SOC;下游功能模块包括与存储控制器SOC外部的主机通信的主机接口;并且分析输入消息包括确定输入消息是否满足失序匹配标准,其中在确定输入消息满足失序匹配标准的情况下,所配置的消息检查引擎使得与失序匹配标准相关联的一个或多个消息至少暂时被保持。例如,消息路由模块(664)将确保对应于来自第一个源(660a)的S1MSG(662)的主机MSG(672)将处于正确的(例如,主机强制的)排序中,即使S1MSG(662)在消息路由模块(664)处被无序接收。类似地,消息路由模块(664)将(例如,独立地)强制和/或确保在对应于来自第n个源(660b)的SnMSG(666)的主机MSG(672)中遵循正确的序列。

虽然已经出于清楚理解的目的相当详细地描述了前述实施例,但是本发明不限于所提供的细节。存在实现本发明的许多替代方式。所公开的实施例是说明性的,并且不是限制性的。

相关技术
  • 一种食品检测用样品采集方法
  • 一种可新风采集的食品检测用样品盛放装置
技术分类

06120116550888