CN114822655A

CN114822655A - Non-volatile storage device with fast boot code transfer with low speed rollback

Info

Publication number: CN114822655A
Application number: CN202110799127.4A
Authority: CN
Inventors: Y·平托; R·索玛桑达拉姆
Original assignee: Western Digital Technologies Inc
Current assignee: Western Digital Technologies Inc
Priority date: 2021-01-19
Filing date: 2021-07-15
Publication date: 2022-07-29
Also published as: DE102021118110A1

Abstract

A memory system includes a non-volatile memory configured to store boot code and a control circuit coupled to the non-volatile memory. In response to a first request from a host to transfer the boot code, the storage system begins transferring the boot code to the host at a first transfer speed. Determining that the boot code transfer has failed before successfully completing the transfer of the boot code to the host at the first transfer speed. Thus, the host will issue a second request for the boot code. In response to a second request for the boot code, and recognizing that this is a rollback condition because a previous transmission of the boot code failed, the storage device retransmits the boot code to the host at a lower transmission speed than the first transmission speed.

Description

Non-volatile storage device with fast boot code transfer with low speed rollback

Background

Many electronic devices utilize embedded or connected memory systems. Typically, embedded or connected storage systems include non-volatile memory, such as flash memory. An electronic device that includes an embedded or connected storage system is referred to as a host.

The process by which a host initiates an operation and enters a ready state for the intended operation is referred to as a "boot" or "boot process". The host typically has a ROM (read only memory) that stores a minimum amount of code for starting the boot process. When the host is powered on or rebooted, code stored in the ROM that instructs the host to upload the complete boot code from a dedicated portion of the embedded or attached storage system will be executed. The host will use the boot code to perform the boot process.

Since users of electronic devices generally do not want to wait too long for the boot process to be completed, it is desirable to perform the transfer of the complete boot code from an embedded or connected memory system at a high transfer speed. In some cases, the transmission speed of the boot code is pre-programmed in an embedded or connected storage system. However, problems can occur when line conditions (e.g., temperature, interference, and/or line delay) become unfavorable for communication at a preprogrammed transmission speed. For example, boot code may be subject to corruption during transfer from the storage system to the host. If the boot code cannot be read by the host, the host and/or the storage system may be deemed inoperable.

Drawings

Like numbered elements refer to common features in different figures.

FIG. 1A is a block diagram of one embodiment of a storage system connected to a host.

FIG. 1B illustrates a block diagram of one embodiment of a front-end processor circuit.

Figure 1C illustrates a block diagram of one embodiment of a back-end processor circuit.

FIG. 1D illustrates a block diagram of one embodiment of a memory package.

FIG. 1E is a block diagram of an interface between a host and a storage system.

Figure 2A is a functional block diagram of one embodiment of a memory die.

Figure 2B is a functional block diagram of one embodiment of an integrated memory component.

FIG. 2C depicts one embodiment of an integrated memory component.

FIG. 3 is a timing diagram describing how commands are executed on an interface between a host and a storage system.

FIG. 4 is a block diagram depicting the structure of a command.

FIG. 5 is a flow chart describing one embodiment of a process for transferring boot code from a storage system to a host.

FIG. 6 is a flow chart describing one embodiment of a process for transferring boot code from a storage system to a host.

FIG. 7 is a flow chart describing one embodiment of a process for transferring boot code from a storage system to a host.

FIG. 8 is a timing diagram describing one embodiment of a process for transferring boot code from a storage system to a host.

FIG. 9 is a timing diagram describing one embodiment of a process for transferring boot code from a storage system to a host.

FIG. 10 is a timing diagram describing one embodiment of a process for transferring boot code from a storage system to a host.

FIG. 11 is a flow chart describing one embodiment of a process for transferring boot code from a storage system to a host.

FIG. 12 is a flow chart describing one embodiment of a process for transferring boot code from a storage system to a host.

FIG. 13 is a flow chart describing one embodiment of a process for transferring boot code from a storage system to a host.

FIG. 14 is a timing diagram describing one embodiment of a process for transferring boot code from a storage system to a host.

Detailed Description

To prevent the host and/or storage system from being deemed inoperable, it is proposed to transmit boot code quickly, and if there is a problem with transmitting boot code quickly, to automatically fall back to transmitting boot code at a lower speed. A storage system implementing the proposal includes a non-volatile memory configured to store boot code for a host, and control circuitry connected to the non-volatile memory. In response to a first request from the host to transfer boot code (e.g., at power up, reset, or other circumstances), the storage system begins transferring boot code to the host at a first transfer speed. If it is determined that the boot code transmission has failed (e.g., the boot code received at the host includes too many errors or is otherwise unavailable due to adverse line conditions such as extreme temperatures, interference, and/or other line delays), the host will issue a second request for the boot code. In response to the second request for boot code and recognizing that this is a rollback condition because the previous transfer of boot code failed, the storage system retransmits the boot code to the host at a lower transfer speed. Transmitting at a lower speed may allow the host to successfully receive the boot code.

FIG. 1A is a block diagram of one embodiment of a storage system 100 connected to a host system 120. Storage system 100 may implement the techniques disclosed herein. Many different types of storage systems may be used with the techniques disclosed herein. Exemplary storage systems include SD cards or solid state drives ("SSDs"); however, other types of storage systems may also be used. The memory system 100 includes a memory controller 102, one or more memory packages 104 for storing data, and local memory (e.g., DRAM/ReRAM) 106. The memory controller 102 includes a front-end processor circuit (FEP)110 and one or more back-end processor circuits (BEPs) 112. In one embodiment, the FEP circuit 110 is implemented on an ASIC. In one embodiment, each BEP circuit 112 is implemented on a separate ASIC. In one embodiment, the ASICs for each of the BEP circuitry 112 and the FEP circuitry 110 are implemented on the same semiconductor, such that the memory controller 102 is fabricated as a system on a chip ("SoC"). Both the FEP 110 and the BEP 112 include their own processors. In one embodiment, the FEPs 110 and BEPs 112 operate in a master-slave configuration, where the FEP 110 is the master and each BEP 112 is a slave. For example, the FEP circuit 110 implements a flash translation layer that performs memory management (e.g., garbage collection, wear leveling, etc.), logical-to-physical address translation, communication with a host, management of DRAMs (local volatile memory), and management of the overall operation of SSDs (or other non-volatile storage systems). The BEP circuitry 112 manages memory operations in the memory enclosure 104 as requested by the FEP circuitry 110. For example, the BEP circuitry 112 may implement read, erase, and program processes. In addition, the BEP circuit 112 may perform buffer management, set a particular voltage level required by the FEP circuit 110, perform error correction (ECC), control a switch mode interface to the memory package, and so forth. In one embodiment, each BEP circuit 112 is responsible for its own set of memory packages. The memory controller 102 is one example of a control circuit.

In one embodiment, there are multiple memory packages 104. Each memory package 104 may include one or more memory dies. In one embodiment, each memory die in the memory package 104 utilizes NAND flash memory (including two-dimensional NAND flash memory and/or three-dimensional NAND flash memory). In other embodiments, the memory package 104 may include other types of memory; for example, the memory package may include Phase Change Memory (PCM) or Magnetoresistive Random Access Memory (MRAM).

In one embodiment, the memory controller 102 communicates with the host system 120 using an interface 130. To operate with the storage system 100, the host system 120 includes a host processor 122, a host memory 124, and an interface 126 that communicate via a bus 128. Host memory 124 is the physical memory of the host and may be DRAM, SRAM, non-volatile memory, or another type of storage device. Host 120 may also include a hard disk drive connected to bus 128 and/or a USB drive in communication with bus 128. Software (code) for programming host processor 122 may be stored in host memory 124, a hard disk drive or a USB drive connected to bus 128. The host memory 124, hard disk drive and USB drive connected to the bus 128 are examples of non-transitory processor-readable storage media that store processor-readable code that, when executed on the host processor 122, causes the host processor 122 to perform the methods described below.

The host system 120 is external to and separate from the storage system 100. In one embodiment, the storage system 100 is embedded in or connected to a host 120. The memory controller 102 may communicate with the host 120 via various types of communication interfaces including, for example, an SD card interface, NVME over PCIe, NVME over fabric architecture, or cache/memory coherent architectures based on accelerator Cache Coherent Interconnect (CCIX), fast link Computing (CXL), open coherent accelerator processor interface (OpenCAPI), Gen-Z, etc.

FIG. 1B is a block diagram of one embodiment of the FEP circuit 110. FIG. 1B shows a host interface 150 and a host processor 152 in communication with the host system 120. Host processor 152 may be any type of processor known in the art suitable for implementation. The host processor 152 communicates with a Network On Chip (NOC) 154. NOCs are communication subsystems on integrated circuits, typically between cores in a SoC. NOCs may span both synchronous and asynchronous clock domains, or use asynchronous logic that is not clocked. NOC technology applies network theory and methodology to on-chip communications and represents a significant improvement over conventional bus and crossbar interconnects. NOCs improve SoC scalability and complex SoC power efficiency over other designs. The wires and links of the NOC are shared by many signals. Since all links in the NOC can run simultaneously on different data packets, a high degree of parallelism is achieved. Thus, as the complexity of integrated subsystems continues to increase, NOCs provide enhanced performance (such as throughput) and scalability compared to previous communication architectures (e.g., dedicated point-to-point signal lines, shared buses, or segmented buses with bridges). Connected to the NOC 154 and in communication with the NOC 154 are a memory processor 156, SRAM 160, and DRAM controller 162. The DRAM controller 162 is used to operate and communicate with a DRAM (e.g., DRAM 106, which is a volatile memory). SRAM 160 is a local volatile RAM memory used by memory processor 156. The memory processor 156 is used to run the FEP circuit and perform various memory operations. Also in communication with the NOC are two

PCIe interfaces

164 and 166. In the embodiment of FIG. 1B, memory controller 102 includes two BEP circuits 112; thus, there are two PCIe interfaces 164/166. Each PCIe interface 164/166 communicates with one of the BEP circuits 112. In other embodiments, there may be more or less than two BEP circuits 112; thus, there may be more than two PCIe interfaces.

Fig. 1C is a block diagram of one embodiment of the BEP circuit 112. Fig. 1C shows a PCIe interface 200 for communicating with the FEP circuit 110 (e.g., communicating with one of the PCIe interfaces 164 and 166 of fig. 1B). PCIe interface 200 communicates with two

NOCs

202 and 204. In one embodiment, two NOCs may be combined into one large NOC. Each NOC (202/204) is connected to SRAM (230/260), buffer (232/262), processor (220/250), and data path controller (222/252) through XOR engine (224/254), ECC engine (226/256).

The ECC engine 226/256 is used to perform error correction as is known in the art. The ECC engine 226/256 may be referred to herein as a controller ECC engine. XOR engine 224/254 is used to perform an XOR on the data so that the data may be combined and stored in a recoverable manner in the presence of a programming error. In one implementation, the XOR engine 224/254 may recover data that cannot be decoded using the ECC engine 226/256.

The data path controller 222 is connected to a memory interface 228 for communicating with the integrated memory component via four channels. Thus, the top NOC 202 is associated with a four channel memory interface 228 for communicating with the memory package, and the bottom NOC 204 is associated with a four additional channel memory interface 258 for communicating with the memory package. In one embodiment, each memory interface 228/258 includes four switched mode interfaces (TM interfaces), four buffers, and four schedulers. For each channel there is one scheduler, buffer and TM interface. The processor may be any standard processor known in the art. The data path controller 222/252 may be a processor, FPGA, microprocessor, or other type of controller. XOR engine 224/254 and ECC engine 226/256 are dedicated hardware circuits, referred to as hardware accelerators. In other embodiments, XOR engine 224/254, ECC engine 226/256 may be implemented in software. The scheduler, buffer and TM interface are hardware circuits. In other embodiments, the memory interface (circuitry for communicating with the memory die) may be a different structure than depicted in FIG. 1C. In addition, controllers having different structures than fig. 1B and 1C may also be used with the techniques described herein.

Fig. 1D is a block diagram of one embodiment of a memory package 104 that includes a plurality of memory dies 300 (memory die 0, memory die 1, memory die 2, … memory die M) connected to a memory bus (data lines and chip enable lines) 318. The memory bus 318 is connected to the switched mode interface 270 for communication with the TM interface of the BEP circuit 112 (see, e.g., fig. 1C). In some embodiments, the memory enclosure may include a small controller connected to the memory bus 318 and the TM interface 270. In summary, the memory package 104 may have 8 or 16 memory dies; however, other numbers of memory dies may also be implemented. The techniques described herein are not limited to any particular number of memory dies. In some embodiments, the memory package may also include a processor, a CPU device, such as a RISC-V CPU, and an amount of RAM to help implement some of the capabilities described below. The techniques described herein are not limited to any particular number of memory dies.

FIG. 1E is a block diagram of the interface 130 between the host 120 and the storage system 100. In one embodiment, the interface 130 is an SD card interface, which includes the following signals: CLK, V _DD 、V _SS 、Data[3:0]And a CMD. CLK is the host to memory system clock signal. V _DD Is the power signal provided to the memory system 100. The voltage level provided on this signal is also commonly referred to as V _DD 。V _SS Is a ground signal provided to memory system 100. Data [3:0]]Is a four bit bidirectional data bus. CMD is a one-bit bidirectional command and response signal.

Fig. 2A is a block diagram depicting one example of a memory die 300 in which techniques described herein may be implemented. The memory die 300 (which may correspond to one of the memory dies 300 of fig. 1C) includes a non-volatile memory array 302. All or a portion of the memory array 302 is used to store boot code 350. In one embodiment, the boot code 350 resides on one memory die 300. In another embodiment, the boot code 350 resides on multiple memory dies 300. The array terminal lines of memory array 302 include various word line layers organized in rows and various bit line layers organized in columns. However, other orientations may be implemented. Memory die 300 includes row control circuit 320 whose outputs 308 are connected to corresponding word lines of memory array 302. Row control circuitry 320 receives a set of M row address signals and one or more various control signals from system control logic circuitry 360 and may generally include circuitry such as row decoders 322, array terminal drivers 324, and block selection circuitry 326 for both read and write operations. The row control circuit 320 may also include read/write circuits. The memory die 300 also includes column control circuitry 310 that includes sense amplifiers 330, the inputs/outputs 306 of which are connected to corresponding bit lines of the memory array 302. Although only a single block is shown for array 302, the memory die may include multiple arrays or multiple planes that may be individually accessed. Column control circuitry 310 receives a set of N column address signals and one or more various control signals from system control logic 360 and may generally include circuitry such as column decoders 312, array terminal receivers or drivers 314, block selection circuitry 316, and read/write circuitry and I/O multiplexers.

System control logic 360 receives data and commands from host 120 and provides output data and status to memory controller 102. In some embodiments, system control logic 360 includes a state machine 362 that provides die-level control of memory operations. In one embodiment, the state machine 362 can be programmed by software. In other embodiments, the state machine 362 is implemented without software and entirely in hardware (e.g., circuitry). In another embodiment, the state machine 362 is replaced by a microcontroller or microprocessor, with the microcontroller or microprocessor being on or off the memory chip. The system control logic 360 may also include a power control module 364 that controls the power and voltages supplied to the rows and columns of the memory array 302 during memory operations and may include charge pump and regulator circuitry for generating regulated voltages. The system control logic 360 includes a memory device 366 that may be used to store parameters for operating the memory array 302.

Commands and data are transferred between memory controller 102 and memory die 300 via memory controller interface 368 (also referred to as a "communication interface"). Memory controller interface 368 is an electrical interface for communicating with memory controller 102. Examples of the memory controller interface 368 include a switch mode interface and an Open NAND Flash Interface (ONFI). Other I/O interfaces may also be used. For example, the memory controller interface 368 may implement a switched mode interface that connects to a switched mode interface of the memory interface 228/258 of the memory controller 102. In one embodiment, memory controller interface 368 includes a set of input and/or output (I/O) pins that connect to memory controller 102.

In some embodiments, all elements of memory die 300 (including system control logic 360) may be formed as part of a single die. In other embodiments, some or all of system control logic 360 may be formed on different dies.

For purposes of this document, the phrase "control circuitry" includes any one or combination of the memory controller 102, the state machine 362, a microcontroller, a microprocessor, all or a portion of the system control logic 360, the row control circuitry 320, the column control circuitry 310, and/or other similar circuitry for controlling non-volatile memory. The one or more control circuits may comprise hardware only or a combination of hardware and software, including firmware. For example, a controller programmed by firmware to perform the functions described herein is one example of a control circuit. The control circuit may include a processor, FGA, ASIC, integrated circuit, or other type of circuit.

In one implementation, memory structure 302 includes a three-dimensional memory array of non-volatile memory cells, in which multiple memory levels are formed above a single substrate, such as a wafer. The memory structure may include any type of non-volatile memory that is integrally formed in one or more physical levels of memory cells having an active area disposed above a silicon (or other type) substrate. In one example, a non-volatile memory cell includes a vertical NAND string having a charge trapping layer.

In another implementation, the memory structure 302 includes a two-dimensional memory array of non-volatile memory cells. In one example, the non-volatile memory cells are NAND flash memory cells that utilize floating gates. Other types of memory cells (e.g., NOR-type flash memory) may also be used.

The exact type of memory array architecture or memory cells included in memory structure 302 is not limited to the examples described above. Many different types of memory array architectures or memory technologies may be used to form the memory array 302. No particular non-volatile memory technology is required to implement the new embodiments claimed herein. Other examples of suitable technologies for the memory cells of the memory array (or other type of memory structure) 302 include ReRAM memory (resistive random access memory), magnetoresistive memory (e.g., MRAM, spin-transfer torque MRAM, spin-orbit torque MRAM), FeRAM, phase change memory (e.g., PCM), and so forth. Examples of suitable technologies for memory cell architectures include two-dimensional arrays, three-dimensional arrays, cross-point arrays, stacked two-dimensional arrays, vertical bit line arrays, and the like.

One example of a ReRAM cross-point memory includes reversible resistance-switching elements arranged in a cross-point array accessed by X-lines and Y-lines (e.g., word lines and bit lines). In another embodiment, the memory cell may include a conductive bridge memory element. The conductive bridge memory elements may also be referred to as programmable metallization cells. The conductive bridge memory element may function as a state-change element based on physical repositioning of ions within the solid electrolyte. In some cases, a conductive bridge memory element may include two solid metal electrodes, one being relatively inert (e.g., tungsten) and the other being electrochemically active (e.g., silver or copper), with a thin film of solid electrolyte between the two electrodes. As temperature increases, the mobility of the ions also increases, which results in a lower programming threshold for the conductive bridge memory cell. Thus, the conductive bridge memory element can have a wide range of programming thresholds over the entire temperature range.

Another example is Magnetoresistive Random Access Memory (MRAM) that stores data through magnetic memory elements. These elements are formed of two ferromagnetic layers separated by a thin insulating layer, each of which can hold a magnetization. One of the two layers is a permanent magnet set to a particular polarity; the magnetization of the other layer may be changed to match the magnetization of the storage memory by an external magnetic field. The memory device is constructed from a grid of such memory cells. In one embodiment for programming, each memory cell is located between a pair of write lines arranged at right angles to each other, parallel to the cell, one above the cell and one below the cell. When a current is passed through them, an induced magnetic field is generated. MRAM-based memory implementations are discussed in more detail below.

Phase Change Memories (PCMs) take advantage of the unique properties of chalcogenide glasses. One embodiment uses a GeTe-Sb2Te3 superlattice to achieve a non-thermal phase change by merely changing the coordination state of the germanium atoms with a laser pulse (or a light pulse from another source). Thus, the programmed dose is a laser pulse. The memory cells may be inhibited by preventing the memory cells from receiving light. In other PCM implementations, the memory cell is programmed by current pulses. It should be noted that the use of "pulses" in this document does not require rectangular pulses, but includes (continuous or discontinuous) vibrations or pulse trains of sound, current, voltage light or other waves. These memory elements within each selectable memory cell or bit may include additional series elements such as ovonic threshold switches or metal insulator substrates as selectors.

One of ordinary skill in the art will recognize that the techniques described herein are not limited to a single particular memory structure, memory configuration, or material composition, but encompass many related memory structures within the spirit and scope of the techniques as described herein and as understood by one of ordinary skill in the art.

The elements of fig. 2A may be grouped into two parts, namely the structure of memory array 302 and peripheral circuitry that (in some embodiments) includes all of the structures except memory array 302, namely 310, 320, and 360. An important characteristic of a memory circuit is its capacity, which can be increased by: increasing the area of the memory die of memory system 100 that is reserved for a particular use of memory fabric 302; however, this reduces the area of the memory die available for peripheral circuitry. This can place considerable limitations on these peripheral components. For example, it is desirable to fit the sense amplifier circuitry within the available area, which can be a significant limitation on the sense amplifier design architecture. The reduction in available area relative to system control logic 360 may limit the available functions that may be implemented on a chip. Thus, a substantial tradeoff needs to be made in the design of the memory die of memory system 100 in the amount of dedicated area for memory structure 302 and the amount of dedicated area for peripheral circuitry.

Another area where memory array 302 and peripheral circuitry are often contradictory is in the processing involved in forming these areas, as these areas often involve different processing technologies, resulting in tradeoffs when implementing different technologies on a single die. For example, when the memory array 302 is a NAND flash memory, this is an NMOS structure, while the peripheral circuitry is typically CMOS based. For example, elements such as sense amplifier circuits, charge pumps, logic elements in the state machine, and other peripheral circuitry in the system control logic 360 typically employ PMOS devices. The processing operations used to fabricate a CMOS die will differ in many respects from those optimized for NMOS flash NAND memory or other memory cell technologies.

To improve these limitations, the embodiments described below may separate the elements of fig. 2A onto separately formed dies, which are then bonded together. More specifically, memory array 302 may be formed on one die (memory die), and some or all of the peripheral circuit elements (including one or more control circuits) may be formed on a separate die (control die). For example, a memory die may be formed of only memory elements, such as flash NAND memory, MRAM memory, PCM memory, ReRAM memory, or other memory type of memory cell array. Some or all of the peripheral circuitry (even including elements such as decoders and sense amplifiers) may then be moved onto a separate control die. This allows each of the memory dies to be individually optimized according to its technology. For example, a NAND memory die can be optimized for NMOS-based memory array structures without concern for CMOS elements that have now moved to a separate peripheral circuitry die that can be optimized for CMOS processing. This provides more space for peripheral elements, which now can incorporate additional capabilities that may not be easily incorporated if the peripheral elements are limited to the edge of the same die that houses the memory cell array. The two dies may then be bonded together in a bonded multi-die memory circuit, with the array on one die connected to peripheral elements on the other memory circuit. For example, while the following description will focus on bonded memory circuits of one memory die and one control die, other embodiments may use more dies, such as two memory dies and one peripheral circuit die.

Fig. 2B shows an alternative arrangement to that of fig. 2A, which may be implemented using wafer-to-wafer bonding to provide bonded die pairs (referred to as integrated memory components). FIG. 2B depicts a functional block diagram of one embodiment of an integrated memory component 307. One or more integrated memory components 307 may be used in memory package 104 in storage system 100. Integrated memory assembly 307 includes two types of semiconductor dies (or more succinctly, "dies"). Memory die 301 includes memory array 302. The memory array 302 may include non-volatile memory cells. A portion of the memory array 302 is used to store boot code 350. The boot code 350 is used by the host processor 124 to perform the boot process, as described above.

Control die 311 includes control circuits 310, 320, and 360 (the details of which are discussed above). In some embodiments, control die 311 is configured to connect to memory array 302 in memory die 301. Fig. 2B shows an example of peripheral circuitry, which includes control circuitry formed in a peripheral circuitry or control die 311, which is coupled to a memory array 302 formed in a memory die 301. Common components are labeled in a manner similar to that of FIG. 2A. System control logic 360, row control circuitry 320, and column control circuitry 310 are located in control die 311. In some embodiments, all or a portion of column control circuitry 310 and all or a portion of row control circuitry 320 are located on memory die 301. In some embodiments, some of the circuitry in system control logic 360 is located on memory die 301.

System control logic 360, row control circuitry 320, and column control circuitry 310 may be formed from conventional processes (e.g., CMOS processes) such that adding elements and functions more commonly found on memory controller 102, such as ECC, may require few or no additional process steps (i.e., the same process steps used to manufacture memory controller 102 may also be used to manufacture system control logic 360, row control circuitry 320, and column control circuitry 310). Thus, although removing such circuitry in a die (such as memory die 301) may reduce the number of steps required to manufacture such a die, adding such circuitry to a die (such as control die 311) may not require many additional process steps.

Fig. 2B shows column control circuitry 310 on a control die 311 that includes sense amplifiers 350, which is coupled to the memory array 302 on the memory die 301 by electrical paths 306. For example, electrical path 306 may provide electrical connections between column decoder 312, driver circuit 314, block selector 316, and bit lines of memory array (or structure) 302. Electrical paths may extend from column control circuitry 310 in control die 311 through pads on control die 311 that are bonded to corresponding pads of memory die 301 that are connected to bit lines of memory structure 302. Each bit line of memory structure 302 may have a corresponding one of electrical paths 306, including a pair of bond pads connected to column control circuitry 310. Similarly, row control circuitry 320 (including row decoder 322, array driver 324, and block selector 326) is coupled to memory array 302 by electrical path 308. Each of electrical paths 308 may correspond to a word line, a dummy word line, or a select gate line. Additional electrical paths may also be provided between the control die 311 and the memory structure die 301.

In some embodiments, there is more than one control die 311 and/or more than one memory die 301 in integrated memory assembly 307. In some embodiments, integrated memory assembly 307 comprises a stack of a plurality of control die 311 and a plurality of memory die 301. In some embodiments, each control die 311 is attached (e.g., bonded) to at least one of the memory fabric dies 301.

As noted herein, there may be more than one control die 311 and more than one memory die 301 in the integrated memory assembly 307. In some embodiments, integrated memory assembly 307 comprises a stack of a plurality of control die 311 and a plurality of memory die 301. Figure 2C depicts a side view of one embodiment of integrated memory component 307 stacked on substrate 400. Integrated memory assembly 307 has three control die 311 and three memory die 301. Each control die 311 is bonded to one of the memory dies 301. Some of the

bond pads

402, 404 are depicted. There may be more bond pads. The space between the two dies 301, 311 bonded together is filled with a solid layer 406, which may be formed of epoxy, other resin, or polymer. The solid layer 406 protects the electrical connections between the dies 301 and 311 and further secures the dies together. Various materials may be used for solid layer 406, but in embodiments, the material may be Hysol epoxy from Henkel corporation, which has an office in california, usa.

Integrated memory component 307 may be stacked, for example, at a stepped offset, such that bond pads 410 at each level are uncovered and accessible from above. Wire bonds 412 connected to bond pads 410 connect control die 311 to substrate 400. A plurality of such wire bonds may be formed across the width of each control die 311 (i.e., into the page of fig. 2C).

Through Silicon Vias (TSVs) 414 may be used to route signals through the control die 311. Through Silicon Vias (TSVs) 416 may be used to route signals through the memory die 301.

TSVs

414, 416 may be formed before, during, or after the formation of the integrated circuits in semiconductor dies 301, 311. TSVs may be formed by etching holes through the wafer. The holes may then be lined with a barrier against metal diffusion. The barrier layer, in turn, may be lined with a seed layer, and the seed layer may be plated with an electrical conductor, such as copper, although other suitable materials may be used, such as aluminum, tin, nickel, gold, doped polysilicon, and alloys or combinations thereof.

For one embodiment of the specific implementation depicted in fig. 2C, the various depicted

TSVs

414 and 416 connected to the bond pads 410 and wire bonds 412 may be used so that the multiple control dies 311 may communicate with each other and the multiple control dies 311 may transfer data between each other, e.g., a first control die may read data from a memory die to which it is bonded, transfer the data (after some optional processing) to a second control die, and the second control die may program the data into a memory die bonded to the second control die.

Solder balls 418 may optionally be attached to contact pads 420 on the lower surface of substrate 400. Solder balls 418 may be used to electrically and mechanically couple integrated memory assembly 307 to a printed circuit board. In the case where integrated memory component 307 is to be used as an LGA package, solder balls 418 may be omitted. Solder balls 418 may form part of an interface between integrated memory component 307 and memory controller 102.

In the embodiment of fig. 2C, the memory die 301 and the control die 311 are arranged in pairs. That is, each memory die 301 is bonded to and communicates with a corresponding/matched/paired control die 311. In other embodiments, the control die may be bonded (or otherwise connected) to more than one memory die.

As described above, in one embodiment, the interface 130 between the storage system 100 and the host 120 is an SD card interface (see, e.g., FIG. 1E). In one embodiment, the communication over the SD card interface is based on a command and data bit stream. The command is a token to initiate an operation. Commands are sent from the host 120 to the storage system 100 (e.g., memory controller 102). Commands are transmitted serially on the CMD line. The response is a token sent from the storage system 100 (e.g., memory controller 102) to the host 120 as a response to a previously received command. The response is transmitted serially on the CMD line. Data may be transferred from host 120 to storage system 100 or from storage system 100 to host 120 via Data lines Data [3:0 ]. The data transfer is performed in SD data blocks. Cyclic Redundancy Checks (CRCs) are error detection codes that are commonly used in digital networks and storage devices to detect undesirable changes in the original data. The SD data block includes CRC bits. The command may result in the transmission of one or more SD data blocks (each having CRC bits).

FIG. 3 is a timing diagram/signal diagram depicting CMD lines and Data [3:0] of interface 130 over time. FIG. 3 includes an example of a command from host 120 to memory system 100 on the CMD lines that causes memory system 100 (e.g., memory controller 102) to send a response token on the CMD lines and multiple Data blocks in Data [3:0], with CRC bits appended to each SD Data block. For example, the command of FIG. 3 may include a request to send the boot code 350, and the data block may include the boot code 350 (read from the memory array 302) with the CRC bits added. Alternatively, the commands of FIG. 3 may include a request to read data from the memory array 302, and the data block may be subject to a data read.

FIG. 4 depicts the structure of one embodiment of a command sent from host 120 to memory system 100 on the CMD line. In this embodiment, the command has 48 bits. The command starts with a start bit (e.g., 0) and then is a bit indicating the direction of transmission (e.g., 1 from the host 120). The next six bits indicate the command index of the command, which is interpreted as a binary-coded number between 0 and 63, indicating which command in the command set is being issued. Some commands require parameters encoded by a thirty-two bit data pattern [39:8 ]. The parameter is followed by eight CRC bits. The command is terminated by an end bit (e.g., 1). One example of a command is an idle command (e.g., CMD0) that requests that storage system 100 enter an idle state and have a command index equal to 0 (in one embodiment). In general, the parameter [39:8] of CMD0 is set to 0.

As described above, the storage system 100 stores boot code 350 for the host 120. The host 120 has a ROM (not shown in fig. 1) that stores a minimum amount of code for starting the boot process. When the host 120 powers up or reboots, code stored in the ROM will be executed that instructs the host 120 to upload the complete boot code 350 from the storage system 100. The host processor 124 will use the boot code to perform the boot process.

To improve performance, it is optimal if the boot code 350 is transferred from the storage system 100 to the host 120 at a high transfer speed. However, problems can occur when line conditions (e.g., temperature, interference, and/or line delay) become detrimental to communicating at high transmission speeds. For example, the boot code 350 may be corrupted during transmission from the storage system 100 to the host 120 due to extreme temperatures, interference, or other line delays. If the boot code 350 cannot be read by the host 120, the host 120 and/or the storage system 100 may be deemed inoperable.

To prevent the host 120 and/or the storage system 100 from being deemed inoperable, it is suggested to transmit the boot code quickly, and if there is a problem with transmitting the boot code quickly, automatically fallback to transmitting the boot code at a lower speed. FIG. 5 is a flow chart describing one embodiment of a process for implementing a fast boot code transfer from storage system 100 to host 120, wherein if there is a problem with the fast boot code transfer, a fallback to a low speed boot code transfer is made. In one implementation, the process of FIG. 5 is performed by any of the control circuits of memory system 100 described above. For example, in one implementation, the process of FIG. 5 is performed by or in the direction of memory controller 102 (or another processor in memory system 100).

In step 502 of FIG. 5, the control circuitry receives a request to transmit boot code 350 to an entity external to memory system 100. In one embodiment, the host 120 is an entity external to the storage system 100, and the control circuitry receives the request from the host 120. In step 504, the control circuitry begins transmitting the boot code 350 to the entity via the interface 130 at a first transmission speed (e.g., a fast transmission speed). In one exemplary implementation, the control circuitry reads the boot code 350 from the non-volatile memory array 302 and adds CRC bits (error correction) to the boot code before beginning to transmit the boot code to create a plurality of Data blocks that are transmitted to the host 120 via Data [3:0], as depicted in FIG. 3. In step 506, the control circuitry determines that the boot code 350 was not successfully transmitted. In one embodiment, the control circuitry is configured to determine that the boot code was not successfully transmitted by receiving an indication from the host that the boot code was not successfully transmitted. More detailed information is provided below. In step 508, the control circuit transmits the boot code 350 to the entity via the interface 130 at a lower transmission speed than the first transmission speed. In one embodiment, in response to determining that the boot code 350 was not successfully transmitted, the control circuitry is configured to automatically select a lower transmission speed. In one exemplary implementation, the control circuitry is configured to use the lower transmission speed without an indication from the host 120 to use the lower transmission speed.

In one embodiment, interface 230 may operate in three modes, each mode having its own transmission speed. The following table provides one example of a plurality of transmission speeds of the interface 230.

Mode(s)	Speed of transmission
		SD HS	25MB/s
DDR50	50MB/s
		SDR104	104MB/s

The transmission speed indicates the amount of Data that can be transmitted over Data [3:0] in one second of time. The modes SD HS and SDR104 transmit data on the rising edge of the clock signal CLK. The mode DDR50 transfers data on rising and falling edges of the clock signal CLK. In one embodiment, the clock speed is the same for SD HS and DDR50, but for DDR50, the Data on Data [3:0] has a higher transfer speed because for DDR50, the Data is transferred on the rising and falling edges of the clock signal CLK. In other embodiments, more than three modes of operation and more than three transfer speeds may be implemented, and/or different modes of operation and different transfer speeds may be implemented. According to the above table, the SD HS is a mode having the lowest transmission speed (25MB/s), and the SDR104 is a mode having the highest transmission speed (104 MB/s).

In one exemplary implementation, step 504 includes transmitting the boot code (SDR104) at a highest transmission speed of 104MB/S, and step 508 includes transmitting the boot code at a lowest transmission speed of 25MB/S (SD HS), even if there is another transmission speed (e.g., 50MB/S for DDR50) that is lower than the first transmission speed (e.g., 104MB/S for SDR104) and higher than the lowest transmission speed (e.g., 25MB/S for SD HS).

In another exemplary implementation, step 504 includes transmitting the boot code (SDR104) at a highest transmission speed of 104MB/S, and step 508 includes transmitting the boot code at a next lower transmission speed relative to the first transmission speed. In this example, the next lowest transfer speed relative to the first transfer speed is 50MB/S (DDR 50). It should be noted that this time the low transmission speed (e.g., 50MB/s for DDR50) is higher than the lowest transmission speed (e.g., 25MB/s for SD HS).

It should be noted that in the process of FIG. 5, all or a portion of the boot code 350 is transmitted (or attempted to be transmitted) twice: once in step 504 and a second time in step 508. In both step 504 and step 508, the same boot code is transmitted. Thus, in both

steps

504 and 508, the control circuitry reads the same boot code 350 from the same location in the memory array 302 and sends the same boot code 350 to the host 120.

In some embodiments, the control circuitry is configured to transmit the tuning block to the host 120 prior to beginning transmission of the boot code 350 so that the host 120 tunes to receive data from the storage system 100. A tuning block is a known block of data that can be used to tune the sampling point of the host 120. Tuning will compensate for static delays in the timing budget, including process, voltage, and different PCB loads and offsets. In some embodiments, the known data blocks, including the tuning blocks, are sent to the host forty times. In other embodiments, known data blocks including tuning blocks may be sent to the host more or less than forty times. In one implementation, the tune block includes 64 bytes of predefined Data transmitted over Data [3:0 ]. In some embodiments, CRC bits are added to the tuning block. In some implementations that include a tuning block, determining that the boot code was not successfully transmitted in step 506 may include determining that the boot code was not successfully transmitted due to the host 120 failing to successfully receive the tuning block, the host 120 failing to successfully tune reception using the tuning block, and/or the host 120 failing to successfully receive the boot code 350 after successful tuning.

FIG. 6 is a flow chart describing one embodiment of a process for implementing a fast boot code transfer from the storage system 100 to the host 120, wherein if there is a problem with the fast boot code transfer, a fallback to a low speed boot code transfer is made. In one implementation, the process of FIG. 6 is performed by any of the control circuits of memory system 100 described above. For example, in one implementation, the process of FIG. 6 is performed by or at the memory controller 102 (or another processor in the memory system 100). The process of fig. 6 is one exemplary implementation of the process of fig. 5.

In step 602 of FIG. 6, the host 120 sends a request to transmit the boot code 350 by holding the command line CMD at a preset level for a predetermined number of clock cycles during a first initial period of time. In one embodiment of memory system 100, when the host first powers up, or powers back up, or resets start-up system 100, if host 120 holds CMD low (e.g., ground, 0v, or a preset low voltage) for 75 or more clock cycles, this is considered a command or request for memory system 100 to transmit boot code 350 to host 120. In step 604, the control circuit (e.g., the memory controller 102) receives a request from the host 120 to transmit the boot code 350 by sensing that the host 120 has maintained the command line CMD at a preset level for a predetermined number of clock cycles during a first initial period of time. In one embodiment, steps 602 and 604 are exemplary implementations of step 502 of FIG. 5. In step 606 of FIG. 6, the control circuitry begins transmitting boot code to the host at a first transmission speed as preconfigured on the storage system 100. For example, memory system 100 may include a register or set of registers that host 100 may utilize to program the transfer speed that should be used to transfer the boot code. In another embodiment, the storage system 100 may be preconfigured to transmit at a transmission speed. In one embodiment, step 606 is an exemplary implementation of step 504 of FIG. 5.

As described above, in some embodiments, the storage system 100 will transmit the tuning block before sending the actual boot code. In step 608, the host fails to successfully receive the boot code. For example, the host 120 may be unable to successfully receive a tuning block, unable to successfully perform tuning using a tuning block, or unable to receive all or a portion of the boot code 350. In step 610, the host changes the command line to a level other than the preset level before completing the transfer of the boot code to indicate that the boot code was not successfully transferred. Thus, if tuning fails or the boot code is not successfulReceive, the host will change the command line CMD to indicate a failure. For example, if the host holds the command line CMD line at ground to indicate a request to transfer a boot code, then in step 610, the host will change the command line CMD line to V _DD Or other positive voltage. In step 612, the control circuit of the memory system 100 is configured to determine that the boot code has not been successfully transmitted by sensing that the host has changed the command line CMD to a level other than the preset level before completing the transmission of the boot code at the first transmission speed. In one embodiment, the first transmission speed is any one of the three transmission speeds described above. In step 614, the control circuit is configured to set a flag indicating that the boot code was not successfully transmitted in response to sensing that the host has changed the command line CMD to a level other than the preset level before the transmission code is completed. For example, the memory system 100 may include a location in non-volatile storage to store a flag bit that indicates whether the boot code was successfully or unsuccessfully transmitted. In one embodiment, steps 608 through 614 are exemplary implementations of step 506 of FIG. 5.

In step 616 of FIG. 6, the host 120 powers back on (shuts down and then powers on) and/or performs a reset of the storage system 100. In step 618, the host 120 sends a request to the memory system 100 to transmit the boot code by maintaining the command line CMD at a preset level for a predetermined number of clock cycles (e.g., 75) during a second initial period of time. In step 620, the control circuit of the memory system 100 receives a request to transmit a boot code by sensing that the host has kept the command line signal CMD at a preset level (e.g., ground level) for a predetermined number of clock cycles during a second initial period (which is after the first initial period) (from step 618). In step 622, the control circuit checks the status of the flag (which may or may not have been set in step 614). If the flag is set, the control circuitry will reset the flag in step 622. If the flag is set, this means that the previous attempt to transmit the boot code failed. In step 624, the control circuitry is configured to automatically select a lower than first transmission speed in response to the boot code not being successfully transmittedThe transmission speed, boot code unsuccessful transmission is learned by the control circuit by checking the status of the flag in step 622. Step 624 is performed in response to

steps

618, 620 and 622. In step 626, the control circuitry begins transmitting the boot code to the host at the lower transmission speed automatically selected in step 624. In some embodiments, the host may select a lower transmission speed. In other embodiments, the lower transmission speed is not automatically selected. In step 628, the host successfully receives all boot codes transmitted. It should be noted that

steps

626 and 628 may also include transmitting the tuning block. In step 630, the host changes the command line CMD to indicate that the boot code was successfully transmitted; for example, by raising the command line to V _DD (or another positive voltage). In one embodiment, V _DD Is between 2.5 volts and 6 volts. In one embodiment, steps 616 through 630 of fig. 6 are exemplary implementations of step 508 of fig. 5.

FIG. 7 is a flow chart describing one embodiment of a process for implementing a fast boot code transfer from the storage system 100 to the host 120, wherein if there is a problem with the fast boot code transfer, a fallback to a low speed boot code transfer is made. In one implementation, the process of FIG. 7 is performed by any of the control circuits of memory system 100 described above. For example, in one implementation, the process of FIG. 7 is performed by or at the memory controller 102 (or another processor in the memory system 100). The process of fig. 7 is one exemplary implementation of the process of fig. 5. The process of fig. 7 is similar to that of fig. 6 (as indicated by common reference numerals), except that the numerals are used. For example, in the process of FIG. 7, step 605 (performed after step 604 and before 606) includes the control circuit setting a flag to indicate that the boot code transfer process has begun. Step 614 of fig. 6 is omitted from the process of fig. 7. Step 622 of FIG. 7 has been changed from step 622 of FIG. 6 because the flag will not be reset in step 622 when the control circuitry will check the status of the flag. Additionally, at the end of the process of FIG. 7, the control circuitry will reset the flag in step 632. Thus, in the process of FIG. 6, the flag is used to indicate that the transmission of the boot code has failed. In the process of fig. 7, a flag is used to indicate that the boot code transfer process has started, and the flag is reset when the boot code transfer process has completed. Thus, when the process of fig. 7 is performed, if the storage system receives a request to transmit the boot code and the flag has been set, this means that the previous transmission of the boot code failed, so that the current transmission is a fallback mode to be performed at a lower transmission speed.

FIG. 8 is a timing diagram describing one embodiment of a process for transferring boot code from storage system 100 to host 120. FIG. 8 shows a signal V for any of the processes of FIG. 5, FIG. 6, or FIG. 7 _DD CLK, CMD and Data [3:0]Examples of (2). FIG. 8 illustrates an example of the transmission of boot code 350 when there are no errors. Power signal V _DD Is shown rising from ground to what is commonly referred to as V _DD And is maintained throughout the time period during fig. 8 to power the memory system 100. In fig. 8, the clock signal CLK is a series of pulses. To request a boot code transfer, the host 120 holds the command line CMD at ground (e.g., 0 volts) for at least the first 75 clock cycles. In response to receiving the request via command line CMD (e.g., CMD held at 0v for 75 clock cycles), memory system 100 transmits a tuning block (optional) and a boot code. When memory system 100 is first powered on, Data lines Data [3:0]]Is floating. In response to sensing that the CMD remains at ground level for 75 clock cycles, the memory system 100 begins the process of transmitting the boot code. The time period before t1 corresponds to

steps

602 and 604 of fig. 6 when the CMD is held at ground level for 75 clock cycles. At time t1, at Data [3:0]And transmits one or more tuning blocks. If CMD remains low at time t2 (indicating that the tuning process was successful), then boot code is transferred between time t2 and t 3. It should be noted that the time period between t2 and t3 corresponds to step 606 of FIG. 6. FIG. 8 shows that the boot code was successfully transmitted because the boot code was already at Data [3:0]]After the upper completion transfer, the host 120 raises the command line CMD to V at time t3 _DD (or another positive value).

FIG. 9 is a flowchart illustrating a method for storing boot code from storageTiming diagram of one embodiment of the process of system 100 transmitting to host 120. FIG. 9 shows signal V when there is an error in the transmission of the boot code _DD CLK, CMD and Data [3:0]Behavior during the example. Fig. 9 is an exemplary implementation of performing any of the processes of fig. 5, 6, or 7. First, the host 120 passes V _DD Up to the supply voltage (commonly referred to as V) required by memory system 100 _DD ) To provide power to the memory system 100. The signal CLK will clock the memory system 100 from the host 120. To request a boot code transfer, the host 120 will hold the command line CMD low (e.g., ground) for at least the first 75 clock cycles, which corresponds to

steps

602 and 604 of FIG. 6. In response to the request to transmit the boot code, at time t1, the storage system 100 sends one or more tune blocks. In some embodiments, the tuning block will not be transmitted and no tuning process will occur. In the example of FIG. 9, after the tuning block is completed and before the boot code is transmitted, the tuning block is successfully transmitted, e.g., the command line CMD is not raised to V _DD As shown. At time t2, the control circuitry of the storage system 100 begins transmitting the boot code to the host 120 at the first transmission speed, which corresponds to step 606. However, in this example, the host 120 cannot successfully receive the boot code (step 608); thus, at time t3, host 120 responds by raising command line CMD to V _DD (which corresponds to steps 610 and 612) to change the command line CMD. The host 120 then powers back on the memory system 100 after time t3 (corresponding to step 616), and the clock signal CLK will begin again. Prior to time t4, host 120 holds command line CMD at 0v (ground) for at least 75 clock cycles during a second initial time period corresponding to

steps

618 and 620. At time t4, storage system 100 transfers one or more tuning blocks (optional). At time t5, the storage system 100 transmits the boot code at a lower transmission speed (corresponding to steps 626 and 628). Fig. 9 does not show the difference in clock periods of the first or lower transfer speeds in order to keep the plot readable, and it is unclear how the transfer speed will change (e.g., by changing the clock or when the data is sampled, or both). In this example, the transmission is between times t5 and t6Is successfully transmitted (see step 628); thus, at time t6 (step 630), host 120 responds by raising the command line to V _DD The command line is changed to indicate successful transmission of the boot code. In this example, memory system 100 is raised to V by CMD at time t3 _DD Or power is turned back on or both to receive an indication from the host that the boot code was not successfully transmitted.

FIG. 10 is a timing diagram describing one embodiment of a process for transferring boot code from a storage system to a host. The process of fig. 10 shows signal V of the process of fig. 5, 6 or 7 when there is an error in transmitting the tuning block or tuning _DD CLK, CMD and Data [3:0]The behavior of (c). FIG. 10 shows host 120 providing V _DD A (power supply) supplies power to the storage system 100. The clock signal provides the same clock cycles as described above with reference to fig. 8 and 9. The host 120 sends a request to transmit a boot code by holding the command line CMD low (grounded) for at least 75 clock cycles before time t1 (corresponding to steps 602 and 604). At time t1, the storage system 100 begins transmitting the tuning block. In this example, the tuning block was not successfully received, or the tuning block was received but the tuning process failed. Either way, the host raises the command line CMD to V _DD (this corresponds to steps 610 and 612). The host 120 then powers back on (step 616), and the host 120 holds the command line CMD low (e.g., 0v or ground) for at least 75 clock cycles (corresponding to steps 618 and 620) to request that the boot code be transmitted during the second initial period. At time t3, the storage system 100 sends a tune block. This tuning is performed successfully. At time t4, the storage system 100 transmits the boot code to the host 120 (corresponding to steps 626 and 628). Due to the successful receipt of the boot code, at time t5, host 120 raises command line CMD to V _DD (corresponding to step 630).

FIG. 11 is a flow chart describing another embodiment of a process for implementing a fast boot code transfer from storage device 100 to host 120, wherein if there is a problem with the fast boot code transfer, a fallback to a low speed boot code transfer is made. In one implementation, the process of FIG. 11 is performed by any of the control circuits of memory system 100 described above. For example, in one implementation, the process of FIG. 11 is performed by or in the direction of memory controller 102 (or another processor in memory system 100). The process of fig. 11 is one exemplary implementation of the process of fig. 5.

In step 802 of FIG. 11, the host 120 performs a power-up or power-back, and/or a reset of the storage system 100. In step 804, the host 120 sends a first idle command having a data pattern indicating a first transmission speed. The idle command is sent to the storage system 100. One example of this idle command is CMD0, which is a command for the SD card interface. Referring again to fig. 4, each command includes a command index and parameters. CMD0 has a particular bit pattern for the command index, and typically uses all zeros for its parameters. However, it is proposed to include a non-zero data pattern in the parameter field indicating the requested transmission speed. In another embodiment, the data pattern may also indicate whether a tuning block is included. The following table includes an exemplary set of data patterns to be included in the parameter fields (bits 39:8 of the command-see fig. 4).

The data patterns 0xF0F0 and 0xE0E0 indicate that a predefined transmission speed is used. In some implementations, the host 120 may utilize a predefined transfer speed (e.g., one of SD HS, DDR50, or SDR104) to set configuration parameters in the storage system 100. Alternatively, the storage system 100 may be preconfigured with a predefined transfer speed.

The data patterns and associated transmission speeds of the above table are only one set of examples. Other data modes and transmission speeds may also be used. In addition, other embodiments may implement greater or lesser numbers of data modes and transmission speeds than described above.

In step 806 of FIG. 11, the control circuitry receives and/or recognizes the idle command and its data pattern and enters the idle state. The control circuitry will also begin preparing for boot code transfers, which may include reading boot codes from the memory array 302.

Steps

804 and 806 of fig. 11 are exemplary implementations of step 502 of fig. 5.

In step 810 of FIG. 11, the control circuitry will set a flag in response to the first idle command. As described above, the control circuitry on the storage system 100 may include a flag stored in non-volatile memory that indicates that the boot code transfer process has begun. In step 812, the control circuit issues a tuning block if the data mode indication in the idle command includes a tuning block. If the tuning block is successfully transmitted and the host 120 is able to successfully tune in step 814, the control circuitry adds the CRC bits to the boot code block read from the memory array 102 and begins transmitting the boot code at the requested transmission speed in step 816. If tuning is not successful (including either unsuccessful transmission of a tuning block or successful transmission of tuning but not the host), then after step 814, the process continues at step 902 of fig. 12 (or fig. 13) to perform a fallback condition.

If the tuning is successful, then boot code is transmitted from the storage system 100 to the host 120 in step 816. In step 820, the host receives all or a portion of boot code 350. If the boot code was successfully transmitted (step 822), the control circuitry will reset the flag in step 824 (the flag is set in step 818) and both the host and the storage system will enter normal operation in step 826. For example, the host 120 will complete the boot process and then operate at its expected capacity. However, if the boot code was not successfully transmitted (step 822), then the process continues in step 902 of FIG. 12 (or FIG. 13). In one embodiment, steps 810 through 820 of fig. 11 are exemplary implementations of step 504 of fig. 5.

FIG. 12 is a flow diagram describing one embodiment of a process to perform a fallback to low speed boot code transfer when there is a problem with the fast boot code transfer. For example, in FIG. 11, step 816 includes transmitting the boot code at the requested transmission speed, wherein the requested transmission speed is a fast transmission speed. If the transmission of the boot code fails, a rollback procedure is performed according to the steps of FIG. 12. In one implementation, the process of FIG. 12 is performed by any of the control circuits of memory system 100 described above. For example, in one implementation, the process of FIG. 12 is performed by or at the memory controller 102 (or another processor in the memory system 100). The process of FIG. 12 is an exemplary implementation of

steps

506 and 508 of FIG. 5.

If the tuning is not successful (step 814) or the boot code transmission is not successful (step 822), then step 902 of FIG. 12 is performed. In step 902, the host 120 performs a power-up or power-back, or otherwise resets the memory system 100. In step 904, the host 120 sends a second idle command (e.g., CMD0) having a data pattern indicating that the boot code is to be transmitted at the second transmission speed. The above data patterns may be used. In step 906, the control circuitry receives or otherwise identifies a second idle command and data pattern and enters an idle state. In addition, the control circuitry prepares to transmit the boot code 350. In step 908, the control circuitry checks the flag in response to the second idle command. The flag will indicate to the control circuitry whether this is a fallback condition due to a transmission failure or whether this is an initial attempt to transmit the boot code. In step 910, the control circuit determines whether the requested transmission speed (the second transmission speed indicated in the data pattern — see step 904) is lower than the first transmission speed of step 804 of fig. 11. In one embodiment, the host may select a lower transfer speed using the data pattern of step 904. In this example, step 910 of fig. 12 would include the control circuit determining whether the second transmission speed is lower than the first transmission speed. If not, the control circuit will select a new transmission speed lower than the first transmission speed in step 914. If the second transmission speed indicated in the data mode of step 904 is lower than the first transmission speed in step 912, the control circuit sets the new transmission speed to the second transmission speed. In another option, the data mode may indicate that a predefined transfer speed that has been set in a configuration register or memory location is used. However, if the idle command and data pattern in step 804 also indicates that a preconfigured transmission speed is used, then in step 910 it will be determined that the requested new speed is not lower than the first transmission speed, so the control circuit will have to automatically select the new transmission speed to be a speed lower than the first transmission speed. It should be noted that steps 910 through 914 are performed in response to the flag being set.

In step 916, the control circuit issues a tuning block. Step 916 is only performed if the data mode indicates that a tuning block is used. If the data mode indicates that the tuning block is not to be used, the process will skip to step 920. If a tuning block is to be used, the tuning block is transmitted to the host in step 916 and received by the host in step 918. In step 920, the control circuit adds CRC bits to the boot code block and starts transmitting the boot code at the new transmission speed. In step 922, the host 120 successfully receives the boot code. As a result of successful transmission of the boot code, the control circuit resets the flag (see step 908). In step 926, the system enters normal operation; for example, a boot process is performed and the host 120 and storage system 100 are used for their intended purposes.

FIG. 13 is a flow chart describing another embodiment of a process for implementing a rollback procedure when the boot code transmission at the initial fast boot code speed is unsuccessful. Fig. 13 is performed in conjunction with the process of fig. 11, and is an alternative embodiment of the process of fig. 12. In one implementation, the process of FIG. 13 is performed by any of the control circuits of memory system 100 described above. For example, in one implementation, the process of FIG. 13 is performed by or in the direction of memory controller 102 (or another processor in memory system 100). The process of fig. 13 is another exemplary implementation of

steps

506 and 508 of fig. 5. The process of fig. 13 begins with steps 902 through 908, which are the same as fig. 12. However, the process of FIG. 13 deviates from step 950 of the process of FIG. 12 (performed after step 908) in that the control circuit automatically sets a new transfer speed. That is, regardless of the data pattern included in the idle command, the control circuit will automatically select the lowest transmission speed available or the next lowest transmission speed relative to the first transmission speed. After step 950, the process of FIG. 13 includes performing the same steps 916 through 926 as in FIG. 12.

FIG. 14 is a view described in FIGS. 11 to 13During execution of the process used signal V _DD CLK, CMD and Data [3:0]Timing diagrams of the behavior of (a). Initially, power (V) is provided to the memory system 100 _DD ). As described above, signal CLK provides the clock. The first idle command is sent on command line CMD at time t1 and includes a serial set of bits indicating a command with a data pattern according to the structure shown in FIG. 4. This corresponds to

steps

804 and 806. At time t2, at Data lines Data [3:0]]The tuning block is transmitted (step 812). In the example of fig. 14, it is assumed that the data pattern included in the idle command requests a tuning block, the tuning block is successfully transmitted, and the host 120 successfully tunes. At time t3, at Data [3:0]Up transmits a portion of the boot code 350. This corresponds to

steps

816 and 820 of fig. 11. By time t4, the host 120 has determined that the boot code was not successfully transmitted. For example, the data may be corrupted and may not be recoverable using the CRC bits. Therefore, the host computer 120 is powered back on at time t4 (step 902). After power is turned back on and supplied to the memory system 100, the clock signal CLK is supplied again from the host 120 to the memory system 100. At time t5, the host 120 sends a second idle command with a data pattern (step 904). In step 916, at Data [3:0] according to steps 916 and 918]And an upper transmission tuning block. At time t7, boot code is transmitted from the control circuitry of the storage system 100 to the host 120 as per

steps

920 and 922. By time t8, the transmission of the boot code has completed successfully.

A non-volatile storage system has been disclosed that can store boot code for a host and transmit the boot code to the host as part of a boot process, such that the transmission of the boot code to the host is performed at a high speed to mitigate the effect of the transmission on the total time required to complete the boot process. However, if the transfer of the boot code fails, rather than concluding that the non-volatile storage system is inoperable (and possibly replacing it), the non-volatile storage system falls back to a failsafe mode in which the boot code is transferred at a slower rate, thereby increasing the chance that the boot code transfer will succeed.

One embodiment includes a non-volatile storage device including non-volatile memory configured to store boot code and control circuitry coupled to the non-volatile memory. The control circuit is configured to: the method includes receiving a request to transmit a boot code to an entity external to the non-volatile storage device, initiating transmission of the boot code to the entity at a first transmission speed, determining that the boot code was not successfully transmitted, and transmitting the boot code to the entity at a transmission speed lower than the first transmission speed.

In one exemplary implementation, the control circuit is configured to receive a request to transmit a boot code by sensing that the entity has maintained the command line signal at a preset level for a predetermined number of clock cycles during a first time period; the control circuit is configured to determine that the boot code has not been successfully transmitted by sensing that the entity has changed the command line signal to a level other than a preset level before completion of transmission of the boot code to the entity at the first transmission speed; the control circuit is configured to sense that the entity has maintained the command line signal at a preset level for the predetermined number of clock cycles during a second time period subsequent to the first time period; and the control circuit is configured to automatically select the lower transfer speed in response to the boot code not being successfully transferred and in response to sensing that the entity has maintained the command line signal at the preset level for a predetermined number of clock cycles during the second time period.

In one example implementation, the control circuitry is configured to receive the request to transmit the boot code by receiving a first idle command from the entity to place the non-volatile storage device in an idle state, the idle command including a first data pattern indicative of a first transmission speed; the control circuit is configured to determine that the boot code was not successfully transmitted by either turning its power back on or receiving a second idle command with a new data pattern indicating a lower transmission speed; and the control circuit is configured to transmit the boot code to the entity at a lower transmission speed in response to a second idle command with a new data pattern.

One embodiment includes a method of operating a non-volatile storage device, the method comprising: receiving, at the non-volatile storage device, a first request from a host to transmit boot code to the host, the boot code stored in non-volatile memory in the non-volatile storage device; in response to a first request, transmitting at least a portion of boot code from the non-volatile storage device to the host at a first transmission speed; receiving, at the non-volatile storage device, a second request from the host to transmit boot code to the host; and transferring the boot code from the non-volatile storage device to the host at a second transfer speed that is lower than the first transfer speed.

One example implementation includes a non-volatile storage device including non-volatile memory configured to store boot code for a host and control circuitry coupled to the non-volatile memory. The control circuit includes a host interface for communicating with a host. The control circuit is configured to read boot code stored in the non-volatile memory. The control circuit further comprises means for: the method includes first transmitting a boot code to the host at a first transmission speed, and in response to the first transmission of the boot code being unsuccessful, automatically selecting a second transmission speed that is lower than the first transmission speed and retransmitting the boot code to the host at the second transmission speed.

Exemplary architectures for means for first transmitting boot code to a host at a first transmission speed, automatically selecting a second transmission speed lower than the first transmission speed, and re-transmitting boot code to the host at the second transmission speed include, but are not limited to, microprocessors, microcontrollers, RISC processors, FPGAs, state machines, and/or combinations thereof, such as the memory controller 102, the FEP 110, the memory processor 156, and/or the state machine 362 executing any of the processes of fig. 5, 6, 7, 9, 10, 11 and 12 or 13 and/or 14.

For the purposes of this document, references in the specification to "an embodiment," "one embodiment," "some embodiments," or "another embodiment" may be used to describe different embodiments or the same embodiment.

For purposes of this document, a connection may be a direct connection or an indirect connection (e.g., via one or more other components). In some cases, when an element is referred to as being connected or coupled to another element, the element may be directly connected to the other element or indirectly connected to the other element via an intervening element. When an element is referred to as being directly connected to another element, there are no intervening elements between the element and the other element. Two devices are "in communication" if they are directly or indirectly connected, such that they can communicate electronic signals therebetween.

For the purposes of this document, the term "based on" may be understood as "based at least in part on".

For purposes of this document, the use of digital terms such as "first" object, "second" object, and "third" object, without additional context, may not imply a ranking of the objects, but may be used for identification purposes to identify different objects.

For purposes of this document, the term "group" of objects may refer to a "group" of one or more objects.

The foregoing detailed description has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments were chosen in order to best explain the principles of the proposed technology and its practical application to thereby enable others skilled in the art to best utilize it in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto.

Claims

1. A non-volatile storage device, comprising:

a non-volatile memory configured to store boot code; and

a control circuit connected to the non-volatile memory, the control circuit configured to:

receiving a request to transmit the boot code to an entity external to the non-volatile storage,

initiating transmission of the boot code to the entity at a first transmission speed,

determining that the boot code was not successfully transmitted, an

Transmitting the boot code to the entity at a transmission speed lower than the first transmission speed.

2. The non-volatile storage apparatus of claim 1, wherein:

in response to determining that the boot code was not successfully transmitted, the control circuitry is configured to automatically select the lower transmission speed.

3. The non-volatile storage apparatus of claim 1, wherein:

the control circuitry is configured to receive the request from a host, the host being the entity external to the non-volatile storage device; and is

The control circuitry is configured to determine that the boot code was not successfully transmitted by receiving an indication from the host that the boot code was not successfully transmitted.

4. The non-volatile storage apparatus of claim 1, wherein:

the control circuitry is further configured to read the boot code from the non-volatile memory and add error correction to the boot code before beginning transmission of the boot code.

5. The non-volatile storage apparatus of claim 1, wherein:

the control circuitry is further configured to read the boot code from a first location in the non-volatile memory for the beginning of the transfer of the boot code to the entity at the first transfer speed; and is

The control circuitry is further configured to read the boot code from the first location in the non-volatile memory for the transfer of the boot code to the entity at the lower transfer speed.

6. The non-volatile storage apparatus of claim 1, wherein:

the boot code transmitted to the entity at the lower transmission speed is the same boot code that started transmission to the entity at the first transmission speed.

7. The non-volatile storage apparatus of claim 1, wherein:

the control circuit is configured to communicate with the entity at three or more transmission speeds including a lowest transmission speed and a highest transmission speed; and

in response to determining that the boot code was not successfully transmitted, the control circuitry is configured to transmit the boot code to the entity at the lowest transmission speed even if there is another transmission speed that is lower than the first transmission speed and higher than the lowest transmission speed.

8. The non-volatile storage apparatus of claim 1, wherein:

the control circuit is configured to communicate with the entity at three or more transmission speeds including a lowest transmission speed; and is

The control circuit is configured to transmit the boot code to the entity at the lower transmission speed by transmitting the boot code to the entity at a next lower transmission speed relative to the first transmission speed, the next lower transmission speed relative to the first transmission speed being higher than the lowest transmission speed.

9. The non-volatile storage apparatus of claim 1, wherein:

the control circuit is configured to receive the request to transmit the boot code by sensing that the entity has maintained a command line signal at a preset level for a predetermined number of clock cycles during a first time period;

the control circuit is configured to determine that the boot code was not successfully transmitted by sensing that the entity changed the command line signal to a level other than the preset level before the transmitting the boot code to the entity at the first transmission speed was completed;

the control circuit is configured to sense that the entity has maintained the command line signal at the preset level for the predetermined number of clock cycles during a second time period after the first time period; and is

The control circuit is configured to automatically select the lower transfer speed in response to the boot code not being successfully transferred and in response to sensing that the entity has maintained the command line signal at the preset level for the predetermined number of clock cycles during the second time period.

10. The non-volatile storage apparatus of claim 9, wherein:

the control circuit is configured to set a flag indicating that the boot code was not successfully transmitted in response to sensing that the entity has changed the command line signal to a level other than the preset level prior to completion of the transmission of the boot code to the entity at the first transmission speed; and is

The control circuit is configured to automatically select the lower transfer speed in response to checking the status of the flag.

11. The non-volatile storage apparatus of claim 9, wherein:

the control circuit is configured to set a flag in response to the initiation of the transmission of the boot code to the entity at the first transmission speed;

the control circuitry is configured to reset the flag upon completion of successful transmission of the boot code; and is

12. The non-volatile storage apparatus of claim 1, wherein:

the control circuitry is configured to receive the request to transmit the boot code by receiving a first idle command from the entity to place the non-volatile storage in an idle state, the idle command including a first data pattern indicative of the first transmission speed;

the control circuitry is configured to determine that the boot code was not successfully transmitted by re-powering on its power supply and receiving a second idle command having a new data pattern indicative of the lower transmission speed; and is

The control circuit is configured to transmit the boot code to the entity at the lower transmission speed in response to the second idle command having the new data pattern.

13. The non-volatile storage apparatus of claim 12, wherein:

the new data pattern indicates transmission of a tuning block to the entity; and is

The control circuit is configured to transmit the tuning block to the entity before the control circuit transmits the boot code to the entity at the lower transmission speed.

14. The non-volatile storage apparatus of claim 1, wherein:

the control circuitry is configured to receive the request to transmit the boot code by receiving a first idle command from the entity to place the non-volatile storage in an idle state, the idle command including a first data pattern indicating transmission of the boot code;

the control circuit is configured to set a flag in response to the first idle command;

the control circuitry is configured to determine that the boot code was not successfully transmitted by either powering back on it or receiving a second idle command with a new data pattern indicating transmission of the boot code;

the control circuitry is configured to check a state of the flag in response to the second idle command; and is

The control circuit is configured to transmit the boot code at the lower transmission speed in response to the flag being set.

15. The non-volatile storage apparatus of claim 1, wherein:

the control circuitry is configured to receive the request to transmit the boot code by receiving a first idle command from the entity to place the non-volatile storage in an idle state, the idle command including a first data pattern indicating transmission of the boot code at the first transmission speed;

the control circuitry is configured to determine that the boot code was not successfully transmitted by either turning its power back on or receiving a second idle command with a new data pattern indicating that the boot code was transmitted at a new transmission speed;

the control circuitry is configured to check a state of the flag in response to the second idle command;

in response to the flag being set, the control circuitry is configured to retransmit the boot code at the new transmission speed if the new transmission speed is lower than the first transmission speed;

in response to the flag being set, the control circuitry is configured to select the lower transmission speed and retransmit the boot code at the lower transmission speed if the new transmission speed is not below the first transmission speed; and is

The control circuitry is configured to reset the flag after successful transmission of the boot code.

16. The non-volatile storage apparatus of claim 1, wherein:

The control circuit is configured to use the lower transmission speed without an indication from the host to use the lower transmission speed.

17. The non-volatile storage apparatus of claim 1, wherein:

the control circuitry is configured to receive the request to transmit the boot code by receiving a first idle command from the entity to place the non-volatile storage in an idle state, the idle command including a first data pattern indicating to transmit a tuning block and to transmit the boot code at the first transmission speed;

the control circuitry is configured to transmit the tuning block to the entity prior to the start of the transmission of the boot code, for the entity to tune reception from the non-volatile storage; and is

The boot code is not successfully transmitted because the entity failed to successfully tune using the tuning block.

18. A method of operating non-volatile storage, comprising:

receiving, at the non-volatile storage device, a first request from a host to transmit boot code to the host, the boot code stored in a non-volatile memory in the non-volatile storage device;

transmitting at least a portion of the boot code from the non-volatile storage to the host at a first transmission speed in response to the first request;

receiving, at the non-volatile storage device, a second request from the host to transmit the boot code to the host; and

transferring the boot code from the non-volatile storage device to the host at a second transfer speed that is lower than the first transfer speed.

19. The method of claim 18, further comprising:

after transmitting at least the portion of the boot code from the non-volatile storage to the host at the first transmission speed, receiving an indication from the host that the boot code was not successfully transmitted; and

the second transmission speed is automatically selected.

20. A non-volatile storage device, comprising:

a non-volatile memory configured to store boot code for a host; and

control circuitry connected to the non-volatile memory, the control circuitry including a host interface for communicating with the host, the control circuitry configured to read the boot code stored in the non-volatile memory;

the control circuit further comprises means for: the boot code is first transmitted to the host at a first transmission speed, and in response to the first transmission of the boot code being unsuccessful, a second transmission speed lower than the first transmission speed is automatically selected and the boot code is retransmitted to the host at the second transmission speed.