Shared interface for components in an embedded system

[0001] 1. Field of the Invention

[0002] The invention generally relates to a computer system. Specifically, the invention relates to an improved system and method for interfacing components in a computer system.

[0003] 2. Description of the Related Art

[0004] Many modern electronic devices such as cell phones, PDAs, portable music players, appliances, and so on typically incorporate an embedded computer system. An embedded computer system typically contains a computer processor (referred to as a host), non-volatile memory (such as a NAND flash memory and/or ROM memory), and volatile memory such as a dynamic random access memory (DRAM). The host may include a central processing unit (CPU), digital signal processor (DSP), microcontroller unit (MCU) or direct memory access (DMA) data transmission device.

[0005] In some cases, a non-volatile memory controller (e.g., a NAND flash controller) may be provided for use in accessing the non-volatile memory. By providing a non-volatile memory controller, non-volatile memory control and management tasks may be offloaded from the host to the non-volatile memory controller, thereby simplifying design of the host and allowing the host to handle other processing needs of the embedded system.

[0006] Where a host, non-volatile memory controller, non-volatile memory, and volatile memory are provided in an embedded computer system, each component may have one or more interfaces for connecting to other components in the system. To decrease the cost of designing and implementing such an embedded system, and to decrease the power consumption of such an embedded system, there may be a desire to reduce the pin count of the interfaces while maintaining a high level of performance.

[0007] Accordingly, what is needed is an improved system and method for interfacing a host, a non-volatile memory controller, and a volatile memory in an embedded computer system.

[0008] Embodiments of the invention provide a method and apparatus for accessing a non-volatile memory controller and a volatile memory via a shared interface. In one embodiment, the method includes selecting one of the non-volatile memory controller and the volatile memory via shared control signals of the shared interface, wherein the shared control signals are issued to the non-volatile memory controller and the volatile memory. The method also includes issuing commands to the selected one of the non-volatile memory controller and the volatile memory via the shared control signals.

[0016] Embodiments of the invention generally provide a method and apparatus for accessing a non-volatile memory controller and a volatile memory via a shared interface. In one embodiment, the method includes selecting one of the non-volatile memory controller and the volatile memory via shared control signals of the shared interface, wherein the shared control signals are issued to the non-volatile memory controller and the volatile memory. The method also includes issuing commands to the selected one of the non-volatile memory controller and the volatile memory via the shared control signals. In some cases, by sharing control signals issued to the non-volatile memory controller and the volatile memory, the number of pins needed to interface the non-volatile memory controller and the volatile memory may be reduced, thereby reducing complexity and power consumption of the system.

[0017] Embodiments of the invention are described below with respect to an embedded system including a host processor, volatile memory, and non-volatile memory. However, in some cases, the embedded system may contain multiple host processors, multiple volatile memories, and/or multiple non-volatile memories. The volatile memories may include any type of DRAM, SRAM, or any other type of volatile memory. The non-volatile memories may include any type of NAND flash memory, NOR flash memory, programmable read-only memory (PROM), electrically-erasable programmable read-only memory (EE-PROM), read-only memory (ROM), or any other type of non-volatile memory. The host processor may include any type of processor, including a central processing unit (CPU), a digital signal processor (DSP), a microcontroller unit (MCU) or a direct memory access (DMA) data transmission device. Also, each chip in the system may in some cases contain multiple types of processors and/or memories. For example, the host may include a CPU, DSP, and SRAM. The non-volatile memory may, in some cases, include a ROM and a flash memory. Other exemplary combinations which may be used with embodiments of the invention should be readily apparent to one of ordinary skill in the art

[0018] An Exemplary Embedded System

[0019] FIG. 1 is a block diagram depicting an exemplary system 100 according to one embodiment of the invention. As depicted, the system 100 may include a host 102, volatile memory 104 (e.g., a DRAM, SDRAM, DDR-SDRAM, LP-SDRAM, and/or any other type of volatile memory), non-volatile memory controller 106, and non-volatile memory 108 (e.g., a ROM, PROM, EE-PROM, NAND flash memory, NOR flash memory, and/or any other type of non-volatile memory). In some cases, the non-volatile memory controller may contain a boot code buffer 120, NAND manager circuitry 122, DRAM interface 124, controller codes 126, controller core 128, DMA circuitry 130, and a non-volatile memory interface 132.

