Method, controller and storage device for information configuration of interconnection protocols

Abstract

Method, controller and storage device for information configuration of power mode change of an interconnect protocol. The method is for use in a first device capable of linking a second device according to an interconnect protocol, the method comprising, when a hardware protocol engine of the first device for a protocol layer implementing the interconnect protocol performs a power mode change: generating, by the hardware protocol engine, a configuration indication signal to trigger a firmware of the first device to configure information to a physical layer of the interconnect protocol, wherein the configuration indication signal is non-standard with respect to the interconnect protocol and the firmware is outside the hardware protocol engine; configuring, by the firmware, the physical layer with the information in response to the configuration indication signal; and notifying, by the firmware, the hardware protocol engine of completion of the information configuration upon completion of the information configuration to the physical layer.

Description

Technical Field

[0001] This invention relates to an electronic device, and more particularly to a method, controller, and storage device for configuring information for power consumption mode changes. Background Technology

[0002] The amount of data generated and processed in today's mobile devices (such as smartphones, tablets, multimedia devices, wearable devices, and other computing devices) is constantly increasing. The chip-to-chip interconnect technology inside mobile devices or the interconnect interface technology affected by mobile devices needs to be further evolved in order to meet the goals of higher transmission speed, low power consumption, scalability, support for multiplexing, and ease of adoption.

[0003] To this end, the Mobile Industry Processor Interface (MIPI) Alliance has developed interconnect interface technologies that meet the above objectives, such as the MIPI M-PHY specification for the physical layer and the MIPI UniPro specification for the Unified Protocol (UniPro). On the other hand, the Joint Electron Device Engineering Council (JEDEC) has used the MIPI M-PHY specification and the MIPI UniPro specification to introduce the next-generation high-performance non-volatile memory standard, called Universal Flash Storage (UFS). UFS enables high-speed transfers at the billion-bit-per-second level and low-power operation, and possesses the functionality and scalability required for high-end mobile systems, thus facilitating rapid industry adoption.

[0004] When engineers develop chips, electronic modules, or electronic devices based on these interconnect interface technologies, they must ensure that the product's functionality and operation comply with specifications. For example, a system implemented according to the UFS standard may include computing devices and non-volatile memory storage devices, with the computing device acting as the local host and the storage device as the remote device, respectively. A bidirectional link is established between the host and the device. According to the UniPro specification, the host and device must support multiple power modes. When a change in power mode is required, the physical layer channel and speed configuration of the link must also be changed accordingly to achieve the target power mode.

[0005] The UniPro specification defines the process for changing power consumption modes, which requires setting up a standard management information base, especially the physical layer management information base, to configure the physical layer. Since the UniPro specification is primarily implemented through hardware circuits, and it only sets up a standard management information base, if different products require setting specific non-standard attribute parameters for the physical layer during UniPro implementation, the design of this hardware circuit must be modified, causing difficulties in research and development, verification, and maintenance. Summary of the Invention

[0006] The implementation provides a technique for information configuration of an interconnect protocol, wherein during a power mode change of the interconnect protocol, information configuration is achieved through communication between a hardware protocol engine implementing the protocol layer and firmware. The communication between the hardware protocol engine and the firmware is performed in a non-standard manner, and the firmware is located outside the hardware protocol engine.

[0007] The following proposes various implementation methods based on the information configuration technology, such as methods, controllers, and storage devices for power mode changes in interconnect protocols.

[0008] An implementation provides a method for configuring information for power mode changes of an interconnect protocol, applicable to a first device capable of linking a second device according to an interconnect protocol. The method includes: when a hardware protocol engine of the first device, which implements the protocol layer of the interconnect protocol, performs a power mode change according to the protocol layer of the interconnect protocol: the hardware protocol engine generates a configuration indication signal to trigger the firmware of the first device to configure information for the physical layer of the interconnect protocol, wherein the configuration indication signal is non-standard relative to the interconnect protocol, and the firmware is outside the hardware protocol engine; in response to the configuration indication signal, the firmware configures the physical layer; and after completing the configuration of the physical layer, the firmware notifies the hardware protocol engine of the completion of the configuration.

[0009] In some embodiments of the method, the configuration of the physical layer information is performed by the firmware based on at least one vendor-specific management information base (MIB) for power mode changes of the physical layer.

[0010] In some embodiments of the method, the method further includes: in response to a notification that the information configuration is complete, the hardware protocol engine configures the physical layer according to at least one standard management information base for power mode changes of the physical layer.

[0011] In some embodiments of the method, the configuration of the physical layer information is performed by the firmware based on data including: at least one vendor-specific management information base for changing the power consumption mode of the physical layer; and at least one standard management information base for changing the power consumption mode of the physical layer.

[0012] In some embodiments of the method, the firmware notifies the hardware protocol engine of the completion of the information configuration, including: triggering a request conforming to the protocol layer to set up an additional vendor-specific management information base, which is then used to notify the hardware protocol engine of the completion of the information configuration.

[0013] In some embodiments of the method, the request triggered by the firmware is a Device Management Entity (DME) request conforming to the protocol layer, and the additional vendor-specific management information base is configured for the protocol layer.

[0014] In some embodiments of the method, the interconnect protocol is the Universal Flash Storage (UFS) standard, and the protocol layer and the physical layer are the Unified Protocol (UniPro) layer and the physical (M-PHY) layer of the UFS standard.

[0015] An embodiment provides a controller suitable for a first device capable of linking a second device according to an interconnection protocol. The controller includes a hardware protocol engine and a processing unit. The hardware protocol engine implements the protocol layer of the interconnection protocol. The processing unit is coupled to the hardware protocol engine. When the hardware protocol engine performs a power mode change according to the protocol layer, the hardware protocol engine generates a configuration indication signal to trigger firmware executed by the processing unit to configure information at the physical layer of the interconnection protocol, wherein the configuration indication signal is non-standard relative to the interconnection protocol, and the firmware is external to the hardware protocol engine; and the firmware responds to the configuration indication signal to configure the physical layer, and notifies the hardware protocol engine of the completion of the configuration when the configuration is complete.

