Memory bus interface

An interface allows communication between a host device coupled to a host bus and a target device coupled to a target bus. First, the interface receives the address of the target device from the host device via the host bus, where the address has a first width. Next, the interface converts the received address from the first width into one or more address components each having a second width. Then, the circuit accesses the target device by driving the one or more address components onto the target bus. Such an interface allows for a simple, direct communication path between the host bus, such as a system bus, and a target bus, such as an LPC bus. The interface consolidates several tasks into one general purpose interface, providing savings in components used, design complexity, and overall cost of implementation. Further, the length of time required for communications between interfaced busses is substantially reduced.

BACKGROUND OF THE INVENTION

A Low-Pin Count (LPC) bus is an internal-communication bus for computer systems and has been implemented in recent years to gradually replace the Industry Standard Architecture (ISA) bus. For example, theLPC Interface Specification1.0 available from Intel Corporation of Santa Clara, Calif. calls for an LPC interface between a computer system's core logic chipset and motherboard I/O functions.

The LPC bus architecture is a serial, 7-pin simple bus with a 33 MHz clock. There are no defined slots, unlike the ISA and PCI buses, thus only on-board solutions are used in the LPC architecture. Since its speed is limited to 33 MHz, it is not designed for heavy-duty data transfer. Devices that are likely to be found on the LPC bus are legacy devices, such as Super I/Os, and flash boot devices. The LPC bus architecture is software transparent to higher level I/O functions and is compatible with existing peripheral devices and applications. The LPC bus, however, is not readily compatible with other bus architectures, such as register-based memory buses, because of the discrepancy in the bus speeds.

A system bus is a bus architecture designed to facilitate communication between a computer's central processing system and its register based memory system. The bus speed of a system bus is typically not quite as fast as the CPU speed, but is significantly faster than the speed of the LPC bus. As a result, communication between a system bus and an LPC bus cannot be achieved by a simple interface.

In the past, communication between devices that use the system bus and devices that use the LPC bus was indirect and required a significant firmware/software undertaking. This undertaking proved to require a substantially lengthy processing time. Therefore, a need has arisen to eliminate the substantial length of this undertaking by providing a direct path between the system and the LPC busses.

SUMMARY OF THE INVENTION

In one aspect of the invention, an interface allows communication between a host device coupled to a host bus and a target device coupled to a target bus. First, the interface receives the address of the target device from the host device via the host bus where the address has a first width. Next, the interface converts the received address from the first width into one or more address components each having a second width. Then, the interface accesses the target device by driving the one or more address components onto the target bus.

Such an interface allows for a simple, direct communication path between a host bus, such as a bus system, and a target bus, such as an LPC bus. The interface consolidates several tasks into one general purpose interface, providing savings in components used, design complexity, and overall cost of implementation. Further, the length of time required for communications between different busses is substantially reduced.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Various embodiments of the present invention are directed to a device, system, method, and computer-readable medium for facilitating data communication between two different computer bus architectures. In one embodiment, communication between a register-based memory bus and an LPC bus is achieved.FIG. 1and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the embodiments of the invention may be implemented. Those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, such as, for example, hand-held devices, networked PCs, minicomputers, mainframe computers, multiprocessor systems, microprocessor-based or programmable embedded computers, the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communication network.

FIG. 1is a block diagram of a general-purpose computing device in the form of a conventional personal computer20according to an embodiment of the invention. The computer20includes a processing unit21, a system memory22, and a system bus23. The system bus23couples the various system components, including the system memory22, to the processing unit21. The system bus23may be any of several types of busses including a memory bus, a peripheral bus, and a local bus using any of a variety of bus architectures.

The system memory22includes a read-only memory (ROM)24, a random-access memory (RAM)25, and firmware26, which contains the basic routines that help to transfer information between devices of the personal computer20. The personal computer20further includes a hard disk drive27that is also connected to the system bus23through a hard disk controller (not shown). Additionally, optical drives, CD-ROM drives, floppy drives (not shown) may be connected to the system bus23through respective drive controllers (not shown) as well.

