首页> 中国专利> 处理不期望的完成分组和具有非成功完成状态的完成分组的方法

处理不期望的完成分组和具有非成功完成状态的完成分组的方法

摘要

在计算机系统中,请求设备和完成器设备经由高速串行接口而耦合。请求设备向完成器设备传输用于请求事务的分组。完成器设备在服务该请求期间检查错误情况。如果发现错误情况,完成器设备传输具有除了成功以外的其他完成状态的完成分组。完成分组包括完成器标识字段。请求设备记录完成器标识值,并且在寄存器中指示已经接收到具有非成功完成状态的完成分组。

著录项

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2022-12-23

    专利权有效期届满 IPC(主分类):G06F13/40 专利号:ZL028261593 申请日:20021206 授权公告日:20070704

    专利权的终止

  • 2007-07-04

    授权

    授权

  • 2005-06-22

    实质审查的生效

    实质审查的生效

  • 2005-04-20

    公开

    公开

说明书

技术领域

本发明一般地涉及计算机系统领域。更具体地说,本发明涉及高速点对点互连和通信体系结构领域。

背景技术

计算装置,例如计算机系统、服务器、网络交换机和路由器、无线通信设备以及其它电子设备,一般由许多不同的元件组成。这些元件通常包括处理器、系统控制逻辑、存储器系统、输入和输出接口等。为了促进这样的元件之间的通信,计算装置长期依赖于通用输入/输出总线,以使得该计算系统的这些不同的元件能够互相通信来支持由这样的装置提供的种种应用。

这种通用总线体系结构最普遍的一种形式或许就是外围组件互连(PCI)总线。PCI总线标准(1998年12月18日发布的外围组件互连(PCI)局域总线规范,修订版2.2)定义了多接点式(multi-drop)、并行总线体系结构,用于在计算装置中以仲裁的方式来互连芯片、扩充板以及处理器/存储器子系统。典型的PCI总线实现具有133Mbps的吞吐量(即,33兆赫兹32位),而PCI 2.2标准允许每个管脚64位的并行连接,时钟达到133MHz,从而产生超过1Gbps的理论吞吐量。

直到最近,由PCI总线体系结构提供的吞吐量已经提供了足够的带宽来适应即使是最先进的计算装置(例如,多处理器服务器应用、网络装置等)的内部通信需要。然而,最近处理能力的发展和输入/输出带宽需求的增长产生了这样的情形:诸如PCI总线体系结构的现有的通用体系结构已经变成这样的计算装置中的瓶颈。

与现有体系结构相关联的另一个限制是,它们通常不能很好的适合于处理同步(时间相关)数据流。同步数据流的一个例子是多媒体数据流,该多媒体数据流需要传输机制来确保数据消耗与数据接收一样快,并且保证音频部分与视频部分同步。传统的通用输入/输出体系结构异步处理数据,或以带宽允许的随机时间间隔处理数据。这种多媒体数据的异步处理可能导致丢失数据和/或音频和视频错位。

附图说明

从下面给出的详细描述和本发明的实施例的附图,将更完整地理解本发明,但是不应该将它们认为是将本发明限制到所描述的具有的实施例,它们只是用于解释和理解。

图1是计算机系统的一个实施例的方框图。

图2是示例性增强型通用输入/输出端口的图形表示。

图3是示出了事务层分组头部的开始的一个实施例的格式的示图。

图4是支持32位地址格式的请求分组头部的示图。

图5是支持64位地址格式的请求分组头部的示图。

图6是消息的分组头部的示图。

图7是示出了配置事务的请求头部格式的示图。

图8是示出了完成头部的格式的一个实施例的示图。

图9a和9b结合形成用于处理接收的事务层分组的方法的示例性实施例的流程图。

图10是用于处理与接收的请求分组相关联的错误情况的方法的一个

实施例的流程图。

图11是用于处理系统代理不期望的完成分组的方法的一个实施例的流程图。

图12是请求设备处理具有除了“成功完成”以外的完成状态的完成分组的方法的一个实施例的流程图。

图13是完成设备处理具有除了“成功完成”以外的完成状态的完成分组的方法的一个实施例的流程图。

具体实施方式