[0016] An embodiment provides a storage device capable of connecting to a host according to an interconnect protocol. The storage device includes: an interface circuit and a device controller. The interface circuit implements the physical layer of the interconnect protocol to connect to the host. The device controller is coupled to the interface circuit and a storage module. The device controller includes: a hardware protocol engine and a processing unit. The hardware protocol engine implements the protocol layer of the interconnect protocol. The processing unit is coupled to the hardware protocol engine. When the hardware protocol engine changes its power consumption mode according to the protocol layer, the hardware protocol engine generates a configuration indication signal to trigger firmware executed by the processing unit to configure information on the physical layer of the interconnect protocol, wherein the configuration indication signal is non-standard relative to the interconnect protocol, and the firmware is external to the hardware protocol engine; and the firmware responds to the configuration indication signal to configure the physical layer, and notifies the hardware protocol engine of the completion of the configuration when the configuration is complete.

[0017] In some embodiments, the configuration of the physical layer information is performed by the firmware based on at least one vendor-specific management information base for power consumption mode changes of the physical layer.

[0018] In some embodiments, the hardware protocol engine is configured to configure the physical layer based on at least one standard management information base for the power mode change after being notified of the completion of the information configuration.

[0019] In some embodiments, the firmware is used to configure the physical layer based on data including: at least one vendor-specific management information base for changing the power consumption mode of the physical layer; and at least one standard management information base for changing the power consumption mode of the physical layer that is compatible with the protocol layer.

[0020] In some embodiments, the firmware is used to set up an additional vendor-specific management information base by triggering a request conforming to the protocol layer, thereby notifying the hardware protocol engine of the completion of the information configuration.

[0021] In some embodiments, the request triggered by the firmware is a Device Management Entity (DME) request conforming to the protocol layer, and the additional vendor-specific management information base is configured for the protocol layer.

[0022] In some embodiments, the interconnect protocol is the Universal Flash Storage (UFS) standard, and the protocol layer and the physical layer are the Unified Protocol (UniPro) layer and M-PHY layer of the UFS standard.

[0023] As described above, the implementation provides various embodiments of a technique for configuring information in an interconnect protocol, wherein information configuration is achieved through communication between a hardware protocol engine implementing the protocol layer of the interconnect protocol and the firmware during a change in the power consumption mode of the interconnect protocol. The communication between the hardware protocol engine and the firmware is performed in a non-standard manner, and the firmware is located outside the hardware protocol engine. This technique provides a sufficiently flexible circuit architecture that can be efficiently configured to meet the vendor-specific information configuration needs of different products, facilitating product development by adapting to various vendors' designs. Attached Figure Description

[0024] Figure 1 This is a schematic block diagram of a storage system according to one embodiment of the present invention;

[0025] Figure 2A A flowchart of one implementation of a method for configuring information for power mode changes in interconnect protocols;

[0026] Figure 2B for Figure 2A A flowchart of an embodiment of the method;

[0027] Figure 3 for Figure 1 A schematic diagram of the storage system's layered architecture based on the UFS standard;

[0028] Figure 4A In order to determine the basis for changing power consumption modes Figure 2A or Figure 2B A schematic diagram of an embodiment of a method for configuring information;

[0029] Figure 4B In order to determine the basis for changing power consumption modes Figure 2A or Figure 2B A schematic diagram illustrating an embodiment of an information configuration method; and

[0030] Figure 5 A schematic diagram of one implementation of the circuit architecture for achieving the above information configuration method.

[0031] Figure Labels

[0032] 1. Storage System

[0033] 10 mainframes

[0034] 11 Host Interface

[0035] 12. Host Controller

[0036] 13 Hardware Protocol Engine

[0037] 14 Processing Units

[0038] 16 Application Processors

[0039] 20 Storage devices

[0040] 21 Device Interface

[0041] 22 Equipment Controller

[0042] 23 Hardware Protocol Engine

[0043] 24 processing units

[0044] 26 Storage Modules

[0045] 110 MIPI Physical (M-PHY) Layer

[0046] 111 transmitter

[0047] 112 receiver

[0048] 130 MIPI Unified Protocol (UniPro) Layer

[0049] 131 PHY Connector Layer

[0050] 132 Data Link Layer

[0051] 133 Network Layer

[0052] 134 Transport Layer

[0053] 135 Device Management Entity (DME)

[0054] 210 MIPI Physical (M-PHY) Layer

[0055] 211 transmitter

[0056] 212 receiver

[0057] 230 MIPI Unified Protocol (UniPro) Layer

[0058] 231 PHY Connector Layer

[0059] 232 Data Link Layer

[0060] 233 Network Layer

[0061] 234 Transport Layer

[0062] 235 Device Management Entity (DME)

[0063] 310 Interface Circuit

[0064] 320 Hardware Protocol Engine

[0065] 321 Power Consumption Mode Change Flow Control Module

[0066] 325 Select Module

[0067] 330 processing unit

[0068] Steps S10 to S40

[0069] Arrows A100~A142 and A200~A232

[0070] Graphics B100~B140, B200~B240

[0071] BS1~BS3, BS21, BS22 bus

[0072] CLK clock line

[0073] Din, Dout data cables

[0074] RST Reset Line

[0075] SC path

[0076] SL1 Data Channel

[0077] SL2 Data Channel

[0078] L1, L2 paths Detailed Implementation

[0079] To fully understand the purpose, features and effects of the present invention, the present invention will be described in detail below with reference to the following specific embodiments and accompanying drawings.

[0080] The following embodiments provide various examples of a technique for configuring information in an interconnect protocol, wherein information configuration is achieved by communicating between a hardware protocol engine implementing the interconnect protocol and firmware during a power mode change. The communication between the hardware protocol engine and the firmware is performed in a non-standard manner, and the firmware is located outside the hardware protocol engine.

