Patent Application
20060224803
The present invention relates to computer systems; more particularly, the present invention relates to sharing interfaces at a computer system.
Computer system chipsets typically include one are more components that are implemented to provide an interface to input/output (I/O) devices within the computer system. Such devices include a network controller, a hard disk drive, one or memory devices, etc. coupled to the chipset via various types of interfaces.
One interface used to couple I/O devices to the chipset is a serial peripheral interface (SPI). The SPI is an interface that enables the full duplex, serial exchange of data between two devices, a master and a slave. However, a problem with the SPI is that only one master/slave pair may be coupled. Therefore, if a device (e.g., a flash memory device) is coupled to the chipset via SPI, all accesses to the flash memory device must be through the chipset.
The invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements, and in which:
A mechanism for a shared SPI interface is described. In the following detailed description of the present invention numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.
Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
In a further embodiment, a chipset 107 is also coupled to interface 105. Chipset 107 includes a memory control hub (MCH) 110. MCH 110 may include a memory controller 112 that is coupled to a main system memory 115. Main system memory 115 stores data and sequences of instructions that are executed by CPU 102 or any other device included in system 100. In one embodiment, main system memory 115 includes dynamic random access memory (DRAM); however, main system memory 115 may be implemented using other memory types. Additional devices may also be coupled to interface 105, such as multiple CPUs and/or multiple system memories.
MCH 110 is coupled to an input/output control hub (ICH) 140 via a hub interface. ICH 140 provides an interface to input/output (I/O) devices within computer system 100. ICH 140 may support standard I/O operations on I/O busses such as peripheral component interconnect (PCI), accelerated graphics port (AGP), universal serial bus (USB), low pin count (LPC) bus, or any other kind of I/O bus (not shown).
According to one embodiment, a flash memory device 150 and network controller 160 are coupled to ICH 140. In such an embodiment, network controller 160 is coupled to ICH 140 via a Peripheral Component Interface Express (PCI-X) interface. In addition, network controller 160 is also coupled to flash 150.
In one embodiment, both ICH 140 and network controller 160 are coupled to access flash 150 via a shared SPI interface 145. Thus, SPI 145 enables immediate access of flash 150 to ICH 140 and network controller 160. ICH 140 may access flash 150 to retrieve data for CPU 102. For example, BIOS may access flash 150 at boot time, as well as during run time. In one embodiment, ICH 140 implements a Request/Grant protocol to CPU 102. Network controller 160 may access flash 150 to retrieve control information to facilitate management of network connections.
According to one embodiment, ICH 140 and network controller 160 operate at different frequencies. For instance, ICH 140 may be targeted to operate at 17.8M Hz, while network controller 160 is targeted to operate at 15.6M Hz (& 6.25M Hz). In a further, bus arbitration and signaling between ICH 140 and network controller 160 are carried out using standard SPI signals, with the addition of a dedicated Bus-Request signal (as will be described below).
As discussed above, SPI 145 includes standard SPI signals (e.g., CLK, SDI, SDO and CS#), as well as a bus request signal (BREQ). The CLK signal is driven by both ICH 140 and network controller 160 when running a SPI master cycle. This signal is implemented to grant future request to ICH 140. The SDI signal is driven by both ICH 140 and network controller 160 when running an SPI master cycle. This signal is implemented to signal a future request from ICH 140.
The SDO signal is driven by flash 150 whenever an SPI cycle is in progress. The CS# signal is driven by both ICH 140 and network controller 160 when running a SPI master cycle. The CS# signal serves as an implicit grant from ICH 140 to network controller 160. The BREQ signal is a dedicated signal driven by network controller 160. According to one embodiment, network controller 160 drives the BREQ signal low whenever there is no request, and drives the signal high for a request. The BREQ signal remains high until network controller 160 relinquishes the interface.
Arbitration between ICH 140 and network controller 160 for control of SPI 145 follows the below-described rules. First, since ICH includes arbiter 240, network controller 160 defaults the interface to ICH 140. Both ICH 140 and network controller 160 may initiate short accesses to flash 150 at any time. Short accesses are flash accesses that terminate at the SPI 145 cycle completion.
For long accesses (e.g., access that does not end at the SPI cycle completion) the SPI 145 owner polls flash 150 status until the access is completed. At that time the interface may be released to other requests. Very long accesses are accesses that last are longer than allowed to stall the CPU 102. In one embodiment, network controller 160 avoids very long accesses when network controller 160 senses SPI-Request signaling from CPU 102.
Non Blocking Arbitration indicates that ICH 140 and network controller 160 will avoid back-to-back cycles unless to avoid SPI bus starvation. Stand Alone indicates that both devices may operate as stand alone devices. For BIOS accesses to flash 145, CPU 102 will not experience long latencies accessing flash 145 due to interface arbitration with network controller 160.
Further, arbitrary CPU accesses to flash 145 may collide with network controller 160, presenting potential long arbitration latencies. However, the Request/Grant protocol described above is implemented to avoid these long arbitration latencies. According to one embodiment, CPU 102 accesses flash 145 as a plain memory device without control signaling following a CPU 102 reset.
During run time (and advanced boot phase) the BIOS sets a SPI-Request flag and wait for SPI-Grant prior to any access (e.g., read & write). The SPI request is reflected to network controller 160. When the SPI-Request is reflected to network controller 160, bus holding duration is minimized to avoid long latency to CPU 102.
Table 1 below illustrates exemplary network controller 160 accesses to flash 145. Particularly, Table 1 shows network controller 160 cycles to flash 145 based upon a type of access. Thus, access types following power on reset, boot time and nominal operation (e.g., No Future Request and Future Request) is shown.
The above-described mechanism enables a new connection type for the SPI interface from one master to multiple slave devices, or from multiple masters talking with the same slave. Expanding the protocol to multiple masters talking with multiple slaves is also foreseeable based upon the disclosure.
Whereas many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that any particular embodiment shown and described by way of illustration is in no way intended to be considered limiting. Therefore, references to details of various embodiments are not intended to limit the scope of the claims, which in themselves recite only those features regarded as essential to the invention.