下面描述用于提供在电子装置中使用的可升级和可扩展的通用输入/输出通信平台的基于分组的点对点互连体系结构、通信协议和相关方法的实施例。所公开的实施例涉及增强型通用输入/输出互连体系结构和相关联的通信协议。一个示例性实施例包括根复合体(root complex)、交换器或端点(endpoint)中的一个或多个,所述根复合体包括主桥,其中每个至少结合了增强型通用输入/输出特征的一个子集以支持这些元件之间的增强型通用输入/输出通信。

在一个实施例中,使用串行通信信道来执行这些元件的增强型通用输入/输出设备之间的通信,所述串行通信信道使用这样的通信协议,所述协议支持一个或多个创新特征,所述创新特征包括但不局限于虚拟通信信道、基于尾部(tailer)的错误转发(error forwarding)(“尾部”附接在事务层分组以指示错误情况)、对老式(legacy)的基于PCI的设备的支持、多种请求响应类型、流控制和/或数据完整性管理功能。在该实施例中支持的通信协议包括通信协议栈,该通信协议栈包括物理层、数据链路层和事务层。

在另一个实施例中,通信代理结合了增强型通用输入/输出引擎,该引擎包括上述特征的子集。此外,各种实施例的一个或多个元件可以以硬件、软件、传播信号或它们的结合来实现。

图1提供了电子装置100的方框图,对于本实施例,该电子装置100是计算机系统。系统100包括处理器102、作为根复合体104的一部分的主桥103、交换器108以及端点110,每个元件都如所示地进行耦合。根复合体104、交换器108以及端点110包括增强型通用输入/输出通信端口106的一个或多个实例。如所示,元件102、104、108和110中的每一个都经由增强型通用输入/输出通信端口,通过通信链路112,耦合到至少一个其它元件,其中通信链路112支持一条或多条增强型通用输入/输出通信信道。系统100意于代表多种传统和非传统计算系统、服务器、网络交换器、网络路由器、无线通信用户单元、无线通信电话基础设施元件、个人数字助理、机顶盒或任何电子装置中的任何一个或多个,所述任何电子装置将从通过集成这里描述的增强型通用输入/输出互连体系结构和/或通信协议的至少一个子集而引入的通信资源获益。

在该示例性实施例中,处理器102控制电子装置100的功能性能力的一个或多个方面。在这个方面,处理器102可以代表多种控制逻辑设备的任何一个,控制逻辑设备包括但不局限于微处理器、可编程逻辑器件(PLD)、可编程逻辑阵列(PLA)、专用集成电路(ASIC)、微控制器等等的一个或多个。

根复合体104提供处理器102和交换机108和端点110之间的通信接口。如这里所使用的,术语“根复合体”指的是最靠近于主控制器、存储器控制器中心、IO控制器中心或者上述元件的任何组合或芯片组/CPU元件的某种组合(即,处于计算系统环境)的增强型通用输入/输出层次的逻辑实体。尽管在图1中被描述为单个单元,根复合体104可以由多个物理组件实现。根复合体104组装有一个或多个增强型通用输入/输出端口106以便于与其它外围设备进行通信,所述外围设备例如是交换器108、端点110以及老式桥114或116,尽管没有对老式桥114或116进行具体描述。在一个实施例中,每个增强型通用输入/输出接口端口代表不同的层次域。在此方面,图1的实施例表示了具有三个层次域的根复合体104。

图2是示例性增强型通用输入/输出端口106的图形表示。如所示,在该实施例中,增强型通用输入/输出端口106实现了通信栈,该通信栈包括事务层202、数据链路层204和物理层206,该物理层206包括逻辑子块208和物理子块210。事务层的每个元素都将在下面进行详细讨论。

事务层202提供增强型通用输入/输出体系结构和设备核心之间的接口。事务层202的主要职责是为代理中的一个或多个逻辑设备装配和拆解分组。

增强型通用输入/输出体系结构的一个主要目标是最大化设备间通信效率。在一个实施例中,事务层实现了管道完全分离事务协议(pipelined fullsplit-transaction protocol)和用于区分事务层分组的排序和处理需求的机制。事务层还包括事务层分组构造和处理。

增强型通用输入/输出体系结构的一个实施例支持下面的基本事务类型和地址空间:存储器、I/O、配置和消息。支持两种寻址类型:32位和64位。

使用请求和完成分组来承载事务,请求和完成分组可以简称为请求和完成。只有在需要例如返回读取数据或者通知I/O和配置写入事务的完成时,才使用完成。完成通过分组头部的请求器ID(下面讨论)中的值来与它们对应的请求相关联。