[0081] To facilitate understanding and explanation, a circuit architecture implementation method is first provided based on the described technology. This circuit architecture is flexible enough and can be efficiently configured to meet the specific information configuration needs of different product manufacturers, thus adapting to various manufacturers' designs and facilitating product development. For example... Figure 1As shown, when this circuit architecture is applied to storage system 1, the controller of host 10 of storage system 1 (such as host controller 12) or the controller of storage device 20 of storage system 1 (such as device controller 22) can be implemented as a circuit architecture including a hardware protocol engine and a processing unit, thereby realizing the technology for information configuration of interconnection protocols. Furthermore, the method for information configuration of interconnection protocols will be disclosed in... Figure 2A or Figure 2B .

[0082] Please refer to Figure 1 This is a schematic block diagram of a storage system according to one embodiment of the present invention. Figure 1 As shown, storage system 1 includes a host 10 and a storage device 20. The host 10 and storage device 20 communicate via an interconnect protocol, allowing the host 10 to access data on the storage device 20. The interconnect protocol is, for example, the Universal Flash Storage (UFS) standard. The host 10 is, for example, a computing device such as a smartphone, tablet, or multimedia device. The storage device 20 is, for example, a storage device internal or external to the computing device, such as a non-volatile memory-based storage device. The storage device 20 can write data to or provide data to be written to the host 10 under the control of the host 10. The storage device 20 can be implemented as a solid-state storage device (SSD), a multimedia card (MMC), an embedded MMC (eMMC), a secure digital card (SD) card, or a universal flash storage (UFS) device; however, the implementation of this disclosure is not limited to the examples described above.

[0083] The host 10 includes a host interface 11, a host controller 12, and an application processor 16.

[0084] Host interface 11 is used to implement the physical layer of the interconnect protocol to link the storage device 20. For example, host interface 11 is used to implement the physical (M-PHY) layer of the UFS standard.

[0085] The host controller 12 is coupled between the host interface 11 and the application processor 16. When the application processor 16 needs to access data on the storage device 20, it sends a corresponding access action command to the host controller 12, communicates with the storage device 20 through the interconnection protocol, and thus accesses data on the storage device 20.

[0086] The host controller 12 includes a hardware protocol engine 13 and a processing unit 14.

[0087] The hardware protocol engine 13 is used to implement the protocol layer of the interconnection protocol. Taking the UFS standard as an example, the protocol layer is the Unified Protocol (UniPro) layer. The hardware protocol engine 13 communicates and converts information with the host interface 11 and the processing unit 14 according to the specifications of the protocol layer.

[0088] Processing unit 14, coupled to the hardware protocol engine 13, is used to communicate with application processor 16. Processing unit 14 can execute one or more firmware files. For example, access instructions issued by the operating system, driver, or application executed by application processor 16 are converted by the firmware executed by processing unit 14 into an instruction format conforming to the protocol layer of the interconnection protocol, and then sent to hardware protocol engine 13 for processing according to the specifications of the protocol layer. The firmware may be stored, for example, in the internal memory of processing unit 14, or in the internal memory of host controller 12, wherein the internal memory may include volatile memory and non-volatile memory.

[0089] The storage device 20 includes a device interface 21, a device controller 22, and a storage module 26.

[0090] Device interface 21 is used to implement the physical layer of the interconnection protocol to link the host 10. For example, host interface 21 is used to implement the physical (M-PHY) layer of the UFS standard.

[0091] Device controller 22 is coupled between device interface 21 and storage module 26. Device controller 22 can control write operations, read operations, or erase operations of storage module 26. Device controller 22 can exchange data with storage module 26 via address bus or data bus. Storage module 26 may contain, for example, one or more memory chips containing non-volatile memory.

[0092] The device controller 22 includes a hardware protocol engine 23 and a processing unit 24.

[0093] The hardware protocol engine 23 is used to implement the protocol layer of the interconnection protocol. Taking the UFS standard as an example, the protocol layer is the UniPro layer. The hardware protocol engine 13 communicates and converts information with the device interface 21 and the processing unit 24 according to the specifications of the protocol layer.

[0094] Processing unit 24, coupled to the hardware protocol engine 23, communicates with host 10 via device interface 21. Processing unit 24 can execute one or more firmware files. For example, processing unit 24 executes one or more firmware files to control or instruct write operations, read operations, or erase operations of storage module 26, process messages from hardware protocol engine 23, or send messages to hardware protocol engine 23. The firmware can be stored, for example, in the internal memory of processing unit 24, the internal memory of device controller 22, or a specific storage area of ​​storage module 26, wherein the internal memory may include volatile memory and non-volatile memory.

[0095] like Figure 1 As shown, host interface 11 can be coupled to device interface 21 via data lines Din and Dout for sending / receiving data, a reset line RST for sending a hardware reset signal, and a clock line CLK for sending data. Data lines Din and Dout can be implemented in multiple pairs, where a pair of data lines Din and Dout can be referred to as a lane. Host interface 11 can communicate with device interface 21 using at least one interface protocol, such as Mobile Industrial Processor Interface (MIPI), Universal Flash Storage (UFS), Small Computer System Interface (SCSI), or Serial Attached SCSI (SAS); however, the implementation of this disclosure is not limited to the examples described above.

[0096] based on Figure 1 The controllers shown (such as host controller 12 or device controller 22) can be implemented as circuit architectures including hardware protocol engines and processing units. The following example illustrates a method for implementing information configuration for interconnect protocols. Please refer to... Figure 2A This is a flowchart illustrating one implementation of a method for configuring information for power mode changes in an interconnect protocol. The method can be used in a first device (e.g., storage device 20) capable of linking a second device (e.g., host 10) according to an interconnect protocol. For ease of explanation, the following example uses storage device 20 as the first device and host 10 as the second device. Figure 2A As shown, the method includes steps S10 to S30. These steps are performed when the hardware protocol engine (e.g., hardware protocol engine 23) of the first device (e.g., storage device 20) changes the power consumption mode according to the protocol layer of the interconnection protocol.

