Apparatus and method for scheduling virtual circuit data for DMA from a host memory to a transmit buffer memory5995995Abstract A method of scheduling the transmission of cells from a network node involves storing entries in a schedule table at predetermined locations, wherein each location represents a point in time at which a cell is to be transmitted. Each entry in the table contains a pointer to a list of virtual circuits having cells scheduled for transmission at the time corresponding to the location of the entry in the table. When a VC has a cell to be transmitted at a particular time, the VC is queued to the head, rather than the tail, of the list of VCs pointed to by the pointer located at the entry in the table corresponding to the time at which the cell is to be transmitted. The VC is therefore the first VC transmitted from the list of VCs. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE 1
______________________________________
CSR Read/Write
LW Address Default
______________________________________
Tx.sub.-- Pending Slots
WO 0 .times. 0 - 0 .times. F
N.A.
Rx.sub.-- Pending Slots
WO 0 .times. 10 -
N.A.
0 .times. 1F
SAR.sub.-- Cntrl1
RW 0 .times. 20
00000040
SAR.sub.-- Cntrl2
RW 0 .times. 21
00001001
Intr.sub.-- Status
RW1C 0 .times. 22
00000000
Intr.sub.-- Enb
RW 0 .times. 23
00000000
Intr.sub.-- Hldoff
RW 0 .times. 24
00000000
Tx.sub.-- FS.sub.-- List.sub.-- Ptrs
RW 0 .times. 25
00000000
Tx.sub.-- Report.sub.-- Base
RW 0 .times. 26
00000000
Rx.sub.-- Report.sub.-- Base
RW 0 .times. 27
00000000
Tx.sub.-- Report.sub.-- Ptr
RO 0 .times. 28
00000000
Rx.sub.-- Report.sub.-- Ptr
RO 0 .times. 29
00000000
Rx.sub.-- Slot.sub.-- Cong.sub.-- Th
RW 0 .times. 2A
00000000
Tx.sub.-- ABR.sub.-- ADTF
RW 0 .times. 2B
00000000
Tx.sub.-- ABR.sub.-- Nm.sub.-- Trm
RW 0 .times. 2C
00000000
Peephole.sub.-- Cmd
RW 0 .times. 2D
40000000
Peephole Data RW 0 .times. 2E
80000000
Rx.sub.-- Raw.sub.-- Slot.sub.-- Tag
RO 0 .times. 2F
00000000
Rx.sub.-- CellCnt
RO 0 .times. 30
00000000
Rx.sub.-- AAL5.sub.-- DropPKTCnt
RO 0 .times. 31
00000000
Rx.sub.-- Raw.sub.-- DropCellCnt
RO 0 .times. 32
00000000
Tx.sub.-- CellCnt
RO 0 .times. 33
00000000
Real.sub.-- Time
RO 0 .times. 34
00000000
Current.sub.-- Time
RO 0 .times. 35
00000000
Test.sub.-- Cntrl
RW 0 .times. 36
00000000
______________________________________
NOTES:
RW = Read/Write
RW1C = Read/Writeone-to-clear
RO = Read only
WO = Writeonly
Because the local memory and peripheral devices external to the SAR controller are not memory-mapped, there is needed a means by which the host system can access these areas. Two of the CSRs, the Peephole.sub.-- Cmd and the Peephole.sub.-- Data registers, provide a mechanism which allows the host system to access local memory using address space available through a local memory interface (not shown) or peripheral devices using address space available through the peripheral interface. For a read transaction, for example, the host system writes a device address (in the partitioned address space) to the Peephole.sub.-- Cmd register and uses other bits in the register to indicate the type of access and select the type of device to be read as either a peripheral device or SRAM. It then polls the Peephole.sub.-- Data register for an indication that the operation has been completed. Once that indication is given (i.e., setting of bit in data register), the returned data can be read from the register. Because this mechanism is well known in the art, further details are not provided. The operational functions provided by other CSRs are referred to and discussed in more detail later. The primary function performed by the SAR controller 62 is the segmentation and reassembly of CPCS-PDUs. Referring again to FIG. 4, the SAR controller 62 receives packet information over the PCI bus through the PCI interface 78. Connected to both the PCI interface 78 and the PHY interface 80, as well as the adapter's local memory 76 (from FIG. 3) is the segmentation engine 88 and a reassembly engine 90. Collectively, the segmentation engine 88 and the reassembly engine 90 implement the SAR function as described in the ATM User-Network Interface Specification, Version 3.1. In the transmit direction, the SAR controller 62 receives from the driver 24 (shown in FIG. 1) complete AAL5 CPCS-PDUs, each including a 4-byte AAL5 CRC placeholder. The Pad, Control and Length fields provided by the driver must be correct, and are not checked by the SAR controller. In contrast, the AAL5 CRC need not be correct. The segmentation engine 88 segments the AAL5 PDUs into fixed length ATM cells, appends cell headers to each ATM cell created by the segmentation process, computes AAL5 CRCs, and overwrites the placeholder CRCs with the computed CRCs in the transmitted PDUs. Segmentation and transmission of up to 1K AAL5 PDUs simultaneously is supported. In the receive direction, the reassembly engine 90 reassembles the AAL5 PDUs and can reassemble up to 1K AAL5 PDUs simultaneously. In addition, the engine calculates and verifies the AAL5 CRC and length fields of received AAL5 CPCS-PDUs. With respect to the embodiment described herein, a VC opened for transmission and reception of data is defined to be in one of 3 classes: constant bit rate (CBR), and variable bit rate which may be either available bit rate (ABR) or unspecified bit rate (UBR). CBR circuits have a fixed cell transmission rate which is specified at signaling time and does not change thereafter. ABR circuits are subject to the rate-based flow control mechanisms specified by the Traffic Management specification of the ATM Forum. The allowed cell transmission rate for such a circuit will therefore vary over time. UBR circuits have a fixed peak cell rate which is also specified at signaling time and does not change thereafter. The SAR controller guarantees that this peak cell rate will not be exceeded under any condition, but it does not guarantee that this rate will be met. The SAR controller 62 also implements the Generic Flow Control protocol as defined in ITU-T SG 13 Revised version documents I.361-TD41 and I.150-TD42 November 1994 Geneva. GFC is a one-way, link-level flow control scheme for controlling the flow of data into an ATM network. In the GFC protocol, the ATM connections are divided into two categories: controlled and uncontrolled. When a cell is received with the HALT bit set in the GFC field 48 in the cell header 44 (FIG. 2), all transmit traffic is halted. When a cell is received with the SET.sub.-- A bit reset (=0), controlled traffic is halted, while uncontrolled traffic may be transmitted. As implemented herein, all CBR VCs are uncontrolled, while ABR and UBR VCs are controlled. Also supported is credit-based flow control. There are a number of well-known credit-based flow control schemes; thus, a description of credit-based flow control is not provided herein, but can be had with reference to a paper by Cuneyt M. Ozveren, Robert Simcoe and George Varghese, entitled "Reliable and Efficient Hop-by-Hop Flow Control", IEEE Journal on Selected Areas in Communications. May 1995, pp. 642-650. The SAR controller 62 supports up to 1K Virtual Circuits (VCs) simultaneously, in both the receive and transmit directions. Therefore, as many as 1K AAL5 PDUs may be segmented and transmitted simultaneously (1K-way interleaving of AAL5 PDUs on the link), while 1K AAL5 PDUs are being simultaneously received and reassembled. In addition to implementation of the AAL5 adaptation layer, the SAR controller 62 provides support for other adaptation layers via "raw" 52-byte cells and provides for the segmentation of MPEG "super-packets" into multiple 8-cell AAL5 packets. Related support is provided for the insertion of "idle packets" in order to achieve exact rates and reduce the amount of buffering needed, for example, at a set-top box. MPEG super-packet segmentation is selected on a per-VC basis, and idle packet insertion is done on a per-packet basis, where idle packets may consist of any number of cells. ATM is fundamentally a full-duplex technology and thus the transmit and receive operations of SAR controller 62 can be viewed as largely independent operations. Therefore, each operation is discussed separately in the description to follow. Hereafter, it is assumed that a sufficient amount of local memory (e.g., 128 KB SRAM) to support 1K transmit and receive VCs is present on the adapter 12. The term "longword" (LW) refers to a 4-byte unit of data. The term "word" (W) refers to a 2-byte unit of data. The transmit (tx) or outgoing direction of data flow refers to data flowing from host memory, into the SAR controller 62, and onto the network 16. The receive (rx) or incoming direction of data flow refers to data flowing from the network 16, into the SAR controller 62, and then into host memory 22. The word "packet" (or, alternatively, the acronym "PDU") as used herein refers to either AAL5 CPCS-PDUs or raw cells. Raw cells are defined as cells which are not part of an AAL5 CPCS-PDU. For example, they may be F4 or F5 OAM cells, ABR RM cells, or cells for an AAL other than AAL5. It should be noted that tx RM cells are generated by the SAR controller itself. Further, there are many FIFOs and linked lists employed in the architecture of the SAR controller. In the described embodiment, entries for these types of data structures are written to the tail of the structure, and read from the head, unless explicitly set forth otherwise. References to elements in the various link lists to be described are set forth in the format "A[B]:C" wherein A is the list, B the index into the list, and C the field in the element indexed. Transmit Operation Returning to FIG. 1, the driver 24 of the host system 14 places user data contained in a packet received from the user application 28 into one or more of the tx slots 30 in host memory 22 in order to begin the transmission of the packet. Each tx slot 30 is a block of memory in a physically contiguous area in host memory 22. A single AAL5 packet may be contained in a single tx slot, or may span many tx slots 30. Each raw cell must be contained in a single tx slot 30. Although the tx slots 30 are depicted as being of uniform size, their size can in fact vary. Tx slots containing portions of an AAL5 PDU may vary in size from 1 byte to 16 Kbytes, with 1-byte granularity, while tx slots containing raw cells are exactly 52 bytes long. The first byte of a raw cell or AAL5 packet occupies the lowest byte address of a tx slot. A single tx slot can contain at most one AAL5 packet or raw cell. Tx slots 30 may be located at any byte address in host memory 22, although optimal performance is obtained when the starting address of each slot is longword-aligned. Also, for best performance, slots should generally be as large as possible, with the optimal case being a one-to-one correspondence between packets and tx slots. Each AAL5 packet posted for transmission contains the AAL5 pad (0 to 47 bytes), Control (2 bytes), Length (2 bytes) and CRC placeholder (4 bytes) fields. The SAR controller 62 will compute the correct AAL5 CRC and overwrite the placeholder CRC when transmitting the packet. FIG. 5 depicts a classical Internet Protocol (IP) packet 98 to be transmitted on the link as it may appear in host memory when occupying four tx slots. As shown, slot 1 100 contains 8 bytes of SNAP header information. Slots 2 (102) and 3 (104) contain IP SDU data. These user data slots may be different sizes. IP pad information occupies slot 4 (106). The driver 24 may allocate as much host memory 22 as it wishes for tx slots, and any number of tx slots may be in use by the driver 24 at any point in time. In the embodiment shown in the figures, the SAR controller 62 only limits the total number of slots from which it may be reading data for transmission at any one point in time to the number of flows which it supports. In the described embodiment, a "flow" is a VC; however, other types of flows can be utilized without departing from the spirit of the inventive concepts described herein. An example of an alternative type of flow is a stream of packets between a pair of nodes in a datagram network. Once the driver has placed data for one or more packets across one or more VCs in tx slots 30 in host memory 22, it must indicate to the SAR controller 62 the location of the tx slots 30 and the VCs with which each slot is associated. In order to post a single slot for transmission, the driver writes control information to an address space (see Tx.sub.-- Pending Slots in CSRs shown in Table 1) in the SAR controller. In this embodiment, the control information is 2 LWs long. The address space is hereafter referred to as the "tx pending slots" address space. When the driver writes 2 consecutive LWs of control information to this address space, the operation is referred to as posting a tx slot. Note that the 2 LW writes are not required to occur in a single PCI burst; the SAR controller can handle an arbitrarily long delay between the write of the first and the second LWs corresponding to the posting of a single tx slot. The tx pending slot address space is 16-LW deep in order to allow the posting of up to 8 tx slots in a single 16-LW PCI burst. Referring to FIG. 6, there is shown the major functional components of the segmentation engine 88 of the SAR controller 62. A tx rate scheduler FSM 120 is coupled to a tx DMA scheduler FSM 122, worklist pointers 123 and the local memory 76. The tx DMA scheduler FSM 122 is coupled to a tx pending slot FIFO 124, a tx DMA request FIFO 125, and the local memory 76. A tx DMA FSM 126 is coupled to the PCI interface 78, to the tx DMA request FIFO 125, and to a tx cell FSM 130. A tx data synch FIFO 128 is coupled to the tx DMA FSM 126, to the tx cell FSM 130, to a tx data FIFO 132, and to a tx phy FSM 134. The tx phy FSM 134 is coupled back to the rate scheduler FSM 120. Also shown is the adapter-resident local memory 76 (from FIG. 3). Although the local memory is not part of the SAR controller 62 in the illustrated ATM adapter of FIG. 2, it is utilized by the SAR controller 62 during a transmit operation and thus included in the figure. Although some of the data structures in the local memory are used during a receive operation, it is necessary to discuss briefly the various data structures contained within the local memory at this point. An example of the internal organization of the local memory 76 in its entirety is provided by FIG. 7. FIG. 6 illustrates only those data structures that relate to a transmit operation. With reference to both FIGS. 6 and 7, the local memory 76 includes the following control data structures: rx free buffer memories 139, implemented as FIFOs and thus alternatively referred to as rx free slot FIFOs 139, preferably including an rx AAL5 big free slot FIFO 140, an rx AAL5 small free slot FIFO 141 and an rx raw cell free slot FIFO 142; an rx slot.sub.-- tag VC state table 144; VC state tables 146 preferably including a tx VC state table 148 and a rx VC state table 150; an ABR parameters table 152; an ABR value table 154; an RM cell table 156; tx slot descriptors 160, which includes a tx free slot list 161 and active slot lists 162 (both shown in FIG. 6); an ACR lookup table 164; rx AAL5 big.sub.-- slot.sub.-- tags 168, rx AAL5 small.sub.-- slot.sub.-- tags 170, and rx raw.sub.-- slot.sub.-- tags 172; a schedule table 174 including a CBR schedule table 176 and an ABR schedule table 178; and VC List 180. Two reserve fields are also provided, and are indicated by reference numbers 179 and 183. Referring to FIG. 6 only, the combination of the tx pending slot FIFO 124, the tx free slot list 161 and the tx active slot lists is depicted as and referred to as a tx control memory 181. Many of these structures will be discussed in detail with reference to the transmit and/or receive operations. When the above-mentioned control information is written by the host system 14 to the tx pending slot address space, it is placed in the tx pending slot FIFO 124 by the PCI bus interface 78 operating in PCI slave mode. In keeping with the embodiment thus described, the tx pending slot FIFO 124 is 8 entries deep. Each time a set of 2-LW writes occurs to the tx pending slot address space (i.e., each time the driver posts a tx slot for transmission), a single entry is placed on the tx pending slot FIFO 124. The tx pending slot FIFO 124 is shown in further detail in FIG. 8A. Data is read from the head of the FIFO 124 and written to the tail. Tx pending slot head and tail pointers 182 and 184 are used to access the head and tail of the tx pending slot FIFO 124 respectively. A tx pending slot controller 186 in the PCI bus interface 78 controls the manipulation of the head and tail pointers 182 and 184 and the transfer of data to and from the tx pending slot FIFO 124. The tx pending slot controller 186 takes advantage of the burst write capability of the PCI bus 18 to provide a performance advantage. A PCI bus burst write transaction is shown in the timing diagram of FIG. 8B. Accordingly, when data is to be written to successive addresses via the PCI bus 18, this can be accomplished using a single PCI bus transaction having multiple data phases. Whereas the usual device mapped to a single CSR address can be accessed only by separate and individual PCI write transactions to that address, the device as herein described (the tx pending slot FIFO 124) is accessible at any CSR address within a successive range of CSR addresses. The controller 186 recognizes a PCI burst write to a CSR address within this range, and then enables the writing of data to the device during each successive data phase of a burst write to the successive CSR addresses within the range. As previously shown in Table 1, the tx pending slot FIFO 124 is accessible at any of CSR locations 0.times.0H-0.times.FH. Each tx pending slot FIFO entry is 2 longwords long; thus, 2 16 bit locations are used for each entry. In order to post a series of tx slot descriptors to the tx pending slot FIFO 124, the host 14 generates a PCI burst write to successive CSR addresses within the range of the CSR locations 0.times.0H through 0.times.FH. For each successive data phase of the burst write, the controller 186 writes the data to the FIFO 124 and increments the tx pending slot tail pointer 184. When the tx pending slot FIFO 124 is full, the PCI slave disconnects the host from the PCI bus. The burst write transaction is thereby advantageously used to load data to the FIFO. The detailed operation of the CSR burst technique 188 employing the tx pending slot FIFO controller is shown in the flow diagram of FIG. 9. The entry.sub.-- avail bit, when asserted, indicates that at least one entry 220, or two longwords, are available in the tx pending slot FIFO. The counter num.sub.-- word.sub.-- cnt keeps track of the number of entries (each of which are two longwords long) present in the FIFO. Upon initialization (step 190), entry.sub.-- avail is asserted to indicate that there is space available in the FIFO (step 192), and num.sub.-- word.sub.-- cnt=0; that is, the FIFO is empty (step 194). The tx pending slot controller 186 waits for a burst write from the PCI bus 18 to the tx pending slot CSR space 0H-0FH. When a burst write occurs (step 196), if the entry.sub.-- avail signal is deasserted (step 198) indicating that no space is presently available in the tx pending slot FIFO 124, the PCI access is re-tried (step 199). As long as entry.sub.-- avail is asserted (step 198), then for each successive data phase of the burst the data on the PCI bus 18 is written to the tx pending slot FIFO 124 (step 200), the tx pending slot tail pointer 184 is incremented (step 202), and the num.sub.-- word.sub.-- cnt counter 188 is incremented (step 204). For example, if after initialization two entries 220(4 longwords) are written to the tx pending slot FIFO 124, the head pointer 182 points to location 0 while the tail pointer 184 points to location 4. When the host 14 desires to write another tx pending slot, the host 14 performs a burst write to location 0h. The tx pending slot controller 186 senses the write to the tx pending slot CSR address space. For each data phase within the burst, the mapping logic writes the data to the tx pending slot FIFO 124 and increments the tx pending slot tail pointer 184. The tx pending slot controller 186 continues to process the burst writes in this manner until the num.sub.-- word.sub.-- cnt counter reaches 15, indicating that the FIFO 124 is full (step 206). The entry.sub.-- avail bit is then deasserted (step 208) and the tx pending slot controller 186 is disconnected from the PCI bus (step 210). Entries are read from the tx pending slot FIFO 124 by the tx DMA scheduler FSM 122. As will be further described in conjunction with that machine (FIG. 23e), when an entry is read from the tx pending slot FIFO 124, the transmit pending slot head pointer 182 is incremented, the num.sub.-- word.sub.-- cnt counter is decremented by two, and the entry.sub.-- avail bit is asserted, thereby enabling further data writes to the tx pending slot FIFO 124. FIG. 10 illustrates a tx pending slot FIFO entry 220. As shown, the tx pending slot FIFO entry 220 comprises a number of different fields. Included is a RAW field 222, a single-bit field for indicating whether the transmit slot contains data for an AAL5 or idle packet (0) or for a single 52-byte raw cell (1). An IDLE field 224 indicates whether the data in the slot should be DMA'd and transmitted normally (0), or whether the SAR controller should schedule an idle cell for transmission for every cell contained in the slot (1). This bit is used for timing MPEG streams. When it is set, no data from the tx slot will be DMA'd or transmitted on the network 16. A single-bit MGMT field 226 indicates if the data in the slot constitutes an F4 or F5 OAM cell. When this bit is set, it indicates to the SAR controller 62 that the data in the slot should be transmitted whether or not the VC of the data has Flowmaster credits available (even if the VC is under Flowmaster flow control). A VC field 228, shown as a 12-bit field, is used to indicate the VC with which the tx slot data is associated. A CRC10.sub.-- EN field 230 is a 1-bit field which is only of significance when the RAW field bit is set. The bit in the CRC10.sub.-- EN is used to select whether or not a 10-bit CRC should be calculated and appended to the raw cell being transmitted. CRC10.sub.-- EN should be set to 0 for AAL5 slots. Generally, it is set to 1 for both F4 and F5 OAM cells. An EOP field 232 is used for two purposes: to indicate that a transmit slot contains the last byte of data of an AAL5 or idle packet (raw=0), or to indicate that a status report and interrupt should be generated on completion of the DMA of a raw cell slot (raw=1). Also included in the tx pending slot FIFO entry is a slot size (SLOT.sub.-- SIZE) field 234, shown as a 14-bit field, for indicating the number of bytes contained in the transmit slot. If the slot is a raw cell slot (raw=1), then this field should always be set to 52 by the host system. For AAL5 or idle slots (raw=0), this field must be in the range 1-16383 (the value 0 is not allowed). A reserved field 236 is also provided. Lastly, the tx pending slot FIFO entry includes a BASE.sub.-- ADDRESS field 238, implemented as 32-bits wide, for indicating the physical base address of a transmit slot in host memory. It may contain any value for idle slots, since no data is DMA'd from idle slots. With continuing reference to FIG. 6, the tx DMA scheduler FSM takes entries off of the tx pending slot FIFO and places data from the entries onto the tx active slot lists 162, as will be further described with reference to that machine. FIG. 11 illustrates the tx active slot lists 162. The tx active slot lists 162 are "per VC" lists having tx active slot list entries 239. Each tx active slot list entry includes a tx slot descriptor 240, which is associated with a single tx slot in host memory. It can be understood from the figures that the tx slot descriptors are therefore comprised of information from all but the VC field 228 in the tx pending slot FIFO entry 220. The VC field is used to queue a tx slot descriptor contained in fields 222-226 and 230-238 in the pending slot FIFO entry to the appropriate tx active slot list. In the described embodiment, there are 1K active slot lists and each is organized as a linked list. Therefore, each tx active slot list entry 239 further includes a link field 241, which contains a pointer to the next tx slot descriptor on the list. A head pointer 243 and tail pointer 242 for pointing to the head and tail, respectively, of each of the tx active slot lists are 12-bits wide and are obtained from the tx VC state table 148 (from FIG. 7). Storage for each tx slot descriptor in the tx active slot lists is taken from the tx free slot list 161, also located in the local memory 76 as shown previously with reference to FIG. 6. The size of the tx free slot list, according to the described embodiment, is 1K entries. FIG. 12 illustrates the tx free slot list 161. With reference to FIG. 12, the tx free slot list 161 includes tx free slot entries 244, which each include the link field 241 and an empty portion 248 (which is written with a tx slot descriptor from the pending slot FIFO). The entries are taken from the head of the free slot list, pointed to by a base.sub.-- ptr 250 and placed on the tail of the list, being pointed to by end.sub.-- ptr 252. The base.sub.-- ptr 250 and end.sub.-- ptr 252 (from FIG. 12) are stored in one of the CSRs on the SAR controller itself. FIG. 13 illustrates the format of the tx active slot list entry 239 from FIG. 11. With the exception of the link field 241, the fields are the same as the equivalently named fields in the tx pending slot FIFO entries and thus retain the reference numbers used in FIG. 10. Once the data in a posted tx slot has been transmitted, the tx free slot FIFO entry associated with the tx slot is returned to the free slot list by the tx DMA scheduler FSM. The driver keeps a count of the total number of slots (across all VCs) queued but not yet transmitted, and ensures that this number never exceeds the total number of supported tx slot descriptors. This number is determined by the size of the free slot list, which is exactly 1K. Both the tx free slot list and the tx active slot lists are initialized by the driver at initialization time. Initialization of the tx free slot list consists of writing every link field in the tx free slot list entries (1K-1 links) to create a linked list, and writing the base and end pointers of the tx free slot list in the CSRs. Initialization of the tx active slot lists consists of writing the head and tail pointers of all of the tx active slot lists with the value 0, since all tx active slot lists are initially empty. In the embodiment described herein, the tx control memory 181 includes the tx pending slot FIFO 124, the tx free slot list 161 and the tx active slot lists 162; however, alternative implementations of the tx control memory may be utilized. For example, in a network node supporting only one VC, the tx control memory 184 could be implemented as a single data structure, such as a list. A linked list is preferable, as it allows tx slots which are noncontiguous with respect to one another to be chained for a given PDU that spans multiple tx slots. As previously indicated, the network node of the described embodiment supports up to 1K active VCs. When a VC is opened, it is set-up as an AAL5 VC, an AAL3/4 VC, or some other type of flow. The SAR controller 62 recognizes three types of flow: AAL5, Raw and MPEG. Two bits in the tx VC state table 148 for a given VC identify the type of flow to which the VC has been assigned. In the following description, any reference to AAL5 streams includes MPEG streams (since MPEG streams are assumed to be carried over AAL5). An MPEG stream is different from an AAL5 stream only in that a single MPEG packet ("super-packet") may be segmented into several AAL5 packets. When packets are transmitted on a VC which is an AAL5 VC, the AAL5 CRC will be computed and appended to the packets. OAM-F5 cells are identified through the PT field of the cell, rather than by the VC field, and may be carried on the same VC as an AAL5 flow. Whenever the host system wishes to transmit an F4 or F5 OAM cell, it needs to set the bits of the raw and crc10.sub.-- en fields in the tx slot descriptor for the cell. The setting of these bits indicates to the SAR controller that the tx slot contains a single raw cell for which the CRC-10 must be computed and appended. It also indicates, in the case of F5 cells carried over an AAL5, that the CRC-32 of the cell's VC in the tx VC state table should not be updated. It should be noted that, aside from the fact that they do not affect the CRC-32 calculation, OAM-F5 cells are treated no differently than data cells of the VC on which they are being sent. In terms of DMA and transmit scheduling and for purposes of ABR rate-based flow control calculations they are considered part of the normal data flow of the VC. OAM-F4 cells are identified by their VC (VC=3 or 4). The SAR controller will generate the CRC-10 field for all transmitted cells for which the bit of the crc10.sub.-- en field is set. It will then overwrite the appropriate bits in the transmitted cell with the calculated CRC-10 value. This function may be used to aid in the transmission of AALs other than AAL5 which use the CRC-10, such as AAL3/4. FIG. 14 depicts the format of a tx VC state table entry 254 in the tx VC state table 148. As shown, the entry comprises 8 words. Word 0 provides a two-bit channel type (chtyp) field 256 for indicating the channel type. The two bit field is decoded as follows: 00 corresponds to a raw cell data, 01 is reserved, 10 corresponds to AAL5 and 11 corresponds to MPEG cell data. A streaming mode enable (tx.sub.-- AAL5.sub.-- SM) field 258 is a one-bit field for enabling streaming mode for AAL5 cells. This field is used for reports and interrupts, as will be seen later. An FLOWmaster enable (FM) field 260 is set to enable FLOWmaster control support. Word 0 further comprises an ABR parameter base set selection (ABS) field 262 and a rate control (R) field 264 to indicate the particular rate control selected. This two-bit field is decoded as follows: 00 corresponds to CBR, 01 is set for ABR, 10 is set for UBR and 11 is reserved. A one-bit cell loss priority (CLP) field 266 indicates the cell loss priority transferred to the ATM header of the transmitted AAL5 cells. Lastly, word 0 includes a prescale counter value (prescale.sub.-- val) field 268 for providing the prescale counter initial value for CBR and UBR rate control. The remaining bits (7:4) are contained in reserved field 270. This reference number is used to indicate all of the five reserved fields shown in the figure. Now referring to word 1, the entry further comprises an MPEG.sub.-- count field 272, which serves as a counter for counting the number of cells in an MPEG packet. A Prescale.sub.-- count field 274 is a down counter used for slowing down CBR/ABR/UBR rates. A credit field 276 provides a FLOWmaster transmit credit counter. The MSB of word 1 is a second reserved field 270. Together, Words 2 and 3 correspond to a 32-bit CRC 278 for transmitted AAL5 packets. Particularly, word2 contains the low word and word 3 the high word. Word4 includes an active field 280, a flag to indicate that data exists in the active slot list for a VC, and a schedule flag 282 to indicate that a VC is scheduled in the ABR/UBR schedule table. An out-of-rate backward RM (OR.sub.-- BRM) flag 284 is used to indicate that an out-of-rate backward RM cell should be transmitted. A turn field 286 is a flag for indicating that a backward RM turn-around cell is pending. Also provided is a tx active slot list head pointer 288 and, in word5, a tx active slot list tail pointer 290. Word5 also includes a third reserved field 270. Words 6 and 7 include a fourth reserved field 270 and a fifth reserved field 270 respectively. Word6 also includes a transmit slot pointer (tx.sub.-- slot.sub.-- ptr) 292 corresponding to the byte offset into the current slot from which transmit data is being DMA'ed on a VC and an idle field 294. Lastly, word7 provides for ABR or UBR schedule pointers in a VC.sub.-- link field 295. As already stated above, the SAR controller provides support for transmission of data encoded according to the MPEG standard through the use of MPEG Super-Packets. FIG. 15 illustrates the format of an 8 cell AAL5 packet 296 carrying two MPEG PDUs 297 and an AAL5 trailer 298. Each of the MPEG PDUs 297 is exactly 188 bytes in length. This means that 2 MPEG PDUs (376 bytes) may be packed together into a single 8-cell AAL5 packet with no AAL5 padding, as shown. An MPEG super-packet is a packet provided by the driver which may contain any even number of MPEG PDUs on a VC which has been specified as an MPEG VC (in the tx VC state table). The SAR controller automatically segments the packet into 1 or more AAL5 packets, placing 2 MPEG PDUs in each AAL5 packet. The driver does not provide any AAL5 information in MPEG super-packets (as opposed to AAL5 packets, which must include the AAL5 pad, control and length fields and a 4-byte CRC placeholder). For example, if the driver wishes to transmit 10 MPEG PDUs in a single MPEG super-packet, it posts an MPEG super-packet exactly 1880 bytes in length (188.times.10). The SAR controller then segments the super-packet into 5 AAL5 packets and append the appropriate AAL5 length (376), control (0) and CRC fields to each AAL5 packet. As with other AAL5 packets, MPEG super-packets may be posted across any number of slots. SAR Controller Segmentation Engine The segmentation engine 88 of the SAR controller 62 functions to segment data provided by the driver 24 into fixed length cells to be transmitted to the PHY 80. The data to be segmented into cells and transmitted on a given VC resides in host memory 22; therefore, the elements shown in FIG. 6 interoperate in part to schedule DMA requests to host memory 22 to retrieve data for each VC and to transmit that data from the tx data FIFO 132 according to the traffic class and rate requirements for that VC. In brief overview, the tx DMA scheduler 122 reads the tx pending slot FIFO 124 and moves transmit slot descriptors 240 (FIGS. 11-13) from the free slot list 161 to the active slot lists 162. The schedule table 174, which includes the CBR schedule table 176 and ABR schedule table 178, holds entries corresponding to CBR and ABR/UBR VCs to be transmitted. The tx rate scheduler FSM 120 (hereinafter tx rate scheduler 120) loads these entries into the schedule table 174 at locations determined in accordance with the rate requirements for the VCs. The tx rate scheduler 120 scans the CBR and ABR schedule tables 176 and 178, processing each of the entries in the tables sequentially. For each entry read, the tx DMA scheduler FSM 122 (hereinafter tx DMA scheduler 122) places a CBR or ABR tx DMA request entry in the tx DMA request FIFO 125, updates the tx VC state table 254, and moves tx slot descriptors 240 from the tx active slot lists 162 to the tx free slot list 161 as necessary. The tx DMA FSM 126 processes the entries in the tx DMA request FIFO 125, generating a single burst read request to the PCI bus 18 for entries requiring the transfer of data from host memory 22 into the tx data synch fifo 128. The tx data synch fifo 128 provides buffering between the PCI bus 18 and SAR controller 62 clock domains. The tx cell FSM 130 in turn controls the transfer of data between the tx data synch fifo 128 and the tx data fifo 132. The tx data fifo 132 serves as the transmit buffer memory, and as herein shown holds up to 16 CBR and/or ABR/UBR cells for transmission to the PHY interface 80. The configuration of the tx data fifo 132 depends upon whether GFC is enabled. The configuration of the tx data fifo 132 affects the operation of the various FSMs, and so is now described in detail. Dual Mode Tx Data Fifo 132 Recall that, when GFC is enabled and SET.sub.-- A is deasserted, controlled ABR/UBR traffic is halted while uncontrolled CBR traffic continues to flow. If both controlled and uncontrolled traffic are buffered in a single tx data FIFO 132 when GFC is enabled, then if a controlled ABR/UBR cell is at the head of the FIFO and GFC set.sub.-- A is deasserted, any uncontrolled CBR traffic behind the pending ABR/UBR cell is unacceptably blocked from transmission. A dual-mode tx data FIFO 132 is therefore provided. Referring to FIG. 16a, when GFC is disabled, the tx data FIFO 132 is configured as a single FIFO for holding CBR, ABR, and UBR traffic. When GFC is enabled, however, the tx data FIFO 132 is segmented into a cbr tx data FIFO 300 for holding uncontrolled CBR traffic and an abr tx data FIFO 302 for holding controlled ABR and UBR traffic, as shown in FIG. 16b. When GFC is enabled and set.sub.-- A is deasserted, only the abr tx data FIFO 302 traffic flow is halted. The separate cbr and abr tx data FIFOs 300 and 302 thereby prevent blocking of uncontrolled traffic in the event that controlled traffic is halted. More particularly, when GFC is disabled (FIG. 16a), as indicated by the deassertion of a segmented.sub.-- fifo signal by the tx data FIFO 132, the tx data FIFO 132 is configured as a single FIFO for holding CBR, ABR, and UBR VCs. A single set of head and tail pointers controls access to the tx data FIFO 132, shown here as tdf.sub.-- head.sub.-- ptr 304 and tdf.sub.-- tail.sub.-- ptr 306. When GFC is enabled (FIG. 16b), the signal segmented.sub.-- fifo is asserted by the PHY and the FIFO is bifurcated into a cbr tx data FIFO 300 for holding uncontrolled cells and an abr tx data FIFO 302 for holding controlled cells. Two separate sets of pointers are then used. A tdf.sub.-- abr.sub.-- head.sub.-- ptr 308 and tdf.sub.-- abr.sub.-- tail.sub.-- ptr 310 control access to and from the abr tx data FIFO 302, while a tdf.sub.-- cbr.sub.-- head.sub.-- ptr 312 and tdf.sub.-- cbr.sub.-- tail.sub.-- ptr 314 control access to and from the cbr tx data FIFO 300. Consider now the provision of dual FIFOs for controlled and uncontrolled traffic in combination with the provision of only a single DMA request FIFO 125 (FIG. 6). When GFC flow control is enabled and SET.sub.-- A is deasserted, the flow of cells from the abr tx data FIFO 302 is halted, while uncontrolled CBR cells should continue to flow from the cbr tx data FIFO 300. Consider that the abr tx data FIFO 302 becomes full, and then a DMA request for an ABR cell is scheduled into the DMA request FIFO 125. Once the ABR entry rises to the head of the DMA request FIFO 125, back pressure from the abr tx data FIFO 302 prevents the processing of the request. Therefore, any uncontrolled CBR entries behind the ABR entry in the tx DMA request FIFO 125 will not be processed either. This problem can be prevented through the provision of dual DMA request FIFOs--one for controlled and one for uncontrolled traffic. However, the problem is herein solved while allowing the efficient use of a single DMA request FIFO 125. Accordingly, when GFC flow control is enabled, the tx DMA scheduler 122 will not schedule DMA requests from the ABR schedule table 178 unless the abr tx data FIFO 132 can accommodate at least one cell. A fifo.sub.-- remain controller 316 keeps track of the number of entries outstanding in the abr tx data FIFO 302. Thus, whereas cbr DMA scheduling may be prevented by back pressure from the cbr tx data FIFO 300, abr DMA scheduling is counter controlled. As seen in FIG. 6, The fifo.sub.-- remain controller 316 is coupled between the tx phy FSM 134 and the tx rate scheduler 120. The fifo.sub.-- remain controller 316 is shown in more detail in FIG. 17 to include a counter 317 and a comparator 318. It accepts as input a DMA.sub.-- request.sub.-- on.sub.-- abr signal from the tx rate scheduler 120 and a read.sub.-- entry.sub.-- dec[1:0] vector from the tx phy FSM 134, and produces as output a fifo.sub.-- remain.gtoreq.16 LW signal which is fed to the tx rate scheduler 120. A flow diagram representing the operation of the counter 317 is shown in FIG. 18. As herein embodied, the tx data FIFO 132 is a 1K byte FIFO which may be segmented into a 512 byte cbr tx data FIFO 300 and a 512 byte abr tx data FIFO 302. At step 319 the counter 317 is initialized to 128 longwords, which is the number of longwords available in the empty abr tx data FIFO 302. Upon assertion of the DMA.sub.-- request.sub.-- on.sub.-- abr bit by the tx DMA scheduler 122 (step 320), which indicates that a DMA request for an ABR/UBR cell has just been queued to the DMA request FIFO 125, the counter 317 is decremented by the number of bytes associated with the type of cell requested. The cell requested is one of three types: raw, AAL5, or RM. As will be further described in conjunction with the tx data FIFO 132, raw cells consume 14 longwords in the FIFO, AAL5 cells consume 13 longwords, and RM cells consume 3 longwords. Thus, for a raw cell, the counter 317 is decremented by 14 (steps 322 and 324), and for AAL5 cells, by 13 (steps 326 and 328). If the cell requested is neither raw or AAL5, then the counter 317 is decremented by the size of an RM cell, i.e. by 3 (step 332). When a cell is transferred out of the abr tx data FIFO 302, the read.sub.-- entry.sub.-- dec[1:0] vector takes on a non-zero value that encodes the type of cell transmitted. In this case the counter 317 is incremented by the number of bytes in the cell transmitted. Thus, when the read.sub.-- entry.sub.-- dec[1:0] vector is decoded to indicate transmission of a raw cell, the counter 317 is incremented by 14 (steps 336 and 338). Decode of an AAL5 cells increments the counter 317 by 13 (steps 340 and 342). Decode of an RM cell increments the counter 317 by 3 (steps 344 and 346). The output of the counter 317 is input to the comparator 318, where it is compared to a value of 16 longwords. As long as the counter 317 output remains greater than or equal to 16 longwords, the fifo.sub.-- remain.gtoreq.16 LW signal remains asserted and does not prevent DMA scheduling of VCs from the ABR schedule table 178. If the counter 317 output should ever fall below 16 longwords, the fifo.sub.-- remain.gtoreq.16 LW signal will be deasserted, preventing further abr DMA scheduling until a cell is transferred out of the abr tx data FIFO 302. Note that the above described controller 316 is useful in general for transferring various sorts of data units, some of which are subject to a flow control mechanism, between a host memory and a peripheral interface. Where there is generally provided two transmit buffer memories, one for holding flow controlled data units (i.e. the abr tx data FIFO 302) and one for holding uncontrolled data units (i.e. the cbr tx data FIFO 300), and it is desirable to provide only a single request buffer (i.e. the tx DMA request FIFO 125), a controller such as the fifo.sub.-- remain controller 316 can prevent data transfer circuitry (such as the combination of the tx rate scheduler FSM 120, tx DMA scheduler FSM 122, and tx DMA FSM 126) from transferring further data from the host memory to the transmit buffer memory storing the flow controlled data units when it is determined that there is not enough room in the transmit buffer memory storing the flow controlled data units to accommodate another data unit. Meanwhile, the controller 316 allows the data transfer circuitry to transfer further data from the host memory to the transmit buffer memory storing the uncontrolled data units. Note also that, though the previously described embodiment employs a counter for keeping track of the space remaining in the the abr tx data FIFO 302, other embodiments can be used to achieve the same result. For example, a counter could be used to keep track of the number of entries used in the FIFO, rather than the number of entries remaining. Each element shown in FIG. 6 is now described in detail. Tx DMA Request FIFO 125 As the tx rate scheduler 120 scans the schedule table 174, DMA requests are generated by the tx DMA scheduler 122 and placed as entries in the tx DMA request FIFO 125. These entries are then read by the tx DMA FSM 126, which processes the entries and generates DMA requests for data from host memory 22. Referring now to FIGS. 19a-19c, The tx DMA scheduler 122 may generate any of 3 types of entries: a data DMA request entry 350, an idle slot report request entry 352, or an RM cell request entry 354. Fields in the first word of the entry identify the type of entry, as shown in Table 2.
TABLE 2
______________________________________
Tx DMA request FIFO 125 Entry Type Decoding
RM DMA.sub.-- SIZE <5:0>
ENTRY TYPE
______________________________________
0 >0 Data DMA Request
0 0 Idle Slot Report
Request
1 N.A. RM Cell Request
______________________________________
The three types of tx DMA request FIFO 125 entries are defined as follows: Data DMA Requests This type of entry represents a single request by the tx DMA scheduler 122 to read data from host memory 22. Each data DMA request is processed by the tx DMA FSM 126, and results in a single burst read request to the PCI bus 18. FIG. 19a illustrates a data DMA request entry 350. This entry is identified by (RM=0) and (DMA.sub.-- Size>0). Data DMA Request Entry Fields: VC (356) This 12-bit field identifies the VC to which the data to be DMA'd from host memory 22 belongs. The VC is that obtained by the tx rate scheduler 120 when reading either a valid CBR schedule table entry or a worklist entry. Sched.sub.-- Time (358) This 8-bit field is a timestamp representing the time at which the DMA Request was placed in the tx DMA request FIFO 125. It does not affect the functioning of the tx DMA FSM 126, but is placed by the tx Cell FSM 130 in the tx data FIFO 132 along with the data to be transmitted. The field is then used by the tx phy FSM 134 to resynchronize cell transmission, so that the pattern of cells emerging at the PHY interface 80 more closely resembles the pattern seen in the schedule table 174 by the tx rate scheduler 120, as will be further described in conjunction with the tx rate scheduler 120 and the tx phy FSM 134. RM (360) This 1-bit field is cleared (0) for data DMA request entries. It differentiates the entries from RM cell request entries. CLP (362) This 1-bit field indicates the value of the CLP bit which should be inserted in the AAL5 cell transmitted. It has no meaning for raw cells. CRC.sub.-- Ena (364) This 1-bit field when set indicates that a CRC must be computed across the data DMA'd as a result of the request. If the request is for a raw cell (as indicated by the fact that the DMA.sub.-- Size field of the request is equal to 52 bytes), then this bit indicates that a CRC-10 will be computed and inserted in the raw cell transmitted as a result of the request. If the request is for part of an AAL5 packet (DMA.sub.-- Size field of the request is not equal to 52 bytes), then this bit indicates that a CRC-32 should be computed across the data DMA'd and transmitted as a result of the request. EOP (366) This 1-bit field indicates if the DMA burst to be executed is either: A burst of a number of bytes containing the last byte of data in an AAL5 packet; or A 52-byte burst of a raw cell whose EOP bit is set. The bit is used by the tx cell FSM 130 to determine AAL5 packet boundaries, in order to write computed AAL5 CRCs to the tx data FIFO 132 at the appropriate time. This bit does not affect the functioning of the tx DMA FSM 126. DMA.sub.-- Size (368) This 6-bit field differentiates data DMA request entries from idle slot report request entries and indicates the number of bytes to be DMA'd from host memory 22. It will be 0 for idle slot report request entries and non-zero for data DMA request entries. For raw cell slots, this field will always indicate 52 bytes. For AAL5 slots, this field will usually indicate 48 bytes, except sometimes at slot boundaries, and it will never indicate more than 48 bytes. Int (370) This 1-bit field when set indicates that a tx status report should be completed and a tx interrupt generated upon completion of the DMA'ing of data. EOC (372) This 1-bit field indicates whether or not the request is for the end of an AAL5 or raw cell. EOC is set to 1 for every raw cell request (DMA.sub.-- Size=52) and for every request which results in the DMA of the 48th byte of data of an AAL5 cell. Add.sub.-- MPEG.sub.-- Trailer (374) This 1-bit field when set indicates that an AAL5 trailer should be appended to the end of the data DMA'd when the data is placed into the tx data FIFO 132 by the tx cell FSM 130. This bit is set at 376-Byte boundaries of MPEG super-packets. The AAL5 trailer appended will consist of 0 bytes of paddings, a length field=376 bytes, control field=0, and a 4-byte CRC. CBR (376) This 1-bit field indicates whether the request is associated with a CBR or ABR/UBR VC, and is used when GFC is enabled in order to direct the data associated with the request to the appropriate cbr or abr tx data FIFO 300 or 302. DMA.sub.-- Address (378) This 32-bit field indicates the physical address in host memory 22 from which data should be DMA'd. Idle Slot Report Requests Idle slot report requests do not result in any data being DMA'd from host memory 22. Idle slots are used in part by the host 14 for fine tuning of CBR traffic rates. The purpose of an idle slot report request is to indicate to the tx DMA FSM 126 that it should report to the host driver 24 the consumption of an idle slot. Transmit reporting is also discussed in detail later. The tx DMA scheduler 122 issues idle slot report requests only for the last cell of an idle slot, and only when the EOP bit for the idle slot is set (FIG. 10), indicating that consumption of the slot should be reported. If an idle slot does not have its EOP bit set, the tx DMA scheduler 122 will consume the slot without actually issuing any DMA requests for the slot. FIG. 19b illustrates an idle slot report request entry 352. This entry is identified by (RM=0) and (DMA.sub.-- Size=0). Idle Slot Report Request Entry Fields: VC (380) This 12-bit VC identifies the VC for which an idle slot was consumed. RM (382) This 1-bit field is cleared (0) for idle slot report request entries. It differentiates the entries from RM cell request entries. DMA.sub.-- Size (384) This 6-bit field differentiates idle slot report request entries from data DMA request entries. It indicates the number of bytes to DMA'd from host memory 22, and will thus always be 0 for idle slot report request entries and non-zero for data DMA request entries. RM Cell Requests This type of entry represents a single request by the tx DMA scheduler 122 to transmit an RM cell on the link. This request does not result in the DMA of any data from host memory 22. It is simply an indication to the tx DMA FSM 126 that it must request that the appropriate RM cell be created and placed in the tx data FIFO 132 for transmission. FIG. 19c illustrates an RM cell request entry 354. RM Cell Request Entry Fields: VC (386) This 12-bit field identifies the VC on which an RM cell should be transmitted. Sched.sub.-- Time (388) This 8-bit field is a timestamp representing the time at which the RM Cell Request was placed in the FIFO. It does not affect the functioning of the tx DMA FSM 126 or tx cell FSM 130, but is placed in the tx data FIFO 132 along with the data to be transmitted. The field is then used by the tx phy FSM 134 to resynchronize cell transmission, so that the RM cell is transmitted at the appropriate time. RM (390) This 1-bit field is set (1) for RM cell request entries. It differentiates the entries from the 2 other types of entries in the FIFO. CLP (392) This 1-bit field indicates the value of the CLP bit which should be inserted in the transmitted RM cell. Forward (394) This 1-bit field indicates whether the RM cell to be generated is a forward RM cell (1) or a backward RM cell (0). Schedule Table The segmentation engine 88 uses a schedule table and worklist-based approach to DMA scheduling, wherein flows are represented by their VCs in the schedule table 174, shown in more detail in FIG. 20a. The schedule table 174 is a data structure located in local memory 76. It includes a CBR schedule table 176 and an ABR schedule table 178. As herein embodied, the CBR schedule table 176 contains from 2 to 4096 entries 400 used to schedule CBR flows, and the ABR schedule table 178 contains 4K entries 402 used to schedule ABR and UBR flows. Each location or row 404 in the schedule table 174 represents a point in time that is 1 cell time (at whatever rate the physical interface 80 is running) from the adjoining rows. For example, at STS-3c/STM-1 line rates, the first row 404 in the schedule table 174 is associated with a time t=0, the next row 404 with a time t.apprxeq.2.83 .mu.s, and the next row 404 with a time t.apprxeq.5.66 .mu.s. Cell data is transferred from the tx data FIFO 132 to the PHY interface 80 at the line rate; thus, each location 404 represents a point in time at which data can be transferred from the tx data FIFO 132 to the PHY interface 80. The schedule table 174 operates as a circular structure, such that, for example, the entry at row (4095) adjoins the entry at row (4094) and the entry at row 0 in the ABR schedule table 178. There are 2 separate columns in the CBR schedule table 176: cbr.sub.-- vc1 (408) and cbr.sub.-- vc2 (410). Each is a word wide and may include a single entry 400. Each entry 400 contains a 12-bit VC field 412, along with a valid bit 414 and an EOT bit 416. These fields indicate the CBR flow to be scheduled for transmission at the time at which the entry appears. When the valid bit 414 is asserted, the VC 412 in the entry 400 is valid. Otherwise, there is no CBR VC to be scheduled at the time represented by the entry 400. The EOT bit 416 is used to indicate the last entry 400 in the CBR schedule table 176. Only one cbr.sub.-- vc column is used at one time. The column in use is selected by the driver 24 through manipulation of a cbr-st-sel control bit in a CSR (not shown). The provision of two cbr.sub.-- vc columns in the CBR schedule table 176 supports modification of CBR rates in real-time by the driver 24. At initialization time, the driver 24 will select the cbr.sub.-- vc1 column 408 by setting the cbr.sub.-- st.sub.-- sel bit to 0, and initializing all entries in the column. When the driver 24 wishes to modify the CBR schedule, it will write the entries in the cbr.sub.-- vc2 column 410 with the new schedule, then toggle the cbr.sub.-- st.sub.-- sel bit to 1. The tx rate scheduler 120 will then start using the cbr.sub.-- vc2 column to schedule the transmission of CBR flows. If the driver 24 wishes to modify the schedule once again, it will modify the cbr.sub.-- vc1 column, then toggle the cbr.sub.-- st.sub.-- sel bit back to 0. An ABR schedule table entry 402 includes an abr.sub.-- head field 418 and abr.sub.-- tail field 420, each of which hold 12-bit pointers into a VC list 180, located in local memory 76. In addition, the abr.sub.-- head field contains a valid bit 422. The VC list 180 is an array of 1K entries 424, each of which is a 12 bit pointer to another entry 424 in the list. Each entry 424 represents a VC, depending on its position in the array. For example, using the term VCL[i] to represent the ith entry in the VC list, VCL[5] represents VC 5, whereas VCL[256] represents VC 256. As herein implemented, the entries in the VC list 180 are the VC.sub.-- link fields 295 in the tx VC state table entry 254 for each VC. The abr.sub.-- head field 418 of an ABR schedule table entry 402 is a pointer that points to the beginning of a linked list of VCs kept in the VC list 180. The abr.sub.-- tail field 420 of an ABR schedule table entry 402 is a pointer that points to the end of a linked list of VCs kept in the VC list 180. Thus, the abr.sub.-- head and abr.sub.-- tail pointers 418 and 420 of the ABR schedule table entries 402 along with the VC list 180 are used to assign a linked list of ABR and UBR VCs to each ABR schedule table entry 402. The linked list of ABR and UBR VCs located at a given schedule table entry 402 contains the complete set of ABR and UBR VCs which are scheduled to transmit a cell at the time slot represented by the location 404 of the entry 402 in the ABR schedule table 174. The valid bit 422 indicates whether or not the abr.sub.-- head and abr.sub.-- tail pointers 418 and 420 in a given entry 402 are valid. When the valid bit 422 is asserted, the pointers in the entry are valid. Otherwise there are no ABR or UBR VCs to be scheduled at the time represented by the entry 402, and the pointers are ignored. FIG. 20a shows 2 separate lists implemented using the abr.sub.-- head and abr.sub.-- tail fields 418 and 420 of the ABR schedule table 178 and the VC list 180. The list indicated by entry 402 at location 56 contains 4 entries 424: 3, 4, 1021, and 1. The list indicated by entry 402 at location 57 contains 2 entries 424: 5 and 1022. As the ABR schedule table 178 is scanned by the tx rate scheduler FSM 120, the ABR/UBR list at the current schedule table entry 402 is appended to the tail of a linked list called the ABR/UBR work list 428 (hereinafter "work list 428"), shown in FIG. 20b. The work list is implemented with two worklist pointers 123 stored within the segmentation engine 88, the worklist.sub.-- head and worklist.sub.-- tail pointers 430 and 432. These two structures are pointers into the VC list 180. A schedule table ABR/UBR list is appended to the work list by copying the value of abr.sub.-- head 418 into the location in the VC list 180 pointed to by worklist.sub.-- tail 432, and copying the value of abr.sub.-- tail 420 into worklist.sub.-- tail 432. The work list shown in FIG. 20b could have been produced by scanning schedule table entries 56 and 57, for example, where abr.sub.-- head at location 56 pointed to VC list entry 3 and abr.sub.-- tail pointed to VC list entry 1, abr.sub.-- head at location 57 pointed to VC list entry 5, and abr.sub.-- tail at location 57 pointed to VC list entry 1022. The ABR/UBR work list 428 is used to keep track of ABR and UBR cells to be DMA'd and transmitted. Whereas CBR VCs are read directly from the CBR schedule table 176 and then scheduled for DMA, ABR and UBR VCs are first copied onto the tail of the work list 428 from the ABR schedule table 178, then scheduled for DMA when they appear at the head of the work list 428. As ABR VCs are scheduled for DMA, they are popped off of the work list 428, then rescheduled into the ABR schedule table 178 according to the ABR parameters in effect at rescheduling time. As UBR VCs are scheduled for DMA, they are popped off of the work list 428 and rescheduled into the ABR schedule table 178 at the location specified by the peak cell rates of the VCs. When an ABR or UBR VC is rescheduled into a given entry in the ABR schedule table 178, it is added to the head of the ABR/UBR list located at the given schedule table entry, as will be further described in conjunction with the tx rate scheduler FSM 120. The schedule table 174 according to the preferred embodiment supports CBR rates, ABR allowed cell rates or UBR peak rates in the range of approximately 36.6 kb/s to 149.76 mb/s. However, it may be desirable to achieve CBR rates or UBR peak rates down to approximately 8 Kb/s, and it is essential for compliance with the ATM Forum Traffic Management Specification to support ABR rates down to 4.2 kb/s (10 cells/s). In order to achieve these low rates without expanding the schedule table to an unreasonable size, 2 per-VC variables, Prescale.sub.-- val (268) and Prescale.sub.-- count (274), stored in the tx VC state table 254 (FIG. 14), are used. Prescale.sub.-- val specifies a scaling-down of the basic schedule-table implemented rate according to the following equation: Rate=Schedule.sub.-- table.sub.-- rate/(Prescale.sub.-- val+1) For example, if prescale.sub.-- val for a VC is programmed with the value 0, then the rate specified on the VC will be equal to that implemented by the schedule table 174. If prescale.sub.-- val is programmed with the value 1, the rate on the VC will be half that implemented by the schedule table 174. Prescale.sub.-- count is used by the tx rate scheduler 120 to perform the scaling-down operation, as will be further described. For CBR flows, prescale.sub.-- val is programmed by the driver 24 and is never modified by the SAR controller 62. A given CBR rate maps into a given pattern of entries in the CBR schedule table 176 as follows: for every entry for a given VC in the CBR schedule table 176, the entry will receive (1/(st.sub.-- size*(prescale.sub.-- val+1)))th of the link bandwidth, where st.sub.-- size is the size of the CBR schedule table 176 in units of entries. Thus, if a VC appears only once in the CBR schedule table 176, prescale.sub.-- val for the VC is set to 0, and the CBR schedule table 176 contains 2119 entries, the VC will receive (1/2119)*149.76 Mb/s=70.67 Kb/s of bandwidth at STS-3c/STM-1 line rates. If, for example, the driver 24 wishes to allocate one half of the link bandwidth to CBR VC J, it fills half of the cbr.sub.-- vc entries in the cbr.sub.-- vc column being used with the value J, and programs prescale.sub.-- val for the VC with 0. For ABR and UBR flows, prescale.sub.-- val is not used. The tx rate scheduler modifes prescale.sub.-- count as necessary, according to the ABR protocol for ABR flows, or according to the fixed peak rate specified by the driver 24 for UBR flows. For all three types of flows, prescale.sub.-- count is initialized to 0 by the driver 24. Tx Rate Scheduler FSM and Tx DMA Scheduler FSM The tx rate scheduler FSM 120 performs the following functions: scans the off-chip schedule table 174, reading cbr entries 400 from the CBR schedule table 176 and abr entries 402 from the ABR schedule table 178; for each valid entry found in the schedule table 174, calls the tx DMA scheduler FSM to post a data DMA request or idle slot report request to the DMA request FIFO 125; calculates, in the RM cell request generator 435, the timing for the generation of RM cells according to ABR rates in effect for a given ABR VC, and posts requests to the tx DMA scheduler 122 to post an RM cell request to the DMA request FIFO 125; reschedules ABR and UBR flows which have had DMA requests posted to the tx DMA request FIFO 125 by the tx DMA scheduler 122; schedules new, presently unscheduled ABR/UBR VCs into the ABR schedule table 178. The tx DMA scheduler 122 performs the following functions: It reads the tx pending slot FIFO 200 and moves tx slot descriptors 158 from the tx free slot list 161 to the appropriate tx active slot list 162 as necessary; In response to requests from the tx rate scheduler FSM 120, it reads parts of VC state from the tx VC state table 254, reads tx slot descriptors 240 from the active slot list 162, and queues ABR, UBR, and CBR data DMA requests, idle slot report requests, and RM cell requests to the tx DMA FIFO 125. It moves tx slot descriptors 240 from tx active slot lists 162 to the tx free slot list 161 as tx slots are consumed. According to the preferred embodiment, the rate at which the tx rate scheduler 120 (also referred to as the tx rate scheduler 120) scans the schedule table is at least 1.2 times as fast as a cell time at STS-3c/STM-1 line rates (.apprxeq.2.83 .mu.s). This allows the tx rate scheduler 120 to effectively "look into the future" a number of cell times and post requests to the tx DMA scheduler 122 to fill the tx DMA request FIFO 125 with requests for PCI transfers if PCI latency prohibits the tx DMA FSM 126 from making progress on the requests. This ensures that the PCI bus 18 can be used efficiently by the tx DMA FSM 126 when bus bandwidth becomes available. As seen in FIG. 20a, five different pointers facilitate the scanning of the schedule table by the tx rate scheduler 120: CBR.sub.-- current.sub.-- time (436), ABR.sub.-- current.sub.-- time (438), CBR.sub.-- sch (440), CBR.sub.-- schedule.sub.-- time (not shown), and ABR.sub.-- schedule.sub.-- time (444). The CBR.sub.-- current.sub.-- time and ABR.sub.-- current.sub.-- time pointers keep track of the time at which cells associated with entries in the CBR and ABR schedule tables are to be transferred from the tx data FIFO, while the ABR.sub.-- schedule.sub.-- time and CBR.sub.-- sch pointers are used by the tx rate scheduler FSM 120 to scan the schedule tables. The pointers function as follows: CBR.sub.-- Current.sub.-- time This pointer is generated by a counter in the tx phy FSM 134 and points to location 0 of the CBR schedule table 176 after initialization. It advances by one schedule table entry 400 every time a cbr cell is transmitted from the tx data FIFO to the PHY interface, and thus advances at a maximum rate equal to the STS-3c/STM-1 line rate. It wraps at the end of the ABR/UBR portion of the schedule table (4K entries). The SAR controller 62 never actually accesses the CBR schedule table entry 400 pointed to by the CBR.sub.-- current.sub.-- time pointer. ABR.sub.-- Current.sub.-- time This pointer is generated by a counter in the tx phy FSM 134 and points to location 0 of the ABR schedule table 178 after initialization. It advances by one schedule table entry 402 every time an ABR/UBR cell is transmitted from the tx data FIFO to the PHY interface, and thus advances at a maximum rate equal to the STS-3c/STM-1 line rate. It wraps at the end of the ABR/UBR portion of the schedule table (4K entries). The SAR controller 62 never actually accesses the schedule table entry pointed to by the ABR.sub.-- current.sub.-- time pointer. ABR.sub.-- Schedule.sub.-- time This pointer is generated by the tx rate scheduler FSM 120 and points to location 0 of the ABR schedule table after initialization. It is advanced by the tx rate scheduler 120 through successive locations in the ABR schedule table 178 at a rate much faster than the ABR.sub.-- current.sub.-- time pointer; as herein implemented, about 1.2 times faster than STS-3c/STM-1 line rates. The ABR.sub.-- schedule.sub.-- time pointer therefore often represents a point in time which is ahead of the point in time represented by the current time counter. As herein embodied, it will never be allowed to be more than 32 locations ahead of the ABR.sub.-- current.sub.-- time pointer. The tx rate scheduler FSM 120 reads the abr.sub.-- head 418 and abr.sub.-- tail 420 fields of the abr entry 402 at the location 404 pointed to by the ABR.sub.-- schedule.sub.-- time pointer. This pointer wraps at the end of the ABR schedule table 178; i.e. at 4K. CBR.sub.-- schedule.sub.-- time This pointer is generated by the tx rate scheduler FSM 120 and points to location 0 of the CBR schedule table after initialization. It is advanced by the tx rate scheduler 120 through successive locations in the ABR schedule table 178 at a rate much faster than the CBR.sub.-- current.sub.-- time pointer; at least 1.2 times faster than STS-3c/STM-1 line rates. The CBR.sub.-- schedule.sub.-- time pointer therefore often represents a point in time which is ahead of the point in time represented by the current time counter. As herein embodied, it will never be allowed to be more than 32 entries ahead of the ABR.sub.-- current.sub.-- time pointer. This pointer wraps at the end of the ABR schedule table; i.e. at 4K. CBR.sub.-- sch This pointer is generated by the tx rate scheduler FSM 120 and points to location 0 of the CBR schedule table after initialization. It is advanced by the tx rate scheduler 120 at the same rate as the CBR.sub.-- schedule.sub.-- time pointer. The tx rate scheduler FSM 120 reads the cbr entry 400 in one of the CBR columns (either CBR1 (408) or CBR2 (410)) at the location pointed to by the CBR.sub.-- sch pointer. This pointer wraps at the end of the variable-length CBR portion of the CBR schedule table 176. Cbr.sub.-- curtime and abr.sub.-- curtime hereinafter refer to the position of (or the values held in) the CBR.sub.-- current.sub.-- time and ABR.sub.-- current.sub.-- time pointers respectively, whereas cbr.sub.-- sch refers to the position of the cbr.sub.-- sch pointer, cbr.sub.-- sch.sub.-- time refers to the position of the CBR.sub.-- schedule.sub.-- time pointer and abr.sub.-- sch.sub.-- time refers to the position of the ABR.sub.-- schedule.sub.-- time pointer. Separate CBR.sub.-- current.sub.-- time and ABR.sub.-- current.sub.-- time pointers are used when GFC is enabled, as will be further described. When GFC is disabled, only a single current.sub.-- time pointer need be used. In this case, abr.sub.-- curtime will take on the same value as cbr.sub.-- curtime. As will be seen, the schedule table 174 and the above described pointers provide a mechanism for ensuring that data for a given VC is transferred from the tx data FIFO 132 at the rate that was intended for the VC when entries for the VC were written into the schedule table 174. For example, valid entries 402 for a given ABR VC are placed in the ABR schedule table 178 at intervals corresponding to the rate at which they should be transmitted. The entries 402 are read from the ABR schedule table 178 at locations pointed to by the ABR.sub.-- schedule.sub.-- time pointer. Data transfers are initiated from the host memory 22 to the tx data synch FIFO 128, and ultimately to the tx data FIFO 132, in response to the entries read. Since the ABR.sub.-- schedule.sub.-- time pointer leads the ABR.sub.-- current.sub.-- time pointer, data can reside in the tx data FIFO 132 by the time the ABR.sub.-- current.sub.-- time pointer reaches the same location at which the ABR.sub.-- schedule.sub.-- time pointer pointed when the corresponding entry 402 was read. Thus, as will be seen, the tx PHY FSM 134 transfers cell data from the tx data FIFO 132 to the PHY interface 80 when the ABR.sub.-- current.sub.-- time pointer reaches the value that the ABR.sub.-- schedule.sub.-- time pointer held when the data DMA transfer was initiated. In this way, cell data leaves the tx data FIFO 132 at the rate that was intended for the VC when the entries for the VC were placed at intervals in the ABR schedule table 178. The tx rate scheduler 120 and tx DMA scheduler 122 operate generally as shown in the high level flow diagram of FIG. 21. The tx rate scheduler 120 first checks for an abr entry 402 at abr.sub.-- sch.sub.-- time; that is, at the location presently pointed to by the ABR.sub.-- schedule.sub.-- time pointer (step 450). If a valid entry 402 exists here (step 452), the list indicated by the ABR.sub.-- head 418 and ABR.sub.-- tail 420 pointers of the entry 402 is appended to the end of the worklist (step 454). If no valid entry 402 exists here, step 454 is skipped. The tx rate scheduler 120 then checks the CBR schedule table 176 at cbr.sub.-- sch.sub.-- time (step 456). If a valid cbr entry 400 exists here, (step 458), the tx rate scheduler 120 initiates a data transfer of data from the host memory 22 to the tx data synch FIFO 128 and on to the tx data FIFO 132 by invoking the tx DMA scheduler 122 to generate a DMA request to be placed in the DMA request FIFO 125 (step 460). If no valid entry exists at this location in the CBR schedule table (step 458), the tx rate scheduler 120 then checks to see if ABR DMA scheduling is allowed. (step 461). If so, the tx rate scheduler 120 checks to see if an entry exists in the worklist 428 (step 462). If so, the tx rate scheduler 120 reads the head of the worklist 428 (step 464) and initiates a data transfer for the VC at the head of the worklist 428 by calling the tx DMA scheduler 122 to generate a DMA request to be placed in the DMA request FIFO 125 (step 466). The VC is then rescheduled into the ABR schedule table 178 (step 468). After a DMA request is scheduled, or in the event that no valid entry exists in either the CBR schedule table or the work list, the CBR.sub.-- schedule.sub.-- time and ABR.sub.-- schedule.sub.-- time pointers are advanced (step 470) and the process is repeated. The scanning of the schedule table 174 is stalled when either the tx DMA request FIFO 125 becomes full or the tx DMA scheduler 122 has scanned 32 entries ahead of the "current time" into the schedule table. FIGS. 22a-22j show a flow diagram representing the detailed operation of the tx rate scheduler 120, while FIGS. 23a-23d show a flow diagram of the operation of the tx DMA scheduler 122. Referring now to FIG. 22a, the tx rate scheduler 120 first checks to see if ABR DMA scheduling is permitted (steps 472 and 474). If GFC controlled traffic is not enabled, ABR scheduling is permitted if the ABR.sub.-- schedule.sub.-- time pointer is within the permitted range of the ABR.sub.-- current.sub.-- time pointer. Thus, if abr.sub.-- sch.sub.-- time is within 32 cell times of abr.sub.-- curtime as shown at step 472, and if the segmented.sub.-- fifo signal is in its deasserted state at step 474 (indicating GFC controlled traffic is disabled), then ABR DMA scheduling is permitted, and is so indicated by the assertion of the signal ABR.sub.-- ON (step 476). Else the ABR.sub.-- ON signal is deasserted (step 478). If GFC controlled traffic is enabled, i.e. the segmented.sub.-- fifo signal is in its asserted state, then the tx rate scheduler 120 must not only ensure that abr.sub.-- sch.sub.-- time is within the permitted range of abr.sub.-- curtime, but also that there is room in the abr tx data FIFO 302 to accommodate at least one ABR cell. Thus, as shown at steps 472 and 474, if abr.sub.-- sch.sub.-- time is less than abr.sub.-- curtime+32, and if there are at least 16 long words available in the abr tx data FIFO 302 as indicated by the assertion of the signal fifo.sub.-- remain.gtoreq.16 LW output from the fifo.sub.-- remain counter 316, the ABR.sub.-- ON signal is asserted (step 476); else ABR.sub.-- ON is deasserted (step 478). If ABR DMA scheduling is permitted, i.e. ABR.sub.-- ON is asserted, the tx rate scheduler 120 proceeds to read the valid field 422 in the abr entry 402 in the ABR schedule table 178 at the location pointed to by the ABR.sub.-- schedule.sub.-- time pointer (step 480). If the valid bit is set (step 482), indicating a valid ABR entry 402 exists at this location, then the list indicated by the ABR.sub.-- head and ABR.sub.-- tail fields 418 and 420 of the entry 402 is appended to the tail of the worklist 428. The worklist 428 is appended as shown in FIG. 22b. First a worklist.sub.-- valid bit is checked (step 484). If the worklist.sub.-- valid bit is deasserted, indicating that no valid entries presently exist in the worklist, then the worklist.sub.-- head pointer 430 is written with the VC number contained in the abr.sub.-- head field 418 of the ABR schedule table entry 402 at the location pointed to by the ABR.sub.-- schedule.sub.-- time pointer (step 488), and the worklist.sub.-- tail pointer 432 is written with the VC number contained in the abr.sub.-- tail field 420 of the abr entry 402 at the location pointed to by the ABR.sub.-- schedule.sub.-- time pointer (step 490). If the worklist.sub.-- valid bit is asserted, then the worklist 428 is not presently empty. In this case, the list indicated by the ABR.sub.-- head and ABR.sub.-- tail fields is appended to the tail of the worklist by writing the VC number contained in the abr.sub.-- head field 418 of the entry 402 at the location pointed to by the ABR.sub.-- schedule.sub.-- time pointer to the location in the VC List 180 pointed to by the worklist.sub.-- tail pointer 432 (step 492), and by writing the VC number contained in the abr.sub.-- tail field 420 of the entry 402 to the worklist.sub.-- tail pointer 432 (step 490). In either case, the worklist.sub.-- valid bit is then set (step 493). Referring back to FIG. 22a, the tx rate scheduler 120 next checks to see whether a DMA request for a CBR cell should be placed in the tx DMA request FIFO 125. If cbr.sub.-- sch.sub.-- time is less than cbr.sub.-- curtime+32 (step 494), and if a cbr.sub.-- inhibit bit (to be further described later) is deasserted (step 495), the CBR schedule table 176 is read at the location currently pointed to by the cbr.sub.-- sch pointer (step 496). Referring now to FIG. 22c, which shows the cbr handling portion of the tx rate scheduler 120, if the valid bit at this location is asserted, indicating that a valid CBR entry exists here (step 498), then the CBR VC number to be scheduled for DMA is read from the VC field at this location (step 500). This VC number is used to index the tx VC state table 254. The tx rate scheduler 120 then reads the contents of the prescale.sub.-- count field in the tx VC state table 254 for the VC (step 502). If prescale.sub.-- count is non-zero (step 504), then the VC may not transmit a cell. In this case, prescale.sub.-- count value is decremented (step 506). If prescale.sub.-- count is 0 (step 504), then the tx rate scheduler 120 determines whether data is available in host memory 22 for the VC. Accordingly, the Active bit is in the tx VC state table 254 for the VC read (step 508). If it is deasserted (step 510), no data exists to be transmitted on this CBR VC, and the tx rate scheduler proceeds to schedule any pending ABR/UBR VCs for DMA in the event that ABR scheduling is allowed (step 512). If the active bit is set (step 510), data exists in the active slot list 162 for the CBR VC. The VC's prescale.sub.-- count value is then reset to the value of prescale.sub.-- val; that is, the prescale.sub.-- count field in the tx VC state table 254 for the VC is written with the value contained in the prescale.sub.-- val field in the tx VC state table 254 for the VC (step 514). The tx rate scheduler 120 then determines what value should be passed to the tx DMA scheduler 122 to be used as the Sched.sub.-- Time timestamp field in the DMA request entry to be posted. When GFC is disabled and the tx data FIFO 132 is not segmented, only a single timestamp need be used; thus, when the segmented.sub.-- fifo signal is deasserted (step 516), a schedule.sub.-- time variable is set to abr.sub.-- sch.sub.-- time (step 518). If the segmented.sub.-- fifo signal is asserted, two separate tx data FIFOs are operating independently and thus their respective entries require independent timestamps; thus, the schedule.sub.-- time variable for CBR traffic is set to cbr.sub.-- sch.sub.-- time (step 520), while the schedule.sub.-- time variable for ABR/UBR traffic will be timestamped with abr.sub.-- sch.sub.-- time. A DMA.sub.-- request signal is then asserted (step 521), invoking the tx DMA scheduler 122 to post a CBR DMA request entry to the DMA request FIFO 125. Referring now to FIGS. 23a-23d, the tx DMA scheduler 122 senses the assertion of the DMA.sub.-- request signal to prepare a DMA request entry for the DMA request FIFO 125 (step 522). If the request is from the RM cell request generator 435 (step 524), the tx DMA scheduler builds an RM cell request entry 354 (step 526) and indicates that a cell has been scheduled for DMA by asserting a cell.sub.-- sent signal (step 528). The RM cell request entry 354 fields are written as follows: VC: from the RM cell request generator FSM 435, the VC on which the RM cell is to be transmitted. Sched.sub.-- time: the current value of schedule.sub.-- time as passed from the tx rate scheduler FSM. RM: =1. CLP: from the RM cell request generator FSM 435. FORWARD: from the RM cell request generator FSM 435. If the request is not from the RM cell request generator FSM 435 (step 524), then the tx DMA scheduler 122 has been called from either the cbr or abr handling portions of the tx rate scheduler FSM. In this case, the tx DMA scheduler 122 first reads the slot.sub.-- size field 234 in the slot descriptor 240 at the head of the tx active slot list 162 for the VC (step 527), and then reads the tx.sub.-- slot.sub.-- ptr field 292 in the tx VC state table 254 for the VC (step 529). If the tx.sub.-- slot.sub.-- ptr field is 0 (step 530), the beginning of a transmit slot is being processed. The size of the DMA transfer to be requested is then determined. If the raw bit 222 in the entry at the head of the tx active slot list 162 for the VC is asserted (step 532), then the size of the DMA transfer will be 52 bytes; thus, a DMA.sub.-- size variable is set to 52 (step 533). If the idle bit 224 in the entry at the head of the tx active slot list 162 for the VC is asserted (step 534), then the tx DMA scheduler 122 proceeds to an idle cell processing portion, to be further described. If the idle bit 224 is deasserted (step 534), then the tx DMA scheduler 122 will build a data DMA request entry 350. First determined is the size of the DMA transfer to be requested. Accordingly, the tx DMA scheduler 122 checks the chtyp field in tx VC state for the VC to see if the request is for an MPEG cell (step 536). If it is not, then the request is for an AAL5 cell, and the size of the DMA transfer is determined. The tx.sub.-- slot.sub.-- ptr field in tx VC state 254 for the VC indicates the byte position within the current slot from which data is currently being DMA'd. Therefore, the size of the DMA transfer to be requested is determined as the minimum of either slot.sub.-- siz-tx.sub.-- slot.sub.-- ptr, or 48 bytes. The DMA.sub.-- siz variable is set to this value at step 538. If at step 536 the request is determined to be for an MPEG cell, then the size of the DMA transfer depends upon whether the request is for the final cell in an 8-cell MPEG superpacket. Therefore, at step 540 the MPEG.sub.-- count field in tx VC state for the VC is checked. This field was initialized to 0 and is updated on the transmission of each cell in an 8-cell MPEG superpacket. Thus, if MPEG.sub.-- count is less than 7, then the size of the DMA transfer to be requested is determined as the minimum of either slot.sub.-- siz-slot.sub.-- ptr or 48 bytes, as for a regular AAL5 packet. DMA.sub.-- size is then set to this value at step 538, and the MPEG.sub.-- count value is incremented. If the MPEG.sub.-- count value is equal to 7 (step 540), the size of the DMA transfer to be requested is determined as the minimum of either slot.sub.-- siz-slot.sub.-- ptr, or 40 bytes. The DMA.sub.-- size variable is set accordingly at step 542, and MPEG.sub.-- count is reset. Once the size of the DMA has been determined, the DMA address from which data should be DMA'd is determined by adding the value in slot.sub.-- ptr to the contents of the base.sub.-- address field 238 in the tx active slot list 162 for the VC (step 544). Referring now to FIG. 23b, the Data DMA request entry is built at step 546 as follows: VC : When called from the cbr handling portion of the tx rate scheduler 120, the contents of the VC field read from the CBR schedule table entry 400 at the location pointed to by the cbr.sub.-- sch pointer. When called from the abr handling portion of the tx rate scheduler 120, the contents of the VC field from the entry at the head of the worklist 428. CBR: the contents of the RC field in the tx VC state table 254 for the VC. When called from the cbr handling portion of the tx rate scheduler, is =1. When called from the abr handling portion of the tx rate scheduler, is =0. Sched.sub.-- time: schedule.sub.-- time as passed from the tx rate scheduler FSM 120. RM: 0 CLP: the contents of the CLP field in the tx VC state table 254 for the VC CRC.sub.-- Ena: 1 DMA.sub.-- Size: Raw cell: 52 bytes AAL5/MPEG cell: the contents of the variable DMA.sub.-- size as determined by the tx DMA scheduler FSM at steps 538 or 542. EOP: 1 if the tx slot descriptor for the VC indicates a raw cell and the EOP bit is set, or 1 if the tx VC state table 254 for the VC indicates an AAL5 or MPEG VC and the EOP bit is set in the VC's tx slot descriptor, indicating the end of a packet. Add.sub.-- MPEG.sub.-- Trailer: 1 if the chtyp field in the tx VC state table 254 for the VC indicates an MPEG VC. DMA Address: as determined by the tx DMA scheduler 122 at step 544. INT: raw cell: 1 if the EOP field in the tx.sub.-- active.sub.-- slot.sub.-- list for the VC is set. AAL5 cell: 1 if the end of a slot has been encountered and either the AAL5.sub.-- SM field in the tx VC state table 254 is set, or the EOP bit in the tx slot descriptor is set. Once the Data DMA request has been built, it is written to the tail of the tx DMA request FIFO 125 (step 548), and the cell.sub.-- sent bit is set to indicate that a cell is scheduled for DMA (step 550). If the cell scheduled was not a raw cell (step 552), i.e. was an AAL5 or MPEG type cell, the tx.sub.-- slot.sub.-- ptr value must be updated. Accordingly, referring to FIG. 23c, DMA.sub.-- size is added to tx.sub.-- slot.sub.-- ptr (step 554). If tx.sub.-- slot.sub.-- ptr is not yet equal to slot.sub.-- siz (step 556), the entire slot has not yet been consumed. The tx.sub.-- slot.sub.-- ptr field in tx VC state for the VC is therefore updated with the new value of tx.sub.-- slot.sub.-- ptr (step 558), and a tds.sub.-- complete bit is set, returning control to the tx rate scheduler FSM (step 560). If tx.sub.-- slot.sub.-- ptr is now equal to slot.sub.-- siz (step 556), the end of a slot has been encountered (step 561). The transmit slot descriptor 240 is then moved from the head of the active slot list 162 to the tail of the free slot list 161 (step 562). The head pointer 243 for the tx active slot list for the VC is then compared to the tail pointer 242 of the tx active slot list for the VC (step 564). If the pointers are equal, the end of the active slot list has been reached. In this case, the active field 280 in tx VC state 254 for the VC is reset to 0 (step 566), deactivating the VC from scheduling. The tds.sub.-- complete bit is then set, returning control to the tx rate scheduler FSM (step 560). If the head and tail pointers 243 and 242 for the active slot list 162 for the VC are determined at step 564 to be unequal, then the head pointer 243 into the tx active slot list for the VC is updated by copying the link field 241 in the current tx active slot list entry into the tx active slot list head pointer 243 (step 568). The tds.sub.-- complete bit is then set, returning control to the tx rate scheduler 120 (step 560). Referring back to FIG. 23a, if the value of tx.sub.-- slot.sub.-- ptr as checked at step 530 is determined to be non-zero, either an idle slot is to be processed or processing of an AAL5 or MPEG type slot is to be continued. Accordingly, the tx DMA scheduler 122 checks the idle field 224 in tx VC state for the VC. If the idle bit is reset, processing of an AAL5 or MPEG slot continues as described from step 536. If the idle field is set, idle slot processing continues from step 572 (FIG. 23d). Idle cell processing is thus entered at step 572 either from step 570 or as previously described from step 534. At this point, The tx DMA scheduler 122 determines whether an idle slot report request 352 should be generated. If the EOP bit in the tx active slot list 162 for the VC is set, and if the end of a slot has been encountered, then an idle slot report request 352 is generated. Note that, as for idle cells, the size of the DMA request is 0, since no data is actually transferred for idle slots. The Idle slot report request is generated as follows at step 574: VC: the contents of the VC field read from the CBR schedule table entry at the location pointed to by the cbr.sub.-- sch.sub.-- time pointer. CBR: the contents of the RC field in the tx VC state table 254 for the VC. When called from the cbr handling portion of the tx rate scheduler, is =1. When called from the abr handling portion of the tx rate scheduler, is =0. RM: 0 DMA.sub.-- Size: 0 The Idle cell report request 352 is then written to the tail of the tx DMA request FIFO 125 (step 576). Whether or not an idle cell report request 352 was generated, the tx DMA scheduler 122 then proceeds to set DMA.sub.-- size to 48; i.e. the size in bytes of an idle cell (step 578). Processing then proceeds from step 554 as previously described. Referring back to FIG. 22c, the tx rate scheduler FSM 120 awaits the assertion of the tds.sub.-- complete signal (step 580). Referring now to FIG. 22d, if the segmented.sub.-- fifo signal is deasserted (step 581), a lastcell.sub.-- time parameter is written with the current abr.sub.-- sch.sub.-- time (step 582), and a lasttime.sub.-- valid bit is set (step 583). These signals will be further described later in conjunction with the scheduling of new VCs. The tx rate scheduler 120 then proceeds with the updating of the schedule time pointers. If, at step 498 (FIG. 22a), no CBR VC is located at the CBR schedule table entry being read (the valid field of the entry is deasserted), and if ABR.sub.-- ON is asserted (step 570) indicating that ABR DMA requests are permitted, then the tx rate scheduler FSM 120 checks the worklist 428 to see if there is an ABR/UBR VC waiting to generate a DMA request. The tx rate scheduler 120 first checks the worklist.sub.-- valid bit (step 584). If the worklist.sub.-- valid bit is 0, there are no ABR or UBR VCs waiting for DMA scheduling, so the tx rate scheduler 120 proceeds to update the schedule table pointers. If the worklist.sub.-- valid bit is set, the value at the head of the worklist is the VC number to be scheduled for DMA (step 585). The worklist 428 is then updated. Accordingly, at step 586 the worklist.sub.-- head pointer 430 is compared to the worklist.sub.-- tail pointer 432. If the pointers are equal, the worklist 428 is now empty and the worklist.sub.-- valid bit is reset to 0 (step 588). If the pointers are not equal, the worklist.sub.-- head pointer 430 is updated to point to the next entry in the worklist 428 by writing the value at the location in VC List 180 pointed to by the worklist.sub.-- head pointer 430 to the worklist.sub.-- head pointer 430 (step 590). The tx rate scheduler 120 now proceeds to initiate a data transfer from the host memory 22 to the tx data synch FIFO 128 and on to the tx data FIFO 132 by invoking the tx DMA scheduler FSM 122 to schedule a DMA request. The tx rate scheduler 120 reads the contents of the prescale.sub.-- count field in the tx VC state table 254 for the VC (step 592). If prescale.sub.-- count is non-zero (step 594), then the VC may not transmit a cell. In this case, the prescale.sub.-- count value is decremented (step 596), and the VC is rescheduled into the ABR schedule table 178. Accordingly, reschedule.sub.-- vc bit is set, invoking the rescheduling portion of the tx rate scheduler 120. A parameter "t" is set to 4K, step (598) indicating the number of locations from current schedule time at which the VC should be re-entered into the ABR schedule table 178. The value of 4K effectively reschedules the VC at the same location in the ABR schedule table 178. The tx rate scheduler 122 then waits at step 600 for the assertion of a reschedule.sub.-- done bit from the rescheduling portion of the tx rate scheduler (to be further described later), and then proceeds to update the schedule table pointers. If the prescale.sub.-- count value as checked at step 594 was found to be 0, then the tx rate scheduler 120 determines whether data is available in host memory 22 for the VC. Accordingly, the active bit 280 in the tx VC state table 254 for the VC read (step 602). If it is deasserted (step 604), no data exists to be transmitted on this ABR/UBR VC, so the sch bit 282 in tx VC state for the VC is reset to 0 (step 606), indicating that this VC is not currently scheduled in the ABR schedule table 178. If the active bit is asserted, the tx rate scheduler 120 proceeds to schedule an ABR/UBR VC for DMA. Referring now to FIG. 22f, before the VC is scheduled for DMA, the prescale.sub.-- count field in the tx VC state for the VC is reset to its initial value. Each VC has associated with it a value delta.sub.-- T which represents the time in number of cells, and therefore in number of locations or rows 404 in the ABR schedule table 178, by which successive cells on a VC are to be transmitted. In the case of an ABR VC, the value of delta.sub.-- T is derived from the current ACR (Allowed Cell Rate) for the VC, which is read from the ABR value table for the VC. In the case of a UBR VC, the value of delta.sub.-- T is derived from the peak cell rate, which is read from the abr parameter table 152 for the VC. The prescale.sub.-- count field in tx VC state for the VC is written with the integer portion of delta.sub.-- T divided by the size of the schedule table 178; herein, the integer portion of delta.sub.-- T divided by 4096 (step 608). The prescale.sub.-- cnt field then effectively holds the number of times the rate scheduler 120 should cycle through ABR schedule table 178 before scheduling the VC for DMA. The rate scheduler next sets the schedule.sub.-- time parameter to abr.sub.-- sch.sub.-- time (step 610). This value is to be passed to the DMA scheduler FSM 122 to be written as the timestamp portion of any data or RM cell requests. The DMA request signal is then asserted (step 612), invoking the DMA scheduler FSM to post a DMA request to the DMA request FIFO 125. The rate scheduler 120 then waits for the tds.sub.-- complete signal from the DMA scheduler 122 (step 614), indicating that the request has been successfully posted. Referring to FIGS. 23a-23d, the DMA request is built by the tx DMA scheduler FSM 122 in the same manner as was previously described in relation to the CBR handling portion of the tx rate scheduler FSM. However, when a data DMA request entry is built (FIG. 23b step 546), the CBR field in the data DMA request entry is set to 0 when called from the ABR handling portion of the tx rate scheduler 120. Likewise, the CBR field in an idle slot report request entry is also set to 0 when called from the ABR handling portion of the tx rate scheduler 120 (FIG. 23d step 574). Referring back to FIG. 22f, upon detecting the assertion of the tds.sub.-- complete signal (step 614), the signal DMA.sub.-- request.sub.-- on.sub.-- abr is asserted (step 616). This signal is used to decrement the fifo.sub.-- remain counter 317 as previously described. The tx rate scheduler 120 then sets the value in a lastcell.sub.-- time register to abr.sub.-- sch.sub.-- time (step 618), and then sets a lasttime.sub.-- valid bit (step 620). The lastcell.sub.-- time register stores abr.sub.-- sch.sub.-- time for the last ABR cell scheduled for DMA, and the lasttime.sub.-- valid bit indicates that the value in the lastcell.sub.-- time register is valid. The lastcell.sub.-- time register and the lasttime.sub.-- valid bit are used by the rate scheduler FSM when scheduling new VCs into the schedule table, and will be further described later in conjunction therewith. After scheduling the ABR DMA request, the tx rate scheduler 120 calls the rescheduling portion of the tx rate scheduler 120 to reschedule the VC into the ABR schedule table. Accordingly, a reschedule.sub.-- vc signal is asserted, and a value "t" is passed which indicates the position in the ABR schedule table 178 at which the VC should be appended (step 622). The delta.sub.-- T value for the VC is first prescaled as previously described by performing the function (delta.sub.-- T/table.sub.-- size), where table.sub.-- size is the size of the ABR schedule table 178, herein 4096. The remainder of the function then gives the position in the ABR schedule table 178 relative to abr.sub.-- sch.sub.-- time at which the VC should be appended, while the integer portion of the function is written as the prescale.sub.-- cnt value in tx VC state for the VC (FIG. 22f step 608). It is the remaining portion of the function that is passed to the rescheduler portion of the tx rate scheduler 120 as the parameter "t". Note that when the tx DMA scheduler 122 issues a DMA request for an ABR or UBR VC, it will reschedule the VC in the schedule table whether or not the VC has any data left to send. This means that an ABR or UBR VC at the head of the worklist 428 may in fact have no data available for fetching. If this event occurs, the active condition check at step 604 will fail. The VC will be taken off of the work list, it will not be rescheduled, and the sch bit will be cleared in the tx VC state table 254 for the VC to indicate to the rate scheduler FSM that the VC is no longer scheduled for transmission. When, at some point in the future, the host posts a tx slot for the VC, the VC will be placed at the tail of the worklist 428 (as will be further described) and the sch bit will be set. The rescheduling portion of the rate scheduler FSM reschedules VCs into the ABR schedule table either in the event that the prescale.sub.-- cnt value for the VC was zero, or in the event that a DMA request has been generated for the VC. Referring to FIG. 22j, the rescheduler portion of the tx rate scheduler FSM 120 awaits the assertion of the reschedule.sub.-- vc signal (step 624). When the signal is asserted, the tx rate scheduler 120 accepts as input a VC number and a time value "t". For VCs for which the prescale count was non-zero, "t" is set to 4K (FIG. 22e step 598), effectively resch | ||||||