[0020] In one embodiment, the non-volatile memory interface 132 may be used by the non-volatile memory controller 106 to access information stored in the non-volatile memory 108 including boot codes, controller codes, operating system code, application codes, data, and any other information. Similarly, the DRAM interface 124 may be used by the non-volatile memory controller 106 to access the volatile memory 104. As described below, information in the non-volatile memory 108 may be loaded into the boot code buffer 120, controller code buffer 126, and/or volatile memory 104 and used for initialization of the system 100. The controller core 128 may be used to perform controller operations, for example, by running controller codes stored in the controller code buffer 126. Also, as described below, the DMA circuitry 130 may be utilized to automatically transfer information from the non-volatile memory 108 to the volatile memory 104.

[0021] In one embodiment of the invention, a shared interface 140 may be utilized by the host 102 to access the non-volatile memory 108 (e.g., via the non-volatile memory controller 106) and the volatile memory 104. As depicted, a portion of the shared interface 140 may include a synchronous serial connection (e.g., a fast connection, DQ/DQS 110) to the volatile memory 104. The shared interface 140 may also include shared address and control lines (ADR/CTL 112) for providing control signals and address bits to the volatile memory 104 and/or non-volatile memory controller 106. Also, other interface connections, described in greater detail below, may also be provided. In some cases, by providing a shared interface 140 for accessing the non-volatile memory controller 106 and the volatile memory 104, no extra pins may be needed to connect the host 102 to the non-volatile memory controller 106. For example, each of the address and control pins connected to the non-volatile memory controller 106 may also be connected to the volatile memory 104.

[0022] Modes of Operation Utilizing the Shared Interface

[0023] In one embodiment of the invention, the shared interface 140 may be utilized for performing memory accesses in one of a plurality of modes. FIGS. 2A-C depict modes of operation of the system 100 according to one embodiment of the invention.

[0024] FIG. 2A is a block diagram depicting a first mode of operation in which the host 102 accesses the volatile memory 104 according to one embodiment of the invention. As depicted, the host 102 may read from or write to the volatile memory via the shared interface 140. Where the host 102 accesses the volatile memory 104, the host 102 may assert signals indicating that the host 102 is acting as master (e.g., the side in the interface 140 which initiates and controls a given communication) on the shared interface 140. By asserting the signals indicating that the host 102 is acting as master on the interface 140, other components connected to the shared interface 140 (e.g., the non-volatile memory controller 106) may not attempt to simultaneously control the interface 140. For example, the host 102 may utilize shared address and control signals 112 to select the volatile memory 104, issue commands to the volatile memory 104, and select an address in the volatile memory 104. In one embodiment, the host 102 may utilize the synchronous serial port 110 (or fast port) to transfer data to and from the volatile memory 104. Exemplary signals utilized in the first mode are described below in greater detail.

[0025] FIG. 2B is a block diagram depicting a second mode of operation in which the host 102 accesses the non-volatile memory 108 according to one embodiment of the invention. Where the host 102 accesses the non-volatile memory 108, the host 102 may assert signals indicating that the host 102 is acting as master on the shared interface 140. Also, the host 102 may utilize the shared address and control signals 112 to select the non-volatile memory controller 106, issue commands to the non-volatile memory controller 106, and select an address in the non-volatile memory 108. In response to the commands and/or addresses provided by the host 102 via the shared interface 140, the non-volatile memory controller 106 may access an address in the non-volatile memory 108, e.g., via the non-volatile memory interface 132. In one embodiment, the host 102 may utilize an asynchronous parallel port to pass data between the host 102 and the non-volatile memory controller 106, including data to be written to or data read from the non-volatile memory 108 by the non-volatile memory controller 106. Exemplary signals utilized in the second mode are also described below in greater detail.