在本实施例中的所有事务层分组以定义的头部开始。某些事务层分组包括有跟随头部的数据,这是由在事务层分组头部中指明的格式字段决定的。事务层分组的大小受到预定最大有效负载大小值的限制。在本实施例中的事务层分组数据是四字节自然对齐的,并且以四字节双字来递增。

图3是示出了事务层分组头部的开始的一个实施例的格式的示图。每个事务层分组头部包括三位格式字段(格式[2:0])。事务层分组头部还包括四位类型字段(类型[3:0])。格式字段和类型字段都需要被解码以决定事务层分组格式。下面的表1示出了用于格式字段的示例性编码。

000 2个双字头部,无数据001 3个双字头部,无数据002 4个双字头部,无数据101 3个双字头部,有数据110 4个双字头部,有数据

表1—格式字段编码

本实施例的事务层头部还包括2位扩展类型/扩展长度字段(Et/El)。该字段用于扩展类型字段或者长度字段,这取决于类型字段中的值。该实施例的长度字段一般是八位字段,但是如果类型字段的值指示要使用Et/El字段来扩展长度字段,则长度字段可以扩展为十位字段。取决于类型[3:0]字段中的值,通过附接Et/El字段,类型字段可以被扩展为六位字段。见下面的图2示例的格式、类型和Et/El字段编码(其他的实施例可以使用其他编码策略)。除非特别指出,Et/El字段被用作类型字段的扩展。

分组类型 格式 [2:0] 类型 [3:0] Et/El[1:0]描述MRd 001 010 1001 E19 E18存储器读取请求Et/El字段用于长度[9:8]MRdLk 001 010 1011 00存储器读取请求—锁定MWr 101 110 0001 E19 E18存储器写入请求—公布Et/El字段用于长度[9:8]IORd 001 1010 00IO读取请求IOWr 101 1010 00IO写入请求CfgRd0 001 1010 01配置读取类型0CfgWr0 101 1010 01配置写入类型0CfgRd1 001 1010 11配置读取类型1CfgWr1 101 1010 11配置写入类型1Msg 010 011s2 s1s0消息请求—子字段s[2:0]指明一组消息。该消息字段必须被解码以确定包括是否需要完成的特殊周期MsgD 110 001s2 s1s0带有数据的消息请求—子字段s[2:0]指明一组消息。该消息字段必须被解码以确定包括是否需要完成的特殊周期。MsgComm 110 110c2 c1c0用于高级交换的消息—子字段c[2:0]指明消息类型:000—单播,数据分组001—组播,数据分组010—信令分组,无中断011—保留100—空信令分组,到目的地层次中的主机的中断
101—空信令分组,到目的地设备的中断110—信令分组,具有到目的地层次中的主机的中断111—信令分组,具有到目的地设备的中断CPl 001 0100 00不带有数据的完成—用于具有除“成功完成”之外的完成状态的存储器读取完成、IO和配置写入完成CplD 101 0100 E19 E18带有数据的完成—用于存储器、IO和配置读取完成Et/El字段用于长度[9:8]CplDLk 101 0101 01锁定存储器读取的完成

表2—格式、类型和Et/El编码

请求分组包括请求头部,对于某些类型的请求分组,所述请求头部将跟随有一定数量的双字的数据。这里使用的术语“双字”指示32位长度的数据。对于该示例性实施例,除了对于明确引用数据长度的消息外,不使用消息请求头部的长度字段。并且对于该实施例,对于存储器读请求和存储器写请求,Et/El字段与长度字段连接以形成十位长度字段。十位长度字段允许指示多达4kB数据的读取和写入请求。其他类型的事务层分组受到长度[7:0]字段的大小的限制而指示最多1kB的数据。在一个实施例中,任何事务层分组所包含的数据量都受预定最大有效负载大小的限制。对于包括数据的事务层分组,长度字段中的值应该与实际的数据量相等。如果接收者判断长度字段值与真实的数据量不匹配,则该分组被认为是畸形事务层分组。下面描述畸形事务层分组。

图4是支持32位地址格式的请求分组头部的示图,并且图5是支持64位地址格式的请求分组头部的示图。对于一个实施例,存储器读取请求和存储器写入请求情况或者使用32位地址格式,或者使用64位地址格式。对于低于4GB的地址,使用32位格式。

