Patent Application
20090248955
Code in read-only memory (ROM) is hardwired into non-volatile memory during production, therefore making it difficult to replace. By design, a memory controller can access the boot code in ROM to obtain data for initialization and operation of a memory device, but otherwise is prevented from altering the boot code. However, there may be instances where a user may want to change the boot code. For example, during a testing process, the user may want to modify the code, such as adjusting a wait time to account for the parasitic RC delay in charging a bit line. Currently, the user can only do this by performing a focused ion beam experiment or mask change. These methods may take days to perform, and can cause additional delay and expense.
Another way to replace code in ROM is by having the controller directly access code stored in the memory array instead of code stored in ROM. However, particularly in a NAND string, this is a very slow process which can take upwards of 10 μs while the controller can typically access code at less than 100 ns. Therefore, there is a gap of greater than 100 times in accessing speed and is an inefficient process.
The invention will be understood more fully from the detailed description given below and from the accompanying drawings of embodiments of the invention which, however, should not be taken to limit the invention to the specific embodiment(s) described, but are for explanation and understanding only.
Referring to
It should be understood that memory device 10 may include non-volatile random access memory (NVRAM), ferroelectric random access memory (FeRAM or FRAM), ferromagnetic random access memory (FM-RAM), magnetoresistive random access memory (MRAM), phase-change memory (PCM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory (for ex., flash NOR, flash EPROM), and other non-volatile memory. Further, memory device 10 may be formed and manufactured using MOS (metal oxide semiconductor) technology, CMOS (complementary MOS) technology, BiCMOS (bipolar CMOS) technology, or other semiconductor manufacturing technologies suitable for forming non-volatile memory.
Memory device 10 may include an I/O buffer 12 configured to receive input and output and act as an external interface. The I/O buffer 12 may hold inputted commands for controlling the memory device 10, address information, data to be entered into the memory cell array 32, and data retrieved from the memory cell array 32. The I/O buffer 12 may send data to the secondary cache 14 for temporary storage and on to other components in the memory device 10.
The secondary cache 14 may be configured to receive data from I/O buffer 12 and from memory cell array 32. The controller 16 may be capable of reading any data that is loaded into the secondary cache 14.
The controller 16 may be responsible for programming and erasing of the memory cell array 32. The controller 16 may be capable of sending a ROM address to a ROM 17 and/or 18 to access code, which may include instruction code and macro code. In one embodiment, memory device 10 may include an instruction ROM 17 and a macro ROM 18. The controller 16 may further access code from one or more ROM redundancy registers 20 capable of storing code as a replacement for code that is stored in ROM 17 and/or ROM 18, as further described in
The controller 16 may also be capable of controlling other components of memory device 10 for normal read, write, and erase operations. The controller 16 may include a state machine for dedicated reading, erasing, and/or programming operations of the memory device 10.
The controller 16 may be further capable of controlling the peripheral circuits 22 by providing values to one or more control registers 24 via control register bus 26 and values to one or more parameter registers 28 via redundancy and parameter register bus 30. Peripheral circuits may include charge pumps and regulators 42, block address control and block redundancy circuit 44, column address control and column redundancy circuit 46, and data cache driver 48. The controller 16 may use the control register bus 26 to send controls signals to one or more control registers 24 controlling the charge pumps and regulators 42, block address control and block redundancy circuit 44, column address control and column redundancy circuit 46, and data cache driver 48. For example, control signals may include enable or disable, high or low, etc. The controller 16 may use the redundancy and parameter register bus 30 to send parameter values to one or more parameter registers 28 regulating the charge pumps and regulators 42, block address control and block redundancy circuit 44, column address control and column redundancy circuit 46, and data cache driver 48. For example, parameter values may include voltages sent to the charge pumps and regulators 42, other configurations, etc.
Although represented as single blocks of control registers 24 and parameter registers 28, there may be multiple control registers 24 and parameter registers 28 for controlling one or more of the peripheral circuits 22. It should be noted that peripheral circuits 22 may include additional circuits, such as clocking circuits, or omit some of those illustrated in
To sustain dynamic or static loads during different operating conditions to the memory cell array 32, the charge pumps and regulators 42 may be configured to provide bias voltages to one or more components which may include block address control and block redundancy circuit 44, column address control and column redundancy circuit 46, and data cache driver 48. The charge pumps and regulators 42 may also provide voltages to the wordline decoder 34, the bitline decoder 36, the data cache 38, and other memory components that may require regulated voltages.
The block address control and block redundancy circuit 44 is capable of comparing a block address that is received from the controller 16 to block addresses that are stored in a block redundancy register 44 to determine whether the block address corresponds to a problem location in the memory cell array 32. If the block address control and block redundancy circuit 44 finds a match, block address control 44 disables normal decoding of the memory cell array 32 and activates decoding of block redundancy to retrieve data from a new memory location on memory cell array 32. Similarly, the column address control and column redundancy circuit 46 is capable of comparing a column address that is received from the controller 16 to column addresses that are stored in a column redundancy register to determine whether the column address corresponds to a problem location in the memory cell array 32. If the column address control and column redundancy circuit 46 finds a match, column address control 46 disables normal decoding of the memory cell array 32 and activates decoding of column redundancy to retrieve data from a new memory location on memory cell array 32. Peripheral circuits 22 further include a data cache driver 48 configured to control when and/or how data may be moved in and out of the data cache 38.
Memory cell array 32 includes a plurality of memory cells arranged in an ordered array of rows and columns. The memory cells are independently addressable and may be programmed and read. In response to a received address from the block address control and block redundancy circuit 44, the wordline decoder 34 selects one or more rows (blocks) of the memory cell array for access to data. Similarly, upon receipt of an address from the column address control and column redundancy circuit 46, the bitline decoder 36 selects one or more columns of the memory cell array 32 for access to data.
Memory cell array 32 includes data cache 38 which is capable of reading blocks of data by accessing pages from the memory cell array 32 and storing user input from the secondary cache 14. Data cache 38 may store data immediately prior to programming or immediately after reading from the memory cell array 32. Data cache 38 may include sense amplifiers and latches to sense and hold data.
Memory cell array 32 may include a romfuse block 40 which is write-inhibited after first programming. For example, programming may occur during fabrication of memory device 10 or during user customization such as by blowing selected fuses on the silicon substrate. During the booting process of the memory device 10, the romfuse block 40 may be accessed first for initialization.
According to one embodiment, during a chip initialization sequence of the memory device 10, data transfer occurs from a first page (page0) of the romfuse block 40 to the data cache 38 using a default parameter value. The controller 16 reads the data from data cache 38 via secondary cache 14 and relocates the data into a column redundancy register 50. A column redundancy scheme, as described above, is initialized. Data is transferred from a second page (page1) of romfuse block 40 to data cache 38 with a default parameter value. The controller 16 reads data from data cache 38 via secondary cache 14 and relocates the data into one or more parameter registers 28. The loaded parameter values may then be used. The controller 16 reads data from data cache 38 and relocates the data into a block redundancy register 52. A block redundancy scheme, as described above, is initialized. The controller 16 reads data from data cache 38 via secondary cache 14 and relocates the data into one or more ROM redundancy registers 20. A redundancy for code scheme, as described below, is initialized.
The chip initialization sequence of memory device 10 may be controlled by code stored in ROM 17 and/or 18. However, after data is relocated in one or more ROM redundancy registers, the code in ROM 17 and/or 18 may be replaced with redundancy code stored in one or more of the ROM redundancy registers 20, as further described below. It should be noted that the chip initialization sequence of memory device 10 may be triggered by any number of factors. For example, the chip initialization sequence may begin in response to a power on signal or user command. Further, the chip initialization sequence may differ from the order of steps as described above, but the scope of the claimed subject matter is not limited in these respects.
Referring to
Referring briefly to
Referring now to
For example, if code located in the ROM address is corrupted, faulty, or needs to be changed as determined by a user, the ROM address may be previously flagged or recorded. A program or user may input replacement code to replace code corresponding to the flagged ROM address. One or more addresses and corresponding replacement code may be entered into the memory cell array 32 as redundancy information, which is later stored in the ROM redundancy register 20.
In one or more embodiments, the ROM redundancy register 20 may be used to “replace” code in ROM. It should be noted that the ROM redundancy register 20 does not physically replace the code at an address location in ROM. However, when the ROM address location is accessed, the ROM redundancy register 20 may be capable of substituting code that is stored in the ROM redundancy register 20 for code that is retrieved from the address location in ROM. Therefore, the controller 16 may receive replacement code from the ROM redundancy register 20 in lieu of code from ROM.
To provide replacement code to the controller 16, the ROM redundancy register 20 may be capable of determining whether the ROM address requested from the controller 16 matches with a ROM address stored in the ROM redundancy register 20. If a matching address is found in the ROM redundancy register 20, code located at the ROM address may be replaced by code stored in the ROM redundancy register 20. The ROM redundancy register 20 may include a logic circuit for comparing addresses and determining code that is sent to the controller 16. The logic circuit may use combinatorial or sequential logic.
It should be noted that a matching address does not need to match a requested ROM address exactly. For example, an address match may be found if nine specific bits out of ten bits are identical. What is defined as matching may depend on how a user desires to implement code replacement strategies for the ROM using the ROM redundancy register 20.
In one embodiment, the ROM addresses stored in the registers 70, 72, 74, and 76 may be fed into comparators 86, 88, 90, and 92, respectively. A ROM address may be sent from controller 16 and fed into the comparators 86, 88, 90, and 92. The instruction address buffer 62 may regulate when the ROM address is sent to the comparators 86, 88, 90, and 92. A comparison may be made at the comparators to determine whether there is an address match. If an ROM address stored in a register 70, 72, 74, or 76 matches the ROM address requested from controller 16, a corresponding comparator 86, 88, 90, or 92 may output a high signal (1). If the ROM address stored in the register 70, 72, 74, or 76 does not match the ROM address from controller 16, the corresponding comparator 86, 88, 90, or 92 may output a low signal (0).
The multiplexer 94 may be capable of controlling whether code located at the ROM address or code stored in the ROM redundancy register 20 is sent to the controller 16. The output signals from the comparators 86, 88, 90, and 92 are sent to a multiplexer 94. The multiplexer 94 also receives code located at the ROM address requested by the controller 16. The multiplexer 94 further receives redundant code stored at registers 78, 80, 82, and 84 corresponding to the ROM addresses stored in registers 70, 72, 74, and 76.
If multiplexer 94 receives a high signal from one of the comparators 86, 88, 90, and 92, the multiplexer 94 may output the code stored in one of the registers 78, 80, 82, and 84, which corresponds to the received high signal. The outputted code may be sent to the controller 16, and ROM code is replaced. If multiplexer 94 does not receive a high signal from one of the comparators 86, 88, 90, and 92, the multiplexer 94 may output the code located at the ROM address. The outputted code may be sent to the controller 16, and ROM code is not replaced.
Referring now to
Returning to
As depicted, the configuration and components of
As shown in
It should be noted that memory device 10 may include an instruction ROM 17 and/or a macro ROM 18, and accordingly one or more ROM redundancy registers 20, depending on how the memory device 10 is implemented. Further, if both instruction ROM 17 and corresponding ROM redundancy register 20, and macro ROM 18 and corresponding ROM redundancy register 20 were implemented together, both the instruction code and macro code may work together and/or be passed to controller 16 accordingly.
It will be appreciated that in other embodiments, a ROM 17 and/or 18 and a ROM redundancy register 20 may store code other than instruction code and macro code that is accessed by the controller 16. The sizes of the registers within the ROM redundancy register 20 may vary accordingly with the sizes of the addresses and code in ROM 17 and/or 18. The ROM redundancy register 20 may include any number of registers to hold instruction ROM addresses and code corresponding to the ROM addresses, and is not limited to the registers that are shown. The scope of the claimed subject matter is not limited in these respects.
At 212, during a chip initialization sequence of the memory device, method 200 may further include retrieving redundancy information from a memory cell array in the memory device. The redundancy information may include one or more ROM addresses and code corresponding to one or more ROM addresses. At 214, the method may further include storing the redundancy information in the ROM redundancy register. It should be noted that the method may not be presented and discussed with steps in order of occurrence, and the scope of the claimed subject matter is not limited in this respect.
It is appreciated that redundancy for code in ROM has been explained with reference to one or more embodiments, and that the invention is not limited to the specific details given above. References in the specification made to other embodiments fall within the scope of the present invention.
Any reference to device may include a component, circuit, module, or any such mechanism in which the device can achieve the purpose or description as indicated by the modifier preceding the device. However, the component, circuit, module, or any such mechanism is not necessarily a specific limitation to the device.
Reference in the specification to “an embodiment,” “one embodiment,” “some embodiments,” or “other embodiments” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least some embodiments, but not necessarily all embodiments, of the invention. The various appearances of “an embodiment,” “one embodiment,” or “some embodiments” are not necessarily all referring to the same embodiments.
If the specification states a component, feature, structure, or characteristic “may”, “might”, or “could” be included, that particular component, feature, structure, or characteristic is not required to be included. If the specification or claim refers to “a” or “an” element, that does not mean there is only one of the element. If the specification or claims refer to “an additional” element, that does not preclude there being more than one of the additional element.
Those skilled in the art having the benefit of this disclosure will appreciate that many other variations from the foregoing description and drawings may be made within the scope of the present invention. Indeed, the invention is not limited to the details described above. Rather, it is the following claims including any amendments thereto that define the scope of the invention.
