JEDEC JESD223-1A-2016 Universal Flash Storage Host Controller Interface (UFSHCI) Unified Memory Extension Version 1 1.pdf

《JEDEC JESD223-1A-2016 Universal Flash Storage Host Controller Interface (UFSHCI) Unified Memory Extension Version 1 1.pdf》由会员分享，可在线阅读，更多相关《JEDEC JESD223-1A-2016 Universal Flash Storage Host Controller Interface (UFSHCI) Unified Memory Extension Version 1 1.pdf（30页珍藏版）》请在麦多课文档分享上搜索。

1、 JEDEC STANDARD Universal Flash Storage Host Controller Interface (UFSHCI), Unified Memory Extension Version 1.1 JESD223-1A (Revision of JESD223-1, September 2013) MARCH 2016 JEDEC SOLID STATE TECHNOLOGY ASSOCIATION NOTICE JEDEC standards and publications contain material that has been prepared, rev

2、iewed, and approved through the JEDEC Board of Directors level and subsequently reviewed and approved by the JEDEC legal counsel. JEDEC standards and publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interc

3、hangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for use by those other than JEDEC members, whether the standard is to be used either domestically or internationally. JEDEC standards and publications are adopted wi

4、thout regard to whether or not their adoption may involve patents or articles, materials, or processes. By such action JEDEC does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the JEDEC standards or publications. The information included

5、 in JEDEC standards and publications represents a sound approach to product specification and application, principally from the solid state device manufacturer viewpoint. Within the JEDEC organization there are procedures whereby a JEDEC standard or publication may be further processed and ultimatel

6、y become an ANSI standard. No claims to be in conformance with this standard may be made unless all requirements stated in the standard are met. Inquiries, comments, and suggestions relative to the content of this JEDEC standard or publication should be addressed to JEDEC at the address below, or re

7、fer to www.jedec.org under Standards and Documents for alternative contact information. Published by JEDEC Solid State Technology Association 2016 3103 North 10th Street Suite 240 South Arlington, VA 22201-2107 This document may be downloaded free of charge; however JEDEC retains the copyright on th

8、is material. By downloading this file the individual agrees not to charge for or resell the resulting material. PRICE: Contact JEDEC Printed in the U.S.A. All rights reserved PLEASE! DONT VIOLATE THE LAW! This document is copyrighted by JEDEC and may not be reproduced without permission. For informa

9、tion, contact: JEDEC Solid State Technology Association 3103 North 10th Street Suite 240 South Arlington, VA 22201-2107 or refer to www.jedec.org under Standards-Documents/Copyright Information. JEDEC Standard No. 223-1A -i- UNIVERSAL FLASH STORAGE HOST CONTROLLER INTERFACE (UFSHCI), UNIFIED MEMORY

10、EXTENSION, Version 1.1 Contents Foreword ii Introduction ii 1 Scope . 1 2 Normative Reference. 1 3 Keywords, Abbreviations, Acronyms, and Conventions . 2 4 Unified Memory Functional Requirements 4 4.1 Unified Memory Overview . 4 4.2 Unified Memory Layer Structure 4 4.2.1 UFS Bus Master Transport Lay

11、er (UBMTP) 5 4.2.2 Device Bus Master Manager . 5 4.2.3 UBM_SAP 5 4.2.4 UBM_UIC_SAP . 6 4.3 Register Map . 6 4.3.1 Offset 00h: CAP Controller Capabilities 6 4.3.2 Offset B0h: UMABA Unified Memory Area Base Address 6 4.3.3 Offset B4h: UMABAU Unified Memory Area Base Address Upper 7 4.3.4 Offset B8h: U

12、MAOMAX Unified Memory Area Offset MAX . 7 4.3.5 Offset BCh: UMACONF Unified Memory Architecture Configuration . 8 4.3.6 C0h: UMACAP - Unified Memory Architecture Capability 8 4.4 Host Memory Map 9 4.5 UMPIU Processing 10 4.5.1 Outbound UMPIUs generated by Software 10 4.5.2 Outbound UMPIUs generated

13、by Host Controller/UBMTP Engine . 10 4.5.3 Inbound UMPIUs interpreted by Software . 10 4.5.4 Inbound UMPIUs interpreted by Host Controller/UBMTP Engine 11 4.6 Initialization Sequence for Unified Memory . 13 5 Power Management 14 5.1 Pre-Active . 14 5.2 Pre-Sleep . 15 5.3 Pre-PowerDown 15 5.4 Sleep 1

14、5 5.5 PowerDown . 17 5.6 Idle / Active . 19 Table 1 Outbound UMPIU generated by UBMTP Engine . 10 Table 2 Inbound UMPIUs interpreted by UBMTP Engine 11 Table 3 Possible UM Operations and HIBERNATE in UFS Power Modes 14 Figure 1 Extended UFSHCI Layer Structure . 4 Figure 2 System Memory Structure 9 F

