br>[0025]现在参照附图，描述了本公开的若干示例性方面。措辞“示例性”在本文中用于表示“用作示例、实例或解说”。本文中描述为“示例性”的任何方面不必被解释为优于或胜过其他方面。
[0026]在详细描述中所公开的诸方面包括查明闪存中的命令完成。一示例性方面包括消除软件锁和未完结请求变量并用传输请求完成寄存器替换它们。传输请求完成寄存器可以被映射到通用闪存存储(UFS)传输协议(UTP)传输请求列表(UTRL)时隙。主机的控制器(硬件组件)可在传输请求完成时设置传输请求完成寄存器中的比特，同时门铃寄存器被清除。在该比特被读取之后，传输请求完成寄存器中的这个比特被清除。虽然具体构想了 UFSJS是其他闪存标准(诸如嵌入式多媒体控制器(eMMC))也可受益于本公开的诸方面(例如，eMMC具有在功能上等效于UTRL的任务描述符列表(TDL))。替换软件锁和未完结请求变量通过减少等待时间并消除在使用此类软件锁中可能发生的传输请求排除来提高性能。具体而言，完成上下文和发出上下文可以同时工作。可同时从多个上下文发出传输请求。使用这多个上下文改善了性能，尤其是在多核设备(诸如智能电话)中。
[0027]在叙述本公开的诸方面之前，参照图1-3给出了常规系统以及与其一起出现的问题的概览。本公开的示例性方面在以下参照图4开始。
[0028]就此，图1是主机10经由导体14耦合至设备12的框图。主机10与设备12之间的通信遵循2013年9月发布的UFS v2.0标准。虽然本讨论专注于UFS，但是其他闪存标准也可受益于本公开的诸方面，包括嵌入式多媒体控制器(eMMC)。主机10包括主机控制器16，该主机控制器16是起作用地耦合至恰适通信接口 18的基于硬件的系统。主机控制器16与主机软件20互操作。主机控制器16和主机软件20—起作为控制系统。
[0029]继续参考图1，设备12包括控制器22，该控制器22是起作用地耦合至恰适通信接口24的基于硬件的系统。设备12进一步包括存储器单元26(例如，与非型或者NOT AND(NAND)闪存存储设备)。设备12进一步包括任务队列28。控制器22以及与控制器22的操作相关联的任何软件一起作为控制系统。
[0030]主机10进一步包括门铃寄存器30(UTRLDBR)。门铃寄存器30是基于硬件的组件，其具有与由主机控制器16处置的传输请求时隙数目相等的比特数目。即，门铃寄存器30具有对应于UFS标准协议传输请求列表的比特数目。
[0031]继续参照图1，在常规UFS系统中，纳入主机10的计算元件可能需要从/向存储器单元26读取或写入数据。因此，概述所请求的数据传输的传输请求可被发送给主机控制器16。主机软件20随后向该传输请求指派时隙。主机控制器16可具有多个时隙(未示出)以处置多个传输请求。多个传输请求是常见的，尤其在多核处理器中。当主机软件20已准备好针对设备12的传输请求时，主机软件20设置门铃寄存器30中对应于与该传输请求相关联的时隙的比特。设置门铃寄存器30中的该比特发信令通知主机控制器16通过通信接口 18向设备12发送传输请求。
[0032]设备12根据UFS标准内被很好地记录的规则处置该传输请求。发生数据传输，并且一旦完成该数据传输，主机控制器16就通过清除门铃寄存器30中的该比特来通知主机软件20 ο在操作中，主机10可以接收传输请求中断。主机软件20检查门铃寄存器30以查看哪些任务已完成以及哪些时隙已被指派。然而，在没有更多信息的情况下，主机软件20无法辨别针对完成的任务被设置为O的比特与针对尚未发送的请求被设置为O的比特。因此，主机软件20维持未完结请求变量(未示出)，该未完结请求变量指示哪些时隙已被指派。
[0033]未完结请求变量在开始准备发送传输请求之际被更新，并且在从设备12接收到对传输请求的响应之际被清除。主机软件20将未完结请求变量与门铃寄存器30作比较以知晓哪些时隙已完成请求。在没有进一步控制的情况下，UFS系统可能具有竞态状况，该竞态状况导致错误、延迟、命令中止、或命令丢失。图2A和2B中解说了两种此类竞态状况。
[0034]就此，图2A通过进程34解说了当发送请求在未完结请求变量被更新之前停止运行时所发生的情况。应当领会，进程34可由不同元件(包括软件和硬件)来实现，并且这些元件可以是分开且不同的组件(例如，不同的子例程、不同的软件模块、不同的IC等)。具体而言，并且如上所述，当图1的主机软件20已准备好针对设备12的传输请求时，主机软件20设置门铃寄存器30中对应于与该传输请求相关联的时隙的比特(框36)。主机1的上下文改变(框38)对应于主机10处理某个其他传输请求或处理某些传入数据。设备12处理传输请求(框40)。设备12可能需要一些时间来处理传输请求。当设备12处理传输请求时，可能发生使‘发送命令进程’休眠的上下文切换。当设备12完成传输请求时，设备12发送完成任务通知。主机10随后提出完成中断(框42)。此时，由于上下文已改变，未完结请求变量从未被更新。因此，在完成中断时，主机10检查门铃寄存器30(框44)并读取未完结请求变量(框46)。然而，如上所述，未完结请求变量未被更新，并且因此完成的请求未被识别出(框48 )，于是该命令中止或超时(框50)。
[0035]类似地，图2B解说进程52，其中未完结请求变量的更新发生在更新门铃寄存器30之前(与上述次序相反，这么做以避免进程34中所阐述的竞态状况)。应当领会，进程52可由不同元件(包括软件和硬件)来实现，并且这些元件可以是分开且不同的组件(例如，不同的子例程、不同的软件模块、不同的IC等)。然而，进程52导致了另一种竞态状况(S卩，两个进程争用同一资源)，其中命令被完成，但存在错误。具体而言，进程52在未完结请求变量被更新的时间点开始(框54)。针对另一个传输请求的完成中断被提出(框56)。然而，该中断发生在更新门铃寄存器30之前。由此，当门铃寄存器30被读取时(框58)，该比特未被设置。然而，当未完结请求变量被读取时(框60)，主机软件20查看该传输请求并识别出完成的请求(框62) ο由此，主机软件20将完成该请求，但存在错误(框64)。
[0036]常规系统通过使用软件锁来防止这些竞态状况。软件锁增加了等待时间。为了完整性起见，图3解说与发送请求上下文66和请求完成上下文68相关联的流程。与发送请求上下文66相关联的过程始于发送请求上下文开始(框70)。主机10准备事务数据(框72)。主机软件20随后设置锁并禁用中断(框74)。软件设置未完结请求变量(框76)，并且随后门铃寄存器30被设置(框78)。在门铃寄存器30被设置之后，锁被禁用且中断被启用(框80)。在锁被移除之后，发送请求上下文结束(框82)。
[0037]继续参照图3，请求完成上下文68开始(框84)。主机控制器16清除门铃寄存器30中的(诸)比特(框85)。请求完成中断发生，并且由主机软件20创建锁(框86)。主机10读取主机软件20中的未完结请求变量(框88)。主机10随后读取门铃寄存器30(框90)并参