A number of program modules may be stored on the hard disk drive27or in the ROM24or RAM25, including an operating system, one or more application programs, and other data. A user (not shown) may enter commands and information into the personal computer20through input devices such as a keyboard40and pointing device42. These input devices as well as others not shown are typically connected to the system bus23through a serial port interface46. Other interfaces (not shown) include Universal Serial Bus (USB) and parallel ports. A monitor47or other type of display device may also connect to the system bus23via an interface such as a video adapter48.

Still referring toFIG. 1an LPC bus51has one or more LPC slave devices52(only one slave device shown inFIG. 1) connected to it. An LPC bus interface50interfaces the LPC bus51to the system bus23. In one embodiment the LPC bus51is a serial, 7-pin simple bus with a 33 MHz clock, and there are no defined interface slots for any number of LPC slave devices52. Furthermore, in one embodiment the address/data portion of the LPC bus51is only four bits wide, and the address and data portions of the system bus23are sixteen and eight bits wide, respectively. Consequently, the LPC-bus interface50converts system address words and data bytes into respective LPC address and data nibbles, and vice versa. Alternatively, the LPC bus51and the system bus23may have different sizes from those disclosed. But in each case, the LPC interface50converts addresses and data into the proper widths.

Furthermore, the components, such as the memory22, coupled to the system bus23are mapped to a system address space, which typically has two subspaces: the data space and the I/O space, which in one embodiment includes 216byte-sized memory locations. In one embodiment, the LPC address space, which is the range of addresses assigned to the LPC slave devices52connected to the LPC bus51, is located within the system I/O space. But the LPC address space could alternatively reside in the system data space.

With reference toFIG. 2, the system bus23and the LPC-bus interface50ofFIG. 1are shown in greater detail according to an embodiment of the invention. The system bus23transfers information from a host to a target using memory-bus read/write transactions and comprises three sub-busses: a data bus23a,an address bus23b,and a control bus23c.A read/write transaction is defined as an exchange of information between a host and a target in a predetermined protocol. Because a system-bus23protocol is different from an LPC-bus51protocol, it is necessary to provide the interface50to allow read/write transactions to be communicated between the busses23and51.

The LPC-bus interface50comprises three basic parts that are used to convert system-bus read/write transactions into LPC-bus read/write transactions. A transaction-trigger module201triggers the start of an LPC transaction based upon the detection of a predetermined LPC address on the system bus23. A data synchronization module202synchronizes data transfers between the system bus23and the LPC bus51, and a finite state machine204implements the data transfers. It takes one LPC “transaction” to either write data to or read data from the LPC device52, and such a transaction typically requires multiple cycles of the LPC clock250. For example, where the address bus23bis sixteen bits wide, the data bus23ais eight bits wide, and the LPC bus51is only four bits wide, a typical LPC read/write transaction takes thirteen cycles of the LPC clock20.

The transaction-trigger module201monitors the address bus23bof the system bus23by “looking” for an address within the pre-determined LPC address space. The address determinator210detects, in a conventional manner, an LPC address that is placed on the system address bus23bby a system component such as the CPU21(FIG. 1). In response to the determinator210detecting an LPC address, the pulse synchronization module211generates an LPC-start pulse212that is synchronized to an edge of the LPC clock250. In one embodiment, the LPC-start pulse212has a duration of one LPC clock cycle.

In one embodiment, the addresses of the LPC address space are “hard wired” into the address determinator210. That is, the determinator210includes logic circuitry designed to recognize addresses within a predetermined LPC address space. Consequently, if one wishes to change the LPC address space, he must acquire a new chip that includes a determinator210designed to recognize the new LPC address space.

But in a second embodiment, the LPC address space is programmable into the address determinator210. Specifically, the determinator210includes a first register252for storing a starting address of the LPC address space, and a second register254for storing an ending address of the LPC address space. The address determinator210determines the intermediate addresses that are between the starting and ending address using a conventional algorithm. Consequently, one can move the LPC address space without having to obtain a new chip. Furthermore, the starting and ending LPC addresses can be loaded into the registers252and254at any time, such as during boot of the system20.