[0026] FIG. 2C is a block diagram depicting a mode of operation in which the non-volatile memory controller 106 accesses the volatile memory 104 according to one embodiment of the invention. Where the non-volatile memory controller 106 accesses the volatile memory 104, the non-volatile memory controller 106 may assert signals on the shared interface 140 indicating that the non-volatile memory controller 106 is master of the shared interface 140 (e.g., thereby preventing the host 102 from simultaneously utilizing the interface 140). The non-volatile memory controller 106 may then utilize the shared address and control 112 to select the volatile memory 104, issue commands to the volatile memory 104, and select an address in the volatile memory 104. In one embodiment, the non-volatile memory controller 106 may utilize an asynchronous parallel port to pass data between the non-volatile memory controller 106 and the volatile memory 104.

[0027] In one embodiment, the non-volatile memory controller may transfer data between the non-volatile memory 108 and the volatile memory 104. For example, where data is transferred from the non-volatile memory 108 to the volatile memory 104, the non-volatile memory controller 106 may utilize the non-volatile memory interface 132 to read data from the non-volatile memory 108. The data read from the non-volatile memory 108 may then be written from the non-volatile memory controller 106 to the volatile memory 104 via the shared interface 140. Data may similarly be read from the volatile memory 104 and written to the non-volatile memory 108 via the shared interface 140 and the non-volatile memory controller 106. In some cases, the non-volatile memory controller 106 may be utilized to perform a direct memory access (DMA) transfer between the non-volatile memory 108 and the volatile memory 104. Exemplary signals utilized in the third mode are also described below in greater detail.

[0028] Exemplary Shared Interface

[0029] FIG. 3 is a block diagram depicting a shared interface 140 for an embedded system 100 according to one embodiment of the invention. As depicted, the interface 140 may include shared address and controls 112 and connections for a synchronous serial connection 110. As depicted, the interface 140 may be connected to the host 102 or the non-volatile memory controller 106.