图4和图5的请求分组头部还包括第一双字字节使能字段(1stDWBE)和最后双字字节使能字段(最后DW BE)。第一双字字节使能字段包括用于任何存储器读取或写入请求的第一双字的字节使能。该字段还包括用于输入/输出或配置请求的仅有双字的字节使能。最后双字字节使能字段包括用于任何存储器读取或写入请求的最后双字的字节使能。字节使能字段不用于消息,这是因为这些字段覆盖消息请求头部的消息编码字段(见图7,下面讨论)。

对于一个实施例,对于字节使能字段的每个位,值“0”指示在完成器处,对应的数据的字节未被写,或者,如果是不可预取的则未被读。这里使用的术语“完成器”意为指示由请求分组头部寻址的逻辑设备。值“1”指示在完成器处,对应的数据的字节被写,或者,如果是不可预取的则被读。对于第一双字字节使能字段,位0对应于数据的第一双字的字节0。位1对应于数据的第一双字的字节1。位2对应于数据的第一双字的字节2。位3对应于数据的第一双字的字节3。对于最后双字字节使能字段,位0对应于数据的最后双字的字节0。位1对应于数据的最后双字的字节1。位2对应于数据的最后双字的字节2。位3对应于数据的最后双字的字节3。

图4、5、6和8的示例性分组头部包括请求器ID字段、标签字段、属性字段和虚拟信道ID字段。请求器ID字段和标签字段一起形成事务ID字段。请求器ID字段被分成总线号码字段、设备号码字段和功能号码字段。

标签字段是由每个请求设备生成的5位字段。标签值对于需要为该请求设备完成的所有未完成请求是唯一的。所有的请求和完成包括事务ID字段。对于这些示例性实施例,请求器ID字段是对于每个功能(功能是由唯一功能号码在配置空间中标识的多功能设备的一个独立段)唯一的16位值。功能捕获提供总线号码,该总线号码被提供有由该功能完成的所有配置写入,并且在请求器ID字段的总线号码字段中供应该号码。元件中的每个逻辑设备被设计为响应唯一的设备号码,以用于寻址该元件的配置请求。对于这些示例性实施例,元件可以包含许多(可能多达几十个)逻辑设备。与元件中的逻辑设备相关联的每个功能被设计来响应唯一的功能号码,以用于寻址该元件和逻辑设备的配置请求。每个逻辑设备可以包含多达八个逻辑功能。

属性字段指明事务的特征。可以在属性字段中指明的属性包括优先级属性、事务排序属性和高速缓存一致性管理属性。

虚拟信道ID字段标识虚拟信道。对于这些示例性实施例,虚拟信道ID字段是4位字段,其允许标识为每个事务标识多达16个虚拟信道。对于这些示例性实施例,虚拟信道0用于通用流量,而除了0的虚拟信道用于同步流量。

图6是消息的分组头部的示图。如表2所示,消息可以包括或不包括数据,并且可以需要或不需要完成。消息由支持增强型通用输入/输出互连体系结构的系统中的所有设备解码。

对于消息请求,消息字段被解码以判断特殊循环并且判断消息是否包括数据以及消息是否需要完成。该实施例的消息字段是8位字段,其位于对于其他事务类型而言字节使能字段通常驻留的位置。接收设备把不支持的消息作为无需完成来对待(下面讨论无需完成事务)。

该示例性实施例的消息被分成组。有八组包含伴随请求的数据,有八组不包含。利用不同数目的组的其他实施例是可能的。对于该实施例,如表2所示,包括伴随请求的数据的八组在格式字段具有值b110。不包含数据的八组在格式字段中具有值b010。子字段s[2:0]结合来自类型字段的一位和来自Et/El字段的两位。子字段s[2:0]指示八组之一。

可以实现的各种消息的示例包括,但不限于下列消息:用于解锁设备的消息;用于复位设备的消息;指示可纠正错误情况的消息;指示不可纠正错误情况的消息;指示致命错误情况的消息;用于报告坏请求分组的消息;关于功率管理的消息;关于排序控制/管理的消息和用于模拟老式(例如,PCI)中断信号(或其他老式信号)的消息。这些各个消息类型可以划分到前面讨论的组的一个中。例如,所有的功率管理消息可以包括在一个组中,而中断信令消息可以包括在另一个中。

图7是示出了配置事务的请求头部格式的示图。配置空间是这些示例性实施例的四个支持的地址空间的一个。