[0097] As shown in step S10, the hardware protocol engine (e.g., hardware protocol engine 23) generates a configuration indication signal to trigger the firmware of the first device (e.g., storage device 20) (e.g., executed by processing unit 24) to configure information on the physical layer of the interconnection protocol, wherein the configuration indication signal is non-standard relative to the interconnection protocol, and the firmware is outside the hardware protocol engine (e.g., hardware protocol engine 23).

[0098] As shown in step S20, in response to the configuration indication signal, the physical layer is configured with information via the firmware.

[0099] As shown in step S30, after the information configuration of the physical layer is completed, the firmware (e.g., executed by processing unit 24) notifies the hardware protocol engine (e.g., hardware protocol engine 23) of the completion of the information configuration.

[0100] The following examples further illustrate how the above steps are implemented.

[0101] Regarding step S10, for example, the configuration indication signal may be an interrupt signal or one or more trigger signals of any suitable form. For instance, the hardware protocol engine 23 generates a configuration indication signal (such as an interrupt signal) to trigger the firmware of the first device (such as storage device 20) (e.g., executed by processing unit 24), causing processing unit 24 to suspend other processing tasks and perform the operations shown in steps S20-S30 on the hardware protocol engine 23. In another embodiment, the configuration indication signal may be a polling signal, and processing unit 24 may determine when to serve the hardware protocol engine 23 based on the schedule or priority of currently processed tasks.

[0102] Regarding step S10, for example, taking the UFS standard as an example of the interconnection protocol, the protocol layer in the UFS standard is defined by the UniPro layer. The UniPro specification does not disclose the configuration indication signal for step S10, nor does it disclose that during the power mode change process, the UniPro layer triggers any entity outside the UniPro layer to perform information configuration. Therefore, step S10 is a non-standard practice compared to the UFS standard. The firmware, for example, is in... Figure 1 The firmware is executed by the processing unit 24 of the device controller 22 in the storage device 20, so the firmware is implemented outside the hardware protocol engine 23.

[0103] For example, the firmware described in step S10 can be implemented as one or more specific firmwares to perform the operations described in steps S10 to S30. Furthermore, the firmware can be stored, for example, in the internal memory of the processing unit 24, the internal memory of the device controller 22, or a specific storage area of ​​the storage module 26.

[0104] Regarding step S20, in some embodiments, the configuration of the physical layer information is performed by the firmware based on at least one vendor-specific management information base (MIB) for power mode changes of the physical layer (such as the M-PHY layer). For example, the firmware sets some registers defined in the UniPro specification in the hardware protocol engine 23 according to at least one vendor-specific MIB, such as setting the values ​​of these registers according to the vendor-specific MIB. Here, the vendor-specific MIB is relative to the standard MIB in the UniPro specification, that is, a vendor-specific MIB that is not defined in the UniPro specification.

[0105] For example, a vendor-specific MIB may include values ​​for attributes set for specific circuitry or operations of the vendor-specific M-PHY layer. In one example, the vendor-specific MIB may include a value for controlling the frequency of a clock signal corresponding to a data channel (e.g., a data channel in a certain transmission direction) between host 10 and storage device 20, wherein the frequency of the clock signal affects the data channel rate and may need to be changed during power mode changes. The vendor-specific M-PHY layer may implement circuitry based on a voltage-controlled oscillator (VCO) to generate the clock signal corresponding to the data channel between host 10 and storage device 20, wherein the frequency of the clock signal is controlled by inputting voltage signals of different magnitudes to the voltage-controlled oscillator. For this change in frequency, one or more registers may be correspondingly implemented in the controller (e.g., host controller 12 or device controller 22) to store values ​​for attributes controlling the voltage-controlled oscillator, such as values ​​corresponding to the magnitude of the voltage signal input to the voltage-controlled oscillator (e.g., representing signal amplitude or DC voltage level). In another example, the vendor-specific MIB may include a numerical value (e.g., representing amplitude) for controlling the signal magnitude of the data channel (e.g., a data channel in a certain transmission direction) between host 10 and storage device 20, wherein the signal magnitude affects the power consumption of the data channel, and therefore may need to be changed in power mode changes. The vendor-specific M-PHY layer may implement circuitry based on a low-dropout regulator (LDO) to generate the signal corresponding to the data channel between host 10 and storage device 20. For changes in this signal magnitude, one or more registers may be correspondingly implemented in the controller (e.g., host controller 12 or device controller 22) to store values ​​for controlling the attributes of the LDO, such as values ​​corresponding to the signal magnitude of the LDO. Thus, according to step S20, the physical layer is configured via the firmware to set specific circuitry or operations for the vendor-specific M-PHY layer.

[0106] Regarding step S20, in some embodiments, the configuration of the physical layer information is performed by the firmware based on data including: at least one vendor-specific management information base for changing the power consumption mode of the physical layer; and at least one standard management information base for changing the power consumption mode of the physical layer. Through these embodiments, the hardware protocol engine 23 does not need to implement the configuration of the physical layer information based on a standard management information base.

[0107] Regarding step S30, for the example where the protocol layer is the UniPro layer, the approach to step S30 is non-standard. For example, the hardware protocol engine 23 needs to implement processing logic circuitry capable of receiving and judging this additional vendor-specific management information base, and connecting with the process specified by the original UniPro layer.

[0108] In one embodiment of step S30, notifying the hardware protocol engine of the completion of the information configuration via the firmware includes: triggering a request conforming to the protocol layer to set up an additional vendor-specific management information base, which is then used to notify the hardware protocol engine of the completion of the information configuration. This embodiment refers to using a request specified in the original protocol layer to notify the hardware protocol engine of the completion of the information configuration after the actual information configuration has been completed.

[0109] In another embodiment of step S30, the request triggered by the firmware is a Device Management Entity (DME) request conforming to the protocol layer, and the additional vendor-specific management information base is set up for the protocol layer.

[0110] Please refer to Figure 2B This is a flowchart of another implementation of a method for configuring information on power mode changes for interconnect protocols. Figure 2B Implementation examples and Figure 2A The difference in the embodiments is that, Figure 2B In addition to the aforementioned steps S10 to S30, the embodiments also include: in response to the notification that the information configuration is complete, the hardware protocol engine (such as hardware protocol engine 23) configures the physical layer according to at least one standard management information base for power consumption mode changes of the physical layer.