[0030] In one embodiment, the signals for the synchronous serial connection 110 may include a chip-select signal (CS#, the ‘#’ indicating that the signal may be active-low), a clock signal (CLK), an inverted clock signal (CLK#), a clock enable signal (CKE), a data mask signal (DMs), a serial data signal (DQ), and a serial data strobe signal (DQSs).

[0031] The shared address and control signals 112 may include volatile memory connections 320 used to access the volatile memory 104 and non-volatile memory controller connections 322 used to access the non-volatile memory 108 via the non-volatile memory controller 106. In one embodiment, the volatile memory connections 320 may include a write-enable signal (WE#), column-address strobe signal (CAS#), row-address strobe signal (RAS#), an address bus (A[15:0]), and bank address bits (BA[1], BA[0]).

[0032] As depicted, the volatile memory connections 320 may also be connected to the non-volatile memory connections 322. Respectively, the WE# connection may be shared between the non-volatile memory connection 320 and the volatile memory controller connection 322, the CAS# connection may be shared with an address latch signal (ALE) for the non-volatile memory controller connection 322, the RAS# signal may be shared with a read-enable signal (RE#) for the non-volatile memory controller connection 322, the address bits A[15:0] may be shared with multiplexed input/output pins IO[15:0] for the non-volatile memory controller connection 322, BA[1] may be shared with a chip-enable signal CE# for the non-volatile memory controller connection 322, and BA[0] may be shared with a master-access signal (MA#) for the non-volatile memory controller connection 322. The corresponding shared connections (with exemplary host pin numbers) are also shown below in Table 1.

[0033]

TABLE 1
Shared Interface Connections
		Non-Volatile
Host Pin	Volatile Memory	Memory Controller
0	WE#	WE#
1	CAS#	ALE
2	RAS#	RE#
3:19	A[15:0]	IO[15:0]
20	BA[1]	CE#
21	BA[0]	MA#

[0034] In one embodiment of the invention, the chip-enable signal (CE#) 306 for the non-volatile memory controller 106 may be logically derived from the chip-enable signal CE# of the shared interface 140 and the chip select signal CS#. By deriving the chip enable signal CE# 306 from the CE# and CS# signals, the non-volatile memory controller 106 may determine whether the host 102 is selecting the non-volatile memory controller 106 or the volatile memory 104. In some cases, if the CE# 306 signal were not derived from the CE# and CS# signals, the non-volatile memory controller 106 might react to the shared address and control signals 112 even when the non-volatile memory controller 106 is not selected. For example, when the chip-enable signal CE# is lowered to a low logic level and when the chip-select signal CS# is raised to a high logic level (thereby deselecting the volatile memory 104), then the non-volatile memory controller 104 may be selected (e.g., the chip-enable signal CE# 306 may be lowered).

[0035] The selection circuitry may include a NOT gate 302 which inverts the CS# signal and an OR gate 304 which logically-OR's the CE# signal and the inverted CS# signal. The output of the OR gate 304 may be connected to the CE# signal 306. In one embodiment, the circuitry may be provided as separate circuitry from the host 102, volatile memory 104, or non-volatile memory controller 106. Optionally, the host 102 or the non-volatile memory controller 106 may generate the CE# signal 306 with the necessary signals being input or output on an extra pin of the chip generating the signal 306. Selection of a transfer mode for the shared interface is described below in greater detail with respect to FIGS. 4-5.

[0036] Selecting a Mode of Operation in the Shared Interface

[0037] In one embodiment of the invention, the host 102 and the non-volatile memory controller 106 may use the CS#, CE#, and MA# signals of the shared interface 140 to select a master for the interface 140 and to select which chip is being controlled via the shared interface 140.

[0038] FIG. 4 is a flow diagram depicting a process 400 for using the host 102 to access memory via the shared interface 140 according to one embodiment of the invention. As depicted, the process 400 may begin at step 402 and continue to step 404 where a request to access memory (e.g., the volatile memory 104 or the non-volatile memory 108). Such a request may be received, e.g., from an external device or as a result of an instruction executed by the host 102.

[0039] When the request is received, a determination may be made at step 406 of whether the host 102 is the master of the shared interface 140. The determination may be made, for example, by examining the MA# bit output by the non-volatile memory controller 106. If the MA# bit is lowered, then the non-volatile memory controller 106 may be master of the shared interface 140 and the host 102 may wait until the MA# bit is raised at step 408 by the non-volatile memory controller 106, thereby indicating that the non-volatile memory controller 106 is no longer master of the shared interface 140.

[0040] Once the host 102 becomes master of the shared interface 140, a determination may be made at step 410 of whether the access is directed to volatile memory 104. If a determination is made that the access request is directed to volatile memory 104, then the host may assert CE# and lower CS# at step 420. By asserting CE#, the nonvolatile memory controller 106 may be deselected by the host 102. By lowering CS#, the volatile memory 104 may be selected by the host 102. Then, at step 422, the host 102 may issue access commands to the volatile memory 104, e.g., via the shared address and control signals 112 of the shared interface 140. Then, at step 424, a data access may be performed via a port of the volatile memory 104 (e.g., using connections 110 for a synchronous serial port).

[0041] If a determination is made that the access request is directed to non-volatile memory 108, then the host may lower CE# and assert CS# at step 412. By lowering CE#, the nonvolatile memory controller 106 may be selected by the host 102. By asserting CS#, the volatile memory 104 may be deselected by the host 102. Then, at step 414, the host 102 may issue access commands to the non-volatile memory controller 106, e.g., via the shared address and control signals 112 of the shared interface 140. Then, at step 416, a data access may be performed via a port of the non-volatile memory controller 106 (e.g., using non-volatile memory controller connections 322 for an asynchronous parallel port). The process 400 may then finish at step 430.

[0042] In some cases, the non-volatile memory controller 106 may become master of the shared interface 140 and perform data accesses between the non-volatile memory 108 and the volatile memory 104. For example, the non-volatile memory controller 106 may utilize the shared interface 140 to read data from the volatile memory 104 and then utilize the non-volatile memory interface 132 to the data to the non-volatile memory 108. The non-volatile memory controller 106 may also utilize the non-volatile memory interface 132 to read data from the non-volatile memory 108 and then write the data to the volatile memory 104 via the shared interface 140. In some cases, the non-volatile memory controller 106 may perform a DMA transfer between the non-volatile memory 108 and the volatile memory 104.

[0043] FIG. 5 is a flow diagram depicting a process 500 for using the non-volatile memory controller 106 to access volatile memory 104 via the shared interface 140 according to one embodiment of the invention. The process may begin at step 502 and continue to step 504 where a request is received to perform a transfer (e.g., of data between non-volatile memory 108 and the volatile memory 104). At step 506, the non-volatile memory controller 106 may check CS# and lower the MA# signal if CS# is a high logic level (e.g., implying that the host 102 is not using the shared bus), thereby indicating that the non-volatile memory controller 106 is becoming master of the shared interface 140. After the non-volatile memory controller 106 becomes master of the shared interface 140, the non-volatile memory controller 106 may perform a transfer from the non-volatile memory 108 (e.g., using the non-volatile memory interface 132) to the volatile memory 104 using the shared interface 140. The non-volatile memory controller 106 may transfer the data, for example, from an asynchronous parallel port of the non-volatile memory controller 106 to an asynchronous parallel port of the volatile memory 104. The asynchronous port may also be referred to as a slow port, for example, because data from the asynchronous port is asynchronously transferred to and from the port, e.g., by asserting and lowering transfer signals, which may be slower than a synchronous port which utilizes a clock signal to transfer data.

[0044] After the non-volatile memory controller 106 has completed the transfer, the non-volatile memory controller 106 may raise the MA# signal, thereby indicating that the non-volatile memory controller 106 is no longer master of the shared interface 140. The process 500 may then finish at step 512.

[0045] Because the non-volatile memory controller 106 may in some cases be used to both receive commands and data (e.g., access commands from the host 102) and issue commands and data (e.g., access commands to the volatile memory 104), some of the non-volatile memory controller 106 connections to the shared interface 140 may be input-output connections (e.g., bidirectional connections which may either act as inputs or outputs). Thus, for example, each of the non-volatile memory controller connections 322 may be input-output connections. Optionally, only a portion of the non-volatile memory controller connections 322 may be bidirectional (e.g., the pins needed to control access to an asynchronous port of the volatile memory 104, such as WE#, ALE, RE#, and the IO[15:0] bus).

[0046] Performing DMA Transfers with the Shared Interface

[0047] According to one embodiment of the invention, the shared interface 140 may be utilized to perform DMA transfers, e.g., from the non-volatile memory 106 to the volatile memory 104. Also, in some cases, DMA transfers may be performed from the volatile memory 108 to a buffer in the non-volatile memory controller 106, as described below. By transferring code and/or data from volatile memory 108 to non-volatile memory 104 or to a buffer, the code and/or data may, in some cases, be accessed more quickly (e.g., by the host 102) because of the access time of the volatile memory 104 which is typically faster than the access time of the non-volatile memory 108. In some cases, such transfers may be referred to as code shadowing, because the data transferred may remain in both the non-volatile memory 108 and the volatile memory 104 while being accessed from the volatile memory 104.

[0048] As an example of utilizing the shared interface to perform DMA transfers, the host 102 may, in one embodiment, utilize the shared interface 140 to issue DMA commands to the non-volatile memory controller 106 requesting a DMA transfer e.g., from a location in the non-volatile memory 106 to a location in the volatile memory 104. Each DMA command may include, for example, a source location in the non-volatile memory 108, a destination location in the volatile memory 104, and a size of the code to be transferred.

[0049] When the non-volatile memory controller 106 receives a DMA command, the non-volatile memory controller 106 may assume control of the shared interface 140 (e.g., by lowering the MA# signal). The non-volatile memory controller 106 may then perform the DMA transfer (e.g., utilizing the DMA circuitry 130) from the source location in the non-volatile memory 108 to the destination location in the volatile memory 104. After the DMA transfer is complete, the non-volatile memory controller 106 may then relinquish control of the shared interface 140 (e.g., by raising the MA# signal) and allow the host 102 to access the requested data from volatile memory 104 via the shared interface 140.

[0050] In some cases, the non-volatile memory controller 106 may perform DMA transfers from the non-volatile memory 108 to a buffer in the non-volatile memory controller 106. For example, as described above with respect to FIG. 1, the non-volatile memory controller 106 may contain a boot code buffer 120 and a controller code buffer 126. During a boot sequence (e.g., after the system 100 is powered-on or reset) the non-volatile memory controller 106 may be configured to automatically copy boot code from the non-volatile memory 108 to the boot code buffer 120. The host 102 may then access the boot code buffer 120 via the shared interface 140 and use to boot code to perform initialization operations for the system 100. The non-volatile memory controller 106 may also be configured to automatically copy controller codes from the non-volatile memory 108 to the controller code buffer 126. The controller codes may then be utilized by the controller core 128 to perform controller operations.

[0051] Simultaneous Access to the Volatile Memory with the Shared Interface

[0052] In one embodiment of the invention, the shared interface 140 may be utilized to perform multiple, simultaneous accesses to the volatile memory 104. By allowing multiple, simultaneous accesses to the volatile memory 104, utilization of the volatile memory 104 and the effective memory bandwidth (e.g., the speed at which data may be read from and written to the volatile memory 104) may be increased.

[0053] For example, a first access command may be issued to a first bank in the volatile memory via a first portion of the shared interface 140. While the first access command is being performed, a second access command may be issued to a second bank in the volatile memory via a second portion of the shared interface 140. In some cases, by issuing separate commands via separate portions of the shared interface 140 and by issuing commands which utilize separate control hardware (e.g., the first command may be a read command while the second command may be a write command, or vice versa) and access separate portions of the volatile memory 104 (e.g., separate banks may be accessed), simultaneous accesses to the volatile memory 104 may be successfully performed, for example, without contention on any lines of the shared interface and/or without contention for resources of the volatile memory 104.

[0054] FIG. 6 is a block diagram depicting hardware for performing simultaneous accesses to a volatile memory 104 via a shared interface 140 according to one embodiment of the invention. As depicted, the volatile memory 104 may include a synchronous port 602 (e.g., a fast port), array access decode circuitry 604, address latch circuitry 606, and an asynchronous port 608 (e.g., a slow port). As previously described, the asynchronous port 608 of the volatile memory 104 may be connected to an asynchronous port 620 of the non-volatile memory controller 106 The synchronous port 602 may be connected to the synchronous serial connection 110 of the shared interface 140. The array address decoder circuitry 604 may be utilized to determine which memory array 616 and bank (e.g., bank 0, bank 1, bank 2, bank 3, etc.) is accessed by a given access command. The address latch circuitry 606 may be utilized to latch addresses being accessed (e.g., an address provided by the host 102 or the non-volatile memory controller 106 via the shared address and control lines 112 of the shared interface 140).

[0055] The volatile memory 104 may also include an address decoder 610, synchronous access circuitry 612, and asynchronous access circuitry 614. The address decoder 610 may be utilized to decode addresses latched by the address latch circuitry 606. The synchronous access circuitry 612 may be utilized to perform data accesses via the synchronous port 602 and the asynchronous access circuitry 614 may be utilized to perform data accesses via the asynchronous port 608.

[0056] As an example of performing synchronous accesses to the volatile memory 104, the volatile memory 104 may receive and latch (e.g., using address latch circuitry 606) the address for a first read command from the host 102 via the shared interface 140. After the read command is received, the read command may be decoded (e.g., using the array access decode circuitry 604 and the address decoder 610). The read command may then be performed, e.g., from bank 0 of the memory array 616 using the synchronous access circuitry 612 and the synchronous port 602 to transfer the data being read by the host 102.

[0057] While the read command is being performed, a write command may be received from the non-volatile memory controller 106 (e.g., a command writing data from non-volatile memory 108 to the volatile memory 104) via the shared interface 140. The volatile memory 104 may receive and latch (e.g., using address latch circuitry 606) the address for a first write command from the host 102 via the shared interface 140. After the write command is received, the write command may be decoded (e.g., using the array access decode circuitry 604 and the address decoder 610). The write command may then be performed, e.g., from bank 2 of the memory array 616 using the asynchronous access circuitry 612 and the asynchronous port 602 to transfer the data being written to the volatile memory 104. Thus, the first read command and the first write command may be simultaneously performed.

[0058] In some cases, the non-volatile memory controller 106 may issue commands before the host 102 issues simultaneous commands. Also, in some cases, the non-volatile memory controller 106 may perform a read while the host 102 performs a write. Optionally, other commands may be issued and performed simultaneously by the volatile memory 104 in addition to access commands, e.g., refresh commands or commands which modify a mode register of the volatile memory 104.

[0059] While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.