图8是示出了完成头部的格式的一个实施例的示图。所有读取请求和某些写入请求需要完成。完成包括完成头部,对于某些类型的完成,完成头部跟随有一定数量的双字的数据。示于图8中的完成状态[2:0]字段指示完成的状态。表3示出了一个示例性编码策略。

完成状态[2:0]状态000成功完成001不支持请求—期望完成011保留100完成器中止

表3—完成状态字段编码策略

完成器ID[15:0]字段包含与上面描述的请求器ID字段相同类型的信息。在完成器ID字段中提供的值对应于完成该请求的代理的总线/设备/功能。完成头部包含的请求器ID、标签和信道ID的值与在请求分组的头部中供应的相同。完成头部在属性字段包含的值也与初始供给请求的头部的相同。完成分组被交换机和根复合体路由到发起对应的请求事务的端口。

对于存储器读取请求事务,单个完成分组可能提供少于对应的读取请求所请求的完全的数据量,只要与该对应的读取请求相关联的所有完成分组结合起来返回指明的数据量即可。对于这些示例性实施例,I/O和配置读取请求仅由一个完成分组来完成。

包括数据的完成指明分组头部中的数据量。如果完成分组实际上包含不同于指明的量的数据量,则产生畸形事务层分组。

图9a和9b结合形成用于处理接收的事务层分组的方法的示例性实施例的流程图。下面描述的操作不必以连续的方式发生。一些实施例可以同时进行某些操作。在方框905,进行检查以判断接收的分组的格式和长度字段中包含的值是否匹配分组的真实大小。不匹配指示畸形分组,并且产生错误情况,如方框925所示。下面将讨论错误情况处理。如果接收的分组的真实大小不指示与格式和长度字段的不匹配,则处理继续到方框910。

如果接收的分组是使用64位寻址的存储器请求,则在方框910,检查地址位[63:32]以观察是否地址位[63:32]的任何一个为非零。如果地址位[63:32]都不是非零,则结果是畸形分组,并且处理进行到错误情况方框925。如果地址位[63:32]的至少一个为非零,则处理继续到方框915。

在方框915,进行检查以判断是否分组头部中的任何字段包含保留值。如果发现保留值,则结果是畸形分组,并且处理进行到方框925。如果没有发现保留值,则处理进行到方框930。

在方框930,进行关于分组是请求分组还是完成分组的判断。如果分组是完成分组,则处理进行到完成处理方框935。下面将更完整地讨论完成处理。如果接收的分组不是完成分组,则处理继续到方框940。注意,所有流到方框940的分组都是请求分组。

在方框940,进行检查以判断请求分组是否是完成设备支持的请求类型。如果不支持该请求类型,则结果是不支持的请求,并且处理进行到错误情况方框925。对于该示例性实施例,如果不支持请求类型是广播消息或者使用为广播消息保留的编码的消息,则分组被默默地丢弃,并且不产生错误情况。如果完成设备支持该请求类型,则处理继续到方框945。

如果,如方框945所示,完成设备由于内部错误而不能响应请求分组,则结果是“完成器中止”,并且处理进行到错误情况方框925。否则,在方框950服务该请求。在服务该请求中,可能需要重复方框940和945的处理。

一旦成功地服务该请求,则处理继续到方框955。如方框955所指示的,如果所处理的请求需要完成,则在方框960返回完成分组。

图10是用于处理与接收的请求分组相关联的错误情况的方法的一个实施例的流程图。如在方框1010所见到的,如果接收的请求期望完成,则在方框1020传输具有适合的完成状态的完成。该完成被路由回请求设备。如果接收请求不期望完成,则在方框1030向请求设备传输错误消息。在方框1040向系统报告错误。在方框1030指示的错误消息传输操作可以实现为可编程的选项。

某些系统除了可以包括前面讨论的增强型通用输入/输出互连结构外,还可以包括一个或多个PCI总线。对于经过了增强型通用输入/输出互连结构并且目的地为PCI总线上的设备的存储器、I/O和配置请求,这些实施例的完成状态表示该周期的真实PCI终止。例如,非公布PCI周期必须在可以确定完成状态之前真实地在PCI总线上被服务。对于所有其他情况,完成状态值定义如下。

