技术领域
[0001] 本申请涉及集成电路设计和制造领域，特别涉及包含USB主机控制器的集成电路技术。
相关背景技术
[0002] USB(通用串行总线)是一个外部总线标准，用于规范电脑与外部设备的连接和通讯。USB技术已经被广泛使用，目前已经发展到了3.X的版本。
[0003] USB的一个常规应用是传输文件，但是，本申请的发明人发现，USB在传输大文件时的传输速率远高于传输同样数据量的多个小文件的传输速率。而在不少应用场景中，存在大量的小文件需要被传输。如何使得USB技术可以提高传输大量小文件的速率，这是需要解决的一个重要问题。
[0004] 此外，USB3.x定义了管道的概念，管道即应用软件(下文中也称为“软件”)和设备之间的数据通道，由于能发起数据传输的不仅仅是软件，容易造成管道之间的优先级别混乱，在因为意外中断传输之后，容易丢失当前传输的数据指针，导致在断点续传的时候发生冗余传输。
具体实施方式
[0057] 在以下的叙述中，为了使读者更好地理解本申请而提出了许多技术细节。但是，本领域的普通技术人员可以理解，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。
[0058] 部分概念的说明：
[0059] USB，Universal Serial Bus，通用串行总线
[0060] TRB：Transfer Request Block，传输请求块
[0061] TR：Transfer Ring,传输环
[0062] Endpoint：端点
[0063] XHCI：eXtensible Host Controller Interface，可扩展的主机控制器接口是英特尔公司开发的一个USB主机控制器接口
[0064] SoC：System-on-a-chip，系统单芯片
[0065] PIPE：管道
[0066] DMA：Direct Memory Access，直接内存存取
[0067] 下面概要说明本申请的部分创新点：
[0068] 目前USB3.X的协议在传输大量的小文件时传输速度缓慢，远低于相同总数据量的大文件的传输速度。然而，文件的传输一般是应用软件发起的，从应用层到物理层，导致小文件传输速度缓慢的可能原因有很多，例如应用程序层面的原因，操作系统层面的原因，驱动软件的原因，USB层面的原因等等。而且这些原因仅仅是原因的大致类别，每一种类别还会有许多种具体的因素会导致小文件传输缓慢。
[0069] 在众多的原因中，本发明的发明人创造性地发现，如果能够为一个Endpoint配置至少两个传输线程(目前USB协议中一个Endpoint在进行传输时只支持一个传输线程)，在内存中分别为这些传输线程分别配置传输环，当一个传输线程传输结束时，直接切换到已经配置好传输环的其他传输线程传输，就可以大大提高大量小文件的传输速度。USB传输过程中，每一次传输请求的执行都需要多次DMA请求，对于小数据传输，大都是在获取USB设备的各种信息，如果每次传输都重复地获取这些信息，传输完成之后USB设备信息会被释放，下次传输又要重新获取，这样会造成大量的带宽浪费，如果利用多线线程传输，在一次性获得USB设备的信息之后，把小数据放在不同的线程中，在线程之间做切换传输，一个线程在传输的时候，软件可以准备另一线程的数据，就省去了获取USB设备的信息的MDA请求的时间，这样就提高了传输效率。
[0070] 此外，本申请将USB PIPE至少分为软件请求、周期性请求、保存的请求和未就绪的请求四个，通过这种对USB PIPE的分类管理，可以方便地控制传输优先级和精确定位到断点续传的位置，进一步提高的USB传输的性能。
[0071] 为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请的实施方式作进一步地详细描述。
[0072] 本申请的第一实施方式涉及一种USB传输设备，其基本结构如图1所示，该设备包括：
[0073] 配置模块101，用于在内存中针对一个端点配置对应于第一传输线程的第一传输环和对应于第二传输线程的第二传输环。也就是说为同一个端点配置至少两个传输线程及其传输环。在配置超过两个传输线程的实施例中，其中任意的两个传输线程都可以被认为是第一传输线程和第二传输线程。
[0074] USB的主机控制器102，用于在第一传输线程传输结束时，根据已经配置的第二传输环直接进行第二传输线程的传输。
[0075] 在一个实施例中，对现有的USB协议的配置端点命令进行改进，使得配置端点命令中包括第一和第二传输环的初始出栈指针；当主机控制器执行配置端点命令时，把该配置端点命令中第一和第二传输环的初始出栈指针复制到设备上下文中。
[0076] 在一个实施例中，该USB传输设备还包括：
[0077] 软件请求缓存，用于保存由软件发起的传输请求的管道标识。
[0078] 周期性请求缓存，用于保存周期性的传输请求的管道标识。
[0079] 保存的请求缓存，用于保存因为传输机会用完而中断后需要等待下一个传输机会续传的传输请求的管道标识。
[0080] 未就绪的请求缓存，用于保存由于USB设备返回未就绪信号而中断的传输请求的管道标识。
[0081] 仲裁器，用于传输仲裁，从软件请求缓存、周期性请求缓存、保存的请求缓存和未就绪的请求缓存中选择一个传输请求进行传输。
[0082] 传输管理模块，用于对仲裁器所选择的传输请求的数据传输过程进行管理。
[0083] 管道信息缓存，用于缓存N个管道对应的传输请求的信息，其中N为正整数。
[0084] 管道信息载入模块，用于针对仲裁器选择的传输请求，从管道信息缓存加载该传输请求的信息。
[0085] 传输管理模块还用于在传输过程中或者传输结束后，向管道信息模块传送当前管道的各种状态信息，管道信息模块用于根据当前传输状况决定是否把管道信息写回到管道信息缓存。
[0086] 周期性传输管理模块，用来管理同步和中断两种周期性传输，当软件对一个端点请求一个周期性传输之后，周期性传输管理模块保存该请求，并根据该端点的特性周期性地发起传输请求。
[0087] 在一个实施例中，上述软件请求缓存、周期性请求缓存、保存的请求缓存和未就绪的请求缓存分别包括N个寄存器，每个寄存器对应管道信息缓存中的一个管道。每个寄存器有一个地址，例如1、2、3、……。该寄存器地址作为管道标识实现寄存器与管道信息缓存中管道的地址对应，即这个地址也用来从管道信息缓存中读取相应管道的信息。例如周期性请求缓存的地址为3的寄存器被设为1时，该地址3就是管道标识，表示标识为3管道属于周期性请求。又如保存的请求缓存中地址为3的寄存器被设为0时，表示标识为3管道不属于保存的请求。
[0088] 本申请的第二实施方式涉及一种USB传输方法，其流程如图2所示，该方法包括：
[0089] 在步骤201中，在内存中针对一个端点配置对应于第一传输线程的第一传输环和对应于第二传输线程的第二传输环。
[0090] 在步骤202中，USB的主机控制器在第一传输线程传输结束时，根据已经配置的第二传输环直接进行第二传输线程的传输。
[0091] 因为一个端点配置了两个传输线程，所以主机在处理各种命令时的处理方式也会有相应的变化，这些变化在下面的实施例中进行说明。
[0092] 下面各实施例中，配置端点命令、设置TR出栈指针命令、停止端点命令、传输命令等命令都是现有的USB协议中已有的命令，本申请实施例中的改进主要在主机执行这些命令时的处理方式有改进，部分命令(例如配置端点命令等)中的信息会有改进。以下各个实施例中未提到的部分，例如命令的来源等，实现方式与现有协议相同，本申请中不再详细说明了。
[0093] 在一个实施例中，配置端点命令中包括第一和第二传输环的初始出栈指针；当主机控制器执行配置端点命令时，把该配置端点命令中第一和第二传输环的初始出栈指针复制到设备上下文中。
[0094] 在一个实施例中，当主机控制器执行设置TR出栈指针命令时，选择性地设置第一线程或第二线程的传输环出栈指针。
[0095] 在一个实施例中，当主机控制器执行设置停止端点命令时，同时停止该端点正在执行的所有线程，并且保存当前所有正在执行的线程的传输环出栈指针。
[0096] 在一个实施例中，当主机控制器执行传输命令时，对当前停止的所有线程都要继续执行。
[0097] 在一个实施例中，当端点出现传输错误，需要停止当前端点时，停止该端点的所有线程。
[0098] 在一个实施例中，该方法还包括：
[0099] 如果软件发起的传输请求是周期性的，则将该传输请求的管道标识保存到周期性请求缓存，否则将该传输请求的管道标识保存到软件请求缓存；
[0100] 如果一个传输请求的传输机会用完而中断后需要等待下一个传输机会续传，则将该传输请求的管道标识保存到保存的请求缓存；
[0101] 如果一个传输请求由于USB设备返回未就绪信号而中断，则将该传输请求的管道标识保存到未就绪的请求缓存；
[0102] 从软件请求缓存、周期性请求缓存、保存的请求缓存和未就绪的请求缓存中选择一个传输请求进行传输；
[0103] 针对被选择的传输请求，从管道信息缓存加载该传输请求的信息；
[0104] 在传输过程中或者传输结束后，根据当前传输状况决定是否把管道信息写回到管道信息缓存；
[0105] 其中，管道信息缓存用于缓存N个管道对应的传输请求的信息，N为正整数。
[0106] 为了能够更好地理解本申请的技术方案，下面结合一个具体的例子来进行说明，该例子中罗列的细节主要是为了便于理解，不作为对本申请保护范围的限制。
[0107] 一个USB主机需要同时支持的设备可达127个设备，每个设备可以最大支持31个Endpoint，现实应用中几乎不可能127个设备的每个Endpoint同时都在进行传输(同时传输的线程可以达到127x31＝3937个)，如果我们为每个Endpoint都配备上足够的资源让527个Endpoint可以同时传输，那么将造成资源的极大浪费，所以我们只需要同时可以支持数量不多资源的Endpoint可以同时传输就行了，如果极端情况下资源消耗光了，那么软件可以排队等待前面的某个Endpoint传输完成，再提交传输请求。
[0108] 所以本申请描述的就是如何在有限资源下进行USB PIPE的调度管理。包括如何在一个PIPE的Service Opportunity(传输机会)用完的时候切换到下一个PIPE，当一个PIPE因为传输出错或者收到Device Not Ready(设备未就绪)信号或者收到Stop Command(停止命令)挂起后如何保存断点信息，以及如何恢复传输。
[0109] 在现在的XHCI协议下，USB主机一个Endpoint只能响应一次传输命令，然后读取传输环上的数据进行传输，只有当前的传输完成之后，才能响应下一次传输命令。而本发明可以让USB主机可以同时响应同一Endpoint同时进行两个传输请求，即一个Endpoint可以同时拥有两个传输线程。
[0110] 现在假设设计一个能同时接受n个传输请求的USB主机。n为正整数，可以根据集成USB主机的SOC的需求设定。注意,接受传输请求之后不意味着马上可以进行传输，而只是把PIPE信息写入到PIPE Info Buffer(管道信息缓存)里，等有空闲的线程之后，再从PIPE Info Buffer里读取出来执行传输，同时可以传输的线程数目也可以根据系统需要进行设定。图3是PIPE管理的框图。
[0111] 与PIPE管理相关的模块包括：
[0112] 系统软件模块301(System Software Module)，由XHCI主机驱动、设备驱动和USB应用程序组成。
[0113] 周期性传输管理模块302(Periodic Transfer Management Module)，用来管理同步(Isoch)和中断(Interrupt)两种周期性传输。当软件对某个设备的端点请求一个周期性传输之后，这个请求会被保存到此模块，此模块根据此设备端点的特性，周期性地发起传输请求，直到软件此次请求传输的数据全部完成，这个周期性传输请求从此模块删除。
[0114] 多线程流使能寄存器303(Multithread Stream Enable Register)，是在USB3.x主机硬件中的控制寄存器，可以用来使能主机的多线程功能。
[0115] 多线程控制器304(Multithreads Controller)，可以决定当前是否发起多线程传输。
[0116] 可用管道查找模块305(Available Pipe Lookup Module)，此模块用来查找是否有可用的PIPE资源来接受当前的传输请求。
[0117] 被占用管道寄存器组306(Occupied PIPE)，此为一组寄存器，寄存已经被用掉的PIPE代号(PIPE ID)，比如，如果我们的主机支持32个PIPE，代号分别为PIPE 1、PIPE 2、…、PIPE 32，那么这个寄存器为一个32bit(比特)长度的寄存器，32个bit的编号从1到32，当某个PIPE被占据之后，其对应的bit就被置1，如果某个PIPE被释放，则对应的bit被置0，比如，如果3号PIPE(PIPE 3)被占据，那么则此寄存器的第3个bit被置1，当3号PIPE被释放之后，则第3个bit被置0，如果32个bit都被置1了，意味着当前PIPE全部繁忙，不能接受新的传输请求，之后当其中某个PIPE资源被释放之后，才可以接受新的请求。
[0118] 软件请求缓存307(SW Req Buffer)，此为一组寄存器，保存由软件发起的传输请求的PIPE代号。
[0119] 周期性请求缓存308(Periodic Req Buffer)，此为一组寄存器，保存周期性传输请求。
[0120] 保存的请求缓存309(Saved Req Buffer)，此为一组寄存器，保存由于某种原因中断之后，将来需要继续续传的传输请求。
[0121] 未就绪的请求缓存310(Not Ready Req Buffer)，此为一组寄存器，保存由于USB设备返回NRDY(Not Ready，未就绪)之后中断的传输，下一次收到ERDY(Endpoint Ready，端点就绪)之后继续续传。
[0122] 软件请求缓存307、周期性请求缓存308、保存的请求缓存309和未就绪的请求缓存310是四个寄存器组，每一个寄存器可以被设为0或1，如果是1，则该寄存器对应的PIPE具有相应的原因，如果是0，则对应的PIPE不具有相应的原因。例如，如果Not Ready Req Buffer的第5个寄存器为1，表示PIPE 5属于未就绪的请求。如果Periodic Req Buffer的第2个寄存器为1，表示PIPE 2属于周期性请求。
[0123] 传输仲裁器311(Arbiter)，从软件请求缓存307、周期性请求缓存308、保存的请求缓存309和未就绪的请求缓存310四组传输请求中选取一个进行传输。
[0124] 管道信息缓存312(PIPE Info Buffer)，保存某个传输请求的各种信息，比如流传输的ID，建立传输执行的阶段，传输环传输请求块TRB的出栈指针，当前传输请求块对应的传输存储地址的偏移地址(端点续传的时候，需要接着从上一次传输结束的地方接着传输，所以需要记录上一次已经成功传输完成的数据长度，也就是这个偏移地址)等。
[0125] 管道信息载入模块313(Load PIPE INFO)，当传输仲裁器选取一个传输请求之后，会把选取的PIPE ID传输给此模块，此模块根据PIPE ID，从管道信息缓存中读取相应的传输PIPE信息。
[0126] 传输管理模块314(Transfer Management Module)，负责具体的传输环管理和数据传输。
[0127] 管道信息模块315(PIPE Info Module)，传输管理模块在传输过程中或者传输结束后，向此模块传送当前PIPE的各种状态信息，此模块根据当前传输状况决定是否把PIPE信息写回到管道信息缓存。
[0128] 使用上述系统进行USB3.x PIPE分类管理，可以很容易地管理断点续传和传输的优先级控制。根据传输的来源，把PIPE分为四类：
[0129] 1)SW_REQ：系统软件发起的非周期性传输(保存至软件请求缓存307)[0130] 2)PO_REQ：周期性传输管理模块发起的周期性传输(保存至周期性请求缓存308)[0131] 3)RD_REQ：收到USB设备Ready信号之后发起的传输(保存在未就绪的请求缓存310)
[0132] 4)SO_REQ：因为传输机会用完暂停的传输在下一个传输机会到来的时候发起的传输(保存在保存的请求缓存309)
[0133] 所有的原始传输请求都由系统软件发起。
[0134] 如果系统软件发起的传输请求为周期性的传输，那么这个传输被传输管理模块314传送至周期性传输管理模块302并被保存下来，周期性传输管理模块302会根据PIPE的相关信息，计算出什么时候发起对USB设备的传请求。
[0135] 如果当前传输因为USB设备未就绪(Not Ready)而暂停传输，在收到USB设备的就绪(Ready)信号之后，会发起恢复传输的请求。
[0136] 如果当前传输因为传输机会用完了暂停传输，在下一个传输机会，会自动恢复传输。
[0137] PIPE入驻PIPE缓存的规则：为了实现同一类PIPE的先到先执行，需要记录下上一次入驻的PIPE ID，下一次如果有PIPE需要入驻，则要从比上一次PIPE ID大的ID位置寻找一个空的PIPE空间，如果上一次PIPE ID已经达到最大值，那么下一次PIPE ID从第1个空间开始入驻。
[0138] PIPE执行的规则：假如当前被执行的PIPE ID为X，当执行完成当前PIPE之后，X的值加1，即指向了下一个需要执行的PIPE的ID，当下一次此类PIPE被执行的时候，X即需要执行的PIPE的ID。当X值达到PIPE ID允许的最大值的时候，回到第一个PIPE，即等于1。
[0139] 本发明实施例还实现了USB主机针对同一Endpoint的多线程传输，多线程只针对同一个Endpoint执行两个传输线程。不同的Endpoint之间，只要有传输资源，任何时候都可以同时进行传输。同一个Endpoint和不同Endpoint的线程分享USB主机控制器的所有线程资源。比如USB主机配置成支持4个线程，如果其中三个线程已经被某些Endpoint占据了，另外的Endpoint就只有一个线程可以利用了，当四个线程都被占据时，其它的传输请求只有等待某一个线程结束释放资源只有才能进行传输。
[0140] 对于同一Endpoint,如果有两个线程同时存在于USB主机控制器中，那么它们会分享设备的一些共同信息(包含XHCI协议中插槽上下文(Slot Context)所有信息和端点上下文(Endpoint Context)中除传输环出传输请求块栈指针之外的所有信息)。在端点上下文中增加第二线程的传输环传输请求块出栈指针供第二线程使用。
[0141] 实现多线程所要进行的操作包括：
[0142] a)在内存中针对支持第二线程的Endpoint初始化好两个传输环；
[0143] b)在Configure Endpoint(配置端点)命令中增加对第二线程的支持，即把第一线程和第二线程传输环传输请求块的初始出栈指针都写入输入上下文中，主机控制器执行这个命令的时候，把第一线程和第二线程的传输环传输请求块出栈指针拷贝到输出设备上下文中。在主机控制器执行传输命令的时候，可以根据线程代号选择不同的传输环。
[0144] c)在Set TR Dequeue Pointer(设置传输环队列指针)命令中增加对第二线程的支持，主机执行这个命令的时候，可以选择性设置第一线程或第二线程的传输环传输请求块出栈指针。
[0145] d)通过上层协议使用多线程传输，比如通过上层数据结构定义线程数据，主机和设备传输的时候就不必考虑当前数据属于哪个线程。
[0146] 相应地，USB主机控制器硬件进行的操作包括：
[0147] a)当执行Stop Endpoint(停止端点)命令执行的时候，同时停止所有此Endpoint正在执行的线程，并且保存当前所有正在执行的线程的传输环传输请求块出栈指针。
[0148] b)向设备发送头数据包(Header Packet)，该头数据包中包含线程信息，使得设备知道当前传输属于哪个线程。对于支持多线程的设备，两个线程可以同时发送数据。对于不支持多线程的设备，主机需要在前面一个线程结束后再传输下一个线程，由于早就配置好了下一个线程的传输环，主机已经把线程的传输需要的各种信息和缓存都已经准备好，所以可以直接进入数据传输，而不用等待配置传输环的过程。
[0149] c)在接收到应用软件发来的传输命令时，如果当前有被中止/停止的线程，则继续执行被中止/停止的线程；如果有两个被中止/停止的线程，则都要继续执行。
[0150] d)当Endpoint出现传输错误要中止/停止(Halt)当前Endpoint的时候，此Endpoint的所有线程都被中止/停止。传输错误包含所有传输过程中可能引起传输中断的错误，比如一个线程正在和设备传输数据过程中出现了序列号错误或者重试超过重试上限次数等。
[0151] 相应地，USB设备进行的操作包括：
[0152] a)在设备描述符中增加是否支持多线程的描述。
[0153] b)如果设备支持多线程，那么需要从头数据包中区分出当前传输数据属于哪个线程。如果设备不支持多线程，主机会控制数据流的先后顺序，不必区分当前传输的数据属于哪个线程。
[0154] 在一个实施例中，把相关逻辑设计进USB3.x主机控制器IP，然后集成在SOC芯片中。在编写系统驱动程序和应用软件的时候，配合USB3.x主机控制器一起实现。
[0155] 本申请实施例还提供一种计算机存储介质，其中存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现本申请的各方法实施方式。
[0156] 需要说明的是，在本专利的申请文件中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。本专利的申请文件中，如果提到根据某要素执行某行为，则是指至少根据该要素执行该行为的意思，其中包括了两种情况：仅根据该要素执行该行为、和根据该要素和其它要素执行该行为。多个、多次、多种等表达包括2个、2次、2种以及2个以上、2次以上、2种以上。
[0157] 在本申请提及的所有文献都被认为是整体性地包括在本申请的公开内容中，以便在必要时可以作为修改的依据。此外应理解，在阅读了本申请的上述公开内容之后，本领域技术人员可以对本申请作各种改动或修改，这些等价形式同样落于本申请所要求保护的范围。