The data-synchronization module202synchronizes data from and to the bus23aduring an LPC write or read transaction, respectively. During an LPC write transaction, the data-synchronization module202latches data from the bus23ain response to a write signal on the control bus23cand the LPC start pulse212. The module202then provides this latched data to the finite state machine204. During an LPC read transaction, the data-synchronization module202receives data from an LPC device52via the LPC bus51, finite state machine204, and data bus256, and provides this data to the system data bus23a.In one embodiment, the module202receives a system clock on the control bus23cand synchronizes the transfer of data to the bus23awith the system clock. In another embodiment, the module202functions asynchronously with respect to the system bus23a.Specifically, the module202is conventionally programmed with the length, in LPC clock cycles, of an LPC read transaction. Consequently, the module202starts counting the LPC clock cycles in response to the LPC start pulse212, and drives the data received from the LPC device52onto the data bus23auntil the end (or sometime before the end) of the read transaction. If the LPC clock is an integer multiple of the system clock, then this insures that the read transaction will end in synchronization with the bus23a.For example, in one embodiment, the LPC clock250is twice the frequency of the system clock.

The finite state machine204converts the data and addresses into the formats necessary to allow-transfer between the system busses23aand23band the LPC bus51. Specifically, during an LPC write transaction, the state machine204converts the data and address from the system busses23aand23binto an LPC format suitable for transfer onto the LPC bus51. Similarly, during an LPC read transaction, the state machine204converts the address from the system address bus23binto a format suitable for transfer onto the LPC bus51, and converts the data from the LPC bus into a format suitable for transfer onto the system data bus23a.For example, during an LPC write transaction, the state machine204converts a byte of data and a sixteen-bit address from the system busses23aand23binto two nibbles of data and four nibbles of address suitable for transfer onto the four-bit LPC bus51. Similarly, during an LPC read transaction, the state machine204converts the sixteen-bit address from the system address bus23binto four nibbles of address suitable for transfer onto the address/data portion of the LPC bus51, and converts two nibbles of read data from the address/data portion of the LPC bus into a byte of data suitable for transfer onto the system data bus23a.

It is important to note that in typical bus transactions, one device at a time may drive the bus. In order to relinquish control of the bus, the device so indicates relinquishment and waits for a response from another device that accepts control of the bus. In this fashion, only one device at a time is driving the bus, and, as a result, data is properly transferred from device to device.

FIG. 3is a flow chart of the operation of the LPC interface50ofFIG. 2during an LPC write transaction and an LPC read transaction according to an embodiment of the invention. Reference is also made toFIG. 1during this discussion. For the purposes of this discussion, the “host” refers to any device (such as the CPU21) that resides on the system-bus side of the LPC interface50, and “target” refers to any device (such as the LPC slave52) that resides on the LPC-bus side of the LPC interface50.

First, an LPC write transaction is discussed, where a host device coupled to the system bus23writes data to the target LPC slave52.

Referring to step301, the host device such as the CPU21initiates the LPC write transaction. Specifically, the CPU21drives the system address bus23bwith the LPC address (within the LPC address space) of the LPC slave52, drives the system data bus23awith the data to be written, and drives the system control bus23cwith a write signal. Next, the address determinator210detects that the address on the bus23bis an LPC address. Then, in response to this detection, the pulse synchronization module211generates the LPC pulse212for one LPC clock cycle. In response to the LPC pulse212, the finite state machine204notifies the target devices, including the LPC slave device52, coupled to the LPC bus51that a host device is writing data to one of the LPC devices. The state machine204makes this notification via the LPC bus51. In one embodiment, this notification is performed conventionally according to the LPC bus protocol. Also in response to the LPC pulse212, the state machine204initializes its storage registers (not shown) and then latches the address on the system bus23band the control signals, including the write signal, on the system control bus23cin these registers. Similarly, in response to the LPC pulse212, the data synchronization module initializes its storage register (not shown) and latches the data on the system data bus23bin this register. In one embodiment, step301takes two cycles of the LPC clock250.