当请求被完成设备成功地完成时,产生的完成状态值是“成功完成”(对于该实施例,如表3中所示,在完成状态字段编码为“000”)。例如,来自主桥的读取请求被路由通过交换机到达完成器端点。完成器以指示成功完成状态的完成分组来响应,并且还以该读取请求的数据来响应。交换机将该完成分组路由回主桥。

当完成设备接收并解码请求,但是完成分组不支持所请求的事务并且该请求需要完成时,产生的完成状态是“不支持的请求”(对于该实施例,如表3中所示,在完成状态字段编码为“001”)。不支持的请求的一个示例是对于超范围地址的存储器读取请求。在这种情况下,完成器不能支持该请求,并且该请求期望完成。

对于完成设备接收并解码请求并且完成设备不能支持所请求的事务并且请求设备不期望完成时,产生的完成状态是不支持的请求。因为请求设备不期望完成,所以完成状态经由如上面联系图10描述的消息被传递到请求设备。请求设备不期望完成的不支持请求的一个示例是对超范围地址的存储器写入事务。经由消息的完成状态的通信可以实现为可选的特征。

当完成设备接收并解码请求,但是完成设备由于内部错误而不能响应时,产生的完成状态是“完成器中止”(对于该实施例在完成状态字段中编码为“100”)。

当完成设备接收违反分组格式规则的分组时,结果是“畸形分组”。完成设备通过传输“畸形分组”错误消息来响应这种情况,该错误消息被路由到请求设备。对于本实施例,如果没有其他端口可以被确定地识别为预期的目的地端口,则接收畸形分组的交换机必须将该分组路由到上游端口。

当读取完成具有除了“成功完成”以外的完成状态时,没有数据与完成分组一起返回。具有非成功完成状态的读取完成是为该请求而传输的最后的完成。例如,完成器可以将读取请求分成四部分来服务,并且第二完成分组导致完成器中止完成状态。最后两个完成分组不被传输。一旦请求设备接收具有非成功完成状态的完成分组,则认为请求结束,并且不应该期望对应于该读取请求的其他完成分组。

图11是用于处理系统代理不期望的完成分组的方法的一个实施例的流程图。当代理接收了不对应于由同一代理发出的任何未完成请求的完成时,发生“不期望的完成”。对于图11的示例性方法,方框1110指出如果没有不期望的完成,则在方框1120处继续正常的操作,但是,如果接收了不期望的完成,则该不期望的完成分组在方框1130被丢弃。在分组被丢弃之后,上述错误情况可以在方框1140被报告给系统。对于该示例性实施例,错误报告可以是由软件可编程的选项。

图12是请求设备处理具有除了“成功完成”以外的完成状态的完成分组的方法的一个实施例的流程图。方框1210指出如果完成状态是“成功完成”,则在方框1220处继续正常的操作。如果完成状态不是“成功完成”,则在方框1230记录完成器ID字段的值。对于该实施例,完成器ID值存储在寄存器中。接着,在方框1240,在该实施例的请求设备中的寄存器中设置“接收不成功完成”位。可以在方框1250报告上述错误情况。错误情况报告可以实现为可编程的选项。软件代理可以使用完成器ID值和“接收未成功完成”位来跟踪错误情况的源。

图13是完成设备处理具有除了“成功完成”以外的完成状态的完成分组的方法的一个实施例的流程图。方框1310指出如果传输的完成分组的完成状态是“成功完成”,则在方框1320处继续正常的操作。如果完成状态不是“成功完成”,则在方框1330记录请求器ID和标签字段的值。对于该实施例,请求器ID和标签值存储在一个或多个寄存器中。接着,在方框1340,在该实施例的完成设备中的寄存器中设置“传输不成功完成”位。可以在方框1350报告上述错误情况。错误情况报告可以实现为可编程的选项。软件代理可以使用请求器ID和标签值和“传输未成功完成”位来跟踪错误情况的源。

在前面的说明中,已经参照本发明的具体的示例性实施例描述了本发明。但是,明显的是,可以对其做出各种修改和变化,而不背离本发明的所附权利要求中阐明的更广的技术构思和范围。因此,说明书和附图应该被认为是说明性的,而不是限制性的。

在说明书中引用的“实施例”、  “一个实施例”、“某些实施例”或“其他实施例”是指结合该实施例描述的特定的特征、结构和特性至少包括在本发明的某些实施例中,但不必是所有实施例中。出现的各种“实施例”、“一个实施例”或“某些实施例”不必指相同的实施例。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号