Abstract:
A DMA Controller, in response to a data transfer request from a slave device, initiates a memory transfer cycle and informs the slave device when the data transfer has completed. In order to avoid dead clock cycles on internal bus(es), the DMA Controller initiates a speculative data transfer cycle after the notification. The DMA Controller aborts the speculative data transfer cycle if the slave device does not request another data transfer within a predetermined time.

Description:
BACKGROUND OF THE INVENTION 
     This invention relates to direct memory access (DMA) transfers between peripheral devices and a memory via a DMA controller acting as a bus master located on a processor local bus (PLB). 
     In the recent past, significant advances in silicon densities have permitted the integration of many functions onto a single silicon chip which includes the processor. The increase in density has allowed the integration of some peripheral functions which were formerly implemented at the card level over a system level bus. Some of the functions being integrated on the chip include audio, video and graphics. These functions have increased bandwidth requirements and require efficient utilization of the on-chip bus used to transfer data between a memory and the peripherals. 
     In most applications several bus masters, such as DMA controllers, share an on-chip processor local bus (PLB) under control of a bus arbiter. It is essential that the bus masters relinquish the bus as soon as they no longer require it in order to improve bandwidth utilization. However, it is also more efficient to retain control of the bus when a peripheral requires back-to-back data transfers. The two requirements present a conflict. 
     Once a DMA Acknowledge (DMAA) signal is asserted by the DMA controller to signal a data transfer, the peripheral will use the DMA Acknowledge (DMAA) to de-assert its request if it requires no more transfers. Due to delays, this event takes place very late in the clock cycle. Therefore, the de-assertion of a request must be single latched by the DMA before it can be sampled. PLB bus master requests must start at the beginning of a clock cycle (driven off the output of a latch). For a single clock cycle DMA Acknowledge, the earliest the DMA can sample the peripheral request is the clock after the DMAA. Unfortunately, the DMA cannot instantaneously turn its bus master request on based on the sampling of the peripheral request. Therefore, the DMA must wait for one clock and then assert its PLB bus master request if the peripheral has its request active for another transfer cycle. This results in a lost or &#34;dead&#34; clock cycle between back-to-back DMA peripheral transfers. 
     SUMMARY OF THE INVENTION 
     The invention contemplates a method and apparatus for providing back-to-back DMA transfers with no lost or dead clock cycles between the back-to-back transfers. This is accomplished by asserting a DMA PLB Bus Master Request following the ned of a peripheral transfer when the peripheral request is valid and continuing if the peripheral request remains valid. If the peripheral request is sampled de-asserted in the clock cycle following the de-assertion of DMAA, the DMA asserts a DMA PLB Abort signal which informs the bus arbiter and other devices connected to the PLB that the request should be ignored. The DMA PLB Abort signal is valid if it occurs by the mid point of the current request clock cycle, thus the abort becomes effective as soon as the sampled peripheral request is de-asserted. Since many transfers involve back-to-back transfers, this results in an improvement in the utilization of the bus bandwidth. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a block diagram of a DMA buffered memory to peripheral transfer configuration. 
     FIG. 2 is a block diagram of a slave buffered memory to peripheral transfer configuration. 
     FIG. 3 a block diagram of a direct or &#34;flyby&#34; memory to peripheral transfer configuration. 
     FIG. 4 is a timing diagram illustrating a sequence of signals generated in a DMA buffered memory to peripheral transfer. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     In FIG. 1, a Peripheral Device 10 is connected by a Slave Data Bus 11 to a Slave Bus Controller (SBC) 12 and by a DMA Request (DMAR) lines 13 and a DMA Acknowledge (DMAA) line 14 to a DMA Controller (DMAC) 15. A Processor Local Bus (PLB) 16 interconnects SBC 12, DMAC 15, a second Slave Bus Controller (SBC) 17 and a PLB Arbiter (PLBA) 18. SBC 17 is connected to a memory 19 by Slave Bus 20 which includes both data and address lines. The PLB serves other Bus Masters not shown. The PLBA 18, using conventional arbitration techniques, allows the bus masters to share the Bus 16. As stated before, the bus masters request must be asserted at the beginning of a clock cycle in order to meet the timing requirements of the PLB Arbiter. 
     In operation, the Peripheral 10 asserts a DMAR on line 13. In response to the request, the properly configured DMAC 15 initiates a memory read cycle on the PLB 16 at the address specified by the properly configured DMAC 15. SBC 17 acknowledges and initiates a read operation at the specified address and the data is provided over bus 20. The data read from Memory 19 is forwarded over the PLB 16 to the DMAC 15 where it is stored. The DMAC 15 then performs a write cycle directed over PLB 16 to the SBC 12. SBC 12 acknowledges and drives the data onto bus 11. The DMAC 15 then asserts the DMAA signal on line 14 and the Peripheral 10 copies the data on Bus 11. 
     If DMAR is still asserted during the last clock of DMAA, the DMAC 15 will assert a subsequent PLB DMA Request based on the speculation that the Peripheral 10 will require another transfer. If the Peripheral 10 de-asserted DMAR in the last clock cycle of DMAA, the DMAC 15 will assert a PLB Abort signal to terminate the current PLB request and make the PLB available via the PLB arbiter 18. This will occur in the same clock cycle that the DMAC 15 samples the de-asserted DMAR from Peripheral 10. The PLB Abort signal need not be asserted until the mid point of the clock cycle which occurs after the peripheral de-asserts the DMAR signal. The specific sequence of signals for this configuration (see FIG. 4) are illustrative and will be described in detail below. 
     In FIG. 2 (and FIG. 3), like elements have been provided with the same reference numerals. In this figure, a single Slave Bus Controller 12/17 is used and data read from Memory 19 is buffered in the SBC 12/17. As in FIG. 1, the Peripheral 10 asserts DMAR, the DMAC performs a PLB transfer cycle and the SBC 12/17 reads the data into its buffer. It then drives the data onto the Bus 11. The DMAC 15 asserts DMAA and the Peripheral 10 copies the data on Bus 11. Here also the DMAC 15 executes a speculative DMA PLB Request. If the Peripheral 10 deasserts the DMAR during the last clock of DMAA, the DMAC 15 asserts the DMA PLB Abort as described above. 
     In FIG. 3, the Peripheral 10 is directly connected to the Memory 19 by a Data Bus 30. The SBC 17 provides address and control information to Memory 19 by a Bus 31. The DMAR lines 13 and DMAA line 14 are connected to DMAC 15 and function as previously described. In operation, the Peripheral 10 generates a properly configured DMAR on lines 13. The DMAC 15 performs a transfer cycle directed to the SBC 17 via the PLB. The SBC 17 acknowledges and initiates a memory read operation via the bus 31. 
     Upon acknowledgement, the DMAC 15 asserts DMAA over line 14. The Peripheral 10, in response to the DMAA, copies the data on the Bus 30. At this point, the operation of the DMAC 15 and the Peripheral 10 are identical to that described above in connection with FIGS. 1 and 2. 
     The description thus far has been limited to memory to slave peripheral data transfer cycles. A peripheral slave to memory data transfer cycle is the reverse of the process described above. For example, in the direct transfer illustrated in FIG. 3, the Slave Peripheral 10 generates a request DMAR (indicating a write data transfer as opposed to read data transfer) on line 13. In response, the DMAC 15 initiates a write data transfer cycle directed to SBC 12/17 via the PLB Bus 16. The SBC 12/17 acknowledges the cycle via PLB 16 and in response, the DMAC 15 asserts DMAA via line 14. Upon receipt of the DMAA, the Slave Peripheral 10 drives the data onto the Bus 30 and the SBC 12/17 performs a memory write operation at the address specified by the DMAC 15. The DMAC 15, after deasserting the DMAA, initiates a speculative data transfer cycle and examines the line 13 for a subsequent DMAR. If a timely subsequent DMAR is not asserted, the DMAC 15 asserts a PLB Abort. 
     FIG. 4 illustrates signals used in the DMA buffered memory to peripheral transfer (FIG. 1). They cover ten consecutive clock cycles and illustrate a DMAR by the Peripheral 10 followed by a data transfer, a subsequent de-assertion of the DMAR by the Peripheral 10 and a speculative request by the DMAC 15 followed by assertion of the PLB Abort signal. The signals are defined below. 
     Request (DMAC PLB Request): This signal is asserted by the DMAC to request a data transfer across the PLB bus. 
     ABus (Address Bus): The DMA memory address. The SBC 17 must latch the address at the end of the cycle in which it asserts an Address Acknowledge (AAck) signal. 
     TQuals (Transfer Qualifiers): These signals are driven by the DMAC and are valid any time that the Request signal is active. The signals define the size and type of the transfer. 
     R/W (Read/Write): Driven by the DMAC and valid any time the Request is active. Indicates to an SBC a read or a write transfer. 
     AValid (Address Valid): This signal is driven by the PLB Arbiter to indicate that a valid address and transfer qualifiers are on the PLB. All SBC&#39;s sample this signal and, if the address is within their address range and they are capable of performing the transfer, they respond by asserting their AAck signal. 
     Abort (transfer abort): This signal is driven by the DMAC and causes any SBC to discontinue any response to the signal and the arbiter to re-arbitrate. 
     RdDBus&lt;0:n&gt;(Read Data Bus): Is an n bit data bus used to transfer data during a read operation from an SBC to a Bus Master such as the DMAC. 
     RdDAck (Read Data Acknowledge): This signal is driven by the SBC&#39;s and indicates to a Bus Master that the data on the read data bus is valid and must be latched at the end of the current cycle. 
     RdComp (Data Read Complete): This signal is driven by the SBC&#39;s and is used to indicate to the Bus Arbiter that the read operation has completed. 
     WrDBus&lt;0:n&gt;(Write Data Bus): This is an n bit data bus which is used to transfer data during a write operation from the DMAC to an SBC. 
     WrDAck (Write Data Acknowledge): This signal is driven by a SBC and informs the DMAC that write data will be latched at the end of the current cycle. 
     WrComp (Data Write Complete): This signal is asserted by an SBC to notify the Bus Arbiter that a write transfer has been completed. 
     DMAR (DMA peripheral request): This signal is driven by a peripheral to request a read or write memory operation. 
     DMAA (peripheral acknowledge): This signal is driven by the DMAC to inform the peripheral that it can latch or drive data from or onto the slave bus. 
     DMA --  dataXfer (DMA data transfer) not required for the waveform shown: This signal is driven by the DMAC to indicate to the SBC the last active clock of the DMAA signal. It is used for data latching during peripheral read operations. 
     DMA --  endOP (DMA end of operations): This signal is driven by the DMAC to indicate to the SBC&#39;s the last active clock of a DMA transfer. It is used for data hold times during a DMA peripheral write operation. 
     While several embodiments of the invention have been described and illustrated in detail, it will be obvious to those skilled in this art that modifications and variations can be made without departing from the scope of the invention as set forth in the claims.