[0111] By Figure 2B In one embodiment, firmware (e.g., executed by processing unit 24) can be used to configure the physical layer information based on one or more vendor-specific MIBs. After the information configuration is completed, the hardware protocol engine (e.g., hardware protocol engine 23) configures the physical layer information based on at least one standard management information base for power mode changes of the physical layer.

[0112] In the above regarding Figure 2A or Figure 2B Although the method is illustrated by taking the first device as storage device 20 and the second device as host 10, the method is also applicable to the case where the first device is host 10 and the second device is storage device 20.

[0113] The following detailed explanation uses the Universal Flash Storage (UFS) standard as an example of the interconnect protocol.

[0114] Please refer to Figure 3 , it is Figure 1 This is a diagram illustrating the layered architecture of a storage system based on the UFS standard. Because the UFS standard is based on the MIPI Unified Protocol (UniPro) layer and the MIPI Physical (M-PHY) layer, Figure 1 The host interface 11 and hardware protocol engine 13 of the host 10 shown are respectively used to implement Figure 3 The M-PHY layer 110 and UniPro layer 130 are in the middle; Figure 1 The device interface 21 and hardware protocol engine 23 of the storage device 20 shown are used to implement... Figure 3 The M-PHY layer 210 and UniPro layer 230 are in the middle.

[0115] like Figure 3 As shown, the UniPro layer 130 (or 230) may include a PHY adapter layer 131 (or 231), a data link layer 132 (or 232), a network layer 133 (or 233), and a transport layer 134 (or 234). The various layers in the UniPro layer 230 of the storage device 20 can also operate and be implemented similarly.

[0116] The PHY adapter layer (131 or 231) is used to couple the M-PHY layer (110 or 210) to the data link layer (132 or 232). The PHY adapter layer (131 or 231) can perform bandwidth control, power management, etc., between the M-PHY layer (110 or 210) and the data link layer (132 or 232). In implementation, the M-PHY layer 110 of the host 10 includes a transmitter 111 and a receiver 112, and the M-PHY layer 210 of the storage device 20 includes a transmitter 211 and a receiver 212, thereby enabling the establishment of data channels SL1 and SL2 for full-duplex communication. The UniPro specification supports multiple data channels on the link in each transmission direction (e.g., forward or reverse).

[0117] The data link layer (132 or 232) can perform flow control for data transmission between host 10 and storage device 20. That is, the data link layer (132 or 232) can monitor data transmission or control the data transmission rate. Furthermore, the data link layer (132 or 232) can perform error control based on cyclic redundancy check (CRC). The data link layer (132 or 232) can generate frames using packets received from the network layer (133 or 233), or it can generate packets using frames received from the PHY adapter layer (131 or 231).

[0118] The network layer (133 or 233) is used for routing functions to select transmission paths for packets received from the transport layer (134 or 234).

[0119] The transport layer (134 or 234) can use commands received from the UFS application layer to configure data segments suitable for the protocol and send the data segments to the network layer (133 or 233), or it can extract commands from packets received from the network layer (133 or 233) and send the commands to the UFS application layer. The transport layer (134 or 234) can use a sequence-based error control scheme to ensure the validity of data transmission.

[0120] Furthermore, the UniPro layer (130 or 230) also defines a device management entity (DME) (135 or 235), which can communicate with various layers in the M-PHY layer (110 or 210) and the UniPro layer (130 or 230), such as the PHY adapter layer (131 or 231), the data link layer (132 or 232), the network layer (133 or 231), the transport layer (134 or 234), and even the UFS application layer. This enables functions involving the entire UniPro protocol, such as power-on, power-off, reset, and power mode change control or configuration functions.

[0121] In the UniPro specification, power modes include Fast_Mode, Slow_Mode, FastAuto_Mode, SlowAuto_Mode, Hibernate_Mode, and Off_Mode. The UniPro specification supports setting the power mode for each link (e.g., forward or reverse link) in each transmission direction. Changing the power mode involves, for example, changing from one of the above power modes to another, such as from Slow_Mode to Fast_Mode.

[0122] Please refer to Figure 4A and Figure 4B This is based on the process of changing the power consumption mode. Figure 2A or Figure 2B A schematic diagram illustrating an embodiment of an information configuration method.

[0123] like Figure 4A As shown, overall, based on the UniPro specification, the PHY adapter layer (PA) 131 or 231 provides a method for local and remote device management entities (DME) 135 or 235 to exchange necessary information during power mode changes. This information is transmitted in the PAPowerModeUserData field of the PACP_PWR_req frame (as shown by arrow A110) and the PACP_PWR_cnf frame (as shown by arrow A220), the structure of which is defined in the UniPro specification for use by the DME.

[0124] Please refer to Figure 4A Based on the UniPro specification, as shown by arrow A100, the local DME135 establishes a power mode change request, such as by using the basic primitive instruction PA_LM_SET.req(PA_PWRMode,x).

[0125] As shown in Figure B100, the local PA layer 131 performs capability checking according to the UniPro specification when there is a request to change the power consumption mode, and responds to the local DME 135 using the instruction PA_LM_SET.cnf_L(SUCCESS), as shown by arrow A102.

[0126] As shown in Figure B102, the local PA layer 131 performs PA_DL_PAUSE related processing regarding pausing data link layer transmission. Then, as shown in Figure B104, the local PA layer 131 instructs the M-PHY layer 110 to send a burst transmission (Tx).

[0127] As indicated by arrow A110, the local PA layer 131 sends a PACP_PWR_req frame. Afterwards, as shown in figure B106, the local PA layer 131 waits for acknowledgment (e.g., represented by WaitCnf).

[0128] As shown in Figure B200, the remote PA layer 231 responds to the PACP_PWR_req frame by performing capability checking according to the UniPro specification. Next, as shown by arrow A200, the remote PA layer 231 responds by transmitting the payload data to the remote DME 235 via the PA_LM_PWR_MODE.ind instruction. As shown by arrow A202, the remote DME 235 responds with the PA_LM_PWR_MODE.rsp_L instruction.

[0129] As shown in Figure B202, the remote PA layer 231 performs PA_DL_PAUSE related processing regarding pausing data link layer transmission. Then, as shown in Figure B204, the remote PA layer 231 instructs the M-PHY layer 210 to send a burst transmission (Tx).

[0130] As indicated by arrow A210, the remote PA layer 231 notifies the remote DME 235 that it is currently in burst transmission. Subsequently, as shown in graph B210, the remote PA layer 231 enters the information configuration phase.

[0131] As indicated by arrow A211, based on... Figure 2A or Figure 2B In step S10 of the method, the remote DME 235 generates a configuration indication signal (e.g., represented by the symbol FW_MPHY_CFG.ind) to instruct the firmware that it is time to configure the information of the vendor-specific MIB for the M-PHY. This triggers the firmware of the remote device (e.g., storage device 20) (e.g., executed by processing unit 24) to configure the M-PHY layer. The configuration indication signal is non-standard relative to the interconnection protocol, and the firmware is outside the hardware protocol engine (e.g., hardware protocol engine 23).

[0132] As shown in Figure B215, according to... Figure 2A or Figure 2B In step S20 of the method, after the firmware detects this specific indication, the firmware begins to configure the information of the target M-PHY's vendor-specific MIB, such as programming or programmable configuration, or setting the corresponding M-PHY layer information configuration registers, as shown by arrow A212.

[0133] As indicated by arrow A214, based on... Figure 2A or Figure 2BIn step S30 of the method, after the firmware completes the information configuration of the vendor-specific MIB of the target M-PHY, it notifies the remote PA layer 231 of the completion of the information configuration through the firmware (e.g., executed by processing unit 24). For example, according to one embodiment of step S30, information configuration (such as programming, register setting, or other suitable operations) is performed on a specific UniPro vendor-specific MIB to indicate completion. The above-described step S30 is a non-standard practice.

[0134] Subsequently, optionally, as shown in Figure B220, the remote PA layer 231 enters another information configuration phase, which can be implemented by hardware (such as hardware protocol engine 23) configuring the physical layer according to at least one standard MIB for power mode changes of the M-PHY layer, based on the original specifications of the UniPro layer.

[0135] Alternatively, in another embodiment, the firmware can be used to configure the vendor-specific MIB and the standard MIB separately, and upon completion, notify the remote PA layer 231 according to step S30. In this embodiment, the processing shown in Figure B220 is not required.

[0136] Then, as indicated by arrow A220, the remote PA layer 231 sends a PACP_PWR_cnf frame.

[0137] Next, as Figure 4B As shown in arrow A120, the local PA layer 131 uses PA_LM_PWR_MODE.ind to pass the payload back to the local DME 135. As shown in arrow A122, the local DME 135 responds with PA_LM_PWR_MODE.rsp_L. As shown in figure B108, the local PA layer 131 checks and confirms.

[0138] As indicated by arrow A130, based on... Figure 2A or Figure 2B In step S10 of the method, the local DME135 generates a configuration indication signal (e.g., represented by the symbol FW_MPHY_CFG.ind) to instruct the firmware that it is time to configure the vendor-specific MIB of the M-PHY. This triggers the firmware of the local host (e.g., host 10) (e.g., executed by processing unit 14) to configure the M-PHY layer. The configuration indication signal is non-standard relative to the interconnection protocol, and the firmware is implemented outside the hardware protocol engine (e.g., hardware protocol engine 13).

[0139] On the other hand, as shown in Figure B110, the local PA layer 131 enters the information configuration phase. At the same time, as shown in Figure B230, the remote PA layer 231 waits for the local burst transmission to stop (e.g., represented by Wait EoB).

[0140] As shown in figure B115, according to... Figure 2A or Figure 2B In step S20 of the method, after the firmware detects this specific indication, the firmware begins to configure the information of the target M-PHY's vendor-specific MIB, such as programming or programmable configuration, or setting the corresponding M-PHY layer information configuration registers, as shown by arrow A132.

[0141] As indicated by arrow A134, based on... Figure 2A or Figure 2B In step S30 of the method, after the firmware completes the information configuration of the vendor-specific MIB of the target M-PHY, it notifies the local PA layer 131 of the completion of the information configuration through the firmware (e.g., executed by processing unit 14). For example, according to one embodiment of step S30, information configuration (such as programming, register setting, or other suitable operations) is performed on a specific UniPro vendor-specific MIB to indicate completion. The above-described step S30 is a non-standard practice.

[0142] Subsequently, optionally, as shown in Figure B120, the local PA layer 131 enters another information configuration phase, which can be implemented by hardware (such as hardware protocol engine 13) configuring the physical layer according to at least one standard MIB for power mode changes of the M-PHY layer, based on the original specifications of the UniPro layer.

[0143] Alternatively, in another embodiment, the firmware can be used to configure the vendor-specific MIB and the standard MIB separately, and notify the local PA layer 131 according to step S30 when the configuration is completed. In this embodiment, the processing shown in Figure B120 is not required.

[0144] Next, as shown in Figure B130, the local PA layer 131 instructs the M-PHY layer 110 to stop burst transmission. As shown in Figure B131, the local PA layer 131 waits for the remote burst transmission to stop (e.g., represented by Wait EoB). As shown in Figure B232, the remote PA layer 231 instructs the M-PHY layer 210 to stop burst transmission.

[0145] Next, as shown in Figure B140, the local PA layer 131 uses the PA_DL_RESUME.ind instruction to report to the PA service user (such as DME) that the local PA layer 131 has completed the operation and the data link layer can continue to use the link.

[0146] As indicated by arrow A140, the local PA layer 131 uses the PA_LM_PWR_MODE_CHANGED.ind(PWR_LOCAL) instruction to notify the local DME 135 that the operation of changing the local power consumption mode has been completed.

[0147] Optionally, in one embodiment, as indicated by arrow A142, the local DME135 can be configured to issue a DME_POWERMODE.ind(PWR_LOCAL) instruction to the local firmware (e.g., executed by processing unit 14) after receiving the PA_LM_PWR_MODE_CHANGED.ind instruction.

[0148] On the other hand, as shown in Figure B240, the remote PA layer 231 uses the PA_DL_RESUME.ind instruction to report that the remote PA layer 231 has completed its operation and that the data link layer can continue to use the link.

[0149] As indicated by arrow A230, the remote PA layer 231 uses the PA_LM_PWR_MODE_CHANGED.ind(PWR_REMOTE) instruction to notify the remote DME 235 that the operation of changing the power consumption mode in the remote location has been completed.

[0150] Optionally, in one embodiment, as indicated by arrow A232, the remote DME235 can be configured to issue a DME_POWERMODE.ind(PWR_REMOTE) instruction to the local firmware (e.g., executed by processing unit 24) after receiving the PA_LM_PWR_MODE_CHANGED.ind instruction.

[0151] Please refer to Figure 5 This is a schematic diagram illustrating one implementation of the circuit architecture for the aforementioned information configuration method. For example... Figure 5 As shown, the circuit architecture includes an interface circuit 310, a hardware protocol engine 320, and a processing unit 330. In one embodiment, the controller can be implemented based on the hardware protocol engine 320 and the processing unit 330. In another embodiment, the controller can be implemented based on the interface circuit 310, the hardware protocol engine 320, and the processing unit 330. The controller can be used to implement the aforementioned... Figure 1The host 10 or storage device 20 is included. The interface circuit 310, for example, is a host interface 11 or a device interface 21, used to implement, for example, the M-PHY layer of the UFS standard. The hardware protocol engine 320, for example, is a hardware protocol engine 13 or 23, used to implement, for example, the UniPro layer of the UFS standard.

[0152] For example, such as Figure 5 As shown, interface circuit 310 communicates with hardware protocol engine 320 via bus BS1 to send or receive (or read or write) instructions or data. Processing unit 330 communicates with interface circuit 310 or hardware protocol engine 320, for example, via bus BS2 to send or receive (or read or write) instructions or data. Hardware protocol engine 320 sends configuration indication signals, such as one or more interrupt signals or any suitable trigger signal, to processing unit 330, for example, via bus BS3.

[0153] like Figure 5 As shown, in response to changes in power consumption mode, the hardware protocol engine 320 can be implemented as including a power consumption mode change process control module 321 and a selection module 325.

[0154] The power consumption mode change process control module 321 is used to control the power consumption mode change process, for example, according to the aforementioned Figure 4A or Figure 4B The implementation of power consumption mode changes is achieved through various embodiments.

[0155] In the example of host 10 implemented using hardware protocol engine 320, power mode change process control module 321 can be based on the aforementioned Figure 4A or Figure 4B The implementation in this embodiment is based on the process of the local host 10.

[0156] For the example of storage device 20 implemented using hardware protocol engine 320, power mode change process control module 321 can be based on the aforementioned Figure 4A or Figure 4B The embodiments are implemented using the process for the remote storage device 20.

[0157] In addition, the selection module 325 is used for communication between the interface circuit 310 and the power consumption mode change process control module 321, and for communication between the interface circuit 310 and the processing unit 330.

[0158] For example, bus BS2 is connected to selection module 325 via bus BS21 within hardware protocol engine 320. Bus BS21 serves as a bus for information configuration via firmware. Bus BS2 is connected to power mode change process control module 321 via path L1 within hardware protocol engine 320. Path L1 is used to send instructions to power mode change process control module 321 via firmware to advance the power mode change process.

[0159] The power mode change process control module 321 is connected to the bus BS3 via path L2 inside the hardware protocol engine 320. Path L1 is used by the power mode change process control module 321 to send configuration indication signals to the bus BS3.

[0160] Optionally, the power consumption mode change process control module 321 can be connected to the selection module 325 via the bus BS22 inside the hardware protocol engine 320. The bus BS22 serves as a bus for hardware-based information configuration. In some of the foregoing embodiments, if information configuration is performed using firmware based on a vendor-specific MIB and a standard MIB, the hardware protocol engine 320 does not need to implement physical layer information configuration based on the standard MIB; therefore, the bus BS22 is optional.

[0161] The power consumption mode change process control module 321 can connect to the selection module 325 via path SC within the hardware protocol engine 320. Path SC is used to control the selection module 325 to perform bus switching.

[0162] For example, in implementing such Figure 4A In one example of the information configuration phase shown in Figure B210, the power mode change process control module 321 sends a control signal representing the selection bus BS21 to the selection module 325 via path SC to select bus BS21 to connect to bus BS1, thereby configuring the M-PHY layer by means of firmware (e.g., executed by processing unit 330), as shown in Figure B215.

[0163] For example, in implementing such Figure 4A In one example of the information configuration phase shown in Figure B220, the power mode change process control module 321 sends a control signal representing the selection bus BS22 to the selection module 325 via path SC to select bus BS22 to connect to bus BS1, thereby configuring the physical layer information according to at least one standard MIB for power mode change of the M-PHY layer by hardware (such as hardware protocol engine 320), as shown in Figure B220.

[0164] Furthermore, in the above embodiments concerning the host and storage devices (such as...) Figure 1 , 3In Figures 5 or related diagrams and embodiments, the hardware protocol engine in the host controller or device controller can be designed based on techniques using hardware description languages ​​(HDLs) or any other design method of digital circuits familiar to those skilled in the art. It can be implemented based on one or more circuits such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or complex programmable logic devices (CPLDs), or can be implemented using dedicated circuits or modules. The processing unit in the host controller or device controller can be implemented based on a microcontroller, processor, or digital signal processor.

[0165] As described above, the above embodiments provide a technique for information configuration of interconnect protocols. Various implementations are proposed based on this control technique, such as a method, controller, and storage device for information configuration of power mode changes. During the power mode change process of the interconnect protocol, information configuration is achieved through communication between a hardware protocol engine implementing the protocol layer of the interconnect protocol and the firmware. The communication between the hardware protocol engine and the firmware is performed in a non-standard manner, and the firmware is external to the hardware protocol engine. This technique provides a sufficiently flexible circuit architecture that can be efficiently configured to meet the manufacturer-specific information configuration needs of different products, thus facilitating product development by adapting to various manufacturers' designs.

[0166] The present invention has been disclosed above with reference to preferred embodiments. However, those skilled in the art should understand that the embodiments are merely illustrative and should not be construed as limiting the scope of the invention. It should be noted that all variations and substitutions equivalent to the described embodiments should be considered within the scope of the present invention. Therefore, the scope of protection of the present invention is defined by the claims.

Claims

1. A method for configuring power mode changes for an interconnect protocol, applicable to a first device capable of linking a second device according to the interconnect protocol, characterized in that, The method includes: When the hardware protocol engine of the first device, which implements the protocol layer of the interconnection protocol, changes the power consumption mode according to the protocol layer of the interconnection protocol: The hardware protocol engine generates a configuration indication signal to trigger the firmware of the first device to configure information on the physical layer of the interconnection protocol, wherein the configuration indication signal is non-standard relative to the interconnection protocol, and the firmware is outside the hardware protocol engine. In response to the configuration indication signal, the physical layer is configured via the firmware; and After completing the configuration of the physical layer information, the firmware notifies the hardware protocol engine of the completion of the information configuration.

2. The method according to claim 1, characterized in that, The configuration of the physical layer information is performed by the firmware based on at least one vendor-specific Management Information Base (MIB) used for power mode changes of the physical layer.

3. The method according to claim 2, characterized in that, The method further includes: In response to the notification that the information configuration is complete, the hardware protocol engine configures the physical layer information based on at least one standard management information base for power mode changes of the physical layer.

4. The method according to claim 1, characterized in that, The physical layer information configuration is performed by the firmware based on data including: At least one vendor-specific management information base is used for power mode changes in the physical layer; as well as At least one standard management information base is used for power mode changes of the physical layer.

5. The method according to claim 1, characterized in that, The firmware notifies the hardware protocol engine of the completion of the information configuration, including: A request conforming to the protocol layer is triggered to set up an additional vendor-specific management information base, which is then used to notify the hardware protocol engine of the completion of the information configuration.

6. The method according to claim 5, characterized in that, The request triggered by the firmware is a Device Management Entity (DME) request conforming to the protocol layer, and the additional vendor-specific management information base is configured for the protocol layer.

7. The method according to claim 1, characterized in that, The interconnection protocol is the Universal Flash Storage (UFS) standard, and the protocol layer and the physical layer are the unified protocol of the UFS standard, namely the UniPro layer and the physical layer, namely the M-PHY layer.

8. A controller suitable for use in a first device capable of linking a second device according to an interconnection protocol, characterized in that, The controller includes: A hardware protocol engine for implementing the protocol layer of the interconnection protocol; and The processing unit, which is coupled to the hardware protocol engine, When the hardware protocol engine changes the power consumption mode according to the protocol layer, The hardware protocol engine is used to generate a configuration indication signal to trigger firmware execution by the processing unit to configure information of the physical layer of the interconnect protocol, wherein the configuration indication signal is non-standard relative to the interconnect protocol, and the firmware is outside the hardware protocol engine; and The firmware is used to configure the physical layer in response to the configuration indication signal, and to notify the hardware protocol engine of the completion of the configuration when the configuration is complete.

9. The controller according to claim 8, characterized in that, The configuration of the physical layer information is performed by the firmware based on at least one vendor-specific management information base used for power consumption mode changes of the physical layer.

10. The controller according to claim 9, characterized in that, The hardware protocol engine is used to configure the physical layer according to at least one standard management information base for the power consumption mode change after being notified of the completion of the information configuration.

11. The controller according to claim 8, characterized in that, The firmware is used to configure information about the physical layer based on data including: At least one vendor-specific management information base for physical layer power mode changes; as well as At least one standard management information base is used for power mode changes of the physical layer that are compatible with the protocol layer.

12. The controller according to claim 8, characterized in that, The firmware is used to set up an additional vendor-specific management information base by triggering a request conforming to the protocol layer, thereby notifying the hardware protocol engine of the completion of the information configuration.

13. The controller according to claim 12, characterized in that, The request triggered by the firmware is a Device Management Entity (DME) request conforming to the protocol layer, and the additional vendor-specific management information base is configured for the protocol layer.

14. The controller according to claim 8, characterized in that, The interconnection protocol is the Universal Flash Storage (UFS) standard, and the protocol layer and the physical layer are the unified protocol of the UFS standard, namely the UniPro layer and the physical layer, namely the M-PHY layer.

15. A storage device capable of connecting to a host according to an interconnection protocol, characterized in that, The storage device includes: Interface circuitry for implementing the physical layer of the interconnection protocol to link the host; and A device controller is configured to be coupled to the interface circuit and the storage module, wherein the device controller includes: A hardware protocol engine for implementing the protocol layer of the interconnection protocol; and The processing unit, which is coupled to the hardware protocol engine, When the hardware protocol engine changes the power consumption mode according to the protocol layer, The hardware protocol engine is used to generate a configuration indication signal to trigger firmware execution by the processing unit to configure information of the physical layer of the interconnect protocol, wherein the configuration indication signal is non-standard relative to the interconnect protocol, and the firmware is outside the hardware protocol engine; and The firmware is used to configure the physical layer in response to the configuration indication signal, and to notify the hardware protocol engine of the completion of the configuration when the configuration is complete.

16. The storage device according to claim 15, characterized in that, The interconnection protocol is the Universal Flash Storage (UFS) standard, and the protocol layer and the physical layer are the unified protocol of the UFS standard, namely the UniPro layer and the physical layer, namely the M-PHY layer.

Images