Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
5142672
Johnson , ; et al.
August 25, 1992
Title
Data transfer controller incorporating direct memory access channels and address mapped input/output windows
Abstract
Methods and apparatus are disclosed for transferring data to and from a first bus, to which a first set of high performance devices, including at least one central processing unit ("CPU") is attached, and a second bus, to which a second set of relatively lower performance devices is attached. More particularly the invention accomplishes the above transfer function in a manner that facilitates communication between the first and second set of devices from the compartively lower performance of the second set of devices. According to the preferred embodiment of the invention, a data transfer controller i.e., ("DTC") is disclosed that includes a set of direct memory access ("DMA") channels and an input/output controller comprising a set of address mapped I/O ports. Both the DMA channels and I/O ports may be used to transfer data between the high performance channel (hereinafter referred to as the "Local Bus") coupled to the CPU in a reduced instruction set computer (RISC) system and a typically lower performance, peripheral bus (hereinafter referred to as a "Remote Bus"). The resulting DTC interface between the Local Bus and a Remote Bus permits a wide performance range of standard peripheral devices to be attached to the RISC system in a manner that does not limit system performance.
Inventors:
Johnson; William M.
(San Jose,
CA
)
, Olson; Timothy A.
(Sunnyvale,
CA
)
, Dutton; Drew J.
(Santa Monica,
CA
)
, Lee; Sherman
(Palos Verdes Estates,
CA
)
, Stoenner; David W.
(El Toro,
CA
)
Assignee:
Advanced Micro Devices, Inc.
(Sunnyvale,
CA
)
Appl. No.:
132296
Filed:
December 15, 1987
Current U.S. Class:
710/27
Field of Search:
364/2MS,9MS 395/275,325,425
U.S. Patent Documents
3940743
February 1976
Fitzgerald
4309754
January 1982
Dinwiddie, Jr.
4313160
January 1982
Kaufman et al.
4568930
February 1986
Livingston et al.
4821185
April 1989
Esposito
4847750
July 1989
Daniel
4851990
September 1989
Johnson et al.
4947366
August 1990
Johnson
Foreign Patent Documents
0079140
May., 1983
EP
0204960
Dec., 1986
EP
Other References
8167 Computer Design, vol. 21, Feb. 1982, No. 2, pp. 121-126 "Dual-Bus Design For A Microcomputer", Robert A. Garrow. .
2119 E. D. N. Electrical Design News, vol. 27, Mar. 1982, No. 5, pp. 117-125 "Eliminate System Growth Pains With A .mu.P/Controller Interface" by D. L. Ruhberg and M. C . Wood. .
Nachrichtentechnik Elektronick--29 (1976) H., vol. 25, pp. 229-232, "Mehrmikrorechnersysteme mit Registerkopplung" by W. Cimande and A. Tschelebiev..~
Primary Examiner:
Chan; Eddie P.
Assistant Examiner:
Kulik; Paul
Attorney, Agent or Firm:
Lowe, Price, LeBlanc & Becker
Claims
What is claimed is:
1. A data transfer controller for transferring data to and from a first bus, to which a first set of high performance devices, including at least one central processing unit ("CPU"), is attached, and a second bus to which a second set of relatively lower performance devices is attached, wherein the transferring of data to and from said first and second buses facilitates communication between said first and second set of devices while isolating said first set of devices from said relatively lower performing second set of devices comprising:
(a) direct memory access means, coupled to said first bus and to said second bus, including at least one direct memory access channel means, for channelling direct memory access transfers from said first bus to said second bus and from said second bus to said first bus;
(b) input/output controller means, coupled to said first bus and to said second bus, including at least one address mapped input/output port means, for providing direct access to said second set of devices by said CPU;
(c) means for interconnecting said first bus to said direct memory access means and to said input/output controller means; and
(d) means for interconnecting said second bus to said direct memory access means and said input/output controller means wherein said means for interconnecting said second bus to said access means and said controller means further comprises:
(e) packing and funneling network means, coupled to both said access means and said controller means, for accommodating variable width data transfers between said first bus and said second bus; and
(f) transfer means, including multiplexing means, coupled between said packing and funneling network means, said access means, said controller means and to said second bus, for multiplexing address and data signals being transferred to said second bus.
2. A data transfer controller as set forth in claim 1 wherein said transfer means includes a transceiver, coupled between said multiplexing means and said second bus, for transmitting and receiving signals being transferred to and from said second bus.
3. A data transfer controller as set forth in claim 2 further comprising means for prioritizing access to said port means and said channel means.
4. A data transfer controller as set forth in claim 3 further comprising means for prioritizing access to said port means whenever a plurality of port means exists.
5. A data transfer controller as set forth in claim 3 further comprising means for prioritizing access to said channel means whenever a plurality of channel means exists.
6. A data transfer controller as set forth in claim 1 further comprising means for checking parity for both data and address transfers.
7. A data transfer controller as set forth in claim 1 including a plurality of sets of internal registers wherein said plurality of sets of registers comprises:
(a) a set of internal registers for controlling and maintaining a status of global operation of the data transfer controller;
(b) a set of internal registers for controlling and maintaining a status of said channel means;
(c) a set of internal registers for controlling and maintaining a status of said port means; and
(d) a set of internal registers for buffering data transfers via said channel means.
8. A data transfer controller as set forth in claim 7 wherein said means for interconnecting said first bus to said access means and said controller means further comprises means for initializing said plurality of sets of registers.
9. A data transfer controller as set forth in claim 1 further comprising means for separating operation of said access means from program execution by said CPU.
10. A data transfer controller as set forth in claim 1 wherein said access means is programmable.
11. A data transfer controller as set forth in claim 10 wherein said access means is programmed during initialization by said CPU to determine data transfer addresses independent of the CPU during operation of the data transfer controller.
12. A data transfer controller as set forth in claim 1 wherein said access means further comprises means for performing nonsequential transfers.
13. A data transfer controller as set forth in claim 1 said access means further comprises:
(a) queue means for buffering data being transferred between said first bus and said second bus; and
(b) programmable internal register means for controlling the operation of said queue means.
14. A data transfer controller as set forth in claim 13 wherein each of said at least one channel means further comprises:
(a) first multiplexing means for selectively transferring word length data input to said access means from said first bus and for selectively transferring packed data, input to said access means from said packing and funneling network means, into said queue means;
(b) first packing/funneling register means, coupled to said first multiplexing means and said packing and funneling network means, for storing data during packing and funneling operations; and
(c) second multiplexing means for selectively transferring data output from said queue means, to be funneled to said packing and funneling network means via said first register means, and for selectively transferring packed data input from said packing and funneling network to said first multiplexing means via said first register means.
15. A data transfer controller as set forth in claim 13 wherein the data buffered in said queue means may be directly manipulated by said CPU to avoid a latency associated with data transfers between said first bus and said queue means.
16. A data transfer controller as set forth in claim 1 wherein said access means further comprises transfer rate control means in a path between said first bus and said second bus.
17. A data transfer controller as set forth in claim 1 further comprising means for performing bus sizing.
18. A data transfer controller as set forth in claim 1 further comprising means for overlapping port means operation with the operation of said set of devices attached to said first bus.
19. A data transfer controller as set forth in claim 1 further comprising means for overlapping channel means operation with the operation of said set of devices attached to said first bus.
20. A data transfer controller as set forth in claim 1 further comprising means for performing data packing and unpacking.
21. A data transfer controller as set forth in claim 1 further comprising means for providing separating operation of port means within said controller means from program execution by said CPU.
22. A data transfer controller as set forth in claim 21 wherein said separate operation is accomplished via means for performing overlapped input/output via implementation of read ahead and write behind operation.
23. A data transfer controller as set forth in claim 1 further comprising means for determining if a first bus address input to said port means is within a preselected port means address space.
24. A data transfer controller as set forth in claim 23 wherein each of at least one input/output port means further comprises means for performing address translation between a first bus address input to the port means and a second bus address to be output from the port means, whenever the port means is being addressed by said first bus.
25. A data transfer controller as set forth in claim 24 wherein said address translation is performed over a power of two range of addresses of said first bus to an independent range of addresses of said second bus.
26. A data transfer controller as set forth in claim 25 wherein said means for performing said address translation further comprises means for masking out a preselected number of high order bits from the first bus address and replacing said bits with the same number of high order bits of a second bus address.
27. A data transfer controller as set forth in claim 23 wherein each of said at least one port means further comprises means for multiplexing data to and from said packing and funneling network means.
28. A data transfer controller as set forth in claim 22 wherein each of said port means further comprises a pack/funnel register for buffering data being transferred to and from said packing and funneling network means by said port means.
29. A data transfer controller as set forth in claim 28 wherein said means for performing overlapped input/output further comprises:
(a) means for determining if a given port means is enabled to perform a read ahead/write behind operation instead of direct read/write operation; and
(b) means for immediately responding to an access by said first bus whenever a read ahead/write behind operation is enabled even though an access by said second bus may be in progress.
30. A data transfer controller as set forth in claim 29 wherein said means for responding further comprises:
(a) means for latching the address of said first bus access;
(b) means for determining if said access is a read;
(c) means for performing said read, independent of any access on said second bus, whenever it is determined that said access is a read.
31. A data transfer controller as set forth in claim 30 further comprising means for performing a write, independent of any access on said second bus, whenever it is determined that said access is not a read.
32. A data transfer controller as set forth in claim 31 wherein said means for performing said read further comprises:
(a) means, coupled to said first bus, for immediately transferring the contents of said pack/funnel register to said first bus whenever a given port means is accessed by a first bus read;
(b) means, coupled to said first bus, for buffering an untranslated input address of the first bus access;
(c) means, coupled to said means for buffering untranslated addresses, for translating said input address; and
(d) means, coupled to said second bus, for performing a second bus read using said translated address and for storing the data read off said second bus in said pack/funnel register.
33. A data transfer controller as set forth in claim 32 further comprising means, coupled to said pack/funnel register, for obtaining packed data from said packing and funneling network means for storage in said pack/funnel register.
34. A data transfer controller as set forth in claim 33 further comprising means for inhibiting a subsequent access to a given port means via said first bus while said port means performs a read ahead/write behind operation.
35. A data transfer controller as set forth in claim 31 wherein said means for performing said write further comprises:
(a) means, coupled to said first bus, for storing data being transferred from said first bus to said second bus, via said port means, in said pack/funnel register whenever said port means is accessed by a first bus write;
(b) means, coupled to said first bus, for buffering an untranslated input address of the first bus access;
(c) means, coupled to said means for buffering untranslated addresses, for translating said input address; and
(d) means, coupled to said second bus, for performing a second bus write using said translated address and the data stored in said pack/funnel register.
36. A data transfer controller as set forth in claim 35 further comprising means, coupled to said pack/funnel register, enabling data to be funneled from said pack/funnel register to said second bus via said packing and funneling network means.
37. A data transfer controller as set forth in claim 36 further comprising means for inhibiting a subsequent access to a given port means via said first bus while said port means performs a read ahead/write behind operation.
38. A data transfer controller as set forth in claim 22 further comprising means for performing said read ahead and write behind operations in parallel wherein a first one of said port means is utilized to perform said read ahead function while a second one of said port means is used to perform the write behind function in parallel.
39. A data transfer controller as set forth in claim 1 wherein said packing and funneling network means further comprises:
(a) means for packing data on a transfer from said second bus to said first bus, including means for coverting a number of byte and half word transfers on said second bus to a smaller number of half words and word transfers on said first bus; and
(b) means for buffering data being packed, by said means for packing, in order to facilitate full word transfers of packed data to said first bus.
40. A data transfer controller as set forth in claim 1 said packing and funneling network means further comprises:
(a) means for funneling data on a transfer from said first bus to said second bus, including means for converting a number of word and half word transfers on said first bus to a larger number of half word and byte transfers on said second bus; and
(b) means for buffering data being funneled, by said means for funneling, in order to enable said means for funneling to extract half words and bytes of buffered data one at a time for transfer to said second bus.
41. A data transfer controller as set forth in claim 1 further comprising means for providing separate latency and bandwidth of accesses on said first bus from latency and bandwidth of accesses on said second bus, with concurrency between accesses on both buses.
42. A data transfer controller as set forth in claim 1 including means for configuring said access means to support block and pattern transfers between said first and second buses.
43. A data transfer controller as set forth in claim 1 configured for transferring data between two synchronous buses.
44. A data transfer controller as set forth in claim 1 configured for transferring data between two asynchronous buses.
45. A data transfer controller as set forth in claim 1 wherein said controller operates in a test mode of operation which allows the controller outputs to be driven for diagnostic purposes.
46. A data transfer controller for transferring data to and from a first bus, to which a first set of high performance devices, including at least one central processing unit ("CPU"), is attached, and a second bus to which a second set of relatively lower performance devices is attached, wherein the transferring of data to and from said first and second buses facilitates communication between said first and second set of devices while isolating said first set of devices from said relatively lower performing second set of devices comprising:
(a) direct memory access means, coupled to said first bus and to said second bus, including at least one direct memory access channel means, for channelling direct memory access transfers from said first bus to said second bus and from said second bus to said first bus;
(b) input/output controller means, coupled to said first bus and to said second bus, including at least one address mapped input/output port means, for providing direct access to said second set of devices by said CPU;
(c) means for interconnecting said first bus to said direct memory access means and to said input/output controller means; and
(d) means for interconnecting said second bus to said direct memory access means and said input/output controller means, further comprising:
means for swapping locations of data packets within words being transferred via the controller.
47. A data transfer controller as set forth in claim 46 further comprising means for decoupling the latency and band-width of accesses on said first bus from the latency and bandwidth of accesses on said second bus, with concurrency between accesses on both buses.
48. A data transfer controller as set forth in claim 46 including means for configuring said access means to support block and pattern transfers between said first and second buses.
49. A data transfer controller as set forth in claim 46 configured for transferring data between two synchronous buses.
50. A data transfer controller as set forth in claim 46 configured for transferring data between two asynchronous buses.
51. A data transfer controller as set forth in claim 46 wherein said controller operates in a test mode of operation which allows the controller outputs to be driven for diagnostic purposes.
52. A data transfer controller for transferring data to and from a first bus, to which a first set of high performance devices, including at least one central processing unit *"CPU"), is attached, and a second bus to which a second set of relatively lower performance devices is attached, wherein the transferring of data to and from said first and second buses facilitates communication between said first and second set of devices while isolating said first set of devices rom said relatively lower performing second set of devices comprising:
(a) direct memory access means, coupled to said first bus and to said second bus, including at least one direct memory access channel means, for channelling direct memory access transfers from said first bus to said second bus and from said second bus to said first bus;
(b) input/output controller means, coupled to said first bus and to said second bus, including at least one address mapped input/output port means, for providing direct access to said second set of devices by said CPU;
(c) means for interconnecting said first bus to said direct memory access means and to said input/output controller means; and
(d) means for interconnecting said second bus to said direct memory access means and said input/output controller means; and
(e) a plurality of sets of internal registers wherein said plurality of sets of registers comprises:
(i) a set of internal registers for controlling and maintaining a status of the global operation of the data transfer controller;
(ii) a set of internal registers for controlling and maintaining a status of said channel means;
(iii) a set of internal registers for controlling and maintaining a status of said port means; and
(iv) a set of internal registers for buffering data transfers via said channel means;
wherein said means for interconnecting said first bus to said access means and said controller mans further comprises means for initializing said plurality of sets of registers; and
further comprising a plurality of signal paths used for carrying CPU and device generated signals to and from said plurality of sets of internal registers, which serve to initialize and control data transfer operations.
53. A data transfer controller as set forth in claim 52 wherein said plurality of signal paths comprise the pins of an integrated circuit package.
54. A data transfer controller for transferring data to and from a first bus, to which a first set of high performance devices, including at least one central processing unit ("CPU"), is attached, and a second bus to which a second set of relatively lower performance devices is attached, wherein the transferring of data to and from said first and second buses facilitates communication between said first and second set of devices while isolating said first set of devices from said relatively lower performing second set of devices comprising:
(a) direct memory access means, coupled to said first bus and to said second bus, including at least one direct memory access channel means, for channelling direct memory access transfers from said first bus to said second bus and from said second bus to said first bus;
(b) input/output controller means, coupled to said first bus and to said second bus, including at least one address mapped input/output port means, for providing direct access to said second set of devices by said CPU;
(c) means for interconnecting said first bus to said direct memory access means and to said input/output controller means; and
(d) means for interconnecting said second bus to said direct memory access means and said input/output controller means wherein said controller operates in parallel with at least one data transfer controller, to which it is connected, in a master/slave relationship.
55. A method for transferring data to and from a first bus, to which a first set of high performance devices, including at least one central processing unit ("CPU"), is attached, and a second bus to which a second set of relatively lower performance devices is attached, comprising the steps of:
(a) transferring data between said first bus and said second bus utilizing direct memory access means, including at least one direct memory access channel means, coupled to said buses;
(b) isolating, via said channel means, said first set of devices from the comparatively lower performing second set of devices when transferring data between said first and second bus via said access means;
(c) transferring data between said first and said second bus utilizing input/output controller means, including at least one address mapped input/output port means, coupled to said buses;
(d) isolating, via said port means, said first set of devices from the comparatively lower performing second set of devices when transferring data between said first and second bus via said controller means; and
(e) multiplexing address signals being transferred to said second bus by said access means and said controller means, together with data signals being transferred to said second bus.
56. A method as set forth in claim 55 further comprising the step of packing data being transferred from said second bus to said first bus to accommodate variable width data transfers.
57. A method as set forth in claim 56 further comprising the step of funneling data being transferred from said first bus to said second bus to accommodate variable width data transfers.
58. A method as set forth in claim 55 further comprising the step of prioritizing access to said port means and said channel means.
59. A method as set forth in claim 58 further comprising the step of prioritizing access to said port means whenever a plurality of port means exists.
60. A method as set forth in claim 58 further comprising the step of prioritizing access to said channel means whenever a plurality of channel means exists.
61. A method as set forth in claim 55 further comprising the step of checking parity for both data and address transfers.
62. A method as set forth in claim 55 further comprising the step of initializing a plurality of sets of registers used for controlling said controller means and said channel means.
63. A method as set forth in claim 55 wherein said set of isolating when transferring via said access means further comprises the step of separating operation of said access means from program execution by said CPU.
64. A method as set forth in claim 55 wherein said step of isolating via said access means further comprises the step of programming said access means to determine data transfer addresses independent of the CPU operation.
65. A method as set forth in claim 55 wherein said step of transferring via said access means is performed non-sequentially.
66. A method as set forth in claim 55 wherein the step of isolating via said channel means further comprises the step of controlling the transfer rate between said first bus and said second bus.
67. A method as set forth in claim 55 further comprises the step of performing bus sizing.
68. A method as set forth in claim 55 wherein said step of isolating via said port means further comprises the step of overlapping port means operation with the operation of said set of devices attached to said first bus.
69. A method as set forth in claim 55 wherein said step of isolating via said channel means further comprises the step of overlapping channel means operation with the operation of said set of devices attached to said first bus.
70. A method as set forth in claim 55 wherein the step of isolating via said port means further comprises the step of separating operation of said port means within said controller means from program execution by said CPU.
71. A method as set forth in claim 55 further comprising the step of determining if a first bus address input to said port means is within a preselected port means address space.
72. A method as set forth in claim 71 further comprising the step of translating a first bus address input to a port means to a second bus address to be output from the port means, whenever the port means is being addressed by said first bus.
73. A method as set forth in claim 55 further comprising the steps of:
(a) packing data on a transfer from said second bus wherein said step of packing further includes the step of converting a number of byte and half word transfers on said second bus to a smaller number of half words and word transfers on said first bus; and
(b) buffering data being packed in order to facilitate full word transfers of packed data to said first bus.
74. A method as set forth in claim 55 further comprising the step of funneling data on a transfer from said first bus to said second bus wherein said step of funneling further includes the step of converting a number of word and half word transfers on said first bus to a larger number of half word and byte transfers on said second bus.
75. A method as set forth in claim 74 wherein said step of converting further comprises the steps of:
(a) buffering data being funneled; and
(b) extracting half words and bytes of buffered data, one at a time, for transfer to said second bus.
76. A method as set forth in claim 55 further comprising the step of providing separate latency and bandwidth of accesses on said first bus from latency and bandwidth of accesses on said second bus, with concurrency between accesses on both buses.
77. A method for transferring data to and from a first bus, to which a first set of high performance devices, including at least one central processing unit ("CPU"), is attached, and a second bus to which a second set of relatively lower performance devices is attached, comprising the steps of:
(a) transferring data between said first bus and said second bus utilizing direct memory access means, including at least one direct memory access channel means, coupled to said buses;
(b) isolating, via said channel means, said first set of devices from the comparatively lower performing second set of devices when transferring data between said first and second bus via said access means;
(c) transferring data between said first and said second bus utilizing input/output controller means, including at least one address mapped input/output port means, coupled to said buses;
(d) isolating, via said port means, said first set of devices from the comparatively lower performing second set of devices when transferring data between said first and second bus via said controller means; and
(e) packing data being transferred from said second bus to said first bus to accommodate variable width data transfers; and
(f) funneling data being transferred from said first bus to said second bus to accommodate variable width data transfers;
wherein said step of isolating via said channel mans further comprises the step of buffering data being transferred between said first bus and said second bus, into queue means, under the control of programmed register means.
78. A method as set forth in claim 77 wherein the step of isolating via said channel means further comprises the step of multiplexing word length data input to said access means from said first bus with packed word length data being transferred via said access means from said second bus, for buffering in said queue means.
79. A method as set forth in claim 77 wherein the data buffered in said queue means may be directly manipulated by said CPU to avoid a latency associated with data transfers between said first bus and said queue means.
80. A method for transferring data to and from a first bus, to which a first set of high performance devices, including at least one central processing unit ("CPU"), is attached, and a second bus to which a second set of relatively lower performance devices is attached, comprising the steps of:
(a) transferring data between said first bus and said second bus utilizing direct memory access means, including at least one direct memory access channel means, coupled to said buses;
(b) isolating, via said channel means, said first set of devices from the comparatively lower performing second set of devices when transferring data between said first and second bus via said access means;
(c) transferring data between said first and said second bus utilizing input/output controller means, including at least one address mapped input/output port means, coupled to said buses;
(d) isolating, via said port means, said first set of devices from the comparatively lower performing second set of devices when transferring data between said first and second bus via said controller means; an
wherein the step of isolating via said port means further comprises the step of separating operation of said port means within said controller means from program execution by said CPU, and said separating is accomplished via performing overlapped input/output through the implementation of read ahead and write behind operations.
81. A method as set forth in claim 80 wherein said step of separating further comprises the step of buffering data being transferred by said port means to and from said second bus.
82. A method as set forth in claim 81 wherein said step of performing overlapped input/output further comprises the steps of:
(a) determining if a given port means is enabled to perform a read ahead/write behind operation instead of direct read/write operation; and
(b) responding immediately to an access by said first bus whenever a read ahead/write behind operation is enabled even though an access by said second bus may be in progress.
83. A method as set forth in claim 82 wherein said step of responding further comprises the steps of:
(a) latching the address of said first bus access;
(b) determining if said access is a read; and
(c) performing said read, independent of any access on said second bus, whenever it is determined that said access is a read.
84. A method as set forth in claim 83 further comprising the step of performing a write, independent of any access on said second bus, whenever it is determined that said access is not a read.
85. A method as set forth in claim 84 wherein said step of performing said read further comprises the steps of:
(a) transferring packed data, stored in said port means, to said first bus whenever a given port means is accessed by a first bus read;
(b) buffering an untranslated input address of the first bus access;
(c) translating said input address to a corresponding second bus address;
(d) reading data off said second bus using said translated address; and
(e) storing data read off said second bus in said port means.
86. A method as set forth in claim 85 further comprising the step of inhibiting a subsequent access to a given port via said first bus while said port performs a read ahead/write behind operation.
87. A method as set forth in claim 84 wherein said step of performing said write further comprises the steps of:
(a) storing data being transferred from said first bus to said second bus, via said port means, in said port means whenever said port means is accessed by a first bus write;
(b) buffering an untranslated input address of the first bus access;
(c) translating said input address to a corresponding second bus address; and
(d) performing a second bus write using said translated address and the data stored in said port means.
88. A method as set forth in claim 87 further comprising the step of funneling data from said port means to said second bus via a packing and funneling network means.
89. A method as set forth in claim 88 further comprising the step of inhibiting a subsequent access to a given port via said first bus while said port performs a read ahead/write behind operation.
90. A method as set forth in claim 80 further comprising the step of performing said read ahead and write behind operations in parallel where a first one of said port means is utilized to perform said read ahead function while a second one of said port means is used to perform the write behind function in parallel.
91. A method for transferring data to and from a fist bus, to which a first set of high performance devices, including at least one central processing unit ("CPU"), is attached, and a second bus to which a second set of relatively lower performance devices is attached, comprising the steps of:
(a) transferring data between said first bus and said second bus utilizing direct memory access means, including at least one direct memory access channel means, coupled to said buses;
(b) isolating, via said channel means, said first set of devices from the comparatively lower performing second set of devices when transferring data between said first and second bus via said access means;
(c) transferring data between said first and said second bus utilizing input/output controller means, including at least one address mapped input/output port means, coupled to said buses;
(d) isolating, via said port means, said first set of devices from the comparatively lower performing second set of devices when transferring data between said first and second bus via said controller means;
(e) determining if a first bus address input to said port means is within a preselected port means address space; and
(f) translating a first bus address input to a port means to a second bus address to be output from the port means, whenever the port means is being addressed by said first bus;
wherein said step of translating is performed by masking out a preselected number of high order bits from the first bus address and replacing said bits with the same number of high order bits of a second bus address.
Description
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates generally to methods and apparatus used for transferring data to and from a first bus, to which a first set of high performance devices, including a central processor ("CPU") is attached, and a second bus, to which a second set of relatively lower performance devices is attached, in a manner that does not limit the CPU's performance. The invention more particularly relates to a novel data transfer controller ("DTC"), or set of DTC's, suitable for performing the aforesaid data transfer function between a high performance channel, hereinafter referred to as the "Local Bus", to which a CPU constituting a part of a reduced instruction set computer (RISC) system is attached, and one or more, typically lower performance, peripheral buses, each hereinafter referred to as a "Remote Bus".
2. Description of the Related Art
Methods and apparatus for achieving a high performance system interface between a RISC processor and a set of devices, including memory means internal to the RISC system, are described in copending application Ser. No. 012,226, filed Feb. 19,
1987, now U.S. Pat. No. 4,851,900, assigned to Advanced Micro Devices, Inc. This copending application is hereby incorporated by reference. The novel system interface taught in the copending application includes, according to its preferred embodiment, two 32 bit wide buses referred to as the "Address Bus" and "Data Bus". For the purpose of this application these two buses collectively correspond to the Local Bus.
In order to permit a RISC system to utilize and access a wide array of commercially available peripheral devices that typically operate at lower speeds than a RISC processor, the Local Bus needs to be coupled in some manner to a Remote Bus to which one or more of said peripheral devices are connected. The Remote Bus could also be a complete I/O subsystem with its own processor.
Currently, no devices or methods are known which interconnect and permit data transfers between buses having different performance characteristics (like the aforesaid Local Bus and Remote Bus), while at the same time not appreciably having an affect on the performance of the devices attached to the buses. In addressing this problem it would be a particularly desirable feature to insulate the performance of any high speed processor, e.g., a RISC processor attached to the Local Bus, from the comparatively lower performance of peripherals and/or any I/O subsystem connected to the Remote Bus. Ideally, the bandwidth and latency of accesses on the Local Bus needs to be decoupled from the bandwidth and latency of accesses on the Remote Bus, with concurrency between accesses on both buses.
Another problem to be solved is to provide methods and apparatus which allow I/O port and direct memory access ("DMA") operations to overlap with (i.e., operate in parallel with) devices attached to the Local Bus. Such a parallelism feature would further enhance the performance of the overall system of which the DTC forms a part and more particularly, in a RISC system, would free the RISC processor from having to wait for I/O completion.
I/O controller functions and DMA functions in and of themselves are well known in the prior art. However no combination of these functions are performed by any known methods or apparatus which, (1) interconnect and buffer a high performance RISC system Local Bus and a Remote Bus of the type described hereinbefore; (2) solve the aforementioned problem of interconnecting buses having different performance characteristics and (3) provide the parallelism referred to hereinbefore.
Furthermore, no DMA channel by itself is known which supports a bus to bus interface of the type described hereinabove, i.e., a DMA channel which accounts for differing bus characteristics and parallelism versus a DMA channel that only performs straight address sequencing.
Finally, although systems, such as the IBM 370 (a large main frame computer) are known that include a channel controller network with direct memory access features, no prior art is known at the microprocessor level, in particular in combination with a RISC processing system, that provides both DMA and I/O controller functions on a single chip. Such features would be a desirable adjunct to RISC processing systems which themselves are currently being fabricated at the chip level.
SUMMARY OF THE INVENTION
According to the invention, methods and apparatus are disclosed for transferring data to and from a first bus, to which a first set of high performance devices, including at least one central processing unit ("CPU") is attached, and a second bus, to which a second set of relatively lower performance devices is attached. More particularly the invention accomplishes the aforesaid transfer function in a manner that facilitates communication between the first and second set of devices while insulating the performance of the first set of devices from the comparatively lower performance of the second set of devices.
According to the preferred embodiment of the invention, a data transfer controller i.e., ("DTC") is disclosed that includes a set of direct memory access ("DMA") channels and an input/output controller comprising a set of address mapped I/O ports. Both the DMA channels and I/O ports may be used to transfer data between the high performance channel (hereinafter referred to as the "Local Bus") coupled to the CPU in a reduced instruction set computer (RISC) system and a typically lower performance peripheral bus (hereinafter referred to as a "Remote Bus"). The resulting DTC interface between the Local Bus and a Remote Bus permits a wide performance range of standard peripheral devices to be attached to the RISC system in a manner that does not limit system performance.
It is an object of the invention to provide methods and apparatus that interconnect and permit data transfers between buses having different performance characteristics (like the aforesaid Local Bus and Remote Bus), while at the same time not appreciably having an affect on the performance of the devices attached to the buses.
It is a further object of the invention to provide methods and apparatus which permit a RISC system to utilize and access a wide array of commercially available peripheral devices that typically operate at lower speeds than a RISC processor.
It is still a further object of the invention to insulate the performance of any high speed processor, e.g., a RISC processor attached to a Local Bus, from the comparatively lower performance of peripherals and/or any I/O subsystem connected to a Remote Bus in a manner in which the bandwidth and latency of accesses on the Local Bus may be decoupled from the bandwidth and latency of accesses on the Remote Bus, with concurrency between accesses on both buses.
Further yet, it is an object of the invention to provide methods and apparatus which allow I/O port and DMA operations to overlap with (i.e., operate in parallel with) devices attached to the Local Bus in order to enhance overall system performance.
The preferred embodiment of the invention meets the aforesaid objects in the context of a RISC processing environment, with both the RISC processor and DTC being fabricated at the chip level.
The invention features a reduction in the amount of hardware required to connect peripherals on the Remote Bus to the Local Bus. Additional features of the invention include the flexibility to perform bus sizing, data packing and unpacking, and conversions between byte and half-word data packed into words.
These and other objects and features of the invention will become apparent to those skilled in the art upon consideration of the following detailed description and the accompanying Drawing, in which like reference designations represent like features throughout the figures.
BRIEF DESCRIPTION OF THE DRAWING
FIG. 1 depicts the novel DTC interfacing, in accordance with the preferred embodiment of the invention, with a RISC system via a Local Bus, and interfacing with a Remote Bus to which a set of peripherals, I/O subsystem, etc. may be attached.
FIG. 2 depicts a pin-out diagram for an integrated circuit package that houses the novel DTC and facilitates its interconnection, in accordance with the preferred embodiment of the invention, to both a RISC system via a Local Bus and to a set of peripherals via a Remote Bus.
FIG. 3 is a functional block diagram of a DTC, built in accordance with the teachings of the invention, having 4 I/O ports and 4 DMA channels.
FIG. 4 depicts the established conventions for the location of bytes and half-words within half-words and words, which are supported by the novel DTC taught herein.
FIG. 5 illustrates the swapping of bytes within half-words and words when the DTC is used to convert between the addressing conventions depicted in FIG. 4.
FIG. 6 is a block diagram illustrating I/O port data flow for one I/O port.
FIG. 7 is a flow chart illustrating how the DTC supports overlapped I/O.
FIG. 8 is a block diagram illustrating DMA channel data flow for one DMA channel.
FIG. 9 illustrates empty, partially full and full DMA queues.
FIG. 10 is an example of how commercially available devices may be used to interconnect the novel DTC to the Remote Bus.
FIG. 11 illustrates data location for Local Bus data transfers, on D0-D31, both to and from the novel DTC.
FIG. 12 illustrates data location for Remote Bus data transfers, on RAD0-RAD31, both to and from the novel DTC.
DETAILED DESCRIPTION
According to the preferred embodiment of the invention, the DTC implements four address-mapped input/output ports on the Local Bus. These ports provide a gateway from the Local Bus to the Remote Bus, so that a processor attached to the Local Bus can directly access devices and memories on the Remote Bus.
Each I/O port, according to the preferred embodiment of the invention, is a power-of-two number of bytes in size, and can begin on any corresponding power-of-two address boundary on the Local Bus. The ports can appear on the Local Bus in either the data-memory address space or the I/O address space. These address spaces are defined in the incorporated copending application. The ports are address-mapped, so that addressing on the Local Bus is independent of addressing on the Remote Bus. Optional read-ahead and write-behind features on these ports allow Remote-Bus accesses to be overlapped with Local-Bus accesses. These features will be described in detail hereinafter.
The DTC also implements four buffered DMA channels, supporting DMA transfers from the Remote Bus to the Local Bus, and from the Local Bus to the Remote Bus. For DMA accesses, data, according to the preferred embodiment of the invention, is buffered in one of four 64-word queues. There is one queue per DMA channel.
The DMA queues reduce the overhead of DMA transfers on the Local Bus, by allowing the transfers of large amounts of data for each Local-Bus acquisition. This is particularly effective if the burst-mode capability, as described in the incorporated copending application, of the Local Bus is used. The queues may be manipulated directly by software executing on, for example, the RISC processor.
As indicated hereinabove, FIG. 1 depicts, in block diagram form, the DTC interconnecting a Local Bus of a RISC system with a Remote Bus.
More particularly, the DTC, unit 104, is shown interconnected to 32 bit Address Bus 111 and 32 bit Data Bus 112 via links 111a and 112a respectively.
It should be noted that the Local Bus referred to herein and shown as Local Bus 110 in FIG. 1, is comprised of Address Bus 111 and Data Bus 112.
RISC processor 101, Program Store 102, Data Memory 103, the interconnections between these devices i.e., 111b, 111c, 111d and 112b, Address Bus 111 and Data Bus 112, are all described in detail in the incorporated copending application. The novel DTC will be described herein in the context of the RISC system set forth in the copending application for the sake of illustration only. One of ordinary skill in the art will readilly appreciate how the DTC may be adapted to provide an interface for devices having different performance characteristics without departing from the spirit and scope of the invention described herein.
Not shown in copending application Ser. No. 012,226 are DTC 104 and interface unit 105. Interface unit 105 may, but is not required to, be used to interconnect DTC 104 to Remote Bus 120. Both units 104 and 105 will be described in detail hereinafter.
According to the preferred embodiment of the invention, DTC 104 is implemented in 1.2 micron CMOS technology, and is packaged in a 169-terminal pin-grid-array (PGA) package, using 148 signal pins, 20 power and ground pins, and one alignment pin.
FIG. 2 depicts a pin-out diagram for DTC 104. Integrated circuit package 204 of FIG. 2 houses the novel DTC and facilitates its interconnection, in accordance with the preferred embodiment of the invention, to both the RISC system, depicted in FIG. 1, via Local Bus 110, and to a set of peripherals via Remote Bus 120. The Local Bus connections to and from the DTC are shown on the left hand side of dotted line A--A in FIG. 2, and the Remote Bus connections to and from the DTC are shown on the right hand side of dotted line A--A in FIG. 2.
Before proceeding with the description of how the interface may be utilized, a set of DTC input and output signals has, in accordance with the preferred embodiment of the invention, been defined to facilitate the communication of both substantive and control information between DTC 104 and the devices connected to it via Buses 110 and 120. These signals are in one to one correspondence with the pins shown in the pin-out block depicted in FIG. 2.
A description of the signals input to and output from DTC 104 via the integrated circuit depicted in FIG. 2, along with the description of how the DTC may be utilized to support communications between Local Bus 110 and Remote Bus 120 (to be described in detail hereinafter), will illustrate the DTC's operability and utility. One of ordinary skill in the art will readily appreciate that the same teaching of how to use and control the DTC as an interface between a RISC Processor attached to Bus 110 and devices attached to Bus 120, may be extended to teach how to use and control the DTC to facilitate communication between sets of devices having different performance characteristics, attached to buses which are interconnected via the DTC.
For the sake of illustration and consistency with the incorporated copending application, a 32 bit instruction and data word architecture for the RISC system is assumed. One of ordinary skill in the art will appreciate that the illustrative embodiment in no way limits the implementation or scope of the invention with respect to computer systems having different word lengths.
Reference should now be made to FIG. 2 which depicts each input and output, to and from DTC 104 of the preferred embodiment of the invention, in the pin-out block form.
Focusing on the Local Bus inputs and outputs first, (left hand side of FIG. 2) Address Bus 111 and Data Bus 112 of FIG. 1 are depicted interconnected to block 104 of FIG. 2 via a 64 pin bus interconnect comprised of two sets of 32 pins each. The first set of 32 pins serves to interconnect bus 111 of FIG. 1 to DTC 104 and is labeled "A0-A31" in FIG. 2. The second set of 32 pins, for the separate and independent data bus, bus 112 of FIG. 1, is labeled "D0-D31" in FIG. 2 .
Before proceeding with the FIG. 2 pin description, it should be noted that the term "three state" is used hereinafter to describe signals which may be placed in the high-impedance state during normal operation. All outputs (except MSERR) may be placed in the high impedance state by the *TEST input. Both MSERR and *TEST will be described hereinafter with reference to the FIG. 2 pin description.
Returning to the description of the Local Bus signals, it should be noted that all Local-Bus signals are synchronous to SYSCLK. SYSCLK is described in the incorporated copending application.
The A0-A31 (Address Bus) pins are bidirectional, synchronous and three state. The Address Bus transfers the byte address for all Local-Bus accesses except burst-mode accesses. For burst-mode accesses, it transfers the address for the first access in the sequence.
The D0-D31 (Data Bus) pins are bidirectional, synchronous and three state. The Data Bus transfers data to and from DTC 104 on the DTC's Local Bus side.
All of the other pins and signals on the Local Bus side of line A--A of FIG. 2 are, with the exception of *CSEL, DP0-DP3 and *INTR, described in the incorporated copending application. However, for the sake of clarity and completeness, a review of the purpose of each of these pins and signals in the context of DTC 104 will now be set forth in addition to the description of the pins and signals not described elsewhere. All the pin and signal descriptions to follow are in accordance with the preferred embodiment of the invention.
SYSCLK (System Clock) is an input to DTC 104. The input is a clock signal operating at the frequency of the Local Bus. DTC 104 uses this signal to synchronize all Local-Bus accesses.
*BREQ (Bus Request) is a synchronous, active LOW, DTC 104 output which is used to arbitrate for the Local Bus.
*BGRT (Bus Grant) is a synchronous, active LOW, DTC 104 input that informs DTC 104 that it has control of the Local Bus. It may be asserted even though *BREQ is inactive. If DTC 104 cannot use a granted Local Bus, it asserts *BINV (to be described hereinafter) to create an idle Local-Bus cycle.
*CSEL (Chip Select) is a synchronous, active LOW, DTC 104 input. DTC 104 may, according to the preferred embodiment of the invention, be configured to recognize a Local-Bus request either as the result of an address decode or as the result of an active level on *CSEL. This input is relevant only for accesses to internal DTC 104 registers which, to the extent required to teach the invention, will be described hereinafter.
*BINV (Bus Invalid) is a synchronous, active LOW, DTC 104 output that indicates that Address Bus 111 and related controls are invalid. It defines an idle cycle for the Local Bus. The pin itself is bidirectional.
*DREQ (Data Request) is a bidirectional pin. The signal on this pin is synchronous, three state and active LOW. This signal indicates an active data access on the Local Bus. When it is asserted, the address for the access appears on Address Bus 111.
The DREQT0-DREQT1 (Data Request Type) signals are synchronous and three state. These signals specify the (the value "x" is a don't care):
______________________________________ DREQT1 DREQT0 Meaning ______________________________________ 0 0 Instruction/data memory access 0 1 Input/output access 1 x Coprocessor transfer (ignored by DTC 104) ______________________________________
R/*W (Read/Write) is a bidirectional, synchronous, three state signal. When the DTC 104 is a Local Bus slave, this signal indicates whether data is being transferred from the Local Bus processor to DTC 104 (R/*W LOW) or from DTC 104 to the processor (R/*W HIGH). When DTC 104 is the Local Bus master, this signal indicates whether data is being transferred from DTC 104 to the Local Bus memory (R/*W LOW), or from the Local Bus memory to DTC 104 (R*W HIGH).
SUP/*US (Supervisor/User Mode) is a bidirectional pin. The signal output on this pin is synchronous and three state. This output indicates the program mode of the Local Bus processor (Supervisor mode or User mode) during an access. These modes are defined in the incorporated copending application. The internal registers of DTC 104 are protected from User-mode access (either read or write). DTC 104 I/O ports may be protected from User-mode access as an option.
The OPT0-OPT1 (Option Control) signals are synchronous and three state. These signals specify the data length for Local Bus accesses. Byte and half-word accesses are valid only for accesses reflected on Remote Bus 120 via an I/O port. According to the embodiment of the invention being used for illustrative purposes, DTC 104 supports only 32-bit transfers on Remote Bus 120. The encoding of these signals is as follows:
______________________________________ OPT1 OPT0 Data Width ______________________________________ 0 0 32-bits 0 1 8-bits 1 0 16-bits 1 1 Invalid ______________________________________
*LOCK (Lock) is a bidirectional, synchronous, active LOW signal used to indicate that an atomic read-modify-write cycle is to be performed on Remote Bus 120. It is significant only for an I/O port access. DTC 104 drives this signal HIGH when it is a local-bus master.
DP0-DP3 (Data Parity) are synchronous, three state, odd byte-parity signals for data stored in the Local Bus memory. The DP0 signal is the byte parity for D0-D7, the DP1 signal is the byte parity for D8-D15, and so on. During DMA transfers, DTC
104 allows parity to be transferred to Local Bus 110 from Remote Bus 120 and vice versa. DTC 104 can check for valid parity during either a DMA transfer or a remote-to-local transfer via an I/O port.
*DRDY (Data Ready) is a bidirectional signal that is synchronous and active LOW. For Local Bus reads, this input indicates that valid data is on Data Bus 111. For writes, it indicates that the access is complete, and that data need no longer be driven on Data Bus 112. When DTC 104 is the slave for a Local Bus access, it asserts *DRDY to indicate that it has successfully completed the access (unless *DERR is also asserted). When DTC 104 is the master for a Local Bus access, *DRDY indicates that the Local Bus memory has successfully completed the access (unless *DERR is also asserted).
The *DERR (Data Error) input is synchronous, active LOW and indicates that an error occurred during the current Local Bus access.
*DBREQ (Data Burst Request) is a bidirectional, synchronous, three state, active LOW signal used to establish a burst-mode data access in the Local Bus and to request data transfers during a burst-mode data access.
*DBACK (Data Burst Acknowledge) is a bidirectional, synchronous, active LOW signal that is active whenever a burst-mode data access has been established on the Local Bus (with DTC 104 as either a master or a slave for the access). It may be active even though no data are currently being accessed.
The *INTR (Interrupt Request) output is synchronous, active LOW may be used by DTC 104 to signal interrupt or trap requests.
The *TEST (Test Mode) input is synchronous, active LOW and when active puts DTC 104 in a test mode. All outputs and bidirectional lines, except MSERR, are forced to the high-impedance state in this mode.
The MSERR (Master/Slave Error) output is synchronous, active HIGH and shows the result of the comparison of DTC 104 outputs with the signals provided internally to off-chip drivers. If there is a difference for any enabled driver, this signal is asserted.
Finally, for the Local Bus connections to DTC 104, the *(Reset) input is an synchronous, active LOW signal that resets DTC 104.
On the Remote Bus side of the A--A line shown in FIG. 2 the pins and signals are for the following purposes.
It should be noted that all Remote Bus signals, according to the preferred embodiment of the invention, are synchronous to RCLK, which is a clock at the operating frequency of DTC 104's remote bus interface. RCLK is either an output generated at half the frequency of the ROSC input (to be explained hereinafter), or an input from an external clock generator. Remote Bus signals may be either synchronous or asynchronous to this clock.
The ROSC (Remote Oscillator) input is, when DTC 104 generates RCLK for the Remote Bus, an oscillator input at twice the frequency of RCLK. When RCLK is generated by an external clock generator, ROSC should be tied either HIGH or LOW.
The *RBREQ (Remote Bus Request) output is synchronous, active LOW and is used to arbitrate for Remote Bus 120.
The *RBGRT (Remote Bus Grant) input may be either asynchronous or synchronous, is active LOW and signals that DTC 104 has control of Remote Bus 120. It may be active even though *RBREQ is inactive. If DTC 104 has control of the Remote Bus, yet has no access to perform, it holds *ASTB (to be described hereinafter) inactive.
RAD0-RAD31 (Remote Address/Data Bus) is a bidirectional, Input/Output; asynchronous/synchronous, three state bus. The signals on this bus are multiplexed address/data signals for Remote Bus 120. When *ASTB is asserted, this bus holds the byte address of the Remote Bus access. When *DSTB is asserted, this bus is used to transfer data to and from DTC 104 and Remote Bus 120.
RADP0-RADP3 (Remote Address/Data Parity) is a set of bidirectional, three state, asynchronous/synchronous odd byte-parity signals for RAD0-RAD31. The RDP0 signal is the byte parity for RAD0-RAD7, the DP1 signal is the byte parity for RAD8-RAD15, and so on. During DMA transfers, DTC 104 allows parity to be transferred to Local Bus 110 from Remote Bus 120 and vice versa. DTC 104 can check for valid parity during either a DMA transfer or a remote-to-local transfer via an I/O port.
The *ASTB (Address Strobe) signal is a three state, synchronous, active LOW output signal asserted to indicate that DTC 104 is supplying a byte address for an access on the RAD0-RAD31 lines.
The M/*IO (Memory/I/O) output is three state, synchronous, and indicates whether the current transfer is occurring in the memory address space or the input/output (I/O) address space of the remote bus.
The *RMW (Read-Modify-Write) output is three state, synchronous, and indicates that the current remote-bus access is an atomic read-modify-write signal. It is activated in response to an I/O port access on the Local Bus for which the *LOCK signal is active. *RMW is asserted for the duration of the read-modify-write sequence. Because this signal may be used for synchronization and exclusion, the remote bus must guarantee atomicity.
The RR/*RW (Remote Read/Remote Write) output is three state, synchronous, and determines the direction of a data transfer. A HIGH level indicates a transfer from Remote Bus 120 to DTC 104 (a read), and a LOW level indicates a transfer from DTC
104 to the remote system (a write).
The DSIZE0-DSIZE1 (Data Size Request) signals are three state, synchronous and are outputs reflecting the data width of the requested transfer. The encoding of these signals, according to the preferred embodiment of the invention, is as follows:
______________________________________ DSIZE1 DSIZE0 Data Width ______________________________________ 0 0 32 bits 0 1 8 bits 1 0 16 bits 1 1 Invalid ______________________________________
*DSTB (Data Strobe) is a three state, synchronous, active LOW output indicating that the RAD0-RAD31 lines are available for a data transfer (a read), or that the RAD0-RAD31 lines contain valid data for a write.
The DSACK0-DSACK1 (Data Size Acknowledge) signals are asynchronous/synchronous input signals which indicate that a requested access is complete, and indicate the data width supported by the accessed device (8, 16, or 32 bits.) If the indicated data width is not sufficient for the transfer requested by DSIZE0-DSIZE1, a data-width exception occurs. The encoding of these signals is as follows:
______________________________________ DSACK1 DSACK0 Data Width ______________________________________ 0 0 32 bits 0 1 8 bits 1 0 16 bits 1 1 Invalid or no response ______________________________________
It should be noted that *RBERR and *EOP (to be described hereinafter) provide an alternate means for terminating an access if there is no DSACK0-DSACK1 response.
*RBERR (Remote Bus Error) is an asynchronous/synchronous, active LOW input which, during the data cycle of a Remote-Bus transfer, when active, indicates an error condition on the Remote Bus for the current transfer.
*EOP (End of Process) is an asynchronous/synchronous DTC input active LOW, which a Remote-Bus device may use to signal the end of a DMA transfer, regardless of any termination condition in the DTC, during the final DMA transfer. *EOP terminates the data cycle of a DMA transfer, regardless of DSACK0-DSACK3.
The *DRQ0-*DRQ3 (DMA Request) inputs are asynchronous/synchronous, active LOW, and are used by Remote-Bus devices to request DMA transfers. The inputs *DRQ0-*DRQ3 request DMA transfers for DMA Channels 0 through 3, respectively. According to the preferred embodiment of the invention, the relative priority of the request is programmable to be either fixed or rotating. DTC 104 asserts the corresponding DMA Acknowledge when the DMA transfer occurs. These inputs must be held active until the corresponding DMA Acknowledge output is asserted.
Finally, outputs *DAK0-*DAK3 (DMA Acknowledge) are synchronous, active LOW and are used to acknowledge that DTC 104 is performing a DMA transfer on Remote Bus 120. The outputs *DACK0-*DACK3 acknowledge DMA transfers for DMA channels 0 through 3, respectively.
Having described in detail a set of DTC input and output signals useful for controlling the interface between Local Bus 110 and Remote Bus 120, a detailed functional description of the DTC itself and how it supports a variety of data and address transfers, will now be set forth. This description will complete the demonstration of both the operation and the utility of the invention.
Reference should now be made to FIG. 3 which is functional block diagram of a DTC, built in accordance with the teachings of the invention, having 4 I/O ports and 4 DMA channels. The description of FIG. 3 will provide an overview of the DTC operation.
The DTC is outlined by a dashed line and referenced by reference numeral 310, corresponding to block 104 in FIG. 1.
Only a subset of the previously described DTC input and output signals, with an indication of possible signal direction indicated by arrowheads, is shown in FIG. 3. In particular, the A0-A31, *CSEL, D0-D31, DP0-DP3, RAD0-RAD31 and RADP0-RADP3
signals are shown coupled to DTC 310. Only these signals are necessary in order to explain the overview of how data and address information is channelled through DTC 310.
It will be understood by those skilled in the art that DTC 310 has internal registers (not shown in FIG. 3) which are used for holding and controlling various signals, counters, inputs, outputs, etc., flowing into, out of or through DTC 310. The particular register structure used to implement DTC 310 is instructive although not the only structure for operating and controlling an I/O controller. Accordingly, a general outline of the internal DTC registers used in the preferred embodiment of the invention, along with a brief description of the function of each of these registers, will be set forth for the sake of completeness. Also, whenever a particular internal register of significance is useful in explaining the operation of DTC 310 it will be referenced with particularity.
It should be noted that the internal DTC registers can be addressed, according to the preferred embodiment of the invention, via Address Bus 111. For example, prior to using the I/O ports, a range of addresses may be loaded into internal DTC registers to set up access windows into which (or from which) data is written and retrieved from the ports. This initialization function may be performed, according to the preferred embodiment of the invention, by address compare and control decoder means 301 of FIG. 3, which may be implemented by well known hardware and/or software techniques for loading registers not constituting a part of the invention. In addition to setting up port windows, the *CSEL input and A0-A31 inputs to block 301 and the control output from block 301 (to DTC 310 internal registers) are used, according to the preferred embodiment, to configure DTC 310 to recognize Local Bus requests either as a result of an address decode or as the result of *CSEL being active (LOW).
FIG. 3, in addition to means 301, depicts I/O ports 0-3 (means 302), DMA channels 0-3 (means 303), packing and funneling network (means 304), multiplexing and transceiver devices (transfer means 305), and various parity checking means. Also shown In FIG. 3 are A0-A31 (Address Bus 111), D0-D31 (Data Bus 112) and the *CSEL input, all on the Local Bus side of DTC 310. On the Remote Bus side of DTC 310 the RAD0-RAD31 and the RADP0-RADP3 interface is shown.
As indicated hereinabove, means 301 my be utilized to perform the aforesaid window creation, i.e., open up I/O ports, etc. According to the preferred embodiment of the invention, these windows have power of two address ranges starting on a Local Bus word boundry.
The 4 I/O ports in means 302 are addressed via load and store instructions executed by the illustrative embodiment's RISC processor. The 4 DMA channels in means 303 are preprogrammed in a manner well known for utilizing DMA channels, to determine a start address for data transfer. Typically, sequential addressing is utilized for DMA transfers, although the invention features limited nonsequential transfers, e.g., by 2's, 4's, etc. based on the use of internal DTC counters which increment a base address register. Again, means 301 may be used to initialize the registers and counters in means 302 and 303.
If during operation of the DTC an address presented on A0-A31 is recognized by the I/O controller as being within an I/O port window, then the address is translated within means 302 into the Remote Bus address space. If the address is not recognized, no translation occurs.
Address translation for the I/O ports is performed, according to the preferred embodiment of the invention, by replacing the address input to the DTC with a corresponding Remote Bus address within a range of Remote Bus address loaded into the I/O port registers during initialization. These Remote Bus addresses correspond 1 to 1 with the Local Bus Address window set up for a given port and also correspond to discrete device addresses for devices tied to the Remote Bus.
DTC 310 then performs the Remote Bus access using the translated address, i.e., performs the appropriate read or write in correspondence with the execution of RISC processor load and store instructions, respectively.
With respect to DMA channel means 303, each channel determines the address from which (or to which) data is to be transferred. Means 303 is preprogrammed to perform this determination and operates, independent of the RISC processor except for being initialized. As indicated hereinbefore, the DMA channels have, according to the preferred embodiment of the invention, the flexibility to perform limited non-sequential transfers.
FIG. 3 goes on to show multiplexing and transceiver circuits in means 305 to indicate that addresses and data are interleaved when output to or received from the Remote Bus via the transceivers and the RAD0-RAD31 (and 4 parity bit) interface.
It should also be noted with reference to FIG. 3 that all data to and from means 305 and either an I/O port or DMA channel, must pass through pack/funneling network means 304. If, for example, bits D8-D15 are to be taken from the Data Bus portion of the Local Bus and be transferred onto the Remote Bus (a write), pack/funneling network means 304, according to the preferred embodiment of the invention to be described in greater detail hereinafter, "funnels" 4 copies of the 8 bits juxtaposed in one word to the Remote Bus. For half word transfers from the Local Bus to the Remote Bus, means 304 creates a 32 bit word with 2 sets of the appropriate 16 bits juxtaposed for output by the DTC to the Remote Bus.
For reads, data normally comes back from the Remote Bus late in the same memory cycle as the read is being executed. Normally the data (8, 16 or 32 bits) is right adjusted and "packed" by means 304 into a 32 bit word since all transfers to the Local Bus are 32 bits wide. Again, the details of the operation of means 304 will be set forth hereinafter.
Having completed the description of the overview of DTC 310, a generalized internal register description will now be set forth together with a description of the data formats supported by the novel DTC. This will enable those skilled in the art to understand how to make and use the invention. Also, a specific explanation of the I/O port and DMA functions implemented will be set forth in the context of using the invention to support a RISC system.
Most software interactions with DTC 310 occur via accesses to the internal DTC registers. These registers are read and written by wordlength (i.e. 32-bit) accesses on the Local Bus. None are directly accessible via the Remote Bus.
The registers are grouped into 4 classes:
1. Global Control Registers
2. DMA Channel Registers
3. I/O Port Registers
4. Queue Registers
A RISC processor on the Local Bus accesses DTC registers using load and store instructions. Each register is assigned a unique address in either the data-memory or I/O address space of the RISC system. This address is specified, according to the preferred embodiment of the invention, in terms of a word offset from a base address. The base address is common to all DTC registers. A Chip Select Mapping Register in the DTC specifies the base address for DTC registers, and specifies whether this address is in the data-memory or I/O address space of the RISC system to which the DTC, in accordance with the example being used to illustrate DTC operation, is attached.
Alternatively, as indicated hereinbefore, the DTC can be configured, via means 301 of FIG. 3, to ignore the Local Bus, and respond to any register access for which the *CSEL input is active. In this case, a particular register is selected only by the offset portion of the address.
The Global Control Registers 5 of which are defined for the preferred embodiment of the invention, contain control and status information for the DTC as a whole. The 5 defined registers are a Global Mode, Global Status, Local Burst/Dwell, Remote Burst/Dwell and Chip Select Map Register.
The Global Mode Register may be used to configure DTC options which are not port or channel specific.
Bits have been reserved, in accordance with the preferred embodiment of the invention, in the Global Control register to enable or disable DMA channels and I/O ports, to determine whether Remote Bus operations are synchronous or asynchronous to RCLK, to specify the address space (data memory or I/O address space on the Local Bus) for the DTC's internal registers, to determine whether the DTC is to use the *CSEL input or the Chip Select Mapping Register to detect accesses to internal registers, to determine the relative priorities for DMA channel request (these may be fixed or rotated), to specify the byte order (referred to hereinafter as "LBO", or Local Byte Order) for all Local Bus transfers (i.e., whether bytes within words and half words are to be addressed left to right or vice-versa), to enable or disable parity checking and to enable or disable DTC interrupts.
It should be noted that the LBO information is used, according to the preferred embodiment of the invention, to determine ordering for packing and funneling operations, and is used in conjunction with the Remote Byte Order ("RBO") bits in the Channel Mode and Port Mode registers, to be described hereinafter, to determine whether or not byte swapping is performed on a local-to-remote or remote-to-local transfer.
The information stored in the Global Status register, in accordance with the preferred embodiment of the invention, is as follows:
A Protection Violation bit indicates whether a protection violation occurred on an internal-register access. If a User-mode access (as indicated by SUP/*US) is attempted to an internal DTC register, the DTC responds with *DERR. This bit is set to indicate the reason for the *DERR response.
A Data-Width Exception bit indicates a data width exception on an internal-register access. The DTC responds to an attempted byte or half-word access to an internal register with *DERR. This bit is set to indicate the reason for the *DERR response.
An Addressing Error indicates an attempt to access an unimplemented DTC register. When such an access is attempted, the DTC responds with *DERR. This bit is set to indicate the reason for the *DERR response.
Port Trap bits are used to indicate which of the I/O ports generated a *DERR response. If a port trap bit is set the Port Status Register, to be described hereinafter, of the indicated port gives the reason for the *DERR response.
Channel Interrupt Pending bits are used to reflect the interrupt status of DMA Channels When one of these bits is set an interrupt condition is pending on the channel associated with the bit. The reason for the condition can be determined by examining the appropriate Channel Status Register (one for each channel, to be described hereinafter).
According to the preferred embodiment of the invention, bits are also reserved in the Global Status Register to indicate the device release level for the DTC.
The Local Burst/Dwell Register exercises global control of Local Bus utilization. According to the preferred embodiment of the invention, this register contains a Local Burst Count Field which, in order to support Burst Mode operations described in the incorporated copending application, specifies the maximum number of contiguous Local Bus clock cycles that the DTC can use for data transfer. If the limitation is exceeded on a transfer, the DTC completes any in-progress access before relinquishing the Local Bus. A Local Dwell Count field specifies the number of Local Bus clock cycles for which the DTC must be idle on the Local Bus after a successful Local Bus transfer.
The Remote Bust/Dwell Register exercises global control of DTC Remote Bus utilization. A Remote Burst Count field specifies the maximum number of contiguous Remote Bus clock cycles tha the DTC can use for data transfer. If the limitation is exceeded on a transfer, the DTC completes any in-progress access before relinquishing the Remote Bus. A Remote Dwell Count field specifies the number of Remote Bus clock cycles for which the DTC must be idle on the Remote Bus after a successful Remote Bus transfer.
The last Global Control register presently defined is a Chip Select Mapping Register which controls the addressingof DTC internal registers in certain instances, as indicated hereinbefore with reference to the Global Mode Register. The Global Control register also has a Chip Select Address field which specifies the base address for DTC internal registers.
The DMA Channel Registers contain control and status information for the four DMA channels called for in the preferred embodiment of the DTC. There are four identical sets of registers, one set per DMA channel. Eleven registers have been defined for each channel. Each will be described immediately hereinafter.
A Channel Mode Register controls DMA channel transfers. It must be utilized before a DMA transfer can be performed.
This register, according to the preferred embodiment of the invention, contains: a Remote Wait Count field which specifies the number of cycles (above one) that *DSTB must remain active during a Remote Bus transfer; and a Remote Recovery Count field which specifies the number of cycles that a channel must be idle after a Remote Bus transfer has completed. The value of this field gives the minimum number of cycles required between the end of a data cycle and the beginning of the next data cycle for the DMA channel; a Data Location field which specifies the location of byte and half-word data on the Remote Bus, according the following table:
______________________________________ Field Value Location ______________________________________ 00 By Address 01 Fixed High 10 Fixed Low 11 Fixed Low/Bytes by Address; ______________________________________
an Interrupt Enable bit; a Local Alarm Enable bit which causes the DMA channel to generate an alarm interrupt when set and when the Local Byte Count Register (to be described hereinafter) exceeds the value in the Local Alarm Count Register (also to be described hereinafter); a Remote Alarm Enable bit which causes the DMA channel to generate an alarm when set and when the value in the Remote Byte Counter Register exceeds the value in the Remote Alarm Count Register (both the Remote Byte Count and Remote Alarm registers to be described hereinafter); and a Local Transfer Disable bit. This bit is 0 when transfers to or from the Local Bus memory are performed. When the bit is 1, transfers to or from the Local Bus memory are disabled, and DMA queues are directly read and written by the Local Bus processor; a DMA Request Response Mode field where the bits specify the behavior of the DMA channel for an assertion of the following corresponding *DRQ0-*DRQ3 input:
______________________________________ FIELD VALUE RESPONSE MODE ______________________________________ 00 Ignore DMA Request 01 Single Transfer 10 Demand Transfer 11 Reserved; ______________________________________
A block Mode bit which determines whether block-mode transfers are performed on the Remote Bus; a Remote Address Direction bit which specifies whether the Remote Address Register is incremented or decremented after a DMA transfer on the remote bus; a Remote Address Hold bit which when 0 allows the Remote Addresses Register to be incremented or decremented according to the Remote Address Direction bit, and which holds the Remote Address Register constant when set; a Queue Pattern bit which selects whether the DMA queue associated with the channel is used as a data buffer or a pattern source; and a Transfer Direction bit which controls the direction of DMA channel transfers. When this bit is 0, local-to-remote transfers are performed. When this bit is 1, remote-to-local transfers are performed; a Remote Address Space bit which specifies the address space of the remote transfer. If the bit is 0, transfers are directed to the memory address space (IO/*MEM LOW). If it is 1, transfers are directed the I/O address space (IO/*MEM HIGH); a Data Size Acknowledge Disable bit which enables or disables the DMA channel response to the DSACK0- DSACK1 inputs; a Remote Byte Order bit which specifies the Remote Bus byte order for the DMA channel. When the RBO bit is 0, bytes and half-words are sequentailly addressed from left-to-right within half-words and words. When it is 1, they are sequentially addressed right-to-left; and finally a Data Width field where the bits specify the Remote Bus data width for the DMA channel, as follows:
______________________________________ FIELD VALUE DATA WIDTH ______________________________________ 00 32 bits 01 8 bits 10 16 bits 11 Invalid ______________________________________
A Channel Status Register holds the current status of the channel. It is updated by the DTC when a DMA transfer is terminated or an exception occurs.
This register, according to the preferred embodiment of the invention, contains a parity error bit which, if checking is enabled by the Parity Check Enable bit of the Global Mode Register, is set whenever a parity error is detected during a DMA transfer; a Remote Bus Error bit which is set if *RBERR is asserted during a Remote Bus DMA transfer; a Data Width Exception bit which is set if the DSACK0-DSACK1 response to a Remote Bus DMA transfer indicates that the Remote Bus device or memory cannot handle a transfer of the requested width; an Address Conflict bit which is set if an address conflict is detected during a DMA transfer (i.e. a transfer to DTC internal register or I/O port); a Local Bus Error bit which is set if *DERR is asserted during a Local Bus DMA transfer; an End-Of-Process bit which is set if the *EOP input is asserted during a Remote Bus DMA transfer; a Channel Terminated bit which specifies completion of the DMA transfer; a Local Alarm Count Reached bit which is set if the value in the Local Byte Count Register exceeds the value in the Local Alarm Count Register, if enabled by the Local Alarm Enable bit of the Channel Mode Register; a Remote Alarm Count Reached bit which is set if the value in the Remote Byte Count Register exceeds the value in the Remote Alarm Count Register, if enabled by the Remote Alarm Enable bit of the Channel Mode Register; and a Data Size Acknowledge field which holds the value of the most recent DSACK0-DSACK1 response for the DMA channel. If a data-width exception occurs, this field indicates the Remote Bus response which caused the exception, a Channel Active bit which is 0, when the channel is inactive, and no DMA transfers are performed. If the bit is 1, the channel is active. This bit is set to 0 by the DTC when the termination count is reached or an exception occurs. It may be set to 0 by the Local Bus processor to temporarily suspend transfers on the DMA channel; and finally, a Channel Reset bit. This bit is a "write-only" bit which has the value 0 when read. When a 1 is stored into this bit by the Local Bus processor, the DMA channel is reset, the Local Byte Count Register, the Remote Byte Count Register, and the Queue Head and Queue Tail fields of the Queue Status Register (to be described hereinafter) are set in zero.
A Local Address Register holds the address of a current or pending Local Bus transfer. It is incremented by 4 (bytes) after each successful Local Bus transfer.
A Remote Address Register holds the address of any current or pending Remote Bus transfer. If the Remote Address Hold field of the Channel Mode Register is 0, it is incremented or decremented after each successful Remote Bus transfer according to the Remote Address Direction bit in the Channel Mode Register. The increment or decrement amount is specified by the Data Width field in the Channel Mode Register:
______________________________________ FIELD VALUE INCREMENT/DECREMENT AMOUNT ______________________________________ 00 4 01 1 10 2 11 undefined ______________________________________
A Local Byte Count Register holds the number of bytes successfully transferred on the Local Bus. When this count matches or exceeds the value in the Terminate Count Register (to be described hereinafter), the DMA channel Local Bus transfers are complete. After each successful transfer, the value in the Local Byte Count Register is incremented by 4 (bytes).
A Local Alarm Count Register specifies the number of bytes to be transferred on the Local Bus before an alarm interrupt is generated (if enabled).
A Remote Byte Count Register holds the number of bytes successfully transferred on the Remote Bus. When this count meets of exceeds the value in the Terminate Count Register, the DMA channel Remote Bus transfers are complete. After each successful transfer, the value in the Remote Byte Count Register is incremented by the amount determined by the Data Width field in the Channel Mode Register:
______________________________________ FIELD VALUE INCREMENT/DECREMENT AMOUNT ______________________________________ 00 4 01 1 10 2 11 undefined ______________________________________
A Remote Alarm Count Register specifies the number of bytes to be transferred on the Remote Bus before an alarm interrupt is generated (if enabled).
A Terminate Count Register specifies the number of bytes to be transferred by the DMA channel.
A Pack/Funnel Register buffers data being transferred to or from the Remote Bus. It serves as a destination or source of data during packing and funneling operations on the DMA channel.
The final DMA channel register defined is a Queue Status Register which holds word-address pointers for the current head and tail of the DMA queue.
According to the preferred embodiment of the invention, this register contains a Queue Head field which contains the address of the next queue register available for de-queueing. The value of the filed is incremented by 1 after each word is de-queued and a Queue Tail field which contains the address of the next queue register available for en-queuing. The value of the field is incremented by 1 after each word in en-queued.
The next set of internal registers to be described are the I/O port registers. These registers contain control and status information for the four I/O ports in the DTC. There are four identical sets of registers, one set per I/O port. The set includes 6 registers, a Port Mode Register, a Port Status Register, a Local Base Address Register, a Remote Base Address Register, a Local Port Address Register and a Port Pack/Funnel Register.
The Port Mode Register controls remote programmed I/O transfers (to be described hereinafter). It must be initialized before a remote programmed I/O transfer is performed. The Port Mode Register, according to the preferred embodiment of the invention, contains a Remote Wait Count Field. When the DTC generates Remote Bus timing for I/O port transfers, the field specifies the number of cycles (above one) that *DSTB must remain active during a Remote Bus transfer; and a Remote Recovery Count field. When the DTC generates Remote Bus timing for I/O port transfers, this field specifies the number of cycles that an I/O port must be idle after a Remote Bus transfer has completed. The value of this filed gives the minimum number of cycles required between the end of a data cycle and the beginning of the next data cycle for the I/O port; a Data Location filed which specifies the location of byte and half-word data on the Remote Bus, according to the following table:
______________________________________ FIELD VALUE LOCATION ______________________________________ 00 By Address 01 Fixed High 10 Fixed Low 11 Fixed Low/Bytes by Address ______________________________________
a Window Size field which encodes the size of the I/O port address space, by specifying the logarithm (base 2) of the port size in bytes. For example, if the value of the window size field is 8, the port size is 256 bytes. Similarly, if the window size field is 17, the port size is 128K bytes; A Supervisor Access Only bit which when set only allows Supervisor mode accesses (as indicated by the SUP/*US signal) via the I/O port. When this bit is 0, either User-mode or Supervisor-mode accesses are allowed; and an overlapped I/O bit which determines whether port accesses are direct or de-coupled. If the bit is 0, port transactions are direct; the Remote Bus access must complete before the Local Bus access can complete. If the bit is
1, port accesses are de-coupled, and a Local Bus access can complete before the Remote Bus access is performed. This bit is set to enable an I/O port to perform read-ahead or write-behind operations and provide the parallism with respect to port transactions referred to hereinbefore; a Local Address Space bit which specifies the address space of the I/O port on the Local Bus. If the bit is 0, the I/O port in the data-memory address space of the Local Bus. If the bit is 1, the I/O port is in the I/O address space of the Local Bus; a Remote Address Space bit which specifies the address space of the remote transfer. If the bit is 0, transfers are directed to the memory address space (IO/*MEM LOW). If it is 1, transfers are directed to the I/O address space (IO/*MEM HIGH; a Data Size Acknowledge Disable bit which enables or disables the I/O port response to the DSACK0-DSACK1 inputs; a Remote Byte Order bit which specifies the Remote Bus byte order for the I/O port. When the bit is 0, bytes and half-words are sequentially addressed from left-to-right within half-words and words. When it is 1, they are sequentially addressed right-to-left; and finally, a Data Width field which specifies the Remote Bus data width for the I/O port, as follows:
______________________________________ FIELD VALUE DATA WIDTH ______________________________________ 00 32 bits 01 8 bits 10 16 bits 11 Invalid ______________________________________
The Port Status Register holds the current status of the I/O port. It is updated by the DTC when an I/O port transfer encounters an exception and responds with *DERR. According to the preferred embodiment of the invention, this register includes a Protection Violation bit which indicates whether a protection violation occurred on the I/O port. If a User-mode access (as indicated by SUP/*US) is attempted to an I/O port for which the Supervisor Access only bit in the Port Mode Register is 1, the DTC responds with *DERR. The bit is set to indicate the reason for the *DERR response; a Parity Error bit. If parity checking is enabled by the Parity Check Enable bit of the Global Mode Register, the parity error bit is set whenever a parity error s detected during an I/O port transfer. Parity inputs for signals which are "don't cares" (because of byte or half-word data widths) are ignored. Parity is checked only for reads on the Remote Bus. There is no parity checking on data for writes via the I/O port; a Remote Bus Error which is set if *RBERR is asserted during an I/O port transfer; a Data-Width Exception bit which is set if the DSACK0-DSACK1 response to a Remote Bus I/O port transfer indicates that the Remote Bus device or memory cannot hadle a transfer of the requested width; and finally a Data Size Acknowledge field which holds the value of the most recent DSACK0-DSACK1 response for the I/O port. If a data-width exception occurs, this field indicates the Remote Bus response which caused the exception.
The Local Base Address Register specifies the Local Bus base address of the I/O port. The address space for this port is specified by the Local Address Space bit of the Port Mode Register.
The Remote Base Address Register specifies the Remote Bus base address of the I/O port. The address space for this port is specified by the Remote Address Space bit of the Port Mode Register.
The Local Port Address Register holds the Local Bus for the current I/O port access (which may be a read-ahead or write-behind). This address may be used by software to restart an access encountering an exception.
The Pack/Funnel Register buffers data being transferred to or from the Remote Bus. It serves as a destination or source of data during packing and funneling operations on the I/O port. For read-ahead and write-behind, the Pack/Funnel Register serves as a data buffer. For a write via the I/O port which encounters an exception, the Pack/Funnel Register holds data that may be used by software to restart the write.
The final set of internal registers are the Queue Registers. The Queue Registers buffer data for DMA transfers. These registers may be accessed by the Local Bus processor to directly read or write the contents of the queue. Queue operation for each channel will be described in detail hereinafter.
This completes the detailed description of the function of the internal DTC registers.
As far as register initialization is concerned, after the DTC is reset, its registers have indeterminate values, except that the Global Mode Register is set to zero. This disables all I/O ports and DMA channels, disables interrupts, and enables the *CSEL input.
According to the preferred embodiment of the invention, operating in the context of a RISC system, an initialization routine executing on the RISC processor is responsible for initializing the DTC registers as required by the system. The design of a processor driven initialization routine is well within the knowledge of those skilled in the art and accordingly the initialization routine does not constitute a part of the invention.
It should be noted that until the Chip Select Mapping Register has been properly initialized, the internal DTC registers can be accessed only by asserting the *CSEL input.
For this purpose, *CSEL may be asserted in any system-dependent manner, such as by connecting one of the A31-A11 signals directly to *CSEL (note that this effectively implements a bit-significant address decode for the purpose of initializing DTC registers). Once the Chip Select Mapping Register has been properly initialized, the DTC can be made insensitive to *CSEL, and registers are then accessed using the normal addresses defined by the system.
Next, the data formats supported by the novel DTC, and how they are handled, will be set forth in detail.
As indicated hereinbefore, the preferred embodiment of the DTC supports word (32 bit), half-word (16 bit), and byte (8 bit) transfers on the Remote Bus. Data transfers on the Local Bus are word oriented, although a Local Bus access directed to an I/O port may be half-word of byte access.
There are two defacto standards for addressing bytes and half-words within half-words and words. The DTC supports peripheral devices of either standard, using configuration options which are described hereinafter.
Additionally, the DTC incorporates provisions for converting transfers of a given data width on the Remote Bus to and from transfers of a larger data width on the Local Bus. For any transfer between the Remote and Local Buses, the width of data on the Local Bus must be greater than or equal to the width of data on the Remote Bus. Data-width conversions are performed by the aforementioned packing and funneling means, shown as 304 in FIG. 3.
Focusing on data widths, the DTC's DMA queues always store word length data, and all transfers between the Local Bus and DMA queues are 32 bit transfers. On the other hand, transfers between the Remote Bus and DMA queues may be byte, half-word, or word transfers; byte and half-word transfers involve the packing and funneling operations described in detail hereinafter.
Transfers to and from internal DTC registers are always word-length tranfers. Byte and half-word accesses to DTC registers are not supported, and the DTC responds to an attempted byte or half-word access of an internal register with a *DERR indication. As indicated hereinbefore, a data width exception bit in the Global Status Register is set by the DTC to indicate the cause of the exception.
The DTC allows a byte, word, or half-word access via an I/O port. If the requested data width is larger than the data width indicated by the appropriate Port Mode Register, the DTC handles the size mismatch using the packing and funneling operations described hereinafter.
Focusing first on the Local Bus interface with the DTC, when the DTC is a Local Bus slave, the data width of the associated data transfer is indicated by the OPT0-OPT1 signals. These signals reflect the OPT field of the RISC processor load or store instruction, defined in the incorporated copending application, performing the transfer. The encoding of the OPT0-OPT1 signals has been set forth hereinbefore.
If the DTC cannot support an access of a given width (possibly because the Remote Bus cannot support the access), it responds to the access with a *DERR indication. The data width exception bit of either the Global Status Register or the Port Status Register, as appropriate, is set to indicate the cause of the exception.
With respect to Remote Bus data widths for a DMA transfer on the Remote Bus, the data width of the transfer is specified by the Data Width field of the associated Channel Mode Register (described hereinbefore).
For an I/O port transfer, the data width of the transfer according to the preferred embodiment of the invention, is specified by a combination of the data width field of the associated Port Mode Register and the OPT0-OPT1 inputs on the Local Bus.
The data width for a Remote Bus transfer is reflected on the DSIZE0-DSIZE1 outputs when the transfer occurs. If the requested transfer is not supported by the Remote Bus (because the device or memory on the Remote Bus is not sufficiently wide), the Remote Bus responds DSACK0-DSACK1 response indicating the actual supported data width. This causes a data width exception. (The *RBERR signal may also be used to create an exception, but will not isolate the cause.
If a DMA transfer encounters a data width exception, the transfer is cancelled, and *INTR is asserted if interrupts are enabled.
If an I/O access encounters a data width exception, the DTC responds on the Local Bus with a *DERR indication. In the case of read-ahead or write-behind, *DERR signals that an exception occurred on the most recent access via the corresponding I/O port.
When an exception is caused by a DSACK0-DSACK1 response, the state of the DSACK0-DSACK1 inputs associated with the exception is stored in the Data Size Acknowledge field of the Channel Status or Port Status Register associated with the transfer (the DSACK0-DSACK1 response is stored for any exception). This can allow the interrupt or trap handler to retry the access with the proper data width.
It is possible for a Remote Bus device or memory to give a DASCK0-DSACK1 response indicating that it supports a wider data width than is requested. In this case, the DTC still treats the access as one with the requested width.
Turning to data alignment considerations. Addresses on both the Local and Remote Buses are byte addresses, in that they are sufficient to select a byte in a device or memory attached to either bus. When a half-word or word is accessed, the corresponding address is normally aligned, in that it points to the first byte in the half-word or word. An aligned half-word address has 0 in the least significant bit, and an aligned word address has 00 in the two least significant bits.
The DTC forces alignment for all half-word and word accesses by interpreting the one or two least significant bits of an address as 0 (as appropriate) regardless of the actual values. This is in contrast to some systems, which interpret such accesses as unaligned accesses requiring multiple data accesses, with shifting, alignment, and concatenation. If such accesses must be supported, they must be intercepted by the Unaligned Access Trap in the RISC system to which the DTC described herein is attached.
In cases where a byte is accessed as part of a half-word or word, or where a half-word is accessed as part of a word, the location of the byte or half-word within the half-word or word is determined by one of two established conventions. These conventions relate the location of the byte or half-word to its corresponding address, and are shown in FIG. 4.
In FIG. 4 the following numbering conventions are used:
1. Bytes within half-words are numbered according to the least significant bit of the corresponding address.
2. Bytes within words are numbered according to the two least significant bits of the corresponding address.
3. Half-words are numbered according to the next-to-least significant bit of the corresponding address.
In a RISC system, either of the conventions shown in in FIG. 4 may apply on the Local Bus, and either or both may apply on the Remote Bus. Because of this, the DTC supports both conventions, with conversions between them.
The Local Byte Order ("LBO") bit of the Global Mode Register specifies which of the ordering conventions applies on the Local Bus, as shown in FIG. 4. If the LBO bit is 0, bytes and half-words are sequentially addressed left-to-right within half-words and words. If the LBO bit is 1, they are sequentially addressed right-to-left. Note that only one convention is possible for all transfers on the Local Bus.
The Remote Byte Order ("RBO") bit of the Channel Mode or Port Mode registers specifies which of the ordering conventions applies on the Remote Bus, on a channel by channel or port by port basis. If the RBO bit is 0, bytes and half-words are sequentially addressed left to right within half-words and words. If the RBO bit is 1, they are sequentially addressed right to left.
In general, the LBO bit controls byte and half-word selection during packing and funneling operations. If the LBO bit is 0, packing and funneling proceed left to right for sequentially increasing addresses. If the LBO bit is 1, packing and funneling proceed right to left for sequentially increasing addresses. Note that the order is reversed for sequentially decreasing addresses.
The RBO bit controls the locating of data on the Remote Bus, for those cases where byte and half-word location depend on the address. In addition, when a DMA channel or I/O port is involved in a transfer, the RBO bit for the associated Channel Mode or Port Mode register is compared to the LBO bit. If the selected RBO bit does not match the LBO bit, and the transferred data is wider than a byte, then the bytes within the half-word or word are swapped to convert between the two addressing conventions. This swapping is portrayed graphically in FIG. 5.
In FIG. 5, bytes are labelled with letters (instead of numbers) to emphasize that swapping converts from any addressing convention to the other.
The manner in which packing and funneling operations are supported by the DTC will now be described.
With respect to packing, on a remote to local transfer, the DTC can convert a number of byte or half-word transfers on the Remote Bus into a smaller number of half-word or word transfers on the Local Bus. This is accomplished by packing bytes or half-words into half-words or words. It should be recalled that bytes can be packed into a half-word only for an I/O port access.
Each DTC DMA channel and I/O port has, as previously indicated, an associated 32-bit Pack/Funnel Register. This register supports the packing operation by collecting bytes or half-words until the required amount of data has been collected (the required data width is normally a word, but may be a half-word in the case of the I/O port access). When the data in the Pack/Funnel Register reaches the required width, it is transferred from the Pack/Funnel Register to the appropriate DMA queue (for a DMA channel) or to the Local Bus (for an I/O port). Once data has been removed from the Pack/Funnel Register, further packing operations may proceed.
Local and Remote Bus transfers during packing operations occur as set forth in the following table:
______________________________________ Local Bus Remote Bus Number of Remote Data Width Data Width Bus Transfers ______________________________________ 32 bits 32 bits 1 32 bits 16 bits 2 32 bits 8 bits 4 16 bits 16 bits 1 (I/O port only)
16 bits 8 bits 2 (I/O port only) 8 bits 8 bits 1 (I/O port only) ______________________________________
It should be noted that all data transferred from the Remote Bus to the Local Bus is buffered in the appropriate Pack/Funnel Register, even in cases where the data width on the Remote Bus matches the data width on the Local Bus.
In exceptional cases, the packing operation may be cancelled before the required data width is obtained. These cases arise when there is an exception during a transfer (for example, a parity error), or when the Remote Bus transfer terminates before the packing operation has created a word (e.g. when an odd number of bytes are transferred on a DMA channel). If the packing operation cannot create a data unit of the required width, the remainder of the half-word or word is, according to the preferred embodiment of the invention, padded with zeros.
With respect to funneling, for a local to remote transfer, the DTC can convert a number of word or half-word transfers on the Local Bus into a larger number of half-word or byte transfers on the Remote Bus. This is accomplished by funneling data within a word or half-word into a sequence of half-word or byte transfers. It should be noted that a half-word is funneled into bytes only for an I/O port access).
The Pack/Funnel Register accepts data from a DMA queue (for a DMA channel) or from the Local Bus (for an I/O port), and buffers it during the funnel operation. Funneling extracts half-words or bytes one at a time form the Pack/Funnel Register, and transfers them individually on the Remote Bus. When all data in the Pack/Funnel Register have been transferred, the Pack/Funnel Register may be written with more data to be transferred.
Local and Remote Bus transfers during funneling operations occur in the same manner as during packing, with the table of data widths and number of transfers as set forth hereinbefore.
It should also be noted that all data transferred from the Local Bus to the Remote Bus is buffered in the appropriate Pack/Funnel Register, even in cases where the data width on the Local Bus matches the data width on the Remote Bus.
In exceptional cases, the funneling operation may be cancelled before the data in the Pack/Funnel Register have been exhausted. These cases arise when there is an error during a transfer (for example, a parity error), or when the Remote Bus transfer terminates before the funneling operation has transferred all half-words or words from the Pack/Funnel Register (e.g. when an odd number of gytes are transferred on a DMA channel). In each of these cases, any untransferred data in the Pack/Funnel Register is, according to the preferred embodiment of the invention, ingnored.
Having described how the DTC handles data and the formats supported, the description of the DTC will now turn to it support of programmed I/O.
The term "programmed I/O" as used herein describes any DTC access or data transfer which is the direct result of the execution of a load or store instruction by the RISC processor. This term should not be confused with an access to the RISC system I/O address space, because the DTC supports programmed I/O in either in the RISC system's data memory or I/O address space.
The DTC supports two types of programmed I/O; internal and remote. Internal programmed I/O is used to access DTC internal registers. Remote I/O is used to access data on the Remote Bus in a manner which is coupled to program execution (in contrast to DMA, which is normally decoupled).
As indicated hereinbefore, accesses to internal DTC registers are controlled by the Chip Select Mapping Register. This register specifies the base address for internal registers and whether this address is in the data memory or I/O address space of the RISC system. It also enables and disables the *CSEL input; the base address is irrelevant whenever *CSEL is enabled.
If *CSEL is enabled, the DTC responds to any internal access for which the *CSEL input is active. This access may be in either the data memory or I/O address space of the Local Bus. If *CSEL is disabled, the DTC responds to an access which meets the following criteria:
1. Bits 31-11 of the address for the access match corresponding bits of the Chip Select Address field of the Chip Select Mapping Register
2. The address space (data memory or I/O) for the access matches that specified by the Local Address Space bit of the Chip Select Mapping Register.
If the above criteria are met, the DTC uses the offset portion of the address (bits 10-2) to select an internal register. All accesses to DTC internal registers are word-length accesses, and the DTC responds with *DERR if the OPT0-OPT1 signals are not 00 for an internal register access (the Data Width Exception bit or the Global Status Register indicates the reason for the exception). In any case, the A1-A0 signals are ignored.
For a load (R/*W HIGH), the contents of the selected register are sent to the Local Bus. An unimplemented register bit is read as 0. For a store (R/*W LOW), the selected register is written with the contents of the D31-D0 lines. Any of the D31-D0 lines corresponding to an unimplemented register bit is ignored, but, according to the preferred embodiment, should be 0 for upward compatibility considerations.
The DTC does not successfully complete an access even though it responds to the access, if any of the following conditions apply:
1. The DTC is in the User mode, as indicated by the SUP/*US output being LOW.
2. The address for the access is within the range of addresses recognized by the DTC, but the offset does not select an implemented register.
In each of the above cases, the DTC responds to the access with a *DERR indication. The Protection Violation or Accessing Error bit (as appropriate) of the Global Status Register is set to indicate the reason for the