15、igure 3 Initialization Sequence Diagram for Unified Memory usage . 13 Figure 4 Example flow from ACTIVE Device Power Mode to SLEEP and back to ACTIVE (IMMED=1) 15 Figure 5 Example flow from ACTIVE Device Power Mode to SLEEP and back to ACTIVE (IMMED=0) 16 Figure 6 Example flow from ACTIVE Device Pow

16、er Mode to POWERDOWN and back to ACTIVE (IMMED=1) 17 Figure 7 Example flow from ACTIVE Device Power Mode to POWERDOWN and back to ACTIVE (IMMED=0) 18 Figure 8 UM specific pre-flow before entering HIBERNATE (Manual HIBERNATE) . 19 Figure 9 UM specific pre-flow before entering HIBERNATE (Auto HIBERNAT

17、E) . 19 Figure 10 UM specific post-flow after exiting HIBERNATE (Manual HIBERNATE) 20 Figure 11 UM specific post-flow after exiting HIBERNATE (Auto-HIBERNATE) 20 JEDEC Standard No. 223-1A -ii- Foreword This Unified Memory Extension standard is an extension to the UFSHCI standard, JESD223. Introducti

18、on The UFSHCI standard defines the interface between the UFS driver and the UFS host controller. In addition to the register interface, it defines data structures inside the system memory, which are used to exchange data, control and status information. Furthermore the UFSHCI standard defines the pr

19、otocol layer structure and abstract entities within these layers. Unified Memory offers the possibility to move Device internal working memory into the system memory to reduce overall system cost and to improve Device performance. The Unified Memory feature impacts Host and Device side. This standar

20、d, UFSHCI Unified Memory Extension, describes the requirements to implement Unified Memory functionality in a UFS Host Controller. It is based on the “UFS Unified Memory Extension” standard, which describes the general Unified Memory protocol. JEDEC Standard No. 223-1A Page 1 UNIVERSAL FLASH STORAGE

21、 HOST CONTROLLER INTERFACE (UFSHCI), UNIFIED MEMORY EXTENSION, Version 1.1 (From JEDEC Board Ballot JCB-13-40 and JCB-15-61, under the cognizance of the JC-64.1 Subcommittee on Electrical Specifications and Command Protocols.) 1 Scope This document provides a comprehensive definition of the requirem

22、ents for implementation of a UFS Host Controller, which supports the optional Unified Memory extension. 2 Normative Reference The following normative documents contain provisions that through reference in this text, constitutes provisions of this standard. For dated references, subsequent amendments

23、 to, or revisions of, any of these publications do not apply. However, parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normati

24、ve document referred to applies. MIPI-UniPro, MIPI Alliance Specification for Unified Protocol (UniProSM), Version 1.6 SAM, INCITS T10 draft standard: SCSI Architecture Model 5 (SAM5), Revision 05, 19 May 2010 UFSHCI, JEDEC JESD223C, Universal Flash Storage Host Controller Interface (UFSHCI), Versio

25、n 2.1 UFS, JEDEC JESD220C, Universal Flash Storage (UFS), Version 2.1 UFS-UME, JEDEC JESD220-1A, UFS Unified Memory Extension, Version 1.1 JEDEC Standard No. 223-1A Page 2 3 Keywords, Abbreviations, Acronyms, and Conventions 3.1 Keywords Several keywords are used to differentiate levels of requireme

26、nts and options, as follow: Can: A keyword used for statements of possibility and capability, whether material, physical, or causal (can equals is able to). Expected: A keyword used to describe the behavior of the hardware or software in the design models assumed by this standard. Other hardware and

27、 software design models may also be implemented. Ignored: A keyword that describes bits, bytes, quadlets, or fields whose values are not checked by the recipient. Mandatory: A keyword that indicates items required to be implemented as defined by this standard. May: A keyword that indicates a course

28、of action permissible within the limits of the standard (may equals is permitted). Must: The use of the word must is deprecated and shall not be used when stating mandatory 61 requirements; must is used only to describe unavoidable situations. Optional: A keyword that describes features which are no

29、t required to be implemented by this standard. However, if any optional feature defined by the standard is implemented, it shall be implemented as defined by the standard. Reserved: A keyword used to describe objectsbits, bytes, and fieldsor the code values assigned to these objects in cases where e

30、ither the object or the code value is set aside for future standardization. Usage and interpretation may be specified by future extensions to this or other standards. A reserved object shall be zeroed or, upon development of a future standard, set to a value specified by such a standard. The recipie

31、nt of a reserved object shall not check its value. The recipient of a defined object shall check its value and reject reserved code values. Shall: A keyword that indicates a mandatory requirement strictly to be followed in order to conform to the standard and from which no deviation is permitted (sh

32、all equals is required to). Designers are required to implement all such mandatory requirements to assure interoperability with other products conforming to this standard. Should: A keyword used to indicate that among several possibilities one is recommended as particularly suitable, without mention

33、ing or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited (should equals is recommended that). Will: The use of the word will is deprecated and shall not be used wh

34、en stating mandatory requirements; will is only used in statements of fact. JEDEC Standard No. 223-1A Page 3 3 Keywords, Abbreviations, Acronyms, and Conventions (contd) 3.2 Abbreviations etc. - And so forth (Latin: et cetera) e.g. - For example (Latin: exempli gratia) i.e. - That is (Latin: id est)

35、 3.3 Acronyms BOM Bill Of Material DMA Direct Memory Access DRAM Dynamic Random Access Memory LUN Logical Unit Number NVM Non-Volatile Memory PC Personal Computer SAP Service Access Point SCSI Small Computer System Interface SRAM Static Random Access Memory TC Traffic Class UBMTP UFS Bus Master Tran

36、sport Protocol UFS Universal Flash Storage UM Unified Memory UMA Unified Memory Architecture UME Unified Memory Extension UMPIU Unified Memory Protocol Information Unit UniPro Unified Protocol. UTP UFS Transport Protocol 3.4 Conventions The conventions used for registers in this standard are defined

37、 in the sections that follow. Hardware shall return 0 for all bits and registers that are marked as reserved, and host software shall write all reserved bits and registers with the value of 0. Inside the register section, the following abbreviations are used: HwInit The default state is dependent on

38、 device and system configuration. The value is initialized at reset, either by an expansion ROM, or in the case of integrated devices, by a platform BIOS. Impl Spec Implementation Specific the controller has the freedom to choose its implementation. RO Read Only ROC Read Only and Read to clear RW Re

39、ad Write R/W Read Write. The value read may not be the last value written. RWC Read/Write 1 to clear RWS Read/Write 1 to set JEDEC Standard No. 223-1A Page 4 4 Unified Memory Functional Requirements 4.1 Unified Memory Overview Ever increasing demand for higher storage performance and lower cost in t

40、he consumer market put tight constraints on UFS Device and Host vendors. One way to improve both, performance and cost, is to use Unified Memory. This concept offers the option to move Device internal working memory into the Host memory, which is already available in large capacities in current and

41、upcoming Smartphone, Tablet and portable computer generations. Furthermore the Unified Memory Architecture (UMA) concept is not new since it has been successfully used for many years in the PC and Workstation market. High performance, in particular random read and write accesses, requires a huge amo

42、unt of buffer and cache memory. This may be either implemented as SRAM on the UFS Device controller die or as a separate DRAM inside the UFS Device package. On-die SRAM increases the cost of the controller and DRAM dies in relatively small capacities will become unavailable or expensive in the futur

43、e since they will become a non-mainstream niche product. Moreover, due to UM, the SRAM size on the Device side may be reduced, which also reduces pellet cost, footprint, leakage and power consumption. Also making a dedicated DRAM die obsolete reduces the BOM of the UFS Device, increases the assembly

44、 yield, eliminates the need for an embedded DRAM controller and reduces the power consumption which is required for the DRAM refresh. One die less inside the UFS Device package offers the Device vendor the possibility to add another NVM die to increase the overall NVM capacity. 4.2 Unified Memory La

45、yer Structure The basic UFSHCI layer structure as shown in UFSHCI is solely based on the SCSI Architecture Model SAM, which defines a strict client-server model that does not permit the UFS Device to issue requests to the UFS Host Controller. This is called “Device Bus Master” mode. Figure 1 depicts

46、 the extended UFS Host Controller Layer diagram, which adds “Device Bus Master” mode functionality to the Host Controller. Other future functionalities like e.g., UFSIO might use the “Device Bus Master” mode as well. A p p l i c a t i o n C l i e n t( U C S )T a s k M a n a g e rD e v i c e M a n a

47、g e rA p p l i c a t i o n L a y e rU F S T r a n s p o r t L a y e r ( U T P )U F S I n t e r c o n n e c t L a y e r ( U I C )S C S ID e v i c e B u s M a s t e r M a n a g e rU I C _ S A PU T P _ C M D _ S A PU D M _ S A PU I O _ S A PU T P _ T M _ S A PU F S B u s M a s t e r T r a n s p o r t L

48、 a y e r ( U B M T P )U B M _ S A PU B M _ U I C _ S A PFigure 1 Extended UFSHCI Layer Structure JEDEC Standard No. 223-1A Page 5 4.2 Unified Memory Layer Structure (contd) The following sections describe additional SAPs, Layers and Entities, that are required for UM operation, in detail. 4.2.1 UFS

49、Bus Master Transport Layer (UBMTP) The purpose of this layer is to interpret inbound UMPIU packets and assemble outbound UMPIU packets. In contrast to the UTP layer, the UBMTP layer supports requests from the UFS Device to the UFS Host Controller. The UBMTP Layer is based on the UTP layer but optimized to the requirements of the UM operation (e.g., reduced header size to minimize load on the UniPro link). 4.2.2 Device Bus Master Manager This entity is the counterpart of the same entity on the UFS Device side. The “Device