Next, referring to step303, the state machine204drives the write address latched from the system address bus23bonto the LPC bus51. In one embodiment, this address is sixteen bits wide and the address/data portion of the LPC bus51is only four bits wide. Therefore, the state machine204serially drives the write address nibble by nibble—from the most significant nibble to the least significant nibble—onto the LPC bus51in synchronization with the LPC clock250. Because the LPC targets such as the LPC device52are configured to recognize sixteen-bit addresses, the LPC targets receive and decode all four nibbles of the address to determine which of the targets is being addressed. In such an embodiment, this step takes four cycles of the LPC clock250. Alternatively, the address and the address/data portion of the LPC bus51may have widths that are different than sixteen bits and four bits respectively. Regardless, the state machine204converts the address from the system bus23binto a format suitable for transmission on the LPC bus51. Of course if the system address is in a format that is compatible with the LPC bus51, such conversion may be unnecessary.

Then, referring to step305, the state machine204drives the write data latched in the data synchronization module202onto the LPC bus52. In one embodiment, this data is eight bits wide and the LPC bus51is only four bits wide. Therefore, the state machine204receives the write data from the module202via the bus256serially drives the write data nibble by nibble—from the least significant nibble to the most significant nibble—onto the four-bit-wide address/data portion of the LPC bus51in synchronization with the LPC clock250. Because the LPC targets such as the LPC device52are configured to recognize a byte of data, the addressed LPC target receives both nibbles of data and reconstructs the data byte from these nibbles. In such an embodiment, step305takes two cycles of the LPC clock250. Alternatively, the data and the address/data portion of the LPC bus51may have widths that are different than eight bits and four bits respectively. Regardless, the state machine204converts the data from the system bus23ainto a format suitable for transmission on the LPC bus51. Of course if the system data is in a format that is compatible with the LPC bus51, such conversion may be unnecessary.

Next, referring to step307, the host device relinquishes control of the LPC bus51to the target device. Specifically, the state machine204drives a relinquishment value, for example 0xF hexadecimal, onto the LPC bus51. This is often referred to as the first cycle for bus-drive turnaround. Then, both the state machine204and the LPC target devices, including the slave device52, tristate the LPC bus51to mark the second cycle for bus-drive turnaround. Step307takes two cycles of the LPC clock250.

Then, referring to step309, the target device that will take control of the LPC bus51drives a ready signal onto the LPC bus51to indicate that the device is taking control of the bus51. But in this case, because during a write transaction no LPC target device need take control of the LPC bus51, a designated or default target device (not shown) drives the ready signal onto the bus51to confirm control of the bus51is now with the default target device. Step309takes one cycle of the LPC clock250.

Next, referring to step311, the target device relinquishes control of the LPC bus51back to the host device. Specifically, the default target device drives a relinquishment value, for example 0xF hexadecimal, onto the LPC bus51to mark the first cycle for bus-drive turnaround. Then, both the state machine204and the target devices, including the slave device52, tristate the LPC bus51to mark the second cycle for bus-drive turnaround. Next, the LPC bus51is idle to mark the end of the write transaction, and remains idle until a host initiates a subsequent transaction. Step311takes two cycles of the LPC clock250.

Second, an LPC read transaction is discussed, where a host device, such as the CPU21coupled to the system bus23reads data from the target LPC slave52.

Referring to step301, the host device such as the CPU21initiates the LPC read transaction. Specifically, the CPU21drives the system address bus23bwith the LPC address (within the LPC address space) of the LPC slave52and drives the system control bus23cwith a read signal. Next, the address determinator210detects that the address on the bus23bis an LPC address. Then, in response to this detection, the pulse synchronization module211generates the LPC pulse212for one LPC clock cycle. In response to the LPC pulse212, the finite state machine204notifies the target devices, including the LPC slave device52, coupled to the LPC bus51that a host device is reading data from one of the LPC devices. The state machine204makes this notification via the LPC bus51. In one embodiment, this notification is performed conventionally according to the LPC bus protocol. Also in response to the LPC pulse212, the state machine204initializes its storage registers (not shown) and then latches the address on the system bus23band the control signals, including the write signal, on the system control bus23cin these registers. Similarly, in response to the LPC pulse212, the data synchronization module202initializes its storage register (not shown). In one embodiment, step301takes two cycles of the LPC clock250.

Next, referring to step303, the state machine204drives the read address latched from the system address bus23bonto the LPC bus51. In one embodiment, this address is sixteen bits wide and the address/data portion of the LPC bus51is only four bits wide. Therefore, the state machine204serially drives the read address nibble by nibble—from the most significant nibble to the least significant nibble—onto the LPC bus51in synchronization with the LPC clock250, and the LPC targets receive and decode all four nibbles of the address to determine which of the targets is being addressed. In such an embodiment, this step takes four cycles of the LPC clock250. Alternatively, the address and the address/data portion of the LPC bus51may have widths that are different than sixteen bits and four bits respectively. Regardless, the state machine204converts the address from the system bus23binto a format suitable for transmission on the LPC bus51. Of course if the system address is in a format that is compatible with the LPC bus51, such conversion may be unnecessary.

Next, referring to step313, the host device relinquishes control of the LPC bus51to the LPC slave52. Specifically, the state machine204drives a relinquishment value, for example 0xF hexadecimal, onto the LPC bus51, during the first cycle for bus-drive turnaround. Then, both the state machine204and the LPC targets, including the slave device52, tristate the LPC bus51to mark the second cycle for bus-drive turnaround. Step313, like step307of the write transaction, takes two cycles of the LPC clock250.

Then, referring to step315, the LPC target to be read, here the LPC slave52, drives a ready signal onto the LPC bus51to indicate it is taking control of the bus51. Step315, like step309of the write transaction, takes one cycle of the LPC clock250.

Next, referring to step317, the target, here the LPC slave52, drives the read data onto the LPC bus51. In an embodiment where the read data is eight bits wide and the address/data portion of the LPC bus51is only four bits wide, the slave52serially drives this data nibble by nibble—from the least significant nibble to the most significant nibble—onto the LPC bus51in synchronization with the LPC clock250. The state machine204receives these nibbles and stores them together as a single byte of read data, and provides this byte of data to the data synchronization module202. In such an embodiment, step317takes two cycles of the LPC clock250. Alternatively, the data and the address/data portion of the LPC bus51may have widths that are different than eight bits and four bits respectively. Regardless, the LPC slave52provides the read data in a format suitable for transmission on the LPC bus51, and the state machine204converts this data into a format suitable for transmission on the system data bus23a.Of course, if the LPC data is in a format that is compatible with the system data bus23a,such conversion may be unnecessary.

Next, referring to step319, the LPC target relinquishes control of the LPC bus51back to the host. Specifically, the LPC slave52drives a relinquishment value, for example 0xF hexadecimal, onto the LPC bus51to mark the first cycle for bus-drive turnaround. Then, both the state machine204and the LPC targets, including the slave device52, tristate the LPC bus51to mark the second cycle for bus-drive turnaround. Next, the LPC bus51is idle to mark the end of the read transaction, and remains idle until a host initiates a subsequent transaction. Step311takes two cycles of the LPC clock250.

Still referring to step319, while the LPC target is relinquishing control of the LPC bus51, the data synchronization module202drives the read data onto the system data bus23a.Where the interface between the module202and the data bus23ais asynchronous, the module202stops driving the data onto the bus23aby the end of the read transaction. Specifically, as stated above, the read transaction spans thirteen cycles of the LPC clock250, beginning with the generation of the LPC start pulse212. Therefore, the module202begins counting the number of LPC clock cycles in response to the pulse212, asynchronously drives the read data from the state machine204onto the bus23a,and stops driving the read data onto the bus23aby the end of the thirteenth LPC clock cycle. Alternatively, if the interface between the module202and the data bus23ais synchronous, the module operates in a similar manner except that it drives the data onto the bus23a,and stops driving the data, in synchronization with the system clock (not shown).