A computer system has a processor bus under control of the microprocessor itself, and this bus communicates with main memory, providing high-performance access for most cache fill operations. In addition, the system includes one or more expansion buses, preferably of the PCI type in the example embodiment. A host-to-PCI bridge is used for coupling the processor bus to the expansion bus. Other buses may be coupled to the PCI bus via PCI-to-(E) ISA bridges, for example. The host-to-PCI bridge contains queues for posted writes and delayed read requests. All transactions are queued going through the bridge, upstream or downstream. The system bus is superpipelined, in that transactions overlap. A fast burst transactions are allowed between the bridge and main memory, i.e., requests which can be satisfied without deferring or retrying are applied to the system bus without waiting to get a response from the target. A range of addresses (e.g., system memory addresses) is defined to be a fast burst range, and any address in this range is treated differently compared to addresses outside the range. The bridge is programmed, by configuration cycles, to establish this fast burst range, within which it is known that an out-of-order response will not be received. When a transaction reaches a bridge interface from the PCI bus, and it is recognized that the address is within the fast burst range, then the fast burst mode is allowed, and write or read requests can be issued without waiting for the snoop phase, since there is no possibility of defer or retry.
|
7. A computer system, comprising:
a cpu; a system bus coupled to the cpu; a main memory coupled to said system bus; an expansion bus coupled to the system bus by a bridge; a signal path element of said system bus for initiating by said cpu a transaction on said system bus directed to a device coupled to said expansion bus, said transaction being initiated by a request being applied to said system bus by said cpu, followed by a snoop phase; said signal path element also providing for initiating at least first and second transactions on said system bus directed to a defined range of addresses of said main memory to which transactions are completed in order without being deferred or retried, said first transaction being initiated by a first request being applied to said system bus, followed immediately by a second request, without waiting for a snoop phase.
1. A method of operating a computer system of the type having a cpu with a system bus coupled to the cpu, a main memory coupled to said system bus, and having an expansion bus coupled to the system bus by a bridge, comprising the steps of:
initiating by said cpu a transaction on said system bus directed to a device coupled to said expansion bus, said transaction being initiated by a request being applied to said system bus by said cpu, followed by a snoop phase and a response phase defining a range of main memory addresses to which transactions are completed in order without being deferred or retried; initiating at least first and second transactions on said system bus directed to said range of main memory addresses, said transactions being initiated by a first request being applied to said system bus, followed immediately by a second request, without waiting for a snoop phase.
4. A method according to
5. A method according to
6. A method according to
8. A system according to
9. A system according to
0. 12. A system according to
0. 13. A system according to
|
This invention relates to computer systems, and more particularly to a memory access protocol for a computer system bus which uses a bridge between a processor bus and a standardized system bus.
Computer systems of the PC type usually employ a so-called expansion bus to handle various data transfers and transactions related to I/O and disk access. The expansion bus is separate from the system bus or from the bus to which the processor is connected, but is coupled to the system bus by a bridge circuit.
For some time, all PC's employed the ISA (Industry Standard Architecture) expansion bus, which was an 8-MHz, 16-bit device (actually clocked at 8.33 MHz). Using two cycles of the bus clock to complete a transfer, the theoretical maximum transfer rate was 8.33 MBytes/sec. Next, the EISA (Extension to ISA) bus was widely used, this being a 32-bit bus clocked at 8MHz, allowing burst transfers at one per clock cycle, so the theoretical maximum was increased to 33-MBytes/sec. As performance requirements increased, with faster processors and memory, and increased video bandwidth needs, a high performance bus standard was a necessity. Several standards were proposed, including a Micro Channel architecture which was a 10-MHz, 32-bit bus, allowing 40-MByte/sec, as well as an enhanced Micro Channel using a 64-bit data width and 64-bit data streaming, theoretically permitting 80-to-160 MByte/sec transfer. The requirements imposed by use of video and graphics transfer on networks, however, necessitate even faster transfer rates. One approach was the VESA (Video Electronics Standards Association) bus which was a 33 MHz, 32-bit local bus standard specifically for a 486 processor, providing a theoretical maximum transfer rate of 132-MByte/sec for burst, or 66-MByte/sec for non-burst; the 486 had limited burst transfer capability. The VESA bus was a short-term solution as higher-performance processors, e.g., the Intel P5 and P6 or Pentium and Pentium Pro processors, became the standard.
The PCI (Peripheral Component Interconnect) bus was proposed by Intel as a longer-term solution to the expansion bus standard, particularly to address the burst transfer issue. The original PCI bus standard has been upgraded several times, with the current standard being Revision 2.1, available from a trade association group referred to as PCI Special Interest Group, P.O. Box 14070, Portland, Oreg. 97214. The PCI Specification, Rev. 2.1, is incorporated herein by reference. Construction of computer systems using the PCI bus, and the PCI bus itself, are described in many publications, including "PCI System Architecture," 3rd Ed., by Shanley et al, published by Addison-Wesley Pub. Co., also incorporated herein by reference. The PCI bus provides for 32-bit or 64-bit transfers at 33-or 66-MHz; it can be populated with adapters requiring fast access to each other and/or with system memory, and that can be accessed by the host processor at speeds approaching that of the processor's native bus speed. A 64-bit, 66-MHz PCI bus has a theoretical maximum transfer rate of 528-MByte/sec. All read and write transfers over the bus can be burst transfers. The length of the burst can be negotiated between initiator and target devices, and can be any length.
System and component manufacturers have implemented PCI bus interfaces in various ways. For example, Intel Corporation manufactures and sells a PCI Bridge device under the part number 82450GX, which is a single-chip host-to-PCI bridge, allowing CPU-to-PCI and PCI-to-CPU transactions, and permitting up to four P6 processors and two PCI bridges to be operated on a system bus. Another example is offered by VLSI Technology, Inc., is a PCI chipset under the part number VL82C59x SuperCore, providing logic for designing a Pentium based system that uses both PCI and ISA buses. The chipset includes a bridge between the host bus and the PCI bus, a bridge between the PCI bus and the ISA bus, an a PCI bus arbiter. Posted memory write buffers are provided in both bridges, and provision is made for Pentium's pipelined bus cycles and burst transactions.
The PENTIUM PRO processor, commercially available from Intel Corporation, uses a processor bus structure as defined in the specification for this device, particularly as set forth in the publication "Pentium Pro Family Developer's Manual" Vols. 1-3, Intel Corp., 1996, available from McGraw-Hill, and incorporated herein by reference; this manual is also available from Intel by accessing <http://www.intel.com>.
The P6 bus is "super pipelined" in that the groups of signals on the bus which define a given transaction are interleaved with similar signals which define a subsequent transaction. One transaction does not need to complete before another is initiated. There are multiple phases of a transaction on the P6 bus, and each phase is a subset of signals on the bus, but these phases or stages overlap one another. An address for request #1 is put out on the bus, and addresses for requests #2 and #3 go out before the result for #1 comes back. A target of a bus transaction sends back an encoded "response" that says what the target is going to do, rather than sending the data itself, usually. The response can be a "retry," or that the target is sending the data immediately, or that it is latching a unique ID and it will come back on the bus later and send the data when it is available (a split transaction). Thus, the data completion phases can be out-of-order, for these retry or deferred responses. The preferred mode of operation, often, is to send bursts of data, rather than reads or writes of one 64-bit quadword. For example, if the bridge receives a series of posted writes, these are all posted, and there are a limited number of buffers in the queues of the bridge. In the example, when the address for cache line #1 is put on the bus, preferably the address for cache line #2 immediately follows, but if the request for cache line #1 is retried, then the ordering rules are violated; the rules dictate that #1 has to complete before #2, and if the address for #2 is put out on the bus and it completes in order, its too late, since a retry already is out for #1. To guarantee ordering, it would be necessary to put out address #1, wait until it is known that #1 is not retried or deferred, then put out address #2, etc. This would destroy the benefits of superpipelining on the P6 bus. Now, main memory can usually be accessed in the clock periods allowed on the P6 bus without deferring or retrying; no out of order responses are needed. To the extent that most transactions on the P6 bus are to system memory, it is a penalty to put out the address and the ADS#, wait around for the snoop phase (e.g., six clocks), then put out the next address for a burst; it is known, by the nature of the requests to system memory, that these transactions will complete in order. It is for this reason that the fast burst memory range is employed, as will be explained.
It is therefore one object of the present invention to provide an improved way of handling fast burst transactions on a bus in a computer system.
It is another object of the present invention to provide an improved computer system having enhanced performance when making accesses to devices on an expansion bus, using a bridge between a processor bus and an expansion bus.
It is a further object of the present invention to provide an improved bridge circuit for connecting a processor bus to an expansion bus, particularly one allowing fast burst transactions.
The above as well as additional objects, features, and advantages of the present invention will become apparent in the following detailed written description.
According to one embodiment of the invention, a computer system has a processor bus under control of the microprocessor itself, and this bus communicates with main memory, providing high-performance access for most cache fill operations. In addition, the system includes one or more expansion buses, preferably of the PCI type in the example embodiment. A host-to-PCI bridge is used for coupling the processor bus to the expansion bus. Other buses may be coupled to the PCI bus via PCI-to-(E)ISA bridges, for example. The host-to-PCI bridge contains queues for posted writes and delayed read requests. All transactions are queued going through the bridge, upstream or downstream. The system bus is superpipelined, in that transactions overlap. According to a feature of the invention, provision is made for fast burst transactions, i.e., read requests which can be satisfied without deferring or retrying are applied to the system bus without waiting for the snoop phase. A range of addresses (e.g.,system memory addresses) is defined to be a fast burst range, and any address in this range is treated differently compared to addresses outside the range. The bridge is programmed, by configuration cycles, to establish this fast burst range, within which it is known that an out-of-order response will not be received. Because it is known there will be no out-of-order responses, the initiator (processor) can send out a burst of eight write transactions in quick succession, knowing that all will complete in order. The range values are stored in configuration registers in the bridge, written at the time the machine is turned on; the boot up includes interrogating the main memory to see what its range is, then that range is programmed into the bridge. Thereafter, when a transaction reaches the bridge interface from the expansion bus, and it is recognized that the address is within the range, then the fast burst mode is allowed, and write addresses are allowed to follow one another without the usual delay.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
Referring to
According to the invention, a bridge 18 or 19 is provided between the processor bus 15 and a PCI bus 20 or 21. Two bridges 18 and 19 are shown, although it is understood that many systems would require only one, and other systems may use more than two. In one example, up to four of the bridges may be used. The reason for using more than one bridge is to increase the potential data throughput. A PCI bus, as mentioned above, is a standardized bus structure that is built according to a specification agreed upon by a number of equipment manufacturers so that cards for disk controllers, video controllers, modems, network cards, and the like can be made in a standard configuration, rather than having to be customized for each system manufacturer. One of the bridges 18 or 19 is the primary bridge, and the remaining bridges (if any) are designated secondary bridges. The primary bridge 18 in this example carries traffic for the "legacy" devices such as (E)ISA bus, 8259 interrupt controller, VGA graphics, IDE hard disk controller, etc. The secondary bridge 19 does not usually incorporate any PC legacy items.
All traffic between devices on the concurrent PCI buses 20 and 21 and the system memory 17 must traverse the processor bus 15. Peer-to-peer transactions are allowed between a master and target device on the same PCI bus 20 or 21; these are called "standard" peer-to-peer transactions. Transactions between a master on one PCI bus and a target device on another PCI bus must traverse the processor bus 15, and these are "traversing" transactions; memory and I/O reads and writes are allowed in this case but not locked cycles and some other special events.
In an example embodiment as seen in FIG. 1. PC legacy devices are coupled to the PCI bus 20 by an (E)ISA bridge 23 to an EISA/ISA bus 24. Attached to the bus 24 are components such as a controller 25 (e.g., an 8042) for keyboard and mouse inputs 26 flash ROM 27, NVRAM 28, and a controller 29 for floppy drive 30 and serial/parallel ports 31. A video controller 32 for a monitor 33 is also connected to the bus 20. On the other PCI bus 21, connected by bridge 19 to the processor bus 15, are other resources such as a SCSI disk controller 34 for hard disk resources 35 and 36, and a network adapter 37. A network 38 is accessed by the adapter 37, and a large number of other stations (computer systems) 39 are coupled to the network. Thus, transactions on the buses 15, 20, and 21 may originate in or be directed to another station or server 39 on the network 38. The embodiment of
The processor bus 15 contains a number of standard signal or data lines as defined in the specification for the PENTIUM PRO or P6 processor, mentioned above. In addition, certain special signals are included for the unique operation of the bridges 18 and 19, as will be described. The bus 15 contains thirty-three address lines 15a, sixty-four data lines 15b, and a number of control lines 15c. Most of the control lines are not material here and will not be referred to; also, data and address signals have parity lines associated with them which will not be treated here. The control signals of interest here are described, and include the address strobe ADS#, data ready DRDY#, lock LOCK#, data busy DBSY#, defer DEFER#, request command REQ [4:0]#(five lines), response status RS[2:0]#, etc.
The PCI bus 20 (or 21) also contains a number of standard signal and data lines as defined in the PCI specification. This bus is a multiplexed address/data type, and contains sixty-four AD lines 20a, eight command/byte-enable lines 20b, and a number of control lines 20c as will be described. The definition of the control lines of interest here is given in Appendix B, including frame FRAME#, initiator ready IRDY#, lock P_LOCK#, target ready TRDY#, STOP#, etc. In addition, there are PCI arbiter signals 20d, also described in Appendix B, including request REQx#, grant P_GNTx#, MEMACK#, etc.
Referring to
For transactions traversing the bridge 18, all memory writes are posted writes and all reads are split transactions. A memory write transaction initiated by a processor device on the processor bus 15 is posted to the interface 43 of FIG. 2 and the processor goes on with instruction execution as if the write had been completed. A read requested by a processor 11-14 is not implemented at once, due to mismatch in the speed of operation of all of the data storage devices (except for caches) compared to the processor speed, so the reads are all treated as split transactions in some manner. An internal bus 47 conveys processor bus write transactions or read data from the interface 43 to a downstream delayed completion queue DSDCQ 48 and a RAM 49 for this queue, or to a downstream posted write queue 50 and a RAM 51 for this queue. Read requests going downstream are stored in a downstream delayed request queue DSDRQ 52. An arbiter 53 monitors all pending downstream posted writes and read requests via valid bits on lines 54 in the downstream queues and schedules which one will be allowed to execute next on the PCI bus according to the read and write ordering rules set forth in the PCI bus specification. Commands to the interface 44 from the arbiter 53 are on lines 55.
The components of upstream queue block 45 are similar to those of the downstream queue block 46, i.e., the bridge 18 is essentially symmetrical for downstream and upstream transactions. A memory write transaction initiated by a device on the processor bus 20 is posted to the PCI interface 44 of FIG. 2 and the master device proceeds as if the write had been completed. A read requested by a device on the PCI bus 20 is not implemented at once by a target device on the processor bus 15, so these reads are again treated as delayed transactions. An internal bus 57 conveys PCI bus write transactions or read data from the interface 44 to an upstream delayed completion queue USDCQ 58 and a RAM 59 for this queue, or to an upstream posted write queue 60 and a RAM 61 for this queue. Read requests going upstream are stored in an upstream delayed request queue USDRQ 62. An arbiter 63 monitors all pending upstream posted writes and read requests via valid bits on lines 64 in the upstream queues and schedules which one will be allowed to execute next on the processor bus according to the read and write ordering rules set forth in the PCI bus specification. Commands to the interface 43 from the arbiter 63 are on lines 65.
The structure and functions of the FIFO buffers or queues in the bridge 18 will now be described. Each buffer in a delayed request queue, i.e., DSDRQ 52 or USDRQ 62, stores a delayed request that is waiting for execution, and this delayed request consists of a command field, an address field, a write data field (not needed if this is a read request), and a valid bit. The upstream USDRQ 62 holds requests originating from masters on the PCI bus and directed to targets on the processor bus 15 and has eight buffers (in an example embodiment), corresponding one-to-one with eight buffers in the downstream delayed completion queue DSDCQ 48. The downstream delayed request queue DSDRQ 52 holds requests originating on the processor bus 15 and directed to targets on the PCI bus 20 and has four buffers, corresponding one-to-one with four buffers in the upstream delayed completion queue USDCQ 58. The DSDRQ 52 is loaded with a request from the interface 43 via bus 72 and the USDCQ 58. Similarly, the USDRQ 62 is loaded from interface 44 via bus 73 and DSDCQ 48. The reason for going through the DCQ logic is to check to see if a read request is a repeat of a request previously made. Thus, a read request from the bus 15 is latched into the interface 43 in response to an ADS#, capturing an address, a read command, byte enables, etc. This information is applied to the USDCQ 58 via lines 74, where it is compared with all enqueued prior downstream read requests; if it is a duplicate, this new request is discarded if the data is not available to satisfy the request, but if it is not a duplicate, the information is forwarded to the DSDRQ 52 via bus 72. The same mechanism is used for upstream read requests; information defining the request is latched into interface 44 from bus 20, forwarded to DSDCQ 48 via lines 75, and if not a duplicate of an enqueued request it is forwarded to USDRQ 62 via bus 73.
The delayed completion queues each include a control block 48 or 58 and a dual port RAM 49 or 59. Each buffer in a DCQ stores completion status and read data for one delayed request. When a delayable request is sent from one of the interfaces 43 or 44 to the queue block 45 or 46, the first step is to check within the DCQ 48 or 58 to see if a buffer for this same request has already been allocated. The address and the commands and byte enables are checked against the eight buffers in DCQ 48 or 58. If not a match, then a buffer is allocated (if one is available) the request is delayed (or deferred for the bus 15), and the request is forwarded to the DRQ 52 or 62 in the opposite side via lines 72 or 73. This request is run on the opposite bus, under control of the arbiter 53 or 63, and the completion status and data are forwarded back to the DCQ 48 or 58 via bus 47 or 57. After status/data are placed in the allocated buffer in the DCQ in this manner, this buffer is not valid until ordering rules are satisfied; e.g., a read cannot be completed until previous writes are completed. When a delayable request "matches" a DCQ buffer and the requested data is valid, then the request cycle is ready for immediate completion.
The downstream DCQ 48 stores status/read data for PCI-to-host delayed requests, and the upstream DCQ 58 stores status/read data for Host-to-PCI delayed or deferred requests. The upstream and downstream operation is slightly different in this regard. The bridge control circuitry causes prefetch of data into the DSDCQ buffers 48 on behalf of the master, attempting to stream data with zero wait states after the delayed request completes. DSDCQ buffers are kept coherent with the host bus 15 via snooping, which allows the buffers to be discarded as seldom as possible. Requests going the other direction are not subjected to prefetching, however, since many PCI memory regions have "read side effects"(e.g., stacks and FIFO's) so the bridge never prefetches data into these buffers on behalf of the master, and USDCQ buffers are flushed as soon as their associated deferred reply completes.
The posted write queues each contain a control block 50 or 60 and a dual port RAM memory 51 or 61, with each one of the buffers in these RAMs storing command and data for one write. Only memory writes are posted, i.e., writes to I/O space are not posted. Because memory writes flow through dedicated queues within the bridge, they cannot be blocked be delayed requests that precede them; this is a requirement of the PCI specification. Each of the four buffers in DSPWQ 50, 51 stores 32-Bytes of data plus commands for a host-to-PCI write; this is a cache line the bridge might receive a cacheline-sized write if the system has a PCI video card that supports the P6 USWC memory type. The four buffers in the DSPWQ 50, 51 provide a total data storage of 128-bytes. Each of the four buffers in USPWQ 60, 61 stores 256-Bytes of data plus commands for a PCI-to-host write; this is eight cache lines (total data storage=1-KByte). Burst memory writes that are longer than eight cache lines can cascade continuously from one buffer to the next in the USPWQ. Often, an entire page (e.g., 4-KB) is written from disk to main memory in a virtual memory system that is switching between tasks; for this reason, the bridge has more capacity for bulk upstream memory writes than for downstream.
The arbiters 53 and 63 control event ordering in the QBLKs 45 and 46. These arbiters make certain that any transaction in the DRQ 52 or 62 is not attempted until posted writes that preceded it are flushed, and that no datum in a DRQ is marked valid until posted writes that arrived in the QBLK ahead of it are flushed.
Referring to
Several read requests can be pending on the bus 15 at the same time. That is, another request can be asserted by any agent which is granted the bus (the same processor, or by a different processor), during T5, indicated by dotted lines for the ADS# signal, and the same sequence of error, snoop, response, and data phases would play out in the same order, as discussed. Up to eight transactions can be pending on the bus 15 at one time. The transactions complete in order unless they are split with a deferred response. Transactions that receive a deferred response may complete out of order.
A simple write transaction on the P6 bus 15 is illustrated in FIG. 3b. As in a read transaction, after being granted the bus, in T3 the initiator asserts ADS# and asserts the REQa0# (command and B/E's). TRDY# is asserted three clocks later in T6. TRDY# is active and DBSY# is inactive in T8, so data transfer can begin in T9; DRDY# is asserted at this time. The initiator drives data onto the data bus D[63:0]# during T9.
A burst or full-speed read transaction is illustrated in FIG. 3c. Back-to-back read data transfers from the same agent with no wait states. Note that the request for transaction-4 is being driven onto the bus while data for transaction-1 is just completing in T10, illustrating the overlapping of several transactions. DBSY# is asserted for transaction-1 in T7 and remains asserted until T10. Snoop results indicate no implicit writeback data transfers so TRDY# is not asserted.
Likewise, a burst or full-speed write transaction with no wait states and no implicit writebacks is illustrated in FIG. 3d. TRDY# for transaction-2 can be driven the cycle after RS[2:0]# is driven. In T11, the target samples TRDY# active and DBSY# inactive and accepts data transfer starting in T12. Because the snoop results for transaction-2 have been observed in T9, the target is free to drive the response in T12.
A deferred read transaction is illustrated in FIG. 3a. This is a split transaction, meaning the request is put out on the bus, then at some time later the target initiates occur on the bus in the intervening time. Agents use the deferred response mechanism of the P6 bus when an operation has significantly greater latency than the normal in-order response. During the request phase on the P6 bus 15, an agent can assert Defer Enable DEN# to indicate if the transaction can be given a deferred response. If DEN# is inactive, the transaction cannot receive a deferred response; some transactions must always be issued with DEN# inactive, e.g., bus-locked transactions, deferred replies, writebacks. When DEN# is inactive, the transaction may be completed in-order or it may be retried, but it cannot be deferred. A deferred transaction is signalled by asserting DEFER# during the snoop phase followed by a deferred response in the response phase. On a deferred response, the response agent must latch the deferred ID, DID[7:0]#, issued during the request phase, and after the response agent completes the original request, it must issue a matching deferred-reply bus transaction, using the deferred ID as the address in the reply transaction's request phase. The deferred ID is eight bits transferred on pins Ab[23:16] in the second clock of the original transaction's request phase.
A read transaction on the PCI bus 20 (or 21) is illustrated in FIG. 3f. It is assumed that the bus master has already arbitrated for and been granted access to the bus. The bus master must then wait for the bus to become idle, which is done by sampling FRAME# and IRDY# on the rising edge of each clock (along with GNT#); when both are sampled deasserted, the bus is idle and a transaction can be initiated by the bus master. At start of clock T1, the initiator asserts FRAME#, indicating that the transaction has begun and that a valid start address and command are on the bus. FRAME# must remain asserted until the initiator is ready to complete the last data phase.
When the initiator asserts FRAME#, it also drives the start address onto the AD bus and the transaction type onto the Command/Byte Enable lines, C/BE[3:0]#. A turn-around cycle (i.e., a dead cycle) is required on all signals that may be driven by more than one PCI bus agent, to avoid collisions.
At the start of clock T2, the initiator ceases driving the AD bus, allowing the target to take control of the AD bus to drive the first requested data item back to the initiator. Also at the start of clock T2, the initiator ceases to drive the command onto the C/BE lines and uses them to indicate the bytes to be transferred in the currently addressed doubleword (typically, all bytes are asserted during a read). The initiator also asserts IRDY# during T2 to indicate it is ready to receive the first data item from the target. The initiator asserts IRDY# sand deasserts FRAME# simultaneously to indicate that it is ready to complete the last data phase (T5 in FIG. 3f). During clock T3, the target asserts DEVSEL# to indicate that it recognized its address and will participate in the transaction, and begins to drive the first data item onto the AD bus while it asserts TRDY# to indicate the presence of the requested data. When the initiator sees TRDY# asserted in T3 it reads the first data item from the bus. The initiator keeps IRDY# asserted upon entry into the second data phase in T4, and does not deassert FRAME#, indicating it is ready to accept the second data item. In a multiple-data phase transaction (e.g., a burst), the target latches the start address into an address counter, and increments this address to generate the subsequent addresses.
A write transaction on the PCI bus 20 (or 21) is illustrated in FIG. 3g. At start of clock T1, the write initiator asserts FRAME#, indicating that the transaction has begun and that a valid start address and command are on the bus. FRAME# remains asserted until the initiator is ready to complete the last data phase. When the initiator asserts FRAME#, it also drives the start address onto the AD bus and the transaction type onto the C/BE[3:0]# lines. In clock T2, the initiator switches to driving the AD bus with the data to be written; no turn-around cycle is needed since the initiator continues to drive the bus itself. The initiator also asserts IRDY# in T2 to indicate the presence of data on the bus. FRAME# is not deasserted until the last data phase. During clock T2, the target decodes the address and command and asserts DEVSEL# to claim the transaction, and asserts TRDY# to indicate readiness to accept the first data item.
The system bus 15 is superpipelined, in that transactions overlap. According to a feature of the invention, provision is made for fast burst transactions, i.e., read or write requests which can be satisfied without deferring or retrying are applied to the system bus 15 without waiting for the snoop phase. A range of addresses (e.g., system memory 17 addresses) is defined to be a fast burst range, and any address in this range is treated differently compared to addresses outside the range. The bridge 18 or 19 is programmed, by configuration cycles, to establish this fast burst range, within which it is known that an out-of-order response will not be received. Because it is known there will be no out-of-order responses, the initiator (PCI agent) can send out a burst of eight write transactions in quick succession, knowing that all will complete in order. The range values are stored in configuration registers in the bridge 18 or 19, written at the time the system 10 is turned on; the boot up includes interrogating the main memory 17 or its controller 16 to see what its range is, then that range is programmed into the interface 43 of the bridge. Thereafter, when a PCI-to-main memory transaction reaches the bridge interface 43, and it is recognized that the address is within the range, then the fast burst mode is allowed, and write addresses are allowed to follow one another without the usual delay.
In one embodiment, the fast burst region is defined to be region from 1-MByte to the Top of Memory. The properties of the fast burst region are that any memory transaction to this region will be guaranteed to never be retried or deferred. With this guarantee, the bridge 18 or 19 can issue multi-cachline accesses to this region every three clocks without having to wait for the snoop phase, knowing that these transactions will never be retried or deferred. Multi-transactions will only be issued in this fast burst region without waiting for the snoop phase if a "fast burst memory mode enable" bit is set in an address decode modes register in the bridge.
While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.
Riley, Dwight, Pettey, Christopher J., Hausauer, Brian S., Seeman, Thomas R., Elkhoury, Bassam
Patent | Priority | Assignee | Title |
10062422, | Jun 25 2007 | META PLATFORMS TECHNOLOGIES, LLC | Various methods and apparatus for configurable mapping of address regions onto one or more aggregate targets |
6647454, | Sep 25 2000 | Intel Corporation | Data transfer through a bridge |
6757768, | May 17 2001 | Cisco Technology, Inc. | Apparatus and technique for maintaining order among requests issued over an external bus of an intermediate network node |
6832279, | May 17 2001 | Cisco Systems, Inc. | Apparatus and technique for maintaining order among requests directed to a same address on an external bus of an intermediate network node |
6954450, | Nov 26 2003 | Cisco Technology, Inc | Method and apparatus to provide data streaming over a network connection in a wireless MAC processor |
7096292, | Feb 28 2001 | CAVIUM INTERNATIONAL; MARVELL ASIA PTE, LTD | On-chip inter-subsystem communication |
7243179, | Feb 28 2001 | CAVIUM INTERNATIONAL; MARVELL ASIA PTE, LTD | On-chip inter-subsystem communication |
7436954, | Feb 28 2001 | CAVIUM INTERNATIONAL; MARVELL ASIA PTE, LTD | Security system with an intelligent DMA controller |
7548532, | Nov 26 2003 | Cisco Technology, Inc. | Method and apparatus to provide inline encryption and decryption for a wireless station via data streaming over a fast network |
7653763, | Feb 28 2001 | CAVIUM INTERNATIONAL; MARVELL ASIA PTE, LTD | Subsystem boot and peripheral data transfer architecture for a subsystem of a system-on- chip |
7657678, | Aug 06 1998 | SHAMROCK INNOVATIONS, LLC | Modular computer system |
7734852, | Aug 06 1998 | SHAMROCK INNOVATIONS, LLC | Modular computer system |
7835371, | Nov 26 2003 | Cisco Technology, Inc. | Method and apparatus to provide data streaming over a network connection in a wireless MAC processor |
8060675, | Aug 06 1998 | SHAMROCK INNOVATIONS, LLC | Computing module with serial data connectivity |
8108648, | Jun 25 2007 | META PLATFORMS TECHNOLOGIES, LLC | Various methods and apparatus for address tiling |
8291145, | Aug 10 2004 | Hewlett Packard Enterprise Development LP | Method and apparatus for setting a primary port on a PCI bridge |
8407433, | Jun 25 2007 | META PLATFORMS TECHNOLOGIES, LLC | Interconnect implementing internal controls |
8438320, | Jun 25 2007 | META PLATFORMS TECHNOLOGIES, LLC | Various methods and apparatus for address tiling and channel interleaving throughout the integrated system |
8504992, | Oct 31 2003 | META PLATFORMS TECHNOLOGIES, LLC | Method and apparatus for establishing a quality of service model |
8650330, | Mar 12 2010 | International Business Machines Corporation | Self-tuning input output device |
8868397, | Nov 20 2006 | META PLATFORMS TECHNOLOGIES, LLC | Transaction co-validation across abstraction layers |
8972995, | Aug 06 2010 | META PLATFORMS TECHNOLOGIES, LLC | Apparatus and methods to concurrently perform per-thread as well as per-tag memory access scheduling within a thread and across two or more threads |
9087036, | Aug 12 2004 | META PLATFORMS TECHNOLOGIES, LLC | Methods and apparatuses for time annotated transaction level modeling |
9292436, | Jun 25 2007 | META PLATFORMS TECHNOLOGIES, LLC | Various methods and apparatus to support transactions whose data address sequence within that transaction crosses an interleaved channel address boundary |
9495290, | Jun 25 2007 | META PLATFORMS TECHNOLOGIES, LLC | Various methods and apparatus to support outstanding requests to multiple targets while maintaining transaction ordering |
RE41494, | Apr 19 2000 | SHAMROCK INNOVATIONS, LLC | Extended cardbus/PC card controller with split-bridge technology |
Patent | Priority | Assignee | Title |
5535363, | Jul 12 1994 | Intel Corporation | Method and apparatus for skipping a snoop phase in sequential accesses by a processor in a shared multiprocessor memory system |
5630094, | Jan 20 1995 | Intel Corporation | Integrated bus bridge and memory controller that enables data streaming to a shared memory of a computer system using snoop ahead transactions |
5644124, | Jul 01 1993 | Sharp Kabushiki Kaisha | Photodetector with a multilayer filter and method of producing the same |
5664124, | Nov 30 1994 | LENOVO SINGAPORE PTE LTD | Bridge between two buses of a computer system that latches signals from the bus for use on the bridge and responds according to the bus protocols |
5694556, | Jun 07 1995 | International Business Machines Corporation | Data processing system including buffering mechanism for inbound and outbound reads and posted writes |
5717894, | Mar 07 1994 | Dell USA, L.P. | Method and apparatus for reducing write cycle wait states in a non-zero wait state cache system |
5813036, | Jul 07 1995 | OPTi Inc. | Predictive snooping of cache memory for master-initiated accesses |
6148359, | Dec 31 1996 | Hewlett Packard Enterprise Development LP | Bus-to-bus bridge in computer system, with fast burst memory range |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Nov 03 2000 | Compaq Computer Corporation | (assignment on the face of the patent) | / | |||
Oct 01 2002 | Compaq Information Technologies Group, LP | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 015000 | /0305 | |
Oct 27 2015 | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | Hewlett Packard Enterprise Development LP | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 037079 | /0001 |
Date | Maintenance Fee Events |
May 10 2006 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Jun 14 2010 | REM: Maintenance Fee Reminder Mailed. |
Jun 28 2010 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Jun 28 2010 | M1556: 11.5 yr surcharge- late pmt w/in 6 mo, Large Entity. |
Date | Maintenance Schedule |
Feb 04 2006 | 4 years fee payment window open |
Aug 04 2006 | 6 months grace period start (w surcharge) |
Feb 04 2007 | patent expiry (for year 4) |
Feb 04 2009 | 2 years to revive unintentionally abandoned end. (for year 4) |
Feb 04 2010 | 8 years fee payment window open |
Aug 04 2010 | 6 months grace period start (w surcharge) |
Feb 04 2011 | patent expiry (for year 8) |
Feb 04 2013 | 2 years to revive unintentionally abandoned end. (for year 8) |
Feb 04 2014 | 12 years fee payment window open |
Aug 04 2014 | 6 months grace period start (w surcharge) |
Feb 04 2015 | patent expiry (for year 12) |
Feb 04 2017 | 2 years to revive unintentionally abandoned end. (for year 12) |