Network switch with statistics read accesses

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is related to the following U.S. applications: pending U.S. application Ser. No. 08/774,605 entitled “Network Switch with Multiple Bus Architecture” by Walker et al; pending U.S. application Ser. No. 08/774,557 entitled “Network Switch with Shared Memory System” by Mayer et al; pending U.S. application Ser. No. 08/774,601 entitled “A Programmable Arbitration System for Determining Priority of the Ports of a Network Switch” by Kotzur et al; U.S. application Ser. No. 08/774,602 entitled “Multiport Polling System for a Network Switch” by Walker et al., now U.S. Pat. No. 5,862,338; pending U.S. application Ser. No. 08/774,555 entitled “Network Switch with Separate Cut-through Buffer” by Kotzur et al; pending U.S. application Ser. No. 08/774,524 entitled “Network Switch with Dynamic Backpressure Per Port” by Witkowski et al; pending U.S. application Ser. No. 08/777,501 entitled “A Network Switch With a Multiple Bus Structure and a Bridge Interface for Transferring Network Data Between Different Buses” by Witkowski et al; and pending U.S. application Ser. No. 08/774,547 entitled “Method and System for Performing Concurrent Read and Write Cycles in a Network Switch” by Walker et al, all of which have at least one common inventor, are commonly assigned and are filed concurrently with the present application.

FIELD OF THE INVENTION

The present invention relates to the field of networking devices, and more particularly to a network switch including a switch manager for gathering statistics information in a memory in response to a request by the processor and then informing the processor that the statistics are available, where the processor has ready access to the memory for retrieving the information.

DESCRIPTION OF THE RELATED ART

There are many different types of networks and network systems for sharing files and resources or for otherwise enabling communication between two or more computers. Networks may be categorized based on various features and functions, such as message capacity, range over which the nodes are distributed, node or computer types, node relationships, topology or logical and/or physical layout, architecture or structure based on cable type and data packet format, access possibilities, etc. For example, the range of a network refers to the distance over which the nodes are distributed, such as local-area networks (LANs) within an office or floor of a building, wide-area networks (WANs) spanning across a college campus, or a city or a state, global-area networks (GANs) spanning across national boundaries, etc.

The structure of a network generally refers to the cabling or media and media access used as well as the packet structure of the data transmitted across the media. Various structures are common, including Ethernet using coaxial, twisted pair or fiber-optic cables for operation at 10 megabits per second (Mbps) (e.g. 10Base-T, 10Base-F) or fast Ethernet operating at 100 Mbps (e.g. 100Base-T, 100Base-FX). ARCnet (Attached Resource Computer Network) is a relatively inexpensive network structures using coaxial, twisted pair or fiber-optic cables for operation at 2.5 Mbps. Token Ring topologies use special IBM cable or fiber-optic cable for operation between 1-16 Mbps. Of course, many other types of networks are known and available.

Each network generally includes two or more computers, often referred to as nodes or stations, which are coupled together through selected media and various other network devices for relaying, transmitting, repeating, translating, filtering, etc., the data between the nodes. The term “network device” generally refers to the computers and their network interface cards (NICs) as well as various other devices on the network, such as repeaters, bridges, switches, routers, brouters, to name a few examples. A network operating according to a given communications protocol may be expanded by using one or more repeaters, bridges or switches. A repeater is a hardware device that functions at the physical layer and re-transmits each received packet to every other port. A bridge operates at the data link layer of OSI Reference Model and increases efficiency by filtering packets to reduce the amount of unnecessary packet propagation on each network segment.

A network switch is similar in function to, yet more efficient than, a multiport bridge, which includes a plurality of ports for coupling to several similar networks for directing network traffic among the networks. A network switch usually includes a switching matrix coupled to the ports across a bus and memory for temporarily storing network data, such as Ethernet packets or the like. The switch may also include a processor for performing management functions, such as monitoring statistics, configuration and status information associated with data flow through the network ports. For example, the statistics information may include the number of Ethernet packets handled or dropped. The information may also include the number of “runts”, “overruns”, “jabbers”, late collisions, FCS errors, etc. Configuration data may include status and setup parameters associated with the ports, the switch matrix, memory devices, etc.

The processor was usually coupled to the network ports through the primary data path between the ports and the switch matrix. In this manner, the processor added significant overhead to the data bus when requesting statistical or configuration data. Such overhead traffic reduced the available bus bandwidth for handling network traffic, which is the primary function of a switch. The information was gathered by the ports themselves and then provided to the processor upon request. However, the network ports were usually busy handling network data, so that the processor was forced to wait for significant periods of time before finally receiving the information. This resulted in an inefficient use of the processor and the primary data bus.

It is desired to provide a network switch for gathering statistical information in a more efficient manner without substantially effecting network data flow through the switch and without forcing the processor into a significant number of wait states.

SUMMARY OF THE INVENTION

A network switch according to the present invention includes a plurality of network ports for receiving and transmitting data, where each port includes at least one statistics register for storing statistics information. The information is preferably Ethernet statistical and configuration information. The network switch also includes a switch manager, which further includes a memory, retrieval logic for detecting a statistics request signal and for respondingly retrieving the statistics information for storage in the memory, and response logic for asserting a statistics response signal after the statistics information is stored in the memory. The switch also includes a processor coupled to the switch manager through a bus, where the processor asserts the statistics request signal and then detects assertion of the statistics response signal. Upon detecting the response signal, the processor retrieves the statistics information from the memory. In this manner, the processor is removed from direct connection to the statistics registers and free to complete other tasks while the information is being gathered by the switch manager, thereby increasing the efficiency of the processor and of the network switch. The network switch is useful for facilitating communication in a network system including a plurality of networks coupled to the switch ports, where each network includes one or more network devices.

The switch manager preferably includes a statistics request register, which further includes a statistics request bit for providing the statistics request signal when set, where the processor writes to the statistics request register to set the statistics request bit. One method for effectuating assertion of the statistics request signal is to detect writing to the statistics request register, which may include one or more programmable parameters for specifying the particular statistics information to retrieve. For example, the statistics request register may include a programmable port number, register number and a count of the number of registers to read. The retrieval logic retrieves the statistics information from all of the registers of a port, from one register specified by the register number, or from a number of registers equal to the count beginning with the register identified by the register number. In this manner, the processor writes once to the statistics request register to initiate the request and to specify the particular information to retrieve. The statistics request register is preferably within the memory of the switch manager.

Once the information is stored within the switch manager, there are several ways to inform the processor. The switch manager preferably includes at least one status register including a ready bit indicative of whether the statistics query request is completed. For example, an interrupt register includes a statistics ready bit, which when set, causes an interrupt to the processor across the processor bus. The processor receives the interrupt and respondingly reads the interrupt register to determine the source of the interrupt. Alternatively, a polling register includes a statistics ready bit, where the processor periodically polls the polling register to determine the state of the statistics ready bit. Once set, the processor may retrieve the statistics information from the switch manager memory. Again, the status register(s) may be separate or part of the switch manager memory.

In the preferred embodiment, each of the ports includes a network interface, a processor port interface for enabling the switch manager to retrieve the statistical information, and a data bus interface for network traffic. The switch manager thus includes two separate bus connections to each of the ports, so that statistical reads do not interfere with network data packet flow. Also, each of the ports are preferably defined according to the Ethernet architecture, such as 10Base-T or 100Base-T or the like, although other types of protocols and architectures are contemplated for use with the present invention.

The processor retrieves the statistical information from the switch manager by executing cycles on the processor bus to the switch manager memory. The bus cycles may be regular processor cycles, but are preferably burst cycles to obtain a larger amount of data in a given amount of time.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained when the following detailed description of the preferred embodiment is considered in conjunction with the following drawings, in which:

FIG. 1 is a simplified diagram of a network system including a network switch according to the present invention;

FIG. 2 is a more specific block diagram of the network switch of FIG. 1;

FIG. 3A is a block diagram of an exemplary quad cascade device of FIG. 2 for implementing the ports of the network switch;

FIG. 3B is a diagram illustrating the signals of the particular quad cascade device shown in FIG. 3A;

FIG. 3C is an exemplary timing diagram illustrating processor read timing of the quad cascade device of FIG. 3A;

FIG. 3D is an exemplary timing diagram illustrating processor write timing of the quad cascade device of FIG. 3A;

FIG. 3E is an exemplary timing diagram illustrating processor burst read access timing of the quad cascade device of FIG. 3A;

FIG. 3F is an exemplary timing diagram illustrating a buffer status inquiry of each of the ports FIG. 3A;

FIG. 3G is an exemplary timing diagram illustrating a concurrent read and write cycle on the HSB of FIG. 2;

FIG. 3H is a flowchart diagram illustrating a procedure for executing a concurrent read and write cycle on the HSB of FIG. 2;

FIG. 4 is a block diagram of the switch manager of FIG. 2;

FIG. 5A is a more detailed block diagram of the bus controller block of FIG. 4;

FIG. 5B is a diagram illustrating buffers within the memory of the bus controller block of FIG. 5A;

FIG. 5C is a state diagram illustrating operation of the receive poll state machine within the bus controller block of FIG. 5A;

FIG. 5D is a state diagram illustrating operation of the transmit poll state machine within the bus controller block of FIG. 5A;

FIG. 6 is a more detailed block diagram of the memory controller block of FIG. 4;

FIGS. 7A-7E are more detailed block diagrams of the processor controller block of FIG. 4;

FIG. 8A is a simplified block diagram of the Thunder LAN port interface (TPI) of FIG. 2;

FIG. 8B is a more detailed block diagram of the TPI;

FIG. 8C is a block diagram illustrating the configuration and functionality of each of the Thunder LANs (TLANs) of FIG. 2;

FIG. 8D is a diagram illustrating the general format of a control list for execution by any of the TLANs;

FIG. 8E is a diagram illustrating a definition of TPI peripheral component interconnect (PCI) configuration registers used by the TPI associated with the PCI bus of FIG. 2;

FIG. 8F is a diagram illustrating the definition of the TPI control registers used by the TPI;

FIG. 8G is a flowchart diagram illustrating PCI initialization operations of the CPU of FIG. 2;

FIG. 8H is a flowchart diagram illustrating a receive operation for each of the TLANs;

FIG. 8I is a flowchart diagram illustrating a receive data transfer operation across the high speed bus (HSB) of FIG. 2;

FIG. 8J is a flowchart diagram illustrating a transmit data transfer operation across the HSB;

FIG. 8K is a flowchart diagram illustrating a transmit operation for each of the TLANs;

FIGS. 9A-9H are block diagrams illustrating the organization of the memory of FIG. 2;

FIG. 10 is an exemplary block diagram illustrating several transmit packet links incorporating a broadcast packet;

FIGS. 11A and 11B are block diagrams illustrating the organization of the static memory of FIG. 6;

FIG. 12A is a flowchart diagram illustrating the general operation of the network switch of FIG. 2 for receiving data packets into memory and for transmitting data packets in cut-through mode of operation;

FIG. 12B is a flowchart diagram illustrating the general operation of the network switch of FIG. 2 for transmitting data packets from memory;

FIG. 13 is a flowchart diagram illustrating hash lookup operation of the switch manager of FIG. 2; and

FIG. 14 is a flowchart diagram illustrating a hash lookup procedure for searching hash table entries in the memory of FIG. <b>2</b>.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring now to FIG. 1, a simplified network diagram is shown of a network system <b>100</b> including a network switch <b>102</b> implemented according to the present invention. The network switch <b>102</b> includes one or more “A” ports <b>104</b>, each for coupling to and communicating with one of several “A” networks <b>106</b> through an appropriate media segment <b>108</b>. Each media segment <b>108</b> is any type of media for connecting network devices, such as twisted-pair wire cable, fiber optic cable, etc. The ports <b>104</b> enable bidirectional communication or data flow between the network switch <b>102</b> and each of the networks <b>106</b>. Such bidirectional data flow is according to any one of several modes, such as half-duplex mode or full-duplex mode, for example. As shown in FIG. 1, there are up to “j”+1 networks <b>106</b> individually labeled A-NETWORK0, A-NETWORK1, . . . A-NETWORKj, where each network <b>106</b> is coupled to the network switch <b>102</b> through a corresponding one of the j+1 ports <b>104</b>, individually labeled A-PORT0, A-PORT1, . . . , A-PORTj. The network switch <b>102</b> may include any desirable number of ports <b>104</b> for coupling up to an associated number of networks <b>106</b>. In the embodiment described herein, j is an integer number equal to 23 for a total of 24 ports for coupling up to 24 networks <b>106</b>, where these ports will be referred to collectively as ports <b>104</b>, or individually as ports PORT0, PORT1, PORT2, . . . , PORT23, respectively.

In a similar manner, the network switch <b>102</b> further includes one or more “B” ports <b>110</b>, each for coupling to and interfacing a “B” network <b>112</b> through an appropriate media segment <b>114</b>. Again, each media segment <b>114</b> is any type of media for connecting network devices, such as twisted-pair wire cable, fiber optic cable, etc. The ports <b>110</b> are also bidirectional for enabling data flow between the network switch <b>102</b> and the networks <b>112</b> in a similar manner as described for the ports <b>104</b>. In the embodiment shown, there are “k”+1 ports <b>110</b>, individually labeled B-PORT0, B-PORT1, . . . , B-PORTk, for connecting up to k+1 networks <b>112</b>, individually labeled B-NETWORK0, B-NETWORK1, . . . B-NETWORKk. The network switch <b>102</b> may include any desirable number of ports <b>110</b> for coupling up to an associated number of networks <b>112</b>. In the specific embodiment shown, k is an integer equal to 3 for a total of 4 ports <b>110</b> for coupling up to four networks <b>112</b>. The “A” type ports and networks operate at a different network protocol and/or speed than the “B” type ports and networks. In the specific embodiment shown, the ports <b>104</b> and networks <b>106</b> operate according to the Ethernet protocol at 10 Megabits per second (Mbps), while the ports <b>110</b> and networks <b>112</b> operate according to the Ethernet protocol at 100 Mbps. The ports B-PORT0, B-PORT1, . . . B-PORT3 will be referred to herein collectively as the ports <b>110</b> and individually as PORT24, PORT25, . . . , PORT27, respectively.

The networks <b>106</b> and <b>112</b> include one or more data devices or data terminal equipment (DTE) that allows either input or output of data, or any type of network device for connecting together one or more data devices. Thus, any of the networks, such as A-NETWORK0 or B-NETWORK1, etc., may each include one or more computers, network interface cards (NICs), work stations, file servers, modems, printers, or any other device that receives or transmits data in a network, such as repeaters, switches, routers, hubs, concentrators, etc. For example, as shown in FIG. 1, several computer systems or workstations <b>120</b>, <b>122</b> and <b>124</b> are coupled to the corresponding segment <b>108</b> of A-NETWORKj. The computer systems <b>120</b>, <b>122</b> and <b>124</b> may communicate with each other or with other devices of other networks through the network switch <b>102</b>. Thus, each network <b>106</b> and <b>112</b> represents one or more data devices coupled through one or more segments, where the network switch <b>102</b> transfers data between any two or more data devices in any of the networks <b>106</b> and <b>112</b>.

The network switch <b>102</b> generally operates to receive information from data devices coupled to each of the ports <b>104</b> and <b>110</b> and to route the information to any one or more of the other ports <b>104</b> and <b>110</b>. The network switch <b>102</b> also filters the information by dropping or otherwise ignoring information received from a data device in one network <b>106</b> or <b>112</b> that is only intended for data devices in that same network. The data or information is in the form of packets, where the particular form of each data packet depends upon the protocol supported by a given network. A packet is a predefined block of bytes, which generally consists of header, data, and trailer, where the format of a given packet depends on the protocol that created the packet. The header usually includes a destination address identifying the destination data device and a source address identifying a data device originating the packet, which addresses are typically media access control (MAC) addresses to ensure uniqueness in the industry. A packet intended for one destination device is referred to herein as a unicast packet. The header further includes a GROUP bit indicating whether the packet is a multicast or broadcast (BC) packet intended for multiple destination devices. If the GROUP bit is set to logic one (1), then it is considered a multicast packet, and if all of the destination address bits are also set to logic 1, the packet is a BC packet. However, for purposes of the present invention, multicast and BC packets are treated the same and will be referred to hereinafter as BC packets.

Referring now to FIG. 2, a more specific block diagram is shown of the network switch <b>102</b>. In the embodiment shown, the network switch <b>102</b> includes six similar quad controller or quad cascade (QC) devices <b>202</b>, each incorporating four of the ports <b>104</b>. The QC devices <b>202</b> may be implemented in any desired manner, such as integrated into a single Application Specific Integrated Circuit (ASIC) package or as separate integrated circuit (IC) chips as shown. In the embodiment shown, each port <b>104</b> operates at 10 Mbps at half duplex, for a total throughput of 20 Mbps per port at full duplex. This results in a total of 480 Mbps for all six of the QC devices <b>202</b> operating at full duplex. Each of the QC devices <b>202</b> preferably includes a processor interface coupled to a QC/CPU bus <b>204</b>, and a bus interface coupled to a high speed bus (HSB) <b>206</b>. The HSB <b>206</b> includes a data portion <b>206</b><i>a </i>and various control and status signals <b>206</b><i>b</i>. The HSB <b>206</b> is a 32-bit, 33 Megahertz (MHz) bus for transferring over one gigabit of data per second.

The HSB <b>206</b> and the QC/CPU bus <b>204</b> are further coupled to an Ethernet Packet Switch Manager (EPSM) <b>210</b>, which is implemented as an ASIC in the embodiment shown, although the present invention is not limited to any particular physical or logical implementation. The EPSM <b>210</b> is further coupled to a memory <b>212</b> through a 32-bit memory bus <b>214</b>, which includes a data and address portion <b>214</b><i>a </i>and control signals <b>214</b><i>b</i>. The memory <b>212</b> preferably includes between 4 to 16 Megabytes (MB) of dynamic random access memory (DRAM), although more memory is added as desired depending upon particular application needs. The EPSM <b>210</b> supports any one of at least three different types of DRAM for implementing the memory <b>212</b>, including fast page-mode (FPM) single inline memory modules (SIMMs) operating at approximately 60 nanoseconds (ns), extended data output (EDO) mode DRAM SIMMs, or synchronous mode DRAM SIMMs. Synchronous DRAMs generally require a 66 MHz clock for achieving a burst data rate of 66 MHz data rate or 266 MB per second. EDO DRAMs may operate with either a 33 or 66 MHz clock, but achieve a maximum data burst data rate of 33 MHz, or 133 MB per second with either clock rate. FPM DRAMs may also operate with a 33 or 66 MHz clock, and achieve a maximum burst rate of 16 MHz or 64 MB per second with a 33 MHz clock and a burst rate of 22 MHz or 88 MB per second with a 66 MHz clock.

The memory bus <b>214</b> includes a memory data bus MD[<b>31</b>:<b>0</b>], data parity signals MD_PAR[<b>3</b>:<b>0</b>], row and column address signals MA[<b>11</b>:<b>0</b>], a write enable signal MWE*, bank select signals RAS[<b>3</b>:<b>0</b>]*/SD_CS*[<b>3</b>:<b>0</b>] which are either row signals for FPM DRAM and EDO DRAM or chip selects for synchronous DRAM, memory byte controls signals CAS[<b>3</b>:<b>0</b>]*/SD_DQM[<b>3</b>:<b>0</b>] which are column signals for FPM and EDO or DQM for synchronous DRAM, a row signal SD_RAS* for synchronous DRAM only, a column signal SD_CAS* for synchronous DRAM only, a serial input SIMM/DIMM presence detect signal PD_SERIAL_IN and a parallel input SIMM/DIMM presence detect signal PD_LOAD*.

The HSB <b>206</b> is coupled to a Thunder LAN (TLAN) port interface (TPI) <b>220</b>, which is further coupled to a peripheral component interconnect (PCI) bus <b>222</b> including data and address signals <b>222</b><i>a </i>and related control and status signals <b>222</b><i>b</i>. The PCI bus <b>222</b> is coupled to four TLANs <b>226</b>, which may be implemented in any desired manner. The TLANs <b>226</b> are preferably the TNETE100 ThunderLAN™ PCI Ethernet™ controllers manufactured by Texas Instruments, Inc. (TI), where each incorporates one of the ports <b>110</b>. To the EPSM <b>210</b>, the TPI <b>220</b> operates in a similar manner on the HSB <b>206</b> as another QC device <b>202</b> for interfacing four ports. Thus, the EPSM <b>210</b> effectively “sees” seven (7) quad port devices. With respect to the PCI bus <b>222</b>, the TPI <b>220</b> emulates a standard PCI bus to the degree necessary for proper operation of the TLANs <b>226</b>, which normally interface with PCI memory devices. Thus, the PCI bus <b>222</b> need not be fully PCI compliant. The PCI bus <b>222</b> is coupled to a processor or central processing unit (CPU) <b>230</b>, which is coupled to a local processor bus <b>232</b> for coupling the CPU <b>230</b> to local RAM <b>234</b>, a local flash RAM <b>236</b>, and if desired, a serial port interface <b>238</b>. The serial port interface <b>238</b> is preferably a UART or the like. In the embodiment shown, the CPU is a 32-bit, 33 MHz i960RP CPU by Intel, although the CPU <b>230</b> may be any other suitable processor.

The CPU <b>230</b> generally handles initialization and configuration of the TPI <b>220</b> and the EPSM <b>210</b> upon power up of the network switch <b>102</b>. The CPU <b>230</b> also monitors and gathers statistics and also manages and controls the functions of the various devices of the network switch <b>102</b> during operation. The CPU <b>230</b> further updates the hash table data in the memory <b>212</b> through the EPSM <b>210</b>. The EPSM <b>210</b>, however, controls access to the memory <b>212</b> and performs the DRAM refresh cycles thereby removing refresh operations from the CPU <b>230</b>. The CPU <b>230</b> would otherwise require approximately 6-8 bus cycles to perform each refresh cycle, which would consume valuable processor resources. The CPU <b>230</b> also acts as an additional network port for various purposes, and is often referred herein as PORT28. Thus, the ports <b>104</b>, <b>110</b> and the CPU <b>230</b> collectively incorporate ports PORT0-PORT28, respectively.

The CPU <b>230</b> is further coupled to the EPSM <b>210</b> through a CPU bus <b>218</b>, which includes an address and data portion <b>218</b><i>a </i>and related control and status signals <b>218</b><i>b</i>. The address and data portion <b>218</b><i>a </i>is preferably multiplexed between address and data signals. In particular, the CPU bus <b>218</b> includes an address/data bus CPU_AD[<b>31</b>:<b>0</b>], an address strobe CPU_ADS* from the CPU <b>230</b>, data byte enables CPU_BE[<b>3</b>:<b>0</b>], a read/write select signal CPU_WR*, a burst last data strobe CPU_BLAST*, a data ready signal CPU_RDY* and at least one CPU interrupt signal CPU_INT*. In this disclosure, normal signal names, other than data or address signals, denote positive logic, where the signal is considered asserted when high or at logic one (1), and signal names followed by an asterisk (*) denote negative logic, where the signal is considered asserted when low or at logic zero (0). The functional definition of the signals is generally straightforward and usually determinable by the signal name.

FIG. 3A is a block diagram of an exemplary QC device <b>202</b> for implementing four of the ports <b>104</b>, which device is duplicated six times to implement the 24 ports PORT0-PORT23. One particular device is the L64381 Quad Cascade Ethernet controller device from LSI Logic Corporation (LSI). An upgrade device is the QE110 Quad Cascade Ethernet controller device, also from LSI, which includes additional features and capabilities as described herein. It is noted, however, that the present invention is not limited to any particular device for implementing the ports <b>104</b>. In the embodiment shown, each QC device <b>202</b> includes an Ethernet core <b>300</b> for each of the ports <b>104</b>, where the Ethernet core <b>300</b> is fully synchronous and includes a media access controller, a Manchester Encoder/Decoder, and twisted-pair/AUI (attachment unit interface) transceivers. Each Ethernet core <b>300</b> enables bidirectional data communication with a coupled network <b>106</b> on a corresponding segment <b>108</b>, and each is coupled to a corresponding 128-bit receive FIFO (first-in, first-out) <b>302</b> and a 128-bit transmit FIFO <b>304</b>. Each Ethernet core <b>300</b> is also coupled to a block of statistics counters <b>306</b>, where each block of statistics counters <b>306</b> includes 25 counters for providing on-chip maintenance. The counters within each block of statistics counters <b>306</b> preferably meet the requirements of the simple network management protocol (SNMP). Each of the FIFOs <b>302</b>, <b>304</b> are further coupled to bus interface logic <b>308</b>, which is coupled to the HSB <b>206</b> for enabling bidirectional data flow between each QC device <b>202</b> and the EPSM <b>210</b>. Each QC device <b>202</b> includes configuration and control logic <b>310</b>, for enabling programmable configuration, such as source address insertion, frame check sequence (FCS) insertion, immediate retransmission on collision, bus transfer size and transmit buffer threshold size.

The configuration and control logic <b>310</b> and each of the blocks of statistics counters <b>306</b> and the FIFOs <b>302</b>, <b>304</b> are coupled to the QC/CPU bus <b>204</b>. The EPSM <b>210</b> provides a separate interface between the CPU bus <b>218</b> and the QC/CPU bus <b>204</b>. In this manner, the CPU <b>230</b> has full access to initialize, configure, monitor and modify the activities of each of the QC devices <b>202</b> and thus each of the ports <b>104</b>. The QE110 Quad Cascade Ethernet controller device includes an additional connection <b>320</b> between the configuration and control logic <b>310</b> for detecting a backpressure indication to assert a jamming sequence to terminate a packet being received, if the backpressure indication is received in time. The backpressure indication is preferably a backpressure cycle executed on the HSB <b>206</b>, although any one of several methods may be used to indicate backpressure, such as a separate signal or the like.

It is noted that the jamming sequence should be sent during the first 64 bytes of the data packet being received at a port to be considered “early” or timely. The first 16 bytes (4 DWORDs) are required before a hash lookup procedure, described below, is performed by the EPSM <b>210</b>. Each data bit is transferred in about 100 ns across Ethernet 10Base-T, so that the first 16 bytes are transferred in approximately 13 microseconds (μs). 64 bytes are received in about 51 μs, so that the network switch <b>102</b> has approximately 38 μs to transfer the first 16 bytes received, perform the hashing procedure, execute the backpressure cycle and finally assert the jamming sequence. Since a hash lookup takes approximately 1-2 μs to complete, there is almost always enough time to send the jamming sequence in a timely manner. However, timely assertion of the jamming sequence is not guaranteed, so that there is the possibility of dropping packets due to a threshold violation condition. If the backpressure cycle is executed late, the port rejects the backpressure cycle and the network switch <b>102</b> drops the packet if it is unable to accept the packet. The network switch <b>102</b> may accept that packet since a threshold condition is an early indication and thus memory may be available to store the packet.

If the backpressure cycle is executed in a timely manner and if the port is operating in half duplex, the configuration and control logic <b>310</b> respondingly asserts a collision command to one of the Ethernet cores <b>300</b> of an indicated port <b>104</b>. The Ethernet core <b>300</b> receiving the collision command then asserts a jamming sequence to terminate a packet being received by that port <b>104</b>. If the backpressure cycle is executed within the 64 byte window, then the port indicates that the backpressure cycle will be executed for that port to the EPSM <b>210</b> by asserting an abort signal ABORT_OUT* on the HSB <b>206</b>. If the backpressure cycle is outside the 64 byte window and thus not asserted in time, the ABORT_OUT* signal is not asserted and the EPSM <b>210</b> drops the packet. The EPSM <b>210</b> drops the packet in most cases when an attempt to assert backpressure fails. Although it is desired to drop as few packets as possible for maximum efficiency, a dropped packet is eventually detected at higher network levels at the originating data device and thus is not fatal to overall operation of the network system <b>100</b>. The origination device detects that the packet was dropped and re-sends one or more packets including the dropped packet.

The bus interface logic <b>308</b> preferably includes read latches <b>324</b> and write latches <b>326</b> for implementing concurrent read and write cycle on the HSB <b>206</b> as described further below. These latches latch PORT_NO[<b>1</b>:<b>0</b>] signals asserted on the HSB <b>206</b> at particular cycles of a first clock (CLK_—1) signal. The CLK—1 signal is the primary clock for the HSB <b>206</b> and typically operates at approximately 30-33 MHz in the embodiment shown. Since the CLK_—1 signal is the primary clock, it is referred to hereinafter as simply the CLK signal. A second clock signal CLK_—2 is also used for interface to the memory <b>212</b>, and operates at twice (2×) the frequency of the CLK signal or at approximately 60-66 MHz.

FIG. 3B is a diagram illustrating the signals of the particular quad cascade device <b>202</b> shown in FIG. <b>3</b>A. The signals are divided into several functional and bus sections, including processor interface signals associated with the QC bus <b>204</b>, network interface signals associated with the four ports <b>104</b>, status signals, clock and test signals, bus interface signals associated with the HSB <b>206</b>, and miscellaneous signals.

Concerning the QC bus <b>204</b>, the EPSM <b>210</b> writes data to and reads data from the registers and counters <b>306</b>, <b>310</b> of the QC device <b>202</b> through data signals PDATA[<b>15</b>:<b>0</b>]. The READ* signal is asserted high for a write operation and low for a read operation. The particular register within the QC device <b>202</b> is determined by an address asserted on ADRS[<b>5</b>:<b>0</b>] signals. Assertion of an address strobe signal ADRS_STROBE* along with the corresponding one of several chip select signals CHIP_SELECTm* causes the QC device <b>202</b> to latch the ADRS signals. A lower case “m” appended to the signal name generally denotes multiple signals of a particular type. For example, there are six separate CHIP_SELECT[<b>5</b>:<b>0</b>]* signals, each for separately accessing a respective one of the six QC devices <b>202</b>. A signal PREADY* is asserted low by the QC device <b>202</b> for one cycle of a CLK signal during a write cycle after the rising CLK edge on which the requested data is latched. For a read cycle, the QC device <b>202</b> asserts PREADY* low for one CLK cycle after it places data on the PDATA bus.

FIG. 3C is an exemplary timing diagram illustrating a processor read cycle for a QC device <b>202</b> and FIG. 3D is an exemplary timing diagram illustrating a processor write cycle. FIG. 3E is an exemplary timing diagram illustrating processor burst read access cycle for a QC device <b>202</b>. These timing diagrams are exemplary only and shown to illustrate general functionality and not particular timing or particular signal characteristics.

Referring back to FIG. 3B, the network interface signals include the negative and positive collision threshold signals, the collision reference signal, the serial data in signal, the negative and positive Manchester-Encoded data signals, the positive and negative data threshold signals, the data threshold reference signal, the positive and negative Pre-emphasis signals and the twister-pair/AUI mode select signals for each of the four ports denoted [<b>3</b>:<b>0</b>] of each QC device <b>202</b>. Each QC device receives the CLK signal and has a CLOCK_—20 MHZ input, which receives a 20 MHz clock signal to generate 80, 20 and 10 MHz internal clock signals for use by the ports <b>104</b>. Each Ethernet core <b>300</b> detects a collision occurring on the corresponding segment <b>108</b> and transmits a jamming sequence according to the Ethernet CSMA/CD (Carrier Sense Multiple Access/Collision Detect) method.

Concerning the bus interface signals associated with the HSB <b>206</b>, a QC device <b>202</b> aborts an entire packet by asserting the ABORT_OUT* signal. The EPSM <b>210</b> aborts the current bus cycle by asserting an abort signal ABORT_IN*. In one embodiment, the QC devices <b>202</b> are QE110 devices which are devised to enable the EPSM <b>210</b> to abort a packet being received by executing a backpressure cycle on the HSB <b>206</b>. This particular type of backpressure capability is a “packet by packet” or dynamic “per port” backpressure that allows rejection of one packet being received at one port. L64381 devices include an auto-insert frame check sequence signal (AI_FCS_IN*), which is described further below. QE110 devices replace the AI_FCS_IN* signal with a signal FBPN*, which is used to perform the same functions as the AI_FCS_IN* signal, but is also used to indicate a backpressure cycle and an enhanced packet flush. Of course, many alternative methods may be used to implement dynamic backpressure as described herein. In particular, the EPSM <b>210</b> asserts the FBPN* signal during a read cycle to perform a backpressure request cycle. If the ABORT_OUT* signal is asserted by the corresponding QC device <b>202</b> during the data phase of the read cycle, then the backpressure “request” has been granted by that QC device <b>202</b>, which then asserts a jamming sequence to abort the packet. If the ABORT_OUT* signal is not asserted, then the EPSM <b>210</b> drops the packet.

The EPSM <b>210</b> asserts a status strobe signal STROBE* to all of the QC devices <b>202</b> and the TPI <b>220</b>, each of which responds with the status of its four ports <b>104</b> or <b>110</b> (in the case of the TPI <b>220</b>) in multiplexed fashion on signals PKT_AVAILm* and BUF_AVAILm* when the STROBE* signal is sampled asserted on the rising edge of the CLK signal. There is a separate signal for each QC device <b>202</b>, one set for the TPI <b>220</b> and a similar set for the CPU <b>230</b>, which acts as another port for some operations. In particular, the PKT_AVAILm* and BUF_AVAILm* signals include signals PKT_AVAIL[<b>5</b>:<b>0</b>]* and BUF_AVAIL[<b>5</b>:<b>0</b>]* for the QC devices <b>202</b>, signals TPI_PKT_AVAIL* and TPI_BUF_AVAIL*, otherwise referred to as PKT_AVAIL[<b>6</b>]* and BUF_AVAIL[<b>6</b>]*, respectively, for the TPI <b>220</b>, and signals PCB_PKT_AVAIL* and PCB_BUF_AVAIL*, otherwise referred to as PKT_AVAIL[<b>7</b>]* and BUF_AVAIL[<b>7</b>]*, respectively, corresponding to the CPU <b>230</b>, for a total of <b>8</b> signals per signal type.

In this manner, the HSB <b>206</b> includes signals PKT_AVAIL[<b>0</b>]* and BUF_AVAIL[<b>0</b>]* for the first QC device <b>202</b> to access the four ports PORT0-PORT3, the HSB <b>206</b> includes signals PKT_AVAIL[<b>1</b>]* and BUF_AVAIL[<b>1</b>]* for the next QC device <b>202</b> to access the next four ports PORT4-PORT7 etc., the TPI <b>220</b> includes signals PKT_AVAIL[<b>6</b>]* and BUF_AVAIL[<b>6</b>]* to access the ports PORT24-PORT27, and the EPSM <b>210</b> includes internal signals PKT_AVAIL[<b>7</b>]* and BUF_AVAIL[<b>7</b>]* for the CPU <b>230</b>. Up to four bits are multiplexed on each of the signals corresponding to the four ports separated by respective cycles of the CLK signal.

In response to the STROBE* signal, the bus interface logic <b>308</b> includes port status logic <b>303</b> for multiplexing four status bits on a respective one of the BUF_AVAIL[<b>5</b>:<b>0</b>]* signals to indicate whether each of its corresponding transmit FIFOs <b>304</b> for the respective port has enough empty space available to store data. The port status logic <b>303</b> is either centralized for all four of the ports as shown, or is distributed among the ports. The determination of empty space is according to a configuration register in the bus interface logic <b>308</b> storing a bus transfer field size (TBUS), which is preferably configured by the CPU <b>230</b> to 16, 32 or 64 bytes. In a similar manner, in response to the STROBE* signal, the TPI <b>220</b> includes similar port status logic <b>820</b> (FIG. 8B) coupled to the HSB <b>206</b> for multiplexing four status bits on the BUF_AVAIL[<b>6</b>]* signal to indicate whether each of its internal transmit FIFOs, described below, has enough empty space to store data for corresponding ones of the TLANs <b>226</b> for the respective ports PORT24-PORT27. For the CPU <b>230</b> or PORT28, a PCB <b>406</b> (FIG. 4) within the EPSM <b>210</b> asserts a single status bit on the BUF_AVAIL[<b>7</b>]* signal to indicate whether an internal PCB transmit FIFO within the EPSM <b>210</b> has available space to store data for the CPU <b>230</b>.

In a similar manner, in response to the STROBE* signal, the port status logic <b>303</b> of the bus interface logic <b>308</b> in each QC device <b>202</b> multiplexes four status bits on a respective one of the PKT_AVAIL[<b>5</b>:<b>0</b>]* signals indicating whether each of its receive FIFOs <b>302</b> for the respective port has enough data, according to the TBUS value, to transfer received data for a bus transfer on the HSB <b>206</b>. Likewise, the TPI <b>220</b> multiplexes four status bits on the PKT_AVAIL[<b>6</b>]* signal indicating whether its internal receive FIFOs have received enough data from the respective ports PORT23-PORT27 to transfer on the HSB <b>206</b>. For the CPU <b>230</b>, the PCB <b>406</b> within the EPSM <b>210</b> asserts a single status bit on the PKT_AVAIL[<b>7</b>]* signal to indicate whether an internal PCB receive FIFO within the EPSM <b>210</b> has received enough data from the CPU <b>230</b> for an HSB <b>206</b> bus transfer.

FIG. 3F is an exemplary timing diagram illustrating a buffer status inquiry of the QC device <b>202</b> and the TPI <b>220</b>, including assertion of the STROBE* signal by the EPSM <b>210</b> and response by each of the QC devices <b>202</b>, the TPI <b>220</b> asserting respective PKT_AVAILm* and BUF_AVAILm* signals. The references to PORT0, PORT1, PORT2 and PORT3 in FIG. 3F are the four respective ports of a particular QC device <b>202</b> or the TPI <b>220</b>. The PCB <b>406</b> responds in a similar fashion except that its port is active for all four phases. The STROBE* signal is level triggered and thus sampled low on the first rising edge of the CLK signal. It is noted that the timing diagram of FIG. 3F is exemplary only and shown to illustrate general functionality and not particular timing or particular signal characteristics. For example, the STROBE* signal is periodic and typically asserted low for more than one CLK cycle in operation of the embodiment shown.

Referring back to FIG. 3B, a signal PORT_BUSY* is used to indicate whether the respective port is sending or receiving in half duplex mode, or when the port is transmitting in full duplex mode. Read data signals READ_OUT_PKT[<b>5</b>:<b>0</b>]* are asserted by the EPSM <b>210</b> to inform a respective QC device <b>202</b> to place data from a respective receive FIFO <b>302</b> on the data signals DATA[<b>31</b>:<b>0</b>]. In a similar manner, write data signals WRITE_IN_PKT[<b>5</b>:<b>0</b>]* are asserted by the EPSM <b>210</b> to inform a respective QC device <b>202</b> to retrieve data from the data signals DATA[<b>31</b>:<b>0</b>] into a respective transmit FIFO <b>304</b>. Also, similar signals PCB_RD_OUT_PKT*, PCB_WR_IN_PKT* and TPI_READ_OUT_PKT*, TPI_WRITE_IN_PKT* signals are included for the TPI <b>220</b> and the CPU <b>230</b>, respectively. All of the read and write signals are collectively referred to as the READ_OUT_PKTm* and WRITE_IN_PKTm* signals, respectively. The PORT_NO[<b>1</b>:<b>0</b>] bits indicate which particular port <b>104</b> is being addressed for a cycle executed on the HSB <b>206</b>.

A signal SOP* indicates the Start Of Packet when the beginning or header of a packet is transferred on the HSB <b>206</b>. The AI_FCS_IN* signal is typically asserted with the SOP* and one of the WRITE_IN_PKTm* signals by an external device to cause a L64381 device (for one implementation of the QC devices <b>202</b>) to automatically calculate a CRC (cyclic redundancy check) value from the data in the packet and to insert the CRC into the FCS field of the packet. A QE110 device replaces the AI_FCS_IN* signal with the FBPN* signal, as described previously, for additional functions. A signal EOP* indicates the End Of Packet when the last data transfer of a data packet is transferred on the HSB <b>206</b>. BYTE_VALID[<b>3</b>:<b>0</b>]* signals indicate which bytes are valid in the current word on the DATA signals. It is noted that a data packet is usually too large for a single transfer on the HSB <b>206</b>, so that each bus cycle transfers an amount of data less than or equal to the TBUS value.

It is appreciated that each QC device <b>202</b> operates each of its four ports as 10Base-T Ethernet ports. It is further appreciated that the EPSM <b>210</b> has access to read and write all registers of the QC devices <b>202</b> through the QC bus <b>204</b>. Further, the EPSM <b>210</b> reads data from all of the receive FIFOs <b>302</b> and writes data to all of the transmit FIFOs <b>304</b> through the HSB <b>206</b>.

FIG. 3G is an exemplary timing diagram illustrating a concurrent read and write cycle on the HSB <b>206</b>. The top of the timing diagram indicates the cycle type, where two concurrent read and write cycles are executed one after the other. The CLK, CLK_—2, STROBE*, READ_OUT_PKTm*, WRITE_IN_PKTm*, PORT_NO[<b>1</b>:<b>0</b>], DATA[<b>31</b>:<b>0</b>] and ABORT_OUT* signals are shown plotted on a Y-axis (or vertical axis) versus time plotted on an X-axis (or horizontal axis) of the timing diagram. There are two different types of concurrent read and write cycles that are performed depending upon the particular configuration. For the first, general type of concurrent cycle, if the QC devices <b>202</b> are implemented with the QE110 devices which include the latches <b>324</b>, <b>326</b>, then concurrent read and write cycles are performed without further enhancement. Alternatively, if the QC devices <b>202</b> are implemented with the L64381 devices, external latches and select logic (not shown) are added to latch the PORT_NO signals when asserted on the HSB <b>206</b>. A second, special type of concurrent read and write cycle is performed with the L64381 devices without further enhancement, but only if the PORT_NO signals are the same and only if the QC devices <b>202</b> are different.

The EPSM <b>210</b> determines the type of cycle to execute, such as, for example, read, write, concurrent read and write, backpressure, etc. A read cycle is generally indicated by assertion of one of the READ_OUT_PKTm* signals, and a write cycle is generally indicated by assertion of one of the WRITE_IN_PKTm* signals. A concurrent read and write cycle is indicated by simultaneous assertion of a READ_OUT_PKTm* signal and a WRITE_IN_PKTm* signal. The EPSM <b>210</b> performs a concurrent read and write cycle between two ports under certain conditions, such as, for example, only if both ports are configured to operate in cut-through (CT) mode, described more fully below.

During the concurrent cycle, the EPSM <b>210</b> asserts one of the READ_OUT_PKTm* signals low at the beginning of the third CLK cycle to indicate one of the QC devices <b>202</b> or the TPI <b>220</b>, and asserts the appropriate port number on the PORT_NO[<b>1</b>:<b>0</b>] signals during the third CLK cycle to indicate one of the four ports of the QC device <b>202</b> identified by the particular READ_OUT_PKTm* signal asserted. The QC device <b>202</b> identified by the particular READ_OUT_PKTm* signal latches the PORT_NO[<b>1</b>:<b>0</b>] signals in the third CLK cycle to determine the particular port being read. For example, the QE110 devices implementing the QC devices <b>202</b> are configured with the read latches <b>324</b> to latch the PORT_NO[<b>1</b>:<b>0</b>] signals. Also, the TPI <b>220</b> includes similar read latches <b>819</b><i>b </i>(FIG. 8B) to latch the PORT_NO[<b>1</b>:<b>0</b>] signals in the third CLK cycle, if indicated by the READ_OUT_PKT[<b>6</b>]* signal. Alternatively, external latches are used for this purpose if the QC devices <b>202</b> are implemented with the L64381 devices. At this point, the particular port PORT0-PORT27 identified has been indicated as the source port for a read cycle on the HSB <b>206</b>.

The EPSM <b>210</b> then asserts one of the WRITE_IN_PKTm* signals low at the beginning of the fourth CLK cycle to indicate the same or any other one of the QC devices <b>202</b> or the TPI <b>220</b>, and asserts the appropriate port number on the PORT_NO[<b>1</b>:<b>0</b>] signals during the fourth CLK cycle to indicate one of the four ports of the device indicated by the particular WRITE_IN_PKTm* signal asserted. The QC device <b>202</b> identified by the particular WRITE_IN_PKTm* signal latches the PORT_NO[<b>1</b>:<b>0</b>] signals in the fourth CLK cycle to determine the particular port being written to. For example, the QE110 devices implementing the QC devices <b>202</b> are configured with the write latches <b>326</b> to latch the PORT_NO[<b>1</b>:<b>0</b>] signals in the fourth CLK cycle. Also, the TPI <b>220</b> includes similar write latches <b>819</b><i>b </i>to latch the PORT_NO[<b>1</b>:<b>0</b>] signals in the fourth CLK cycle, if indicated by the WRITE_IN_PKT[<b>6</b>]* signal. In this manner, any other one of the ports PORT0-PORT27 is indicated as the destination port for a write cycle on the HSB <b>206</b>, where the write cycle occurs at the same time as the read cycle just indicated. The source and destination ports may be on the same QC device <b>202</b> or two ports of the TPI <b>220</b>, or may be between different QC devices <b>202</b>. However, a concurrent read and write cycle is not performed between one of the ports <b>104</b> of the QC devices <b>202</b> and one of the ports <b>110</b> of the TPI <b>220</b> in the embodiment shown due to differences in speed of data transfer.

In the following cycles of the CLK signal, packet data is concurrently transferred or read from the source port and directly written to the destination port across the HSB <b>206</b> without being stored in the EPSM <b>210</b> or the memory <b>212</b>. Data transfer occurs in cycles <b>5</b>, <b>6</b>, <b>7</b> and <b>8</b>, for transferring several bytes depending upon the embodiment. For example, up to 64 bytes are transferred for L64381 devices, and up to 256 bytes are transferred for QE110 devices. Although four CLK cycles are shown for the data transfer, the data transfer may occur with one, two or four CLK cycles depending upon how much data is transferred. For new packets, a normal read cycle is first performed to provide the source and destination MAC addresses into the EPSM <b>210</b>, which then performs a hashing procedure, described further below, to determine the destination port number, if known. Once the destination port number is known, and if there is only one destination port, a concurrent read and write operation may be performed for any portion or the entire remainder of the packet as desired.

The special type of concurrent read and write cycle is performed if the PORT_NO signals are the same but between two different ports and thus between two different QC devices <b>202</b>. FIG. 3G also illustrates this case except that the PORT_NO signals remain unchanged throughout the entire cycle. The latches <b>324</b>, <b>326</b> are not necessary since the PORT_NO signals remain unchanged, so that this type of concurrent cycle may be performed between two different L64381 devices without external latches or select logic. The EPSM <b>210</b> determines that the PORT_NO signals are the same between the source and destination ports and that two different QC devices <b>202</b> are involved, and then runs the concurrent cycle as shown.

As shown in FIG. 3G, a second concurrent read and write transfer occurs in the sixth CLK cycle, where the PORT_NO[<b>1</b>:<b>0</b>] signals are then asserted in the seventh, eighth and ninth cycles with the read mode, the read port number and the write port number, respectively. A READ_OUT_PKTm* signal is de-asserted for the seventh CLK cycle in response. Likewise, a WRITE_IN_PKTm* signal is deasserted for the eighth CLK cycle. This second concurrent cycle is either a continuation of the first concurrent cycle for providing continuing and consecutive data of the same data packet, or may be the beginning of an entirely different data packet. The source and destination ports are the same for continuing data for the same packet. However, either the source port, or the destination port, or both may be different in the second concurrent cycle for transferring data for a different packet.

FIG. 3H is a flowchart diagram illustrating a procedure for executing a concurrent read and write cycle on the HSB <b>206</b>. At a first step <b>330</b>, the EPSM <b>210</b> determines whether a concurrent read and write cycle may be executed on the HSB <b>206</b> between a source port and a destination port. The EPSM <b>210</b> then asserts the appropriate signals to identify the source port at next step <b>332</b>. This is performed by asserting the source or “read” port number using the PORT_NO signals on the HSB <b>206</b> and by asserting the appropriate READ_OUT_PKTm* signal. At next step <b>334</b>, the identified source port device detects or stores the identification signals. In the special concurrent cycle with no latches, the QC device <b>202</b> detects the READ_OUT_PKTm* signal and then the PORT_NO signals on the HSB <b>206</b> and begins preparing for a read cycle. In the general concurrent cycles using latches, the indicated QC device <b>202</b> or the TPI <b>220</b> latches the read port number at step <b>334</b> and begins preparing for a read cycle.

At next step <b>336</b>, the EPSM <b>210</b> asserts the appropriate signals to identify the destination port. For the special concurrent cycle, the EPSM <b>210</b> asserts the appropriate WRITE_IN_PKTm* signal and maintains the same PORT_NO signals. For the general case, the EPSM <b>210</b> also asserts the destination or “write” port number on the HSB <b>206</b> along with the appropriate WRITE_IN_PKTm* signal at next step <b>336</b>. At next step <b>338</b>, the identified destination port device detects or stores the identification signals. In the special concurrent cycle with no latches, the indicated QC device <b>202</b> detects the WRITE_IN_PKTm* signal and then the PORT_NO signals on the HSB <b>206</b> and begins preparing for a write cycle. For the general case, the indicated QC device <b>202</b> or the TPI <b>220</b> latches the destination or write port number at next step <b>338</b>. Finally, the indicated source port provides the data on the HSB <b>206</b> while the indicated destination port reads the data from the HSB <b>206</b> at next step <b>340</b> in a concurrent read and write cycle.

The concurrent read and write operation is the fastest type of data transfer cycle since only a single bus cycle is needed for each transfer of packet data. As described further below, a normal CT mode of operation requires at least two transfers, one from the source port to the EPSM <b>210</b>, and another one from the EPSM <b>210</b> to the destination port, which requires two separate cycles on the HSB <b>206</b> for the same data. A concurrent read and write cycle requires a single and direct transfer on the HSB <b>206</b> for the same data, thereby increasing bandwidth of the HSB <b>206</b>. Other, slower modes are provided, including several interim CT and store-and-forward (SnF) modes, where packet data is written to the memory <b>212</b> before being transferred to the destination port.

Referring now to FIG. 4, a simplified block diagram is shown of the EPSM <b>210</b> illustrating data flow and configuration registers. The EPSM <b>210</b> includes three primary sections including an HSB controller block (HCB) <b>402</b>, a memory controller block (MCB) <b>404</b> and a processor control block (PCB) <b>406</b>. A QC interface <b>410</b> couples the HSB <b>206</b> the HCB <b>402</b> of the EPSM <b>210</b>. A set of buffers or FIFOs <b>412</b> are coupled to the other side of the QC interface <b>410</b>, where the FIFOs <b>412</b> include receive, transmit and cut-through FIFOs, described further below. The other side of the FIFOs <b>412</b> (excluding a CT buffer <b>528</b>, FIG. 5A) is coupled to the MCB <b>404</b> through an MCB interface <b>414</b>, which is coupled to an HCB interface <b>418</b> in the MCB <b>404</b> through an appropriate bus <b>420</b>. The HCB interface <b>418</b> is further coupled to a memory interface <b>422</b>, which is coupled to the memory <b>212</b> through the memory bus <b>214</b>. The memory interface <b>422</b> is further coupled to one side of a PCB interface <b>424</b>, which has its other side coupled to one side of an MCB interface <b>426</b> within the PCB <b>406</b> through an appropriate MCB bus <b>428</b>. The other side of the MCB interface <b>426</b> is coupled to one side of a set of FIFOs <b>430</b>, which are further coupled to a CPU interface <b>432</b> within the PCB <b>406</b>. The CPU interface <b>432</b> is coupled to the QC/CPU bus <b>204</b> and to the CPU bus <b>218</b>. The CPU interface <b>432</b> is further coupled to one side of a second set of FIFOs <b>434</b> within the PCB <b>406</b>, which has its other side coupled to a QC/HCB interface <b>436</b>. The other side of the QC/HCB interface <b>436</b> is coupled to the QC interface <b>410</b> across an appropriate HCB bus <b>438</b>.

It is noted that the PCB_BUF_AVAIL*, PCB_PKT_AVAIL*, PCB_RD_OUT_PKT* and PCB_WR_IN_PKT* signals of the HCB bus <b>438</b>, associated with the PCB <b>406</b> and the CPU <b>230</b>, are included in the BUF_AVAILm*, PKT_AVAILm*, READ_OUT_PKTm* and WRITE_IN_PKTm* signals, respectively. In the embodiment shown, the HCB bus <b>438</b> is similar to the HSB <b>206</b>, and is essentially an internal version of the HSB <b>206</b> within the EPSM <b>210</b>. The PCB <b>406</b> behaves in a similar manner as each of the ports <b>104</b> and the TPI <b>220</b> to the HCB <b>402</b>. In this manner, the CPU <b>230</b>, through operation of the PCB <b>406</b>, operates as an additional port (PORT28) to the HCB <b>402</b>.

The CPU interface <b>432</b> is coupled to a register interface <b>440</b> through a bus <b>442</b>, where the register interface <b>440</b> is further coupled to a register bus <b>444</b>. The register bus <b>444</b> is coupled to a set of HCB configuration registers <b>446</b> within the HCB <b>402</b> and to a set of MCB configuration registers <b>448</b> within the MCB <b>404</b>. In this manner, the CPU <b>230</b> initializes and programs the registers in both the HCB and MCB configuration registers <b>446</b>, <b>448</b> through the CPU interface <b>432</b> and the register interface <b>440</b>.

The MCB configuration registers <b>448</b> are used to store a significant amount of configuration information associated with the ports and the memory <b>212</b>. For example, the MCB configuration registers <b>448</b> include port state information indicating whether each port is in a learning (LRN), forwarding (FWD), blocked (BLK), listening (LST), or disabled (DIS) state, memory sector information, bus utilization information of the memory bus <b>214</b>, number of dropped packets, hash table definitions, memory thresholds, BC thresholds, identification of secure ports, if any, memory control information, MCB interrupt source bits, interrupt mask bits and polling source bits, etc.

The description of the EPSM <b>210</b> illustrates that the CPU <b>230</b> has access to the QC devices <b>202</b> and to the memory <b>212</b> for configuration and control purposes. Although primary data flow with the HSB <b>206</b> with the EPSM <b>210</b> is through the FIFOs <b>412</b> and the memory <b>212</b>, data flow also occurs between the HSB <b>206</b> and the CPU <b>230</b> through the HCB bus <b>438</b> and associated FIFOs and interfaces of the EPSM <b>210</b>.

Referring now to FIG. 5A, a more detailed block diagram is shown of the HCB <b>402</b>. The HCB bus <b>438</b> is an internal version of the HSB <b>206</b> for interfacing the PCB <b>406</b>, where both buses <b>206</b>, <b>438</b> will collectively be referred to as the HSB <b>206</b>. Polling logic <b>501</b> is coupled to the HSB <b>206</b>, to a set of local registers <b>506</b> and to the HCB configuration registers <b>446</b>. The polling logic <b>501</b> receives the CLK signal, and periodically asserts the STROBE* signal to the QC devices <b>202</b> and the TPI <b>220</b> for querying the ports <b>104</b>, <b>110</b> and the PCB <b>406</b>. The polling logic <b>501</b> then monitors the multiplexed PKT_AVAILm* and BUF_AVAILm* signals from the QC devices <b>202</b>, the TPI <b>220</b>, where each QC device <b>202</b> and the TPI <b>220</b> provide the status of its four ports <b>104</b>, <b>110</b>, respectively, as described previously. The TPI <b>220</b> responds with the PKT_AVAIL[<b>6</b>]* and BUF_AVAIL[<b>6</b>]* signals and the PCB <b>406</b> responds with the PKT_AVAIL[<b>7</b>]* and BUF_AVAIL[<b>7</b>]* signals.

The polling logic <b>501</b> includes a receive (RX) poll state machine <b>502</b>, which reviews the PKT_AVAILm* signals and updates a RECEIVE LIST <b>509</b> within the registers <b>506</b>. In a similar manner, the polling logic <b>501</b> includes a transmit (TX) poll state machine <b>503</b>, which reviews the BUF_AVAILm* signals and updates a TRANSMIT LIST <b>510</b> within the registers <b>506</b>. If a WTPRIORITY flag in the HCB configuration registers <b>446</b> is set by the CPU <b>230</b>, the RX poll state machine <b>502</b> and the TX poll state machine <b>503</b> both use a set of WEIGHT FACTORS <b>508</b> in the HCB configuration registers <b>446</b> for programming the RECEIVE LIST <b>509</b> and the TRANSMIT LIST <b>510</b>, respectively, as further described below. The HCB configuration registers <b>446</b> also include a set of CT_SNF registers <b>507</b>, which are programmed by the CPU <b>230</b> to determine the desired mode of operation between CT and SnF when the corresponding port is either a source or a destination port.

The registers <b>506</b> are implemented in any desired fashion depending upon the implementation of the EPSM <b>210</b>, such as a latches, flip-flops, static RAM (SRAM), DRAM devices etc., and includes a plurality of status and control registers or buffers. The RECEIVE LIST <b>509</b> includes a plurality of register values indicative of relative receive status and priority of each port. Likewise, the TRANSMIT LIST <b>510</b> includes a plurality of register values indicative of relative transmit status and priority of each port. An RPCOUNT register <b>511</b><i>a </i>stores an RPCOUNT number used by the RX poll state machine <b>502</b> to assign a relative receive priority to each port when packet data is received by that port from an external network device. Alternatively, the RX poll state machine <b>502</b> uses a corresponding weight factor from the WEIGHT FACTORS <b>508</b>. Likewise, a TPCOUNT register <b>511</b><i>b </i>stores a TPCOUNT number used by the TX poll state machine <b>503</b> to assign a relative transmit priority to each port when packet data is available for transmission by that port to an external network device and the port has room to receive data for transmission. Alternatively, the TX poll state machine <b>502</b> uses a corresponding weight factor from the WEIGHT FACTORS <b>508</b>. Relative arbitration count numbers RXNEWCNT, RXACTCNT, TXNEWCNT and TXCTCNT are stored in registers RXNEWCNT <b>511</b><i>c</i>, RXACTCNT <b>511</b><i>d</i>, TXNEWCNT <b>511</b><i>e </i>and TXCTCNT <b>511</b><i>f</i>, respectively.

The HCB <b>402</b> includes arbitration logic <b>504</b> coupled to review the data in the registers <b>506</b> and <b>446</b> for determining the types of cycles executed on the HSB <b>206</b>. An HSB controller <b>505</b> performs and controls each cycle executed on the HSB <b>206</b> for controlling data flow between the EPSM <b>210</b> and the HSB <b>206</b>. The HSB controller <b>505</b> is coupled to the registers <b>506</b> for modifying status bits. The HSB controller <b>505</b> receives an indication of the type of each cycle from the arbitration logic <b>504</b>. The arbitration logic <b>504</b> includes a MAIN arbiter <b>512</b> coupled to four data arbiters, including a new packet receive (RX NW) arbiter <b>513</b>, a receive active (RX ACT) arbiter <b>514</b>, a new packet transmit (TX NW) arbiter <b>515</b>, and a transmit cut-through (TX CT) arbiter <b>516</b>. The MAIN arbiter <b>512</b> generally selects between the RX NW arbiter <b>513</b>, the RX ACT arbiter <b>514</b>, the TX NW arbiter <b>515</b> and the TX CT arbiter <b>516</b>, where each arbiter arbitrates to define the next cycle. The MAIN arbiter <b>512</b> uses any acceptable priority scheme as desired. In the embodiment shown, for example, the MAIN arbiter <b>512</b> uses a round-robin priority scheme.

The FIFOs <b>412</b> are implemented in any desired fashion. In the embodiment shown, two receive buffers RX BUFs <b>520</b>, <b>522</b> implement an RX FIFO, where data is read from one buffer while being written to the other, and vice-versa. Also, two transmit buffers TX BUFs <b>524</b>, <b>526</b> are provided and operate in a similar manner as the RX BUFs <b>520</b>, <b>522</b>. The FIFOs <b>412</b> also include at least one cut-through buffer CT BUF <b>528</b>. The RX BUFs <b>520</b>, <b>522</b> are both 64-byte buffers that each include a bidirectional data interface with the HSB <b>206</b> for data flow in either direction, and a uni-directional interface for providing data to the MCB <b>404</b> through an RX MCB interface <b>530</b>. The TX BUFs <b>524</b>, <b>526</b> are both 64-byte buffers coupled between the HSB <b>206</b> and a TX MCB interface <b>531</b>. The TX BUFs <b>524</b>, <b>526</b> receive data from the MCB <b>404</b> through the TX MCB interface <b>531</b>, and provide data to the HSB <b>206</b>. The CT BUF <b>528</b> is a 64-byte buffer having a bidirectional interface with the HSB <b>206</b>. A FIFO control block <b>529</b> is coupled to the registers <b>506</b>, the HSB controller <b>505</b>, the RX BUFs <b>520</b>, <b>522</b>, the TX BUFs <b>524</b>, <b>526</b>, the CT BUF <b>528</b>, the RX MCB interface <b>530</b> and the TX MCB interface <b>531</b> for controlling data flow through the FIFOs <b>520</b>, <b>522</b>, <b>524</b> and <b>526</b>, for detecting certain status signals asserted through the RX, TX MCB interfaces <b>530</b>, <b>531</b> and for setting certain bits in the registers <b>506</b>, as described further below.

The bus <b>420</b> includes a plurality of data and control signals for interfacing the HCB <b>402</b> to the MCB <b>404</b> through the RX, TX MCB interfaces <b>530</b>, <b>531</b>, hash request logic and MCB interface (referred to as HASH REQ LOGIC) <b>532</b> and transmit arbiter request logic and MCB interface (referred to as TX ARB REQ LOGIC) <b>533</b>. The HSB controller <b>505</b> copies the header of each new packet from one of the ports PORT0-PORT28 into one of the RX BUFs <b>520</b>, <b>522</b> and also into the HASH REQ LOGIC <b>532</b>. The header is at least three DWORDs (32 bits each) or 96 bits, which includes both the source and destination MAC addresses. The HASH REQ LOGIC <b>532</b> requests the hashing procedure to be performed by the MCB <b>404</b>, and sets appropriate bits in the registers <b>506</b>. The hashing procedure is performed to determine the appropriate action to take for the packet.

In the embodiment shown, after receiving the header of a new packet, the HASH REQ LOGIC <b>532</b> asserts a signal HASH_REQ* to the MCB <b>404</b> and multiplexes the 48-bit MAC destination and source addresses and an 8-bit source port number on HASH_DA_SA[<b>15</b>:<b>0</b>] signals. The MCB <b>404</b> detects the HASH_REQ* signal, performs the hashing procedure and then asserts a signal HASH_DONE* to the HASH REQ LOGIC <b>532</b>. The MCB <b>404</b> also asserts signals HASH_DSTPRT[<b>4</b>:<b>0</b>], HASH_STATUS[<b>1</b>:<b>0</b>] and a signal HASH_BP*, if appropriate. The HASH_STATUS[<b>1</b>:<b>0</b>] signals indicate one of four results, including 00b (b denotes a binary number)=DROP_PKT to drop the packet, 01b=GROUP_BC for a broadcast (BC) packet, 10b=MISS_BC for an unknown destination port and thus a BC packet, and 11b=FORWARD_PKT indicating a unicast packet to a single destination port. If HASH_STATUS[<b>1</b>:<b>0</b>]=FORWARD_PKT, then the HASH_DSTPRT[<b>4</b>:<b>0</b>] signals are asserted with a binary port number designating the destination port for the packet. The HASH_BP* signal is asserted to indicate backpressure, if backpressure is enabled and applicable, due to a threshold overflow condition in the memory <b>212</b> as determined by the MCB <b>404</b>.

Certain threshold values are set for the entire memory <b>212</b>, for particular types of packets (BC packets, for example) and on a port by port basis. If a threshold value is reached, so that another packet provided to the memory <b>212</b> would violate a threshold condition, the network switch <b>102</b> determines whether to drop the packet. The sending device eventually detects that the packet is dropped and re-sends the packet. If certain threshold conditions are violated, if backpressure is enabled and if the source port is operating in half duplex mode, the HASH_BP* signal is asserted.

The HASH REQ LOGIC <b>532</b> detects the HASH_BP* signal and determines if HASH_STATUS[<b>1</b>:<b>0</b>]=DROP_PKT, such as, for example, the source and destination ports are the same. If HASH_STATUS[<b>1</b>:<b>0</b>]=DROP_PKT, then no further action is required since the packet is to be dropped. If HASH_STATUS[<b>1</b>:<b>0</b>] is not equal to DROP_PKT, then the HASH REQ LOGIC <b>532</b> determines if HASH_STATUS[<b>1</b>:<b>0</b>]=FORWARD_PKT and the packet is to be transferred in CT mode through the CT BUF <b>528</b>, thereby potentially avoiding the memory <b>212</b>. If the destination port is busy, or if HASH_STATUS[<b>1</b>:<b>0</b>] does not indicate to drop or to forward the packet, then the HASH REQ LOGIC <b>532</b> instructs the HSB controller <b>505</b> to execute a backpressure cycle to the port receiving data.

During SnF operation, the EPSM <b>210</b> receives and stores the entire packet in the memory <b>212</b> before sending any portion of the packet to a destination port. After the packet is received and if the destination port is known, the packet is sent to the destination port when available according to the particular arbitration scheme being used. For CT operation to apply, both ports are preset for CT mode in the CT_SNF registers <b>507</b>, both ports operate at the same speed and the TBUS setting for the destination port is greater than or equal to the TBUS setting for the source port. For the particular embodiment shown using the TLANs <b>226</b> to implement the 100 Mbps Ethernet ports PORT24-PORT27, CT mode is not performed for the ports PORT24-PORT27 since the TLANs require the size of the entire packet prior to transmission. Also, the shown embodiment requires the TBUS values to be equal. The present invention is not limited by these various design considerations. During CT mode of operation, the EPSM <b>210</b> provides the data to the appropriate QC device <b>202</b> for transmission on the indicated destination port if it is not busy. The packet data is buffered through the FIFOs <b>412</b> between the source and destination ports without being transferred to the memory <b>212</b>.

If the destination port is busy at the beginning of a received packet, the data is buffered in the memory <b>212</b> between the source and destination ports according to the interim CT mode of operation. However, the packet portion is immediately available for transmission by a destination port, so that the transfer to the destination port need not wait for the entire packet to be received. As a safety mechanism, interim CT mode of operation may be overridden and the operation for that particular packet switched to SnF mode for the next packet.

If, for any reason, the destination port is unable to accept more data during transfer of a packet in CT mode, such as when the destination port stalls, then operation is switched to the mid-packet interim CT mode. During the mid-packet interim CT mode, the packet data in the FIFOs <b>412</b> is sent to the memory <b>212</b>, and then sent to the destination port when it is available to receive more data. It is noted that since other, subsequently received packets may be received by other ports for transmission by the same stalled port, where these subsequent packets are placed in a corresponding transmit chain for the port, the remaining packet portion of the packet switched to mid-packet interim CT mode is placed first in the transmit chain to ensure proper ordering.

Another mode is referred to as the adaptive SnF mode. While a packet is being transferred according to CT operation, the CPU <b>230</b> monitors and tracks activity of the ports <b>104</b>, <b>110</b> and the PCB <b>406</b> to determine if any one or more of the ports experiences a significant number of errors, such as “runts”, “overruns”, “jabbers”, late collisions, FCS errors, etc. A runt is a packet less than a certain minimum amount of data, which minimum is 64 bytes in the embodiment shown. An overrun is a packet that is greater than a certain maximum amount of data, which maximum is 1,518 bytes in the embodiment shown according to the Ethernet standard. A jabber is packet larger than the maximum size (1,518 bytes for Ethernet) and contains an invalid CRC (cyclic redundancy check) value. Usually, packets with any such errors are dropped and not propagated through the system. According to the adaptive SnF mode, if a port <b>104</b> is operating using CT operation and a significant number of such errors are experienced as determined by the CPU <b>230</b>, the CPU <b>230</b> toggles the preset mode for the desired port from CT to SnF operation until any errors are corrected or otherwise eliminated.

Operation of the ports <b>110</b> of each TLAN <b>226</b> is similar, except that packet data passes through the TPI <b>220</b> across the HSB <b>206</b> to the EPSM <b>210</b> and is stored in the memory <b>212</b> prior to transmission. The TPI <b>220</b> effectively operates as a bridge between the PCI bus <b>222</b> and the HSB <b>206</b>. The TLANs <b>226</b> require the length of the entire packet before transmitting the packet to an external network, so that each packet is received and stored in the memory <b>212</b> in its entirety before being re-transmitted to by one of the TLANs <b>226</b>. Furthermore, data received by a TLAN <b>226</b> for transmission by a QC device <b>202</b>, and data received by a QC device <b>202</b> for transmission by a TLAN <b>226</b> are operated in SnF mode and stored in the memory <b>212</b> due to the large speed differential between the devices <b>202</b>, <b>226</b> in the embodiment shown.

The RX MCB interface <b>530</b> asserts a signal RX_PKT_AVAIL* to the MCB <b>404</b> when packet data is in one of the RX BUFs <b>520</b>, <b>522</b> and ready for transfer to the memory <b>212</b>. Packet data is transferred from the HCB <b>402</b> to the MCB <b>404</b> on a memory data output bus MemDataOut or MDO[<b>31</b>:<b>0</b>]. A static signal MEM_EDO is asserted if the type of memory <b>212</b> is either EDO or synchronous DRAM, and is not asserted for FPM DRAM.

The RX MCB interface <b>530</b> also asserts several other signals while asserting the RX_PKT_AVAIL* signal as appropriate. In particular, the RX MCB interface <b>530</b> multiplexes the source port number on RX_SRC_DST[<b>4</b>:<b>0</b>] signals for one CLK cycle followed by the destination port number, if known, during the next CLK cycle while asserting the RX_PKT_AVAIL* signal. Also, the RX MCB interface <b>530</b> asserts the number of DWORDs (minus one DWORD) on RX_CNT[<b>5</b>:<b>0</b>] signals that is in the selected RX BUF <b>520</b> or <b>522</b>.

The RX MCB interface <b>530</b> asserts a signal RX_SOP* with the RX_PKT_AVAIL* signal if the data is the beginning of a packet, or asserts a signal RX_EOP* with the RX_PKT_AVAIL* signal if the data is the end the packet. The RX MCB interface <b>530</b> asserts a signal RX_CUT_THRU_SOP* with the RX_PKT_AVAIL* and RX_SOP* signals if the packet is being transferred in CT mode but buffered through the memory <b>212</b>, such as for interim CT or mid-packet CT modes. In particular, interim CT (full packet) is indicated if (!RX_CUT_THRU_SOP* &amp; !RX_PKT_AVAIL* &amp; !RX_SOP*) and interim CT mid-packet is indicated if (!RX_CUT_THRU_SOP* &amp; !RX_PKT_AVAIL* &amp; RX_SOP*). The RX MCB interface <b>530</b> asserts a signal RX_MISS_BC* with the RX_PKT_AVAIL* and RX_SOP* signals if the destination address was unknown and thus the packet is a BC packet. The RX MCB interface <b>530</b> asserts a signal RX_GROUP_BC* with the RX_PKT_AVAIL* and RX_SOP* signals if the GROUP bit is set within the packet header, so that, again, the packet is a BC packet. The RX MCB interface <b>530</b> asserts a signal RX_END_BYTE[<b>1</b>:<b>0</b>] with the RX_PKT_AVAIL* and RX_EOP* signals to indicate the byte lane of the last byte in the packet.

The RX MCB interface <b>530</b> asserts a signal RX_ERROR* with the RX_PKT_AVAIL* and RX_EOP* signals if the source port detects and indicates an error in the packet during transmission by asserting the ABORT_OUT* signal. Several error conditions are checked by the ports <b>104</b>, <b>110</b>, such as detection of a FIFO overrun, a runt packet, an oversized packet, frame check sequence (FCS) error, or a Phased-Locked Loop (PLL) error. If the RX_ERROR* signal is asserted, the network switch <b>102</b> drops the packet if being transferred in SnF mode.

The MCB <b>404</b> asserts a signal RX_ACK* to the HCB <b>402</b> after detecting the RX_PKT_AVAIL* signal asserted and after latching the associated signals asserted with the RX_PKT_AVAIL* signal as described above. The MCB <b>404</b> asserts a signal RX_STB* when it is ready to accept the next DWORD of data. The MCB <b>404</b> asserts a signal RX_PKT_COMPLETE* when it determines that the HCB <b>402</b> may request the data. In particular, the MCB <b>404</b> asserts the RX_PKT_COMPLETE* signal after detecting the RX_SOP* signal asserted by the HCB <b>402</b> for CT mode packets. Also, the MCB <b>404</b> asserts the RX_PKT_COMPLETE* signal after detecting the RX_EOP* signal asserted by the HCB <b>402</b> for SnF mode packets. The MCB <b>404</b> does not assert the RX_PKT_COMPLETE* signal if the RX_ERROR* signal was asserted for a SnF packet (indicated by the RX_CUT_THRU* signal not being asserted with the RX_SOP* signal). The MCB <b>404</b> asserts a signal RX_PKT_ABORTED* to the HCB <b>402</b> in lieu of the RX_PKT_COMPLETE* signal if the packet is dropped due to an overflow condition of the memory <b>212</b> as determined by the MCB <b>404</b>.

The TX ARB REQ LOGIC <b>533</b> receives a request from the arbitration logic <b>504</b> to retrieve packet data from the memory <b>212</b> for transmission by an available destination port, which request is typically originated by the TX NW arbiter <b>515</b>. The TX ARB REQ LOGIC <b>533</b> correspondingly asserts a transmit request signal TX_ARB_REQ* to the MCB <b>404</b> while also asserting the destination port number on signals TX_ARB_PORT[<b>4</b>:<b>0</b>] and a maximum transfer length for each data portion on signals TX_ARB_XSIZE[<b>2</b>:<b>0</b>]. The maximum transfer length is defined for the TX BUFs <b>524</b>, <b>526</b> as 000b=16 bytes, 001b=32 bytes, 010b=64 bytes, 011=128 bytes and 100=256 bytes. The MCB <b>404</b> latches these values and asserts an acknowledge signal TX_ARB_ACK* to the TX ARB REQ LOGIC <b>533</b>. The MCB <b>404</b> then retrieves the requested data from the memory <b>212</b> and writes the data to one of the TX BUFs <b>524</b>, <b>526</b>.

Data is transferred to the TX BUFs <b>524</b>, <b>526</b> in the HCB <b>402</b> across a memory data input bus MemDataIn or MDI[<b>31</b>:<b>0</b>]. The TX MCB interface <b>531</b> asserts a signal TX_BUF_AVAIL* when the FIFO control block <b>529</b> determines that either of the TX BUFs <b>524</b>, <b>526</b> are available to receive data from the MCB <b>404</b>. The MCB <b>404</b> asserts a strobe signal TX_STB* when data is available to be sampled by the TX MCB interface <b>531</b> of the HCB <b>402</b> for storage in the available TX BUF <b>524</b> or <b>526</b>. The MCB <b>404</b> asserts several signals concurrently with the TX_STB* signal for identifying characteristics of the data. In particular, the MCB <b>404</b> asserts a signal TX_SOP* with the TX_STB* signal for the beginning or start of a packet from the memory <b>212</b>. The MCB <b>404</b> asserts a signal TX_AIFCS* with the TX_STB* signal if the source port is the PCB <b>406</b> indicating the CPU <b>230</b>. The MCB <b>404</b> asserts a binary number on signals TX_CNT[<b>5</b>:<b>0</b>] with the TX_STB* signal, where the TX_CNT[<b>5</b>:<b>0</b>] signals indicate the number of DWORDs (minus one DWORD) to write into the selected TX FIFO. The MCB <b>404</b> asserts a signal TX_EOP* with the TX_STB* signal for the end of the packet from the memory <b>212</b>. The MCB <b>404</b> also asserts an end of buffer chain signal TX_EOBC* with the TX_EOP* and TX_STB* signals if there is no more data in the memory <b>212</b> for the particular destination port. The MCB <b>404</b> also asserts end byte signals TX_END_BYTE[<b>1</b>:<b>0</b>]* with the TX_EOP* and TX_STB* signals to indicate the byte lane of the last byte in the packet.

For BC packets, the MCB <b>404</b> asserts a signal BC_PORT_STB* while asserting a BC bitmap on the MDI[<b>31</b>:<b>0</b>] signals. The FIFO control block <b>529</b> detects assertion of the BC_PORT_STB* signal, latches the MDI[<b>31</b>:<b>0</b>] signals and stores the result in an internal BCBITMAP[<b>28</b>:<b>0</b>] register. The FIFO control block <b>529</b> uses the values in the BCBITMAP register when setting bits in an array of memory bits TXMEMCYC[<b>28</b>:<b>0</b>] in the TRANSMIT LIST <b>510</b>.

FIG. 5B is a diagram illustrating several of the registers within the registers <b>506</b>. The CT_SNF registers <b>507</b> include an array of programmable source port mode bits SRC CT_SNF[<b>28</b>:<b>0</b>], each corresponding to one of the ports PORT28 to PORT0, respectively, which are programmed by the CPU <b>230</b> to identify the desired mode of operation between CT and SnF when the corresponding port is a source port. In particular, when the SRC CT_SNF bit is set for a given port, it is desired to operate that port in CT mode when the port is acting as a source port. When the SRC CT_SNF bit is cleared, it is desired to operate that port in SnF mode when the port is acting as a source port. Likewise, the CT_SNF registers <b>507</b> include an array of programmable destination port mode bits DEST CT_SNF[<b>28</b>:<b>0</b>], each corresponding to one of the ports PORT28 to PORT0, respectively, which are programmed by the CPU <b>230</b> to identify the desired mode of operation between CT and SnF when the corresponding port is acting as a destination port for a unicast packet. CT mode is desired only when the source and destination ports are both designated for CT mode in the CT_SNF registers <b>507</b>.

The RECEIVE LIST <b>509</b> includes a plurality of registers for storing corresponding receive priority counts referred to as the RXPORTBUFx[<b>4</b>:<b>0</b>] counts, where “x” reflects the port number. Each RXPORTBUFx count is five bits in the embodiment shown for prioritizing up to 32 ports. The RECEIVE LIST <b>509</b> includes a corresponding array of port mask bits RXPRTMSK[<b>28</b>:<b>0</b>], where each RXPRTMSK bit is set by the RX poll state machine <b>502</b> when that RXPRTMSK bit is initially at logic 0, indicating priority is not currently assigned, and when the respective PKT_AVAILm* signal is then asserted. At that time, the RX poll state machine <b>502</b> assigns a priority number in the corresponding RXPORTBUFx register. The priority number remains valid until the port is serviced. While the RXPRTMSK bit is set, the RX poll state machine <b>502</b> ignores further requests by masking subsequent assertions of the corresponding PKT_AVAILm* signal. The HSB controller <b>505</b> clears the RXPRTMSK bit during every read cycle transfer from the respective port for that packet other than for the first transfer for a new packet. The HASH REQ LOGIC <b>532</b> clears the RXPRTMSK bit during the first read cycle transfer if the packet is to be transferred according to SnF mode of operation. The HSB controller <b>505</b> clears the RXPRTMSK bit during the first write cycle transfer to the destination port if the packet is transferred in CT mode.

The RECEIVE LIST <b>509</b> includes an array of in-queue bits RXINQUE[<b>28</b>:<b>0</b>], which are each set when the corresponding RXPRTMSK bit is set. Each RXINQUE bit indicates whether the priority value is valid and if so, that the corresponding port is to be included in arbitration by the arbitration logic <b>504</b>. The RXINQUE bit is cleared by an arbiter in the arbitration logic <b>504</b> when the respective port is submitted to the MAIN arbiter <b>512</b> to be serviced as the next port for transferring data for a new packet or for a continuing SnF packet.

The RECEIVE LIST <b>509</b> includes an array of memory bits RXMEMCYC[<b>28</b>:<b>0</b>] which indicate whether the respective port is to receive data into the memory <b>212</b>. This occurs for SnF mode, for interim CT mode and for interim mid-packet CT mode of operation. The HASH REQ LOGIC <b>532</b> sets a corresponding RXMEMCYC bit upon determination of SnF mode or interim CT mode. The MAIN arbiter <b>512</b> sets the RXMEMCYC bit for mid-packet interim CT mode packets if the destination port does not indicate buffer space available during normal CT mode. The HSB controller <b>505</b> clears the RXMEMCYC bit on the last read cycle transfer of data for the respective port.

The RECEIVE LIST <b>509</b> includes an array of active or CT bits RXACTCYC[<b>28</b>:<b>0</b>], which indicate whether the respective port is transferring a data packet according to normal CT mode of operation. The HASH REQ LOGIC <b>532</b> sets a corresponding RXACTCYC bit for CT mode packets. The HSB controller <b>505</b> clears the RXACTCYC bit on a read cycle of the last data transfer of a packet for the corresponding port. The MAIN arbiter <b>512</b> clears the RXACTCYC bit if the bit is set for CT mode and the MAIN arbiter <b>512</b> converts the packet to a mid-packet interim CT packet.

The TRANSMIT LIST <b>510</b> includes a plurality of registers for storing corresponding transmit priority counts referred to as the TXPORTBUFx[<b>4</b>:<b>0</b>] counts, where “x” reflects the port number. Each TXPORTBUFx count is five bits in the embodiment shown for prioritizing up to 32 ports. The TRANSMIT LIST <b>510</b> includes a corresponding array of port mask bits TXPRTMSK[<b>28</b>:<b>0</b>], where each TXPRTMSK bit is set by the TX poll state machine <b>503</b> when that TXPRTMSK bit is initially at logic <b>0</b>, indicating priority is not currently assigned, and when the respective BUF_AVAILm* signal is then asserted. At that time, the TX poll state machine <b>503</b> assigns a priority number in the corresponding TXPORTBUFx register. The priority number remains valid until the port is serviced. While the TXPRTMSK bit is set, the TX poll state machine <b>503</b> ignores further requests by masking subsequent assertions of the corresponding BUF_AVAILm* signal. The HSB controller <b>505</b> clears the TXPRTMSK bit during every read cycle transfer from the respective port for that packet other than for the first transfer for a new packet. The HSB controller <b>505</b> clears the TXPRTMSK bit during every write cycle transfer of packet data to the destination port.

The TRANSMIT LIST <b>510</b> includes an array of in-queue bits TXINQUE[<b>28</b>:<b>0</b>], which are each set when the corresponding TXPRTMSK bit is set. Each TXINQUE bit indicates whether the priority value is valid and if so, that the corresponding port is to be included in arbitration by the arbitration logic <b>504</b>. The TXINQUE bit is cleared by an arbiter in the arbitration logic <b>504</b> when the respective port is submitted to the MAIN arbiter <b>512</b> to be serviced for transferring data for a new packet or a continuing SnF packet.

The TRANSMIT LIST <b>510</b> includes the TXMEMCYC[<b>28</b>:<b>0</b>] array of memory bits, which indicate whether the respective port is to transmit data received from the memory <b>212</b>. This occurs for SnF mode, for interim CT mode and for interim mid-packet CT mode of operation. The FIFO control block <b>529</b> sets one or more TXMEMCYC bit in response to assertion of the RX_PKT_COMPLETE* signal by the MCB <b>404</b> after receiving data from the HCB <b>402</b>. For unicast packets, only one of the TXMEMCYC bits are set. For BC packets, the FIFO control block <b>529</b> uses its BCBITMAP register to determine which TXMEMCYC bits to set. For SnF mode packets, the TXMEMCYC bits are set after the entire packet is transferred to the MCB <b>404</b> for storage in the memory <b>212</b>. For interim CT mode packets including mid-packet interim mode CT packets, a TXMEMCYC bit is set during the first data transfer of data to the MCB <b>404</b>. The HSB controller <b>505</b> clears a TXMEMCYC bit on the last write cycle transfer of data to a respective port. This occurs when the MCB <b>404</b> also asserts the TX_EOBC* signal indicating there is no more data in the memory <b>212</b> for that port.

The TRANSMIT LIST <b>510</b> includes an array of transmit CT bits TXCTCYC[<b>28</b>:<b>0</b>], which indicate whether there is data in one of the RX BUFs <b>520</b>, <b>522</b> for writing directly to the respective destination port according to normal CT mode of operation. The HASH REQ LOGIC <b>532</b> sets a corresponding TXCTCYC bit on the first data transfer of the packet. The HSB controller <b>505</b> clears the TXCTCYC bit on the first write cycle transfer of data to the corresponding destination port.

The TRANSMIT LIST <b>510</b> includes an array of active CT bits TXACTCTCYC[<b>28</b>:<b>0</b>], which indicate whether the respective port is involved in transferring a packet according to CT mode of operation. The HASH REQ LOGIC <b>532</b> sets a corresponding TXACTCYC bit when it determines that the packet is to be transferred according to CT mode. The FIFO control block <b>529</b> clears the TXACTCYC bit during the first transfer of data to the MCB <b>404</b> for storage in the memory <b>212</b> when the packet is converted from CT mode to mid-packet interim CT mode. The HSB controller <b>505</b> also clears the TXACTCYC bit during the last data transfer of a packet.

The WEIGHT FACTORS <b>508</b> include an array of port weight factors PORTWTx[<b>4</b>:<b>0</b>] for each of the ports PORT0-PORT28, where “x” indicates the particular port number. The PORTWT weight factors are preferably unique and pre-programmed by the user for providing user-programmable priority of the ports. In the embodiment shown, the same weight factor is assigned to each port for both the receive and transmit cases, although different weight factors could be defined for the transmit and receive operations.

FIG. 5C is a state diagram illustrating the receive poll operation of the RX poll state machine <b>502</b>. The primary function of the RX poll state machine <b>502</b> is to monitor the PKT_AVAILm* signals, assign priority counts RXPORTBUFx and set the RXPRTMSK bits in the RECEIVE LIST <b>509</b>. Transitions between states are based on transitions or cycles of the CLK signal and the state of the STROBE* signal. Initially, upon power-up and configuration, the receive priority count number RPCOUNT is set equal to zero and the RX poll state machine <b>502</b> is placed in an initial idle state <b>550</b>. Also, RXINCCNTBY[<b>7</b>:<b>0</b>] logic bits that correspond to the PKT_AVAILm* signals are cleared. The RX poll state machine <b>502</b> stays in state <b>550</b> while the STROBE* signal is not asserted, which is when the STROBE* signal is high or at logic 1. When the STROBE* signal is asserted low, operation transitions to one CLK wait state (RxPollWait) <b>552</b>.

In response to sampling the STROBE* signal being asserted, the QC devices <b>202</b>, the TPI <b>220</b> and the PCB <b>406</b> each respond by asserting a corresponding one of the PKT_AVAILm* signals, otherwise referred to as the PKT_AVAIL[<b>7</b>:<b>0</b>]* signals, after one CLK cycle. Thus, operation proceeds to state <b>554</b> after one CLK cycle to begin polling each of the PKT_AVAIL[<b>7</b>:<b>0</b>]* signals. Operation transitions from state <b>554</b> to state <b>556</b>, then to state <b>558</b> and then to state <b>560</b> on successive cycles of the CLK signal. Operation returns to state <b>554</b> from state <b>560</b> and continues to loop while the STROBE* signal remains asserted. However, the STROBE* signal is preferably periodic and is negated for one CLK cycle and then re-asserted for the next three CLK cycles. Thus, operation returns to state <b>550</b> if the STROBE* signal is de-asserted at step <b>560</b>. In each of the states <b>554</b>, <b>556</b>, <b>558</b> and <b>560</b>, an initial arbitration count logic operation is performed based on an increment of the RXNEWCNT and RXACTCNT numbers compared to the RPCOUNT number to determine if any of the remaining logic operations are performed.

If the initial arbitration count logic operation is true at step <b>554</b>, nine logic operations are performed, labeled <b>1</b>-<b>9</b>, where the first eight operations correspond to ports PORT0, PORT4, PORT8, PORT12, PORT16, PORT20, PORT24 and PORT28, respectively, for the first port of each of the QC devices <b>202</b> and the TPI <b>220</b>, and the PCB <b>406</b>. For each of the eight port logic operations 1-8, a corresponding one of the PKT_AVAILm* signals is compared to a corresponding RXPRTMSK bit to determine whether to accept the request. If the request is accepted for a port, which occurs if the RXPRTMSK has not been previously set, an RXPORTBUFx priority number is assigned for that port. Also, the corresponding RXPRTMSK bit is set to logic 1 to mask further requests by that port, and a corresponding RXINCCNTBY bit is set to logic 1. The ninth logic operation is performed to increment RPCOUNT.

For PORT0, if PKT_AVAIL[<b>0</b>]* is not asserted or if RXPRTMSK[<b>0</b>] is equal to logic 1, then priority has already been established and is not changed until PORT0 is serviced. If, however, the PKT_AVAIL[<b>0</b>]* signal is asserted low and if RXPRTMSK[<b>0</b>] is logic 0, then the corresponding priority count RXPORTBUF0 is set equal to the corresponding weight factor RXPORTWT0 if a WTPRIORITY flag indicates priority according to the weight factors. If, however, the WTPRIORITY flag is false, the priority count RXPORTBUF0 is set equal to RPCOUNT. Then, the RXPRTMSK[<b>0</b>] and RXINCCNTBY[<b>0</b>] bits are both set to logic 1. Setting RXPRTMSK[<b>0</b>] masks further receive polling requests for PORT0. The RXINCCNTBY[<b>0</b>] bit corresponds to the PKT_AVAIL[<b>0</b>]* signal and is used in remaining logic operations in state <b>554</b> to indicate that a priority value was set for PORT0.

In the second logic operation corresponding to PORT4, if PKT_AVAIL[<b>1</b>]* is not asserted low or if RXPRTMSK[<b>4</b>] is equal to logic 1, then priority has already been established and is not changed until PORT4 is serviced. If, however, the PKT_AVAIL[<b>1</b>]* signal is asserted low and if RXPRTMSK[<b>4</b>] is logic 0, then the corresponding priority count RXPORTBUF4 is set equal to the corresponding weight factor RXPORTWT4 if the WTPRIORITY flag indicates priority according to the weight factors. If, however, the WTPRIORITY flag is false, the priority count RXPORTBUF4 is set equal to RPCOUNT plus RXINCCNTBY[<b>0</b>]. In this manner, if WTPRIORITY is false, RXPORTBUF4 is given a priority number of RPCOUNT if PORT0 was not assigned a priority number, or is given a priority number of RPCOUNT+1 if PORT0 was given a priority number. This ensures that PORT0 and PORT4 are not given the same priority number. The RXPRTMSK[<b>4</b>] bit is then set to logic 1 to mask further polling requests. In this manner, the priority number assigned to each port is either the predetermined weight factor for that port, or the priority number is equal to RPCOUNT plus the number of ports having a lower port number and assigned a priority number at the same time.

The next six logic operations are similar to the second logic operation. In eighth logic operation corresponding to the PCB <b>406</b>, if PKT_AVAIL[<b>7</b>]* is not asserted low or if RXPRTMSK[<b>28</b>] is equal to logic 1, then priority has already been established and is not changed until the PCB <b>406</b> is serviced. If, however, the PKT_AVAIL[<b>7</b>]* signal is asserted low and if RXPRTMSK[<b>28</b>] is logic 0, then the corresponding priority count RXPORTBUF28 for the PCB <b>406</b> is set equal to the corresponding weight factor RXPORTWT28 if the WTPRIORITY flag indicates priority according to the weight factors. If, however, the WTPRIORITY flag is false, the priority count RXPORTBUF28 is set equal to RPCOUNT plus the “bit sum” of RXINCCNTBY[<b>6</b>:<b>0</b>]. The bit sum of RXINCCNTBY[<b>6</b>:<b>0</b>] equals the number of the number of priority values that were assigned in the previous seven port logic operations. Thus, the PCB <b>406</b> is given a priority number equal to the predetermined weight factor, or the priority number is RPCOUNT plus the number of ports having a lower port number and simultaneously assigned a priority number. A ninth logic operation is performed in state <b>554</b> to increment RPCOUNT by the bit sum of RXINCCNTBY[<b>7</b>:<b>0</b>], which equals the number of ports assigned priority in state <b>554</b>. This operation ensures that RPCOUNT is incremented for the next set of logic operations in state <b>556</b>.

For example, if all of the ports associated with the first multiplexed bit of the PKT_AVAIL[<b>7</b>:<b>0</b>]* signals, or ports PORT0, PORT4, PORT8, PORT12, PORT16, PORT20, PORT24 and PORT28 request at the same time in state <b>554</b> and RPCOUNT is initially equal to zero and none of the corresponding RXPRTMSK bits have previously been set and if WTPRIORITY is false, then the corresponding priority counts RXPORTBUFx (x=0, 4, 8, 12, 16, 20, 24 and 28) are assigned priority numbers of 0, 1, 2, 3, 4, 5, 6 and 7, respectively, in state <b>554</b>. Then, RPCOUNT is set equal to 8. As another example, if ports PORT4, PORT12 and PORT20 are the only ports requesting service, then the priority numbers RXPORTBUFx (x=4, 12, 20) are assigned priority numbers of 0, 1 and 2, respectively, if WTPRIORITY is false, and then RPCOUNT is set equal to 3. The bit sum operation ensures that a unique priority number is given to each port if several ports are requesting service at the same time. In this manner, the priority numbers are according to a first-come, first-served (FCFS) priority scheme, but a particular order is predetermined to establish priority to handle simultaneous assignments.

The logic operations in states <b>556</b>, <b>558</b> and <b>560</b> are similar to those performed in state <b>554</b>. In state <b>556</b>, if the initial arbitration count logic operation is true, eight logic operations are performed, including seven logic operations associated with the second port of each of the QC devices <b>202</b> and the TPI <b>220</b> based on the PKT_AVAIL[<b>6</b>:<b>0</b>]* signals, which includes ports PORT1, PORT5, PORT9, PORT13, PORT17, PORT21 and PORT25, and the eighth logic operation of state <b>554</b> is repeated for the port PORT28 for the CPU <b>230</b>. In state <b>558</b>, seven logic operations associated with the third port of each of the QC devices <b>202</b> and the TPI <b>220</b> are performed based on the PKT_AVAIL[<b>6</b>:<b>0</b>]* signals, including ports PORT2, PORT6, PORT10, PORT14, PORT18, PORT22 and PORT26, and the eighth logic operation of state <b>554</b> is repeated for the port PORT28 for the CPU <b>230</b>. In state <b>560</b>, seven logic operations associated with the fourth port of each of the QC devices <b>202</b> and the TPI <b>220</b> are performed based on the PKT_AVAIL[<b>6</b>:<b>0</b>]* signals, including ports PORT3, PORT7, PORT11, PORT15, PORT19, PORT23 and PORT27, and the eighth logic operation of state <b>554</b> is repeated for the port PORT28 for the CPU <b>230</b>. In each of the states <b>556</b>, <b>558</b> and <b>560</b>, a final logic operation is performed to update the RPCOUNT by the bit sum of the RXINCCNTBY bits in a similar manner as described previously.

FIG. 5D is a state diagram illustrating the transmit poll operation of the TX poll state machine <b>503</b>. The TX poll state machine <b>503</b> operates in a similar manner as the RX poll state machine <b>502</b>, and includes states <b>561</b>, <b>562</b>, <b>564</b>, <b>566</b>, <b>568</b> and <b>570</b>, which are analogous to the states <b>550</b>, <b>552</b>, <b>554</b>, <b>556</b>, <b>558</b> and <b>560</b>, respectively. However, RPCOUNT is replaced with TPCOUNT and the initial arbitration count logic operation is performed based on an increment of the TXNEWCNT and TXACTCNT numbers compared to the TPCOUNT number to determine if any of the remaining logic operations are performed. The BUF_AVAILm* signals replace the PKT_AVAILm* signals, and TXPRTMSK bits replace the RXPRTMSK bits. Also, for each port equation, each TXPRTMSK bit is logically ANDed with a logic term based on corresponding bits of the TXMEMCYC, TXCTACTCYC and TXCTCYC bit arrays. In particular, the corresponding bits of the TXMEMCYC, TXCTACTCYC and TXCTCYC bit arrays are OR'd together so that priority is assigned to a destination port only if data is available in the EPSM <b>210</b> or the memory <b>212</b> for transmission by that port. Also, TXPORTBUFx priority numbers replace the RXPORTBUFx numbers, TXPORTWT weight factors replace the RXPORTWT weight factors and TXINCCNTBY bits replace the RXINCCNTBY bits. In this manner, each port and the PCB <b>406</b> indicates with a respective one of the BUF_AVAIL* signals in response to the STROBE* signal, and the TX poll state machine <b>503</b> assigns a priority number based on the weight factors or FCFS using TPCOUNT, and sets priority accordingly.

It is appreciated that the polling logic <b>501</b> periodically or continuously toggles the STROBE* signal and monitors the PKT_AVAILm* and BUF_AVAILm* signals of each of the ports <b>104</b>, <b>110</b> and the PCB <b>406</b> for assigning priority to each of the requesting ports, and for setting the corresponding poll mask bits. The assigned priority is based on the preprogrammed weight factors if WTPRIORITY is true, or FCFS if WTPRIORITY is false. The priority remains static until the port is serviced. Eventually the port is serviced and the mask bit is cleared, as described below.

The arbiters <b>513</b>-<b>516</b> select between the ports <b>104</b>, <b>110</b> and the PCB <b>406</b> based on one of several arbitration schemes, where the particular arbitration scheme is user-programmable. The first is the round-robin scheme, where the ports are reviewed in any arbitrary order, such as PORT0, PORT1, . . . , PORT28 or the like, or the order is selected by the WEIGHT FACTORS <b>508</b> pre-programmed in the PORTWTx registers. In the embodiment shown, the WEIGHT FACTORS are used to assign the round-robin order, and are programmed into the respective RXPORTBUFx and TXPORTBUFx counts. The RX NW arbiter <b>513</b> uses and increments the RXNEWCNT priority number, the RX ACT arbiter <b>514</b> uses and increments the RXACTCNT priority number, the TX NW arbiter <b>515</b> uses and increments the TXNEWCNT priority number and the TX CT arbiter <b>516</b> uses and increments the TXCTCNT priority number. For the round-robin scheme, the RX arbiters <b>513</b>, <b>514</b> each review the RXINQUE[ ] values to determine the active receive ports requesting service, and then compare its respective priority number (RXNEWCNT, RXACTCNT) with the values in the RXPORTBUFx counts of the active ports to determine the next port to service. Also, the TX arbiters <b>515</b>, <b>516</b> each review the TXINQUE[ ] values to determine the active transmit ports requesting service, and then compare its respective priority number (TXNEWCNT, TXCTCNT) with the count values in the TXPORTBUFx counts of the active ports to determine the next port to service. Since the WEIGHT FACTORS determine a particular order, the ports are ordered in round-robin fashion.

The second arbitration scheme is FCFS, where WTPRIORITY is false and the ports are serviced based on the order they requested service as indicated by the RXPORTBUFx and TXPORTBUFx priority numbers. The FCFS operates in a similar manner as round-robin, except that the RXPORTBUFx and TXPORTBUFx counts are programmed according to the RPCOUNT and TPCOUNT values as described previously. Then, the RX arbiters <b>513</b>, <b>514</b> each review the RXINQUE[ ] values to determine the active receive ports requesting service, and then compare its respective priority number (RXNEWCNT, RXACTCNT) with the values in the RXPORTBUFx counts of the active ports to determine the next port to service. Also, the TX arbiters <b>515</b>, <b>516</b> each review the TXINQUE[ ] values to determine the active transmit ports requesting service, and then compare its respective priority number (TXNEWCNT, TXCTCNT) with the count values in the TXPORTBUFx counts of the active ports to determine the next port to service. Since the RPCOUNT and TPCOUNT values determine the order, the ports are ordered in FCFS fashion.

Another scheme is the weighted priority scheme, where WTPRIORITY is true and the RXPORTWTx and TXPORTWTx numbers are copied into corresponding ones of the RXPORTBUFx and TXPORTBUFx registers and used for determining priority. However, the RX arbiters <b>513</b>, <b>514</b> determine priority from an RX HIGH PRIORITY number and the TX arbiters <b>515</b>, <b>516</b> determine priority from a TX HIGH PRIORITY number. The RX HIGH PRIORITY number is determined by identifying the highest priority number (or the lowest number) in the RXPORTBUFx counts of the active receive ports, where the active receive ports are determined from the RXINQUE values. Likewise, the TX HIGH PRIORITY number is determined by identifying the highest priority number (or the lowest number) in the TXPORTBUFx counts of the active transmit ports, where the active transmit ports are determined from the TXINQUE values. In this manner, an active (requesting service) port with the highest WEIGHT FACTOR is selected each time, thereby implementing the weighted priority scheme.

The RX NW arbiter <b>513</b> handles all new packet header data and continuing SnF mode packet data received at the ports PORT0-PORT28, which data is transferred to either one of the RX BUFs <b>520</b>, <b>522</b>. The RX NW arbiter <b>513</b> updates the RXNEWCNT number and reviews the RECEIVE LIST <b>509</b> to determine which of the ports PORT0-PORT28 meet its receive criterion. The receive criterion for the RX NW arbiter <b>513</b> is met by those ports having their respective RXINQUE bit asserted and their RXACTCYC bit not asserted. The receive criterion for the RX NW arbiter <b>513</b> also includes ports with their respective RXINQUE and RXMEMCYC bits both asserted. The RX NW arbiter <b>513</b> then arbitrates between those ports meeting its receive criterion and according to a selected arbitration scheme as described previously. After selecting a port and defining a cycle, the RX NW arbiter <b>513</b> requests the MAIN arbiter <b>512</b> to execute a read cycle. When the RX NW arbiter <b>513</b> is next selected by the MAIN arbiter <b>512</b>, the RX NW arbiter <b>513</b> clears the RXINQUE bit of the selected port to be serviced. The RX NW arbiter <b>513</b> continuously repeats this process.

The TX CT arbiter <b>516</b> transfers data in the RX BUFs <b>520</b>, <b>522</b> to a destination port for normal CT operation. The TX CT arbiter <b>516</b> updates the TXCTCNT number and reviews the TRANSMIT LIST <b>510</b> to determine which of the ports PORT0-PORT28 meet its transmit criterion. The transmit criterion for the TX CT arbiter <b>516</b> is met by those ports having their respective TXINQUE and TXCTCYC bits both asserted. The TX CT arbiter <b>516</b> then arbitrates between those ports meeting its transmit criterion and according to the selected arbitration scheme as described above. After selecting a port and defining a cycle, the TX CT arbiter <b>516</b> requests the MAIN arbiter <b>512</b> to execute a write cycle from the selected RX BUF <b>520</b> or <b>522</b> to the winning destination port. When the TX CT arbiter <b>516</b> is next selected by the MAIN arbiter <b>512</b>, the TX CT arbiter <b>516</b> clears the TXINQUE bit of the selected port to be serviced. The TX CT arbiter <b>516</b> continuously repeats this process.

The RX ACT arbiter <b>514</b> transfers subsequent packet data to the CT BUF <b>528</b> from a source port operating in normal CT mode of operation, other than the first read cycle for a new packet (which is handled by the RX NW arbiter <b>513</b>). The RX ACT arbiter <b>514</b> updates the RXACTCNT number and reviews the RECEIVE LIST <b>509</b> to determine which of the ports PORT0-PORT28 meet its receive criterion. The receive criterion for the RX ACT arbiter <b>514</b> is met by those ports having their respective RXINQUE and RXACTCYC bits asserted and their respective RXMEMCYC bit not asserted. The RX ACT arbiter <b>514</b> then arbitrates between those ports meeting its receive criterion and the selected arbitration scheme as described above. After selecting a port and defining a cycle, the RX ACT arbiter <b>514</b> requests the MAIN arbiter <b>512</b> to execute a read cycle to transfer data from the selected source port to the CT BUF <b>528</b>. When the RX ACT arbiter <b>514</b> is next selected by the MAIN arbiter <b>512</b>, the RX ACT arbiter <b>514</b> clears the RXINQUE bit of the selected port to be serviced. The RX ACT arbiter <b>514</b> continuously repeats this process.

The MAIN arbiter <b>512</b> follows each CT mode read cycle into the CT BUF <b>528</b> with a write cycle to transfer data in the CT BUF <b>528</b> to the destination port indicated by the HASH REQ LOGIC <b>532</b>. The MAIN arbiter <b>512</b> determines whether the destination port is busy before allowing the RX ACT arbiter <b>514</b> to transfer CT data to the CT BUF <b>528</b>. If the MAIN arbiter <b>512</b> determines that that destination port is busy, it converts the source and destination ports to mid-packet interim CT mode by setting the respective RXMEMCYC bit and clearing the respective RXACTCYC bit for the source port.

The TX NW arbiter <b>515</b> transfers data from either of the TX BUFs <b>524</b>, <b>526</b> to the HSB <b>206</b> according to SnF mode of operation. The TX NW arbiter <b>515</b> updates the TXNEWCNT number and reviews the TRANSMIT LIST <b>510</b> to determine which of the ports PORT0-PORT28 meet its transmit criterion. The transmit criterion for the TX NW arbiter <b>515</b> is met by those ports having their respective TXINQUE and TXMEMCYC bits asserted and their respective TXACTCTCYC bit not asserted. The TX NW arbiter <b>515</b> then arbitrates between those ports meeting its transmit criterion according to the selected arbitration scheme. After selecting a port and defining a write cycle from a TX BUFs <b>524</b>, <b>526</b> to the selected destination port, the TX NW arbiter <b>515</b> requests the MAIN arbiter <b>512</b> to execute the write cycle. When the TX NW arbiter <b>515</b> is next selected by the MAIN arbiter <b>512</b>, the TX NW arbiter <b>515</b> clears the TXINQUE bit of the selected port to be serviced. The TX NW arbiter <b>515</b> continuously repeats this process.

Referring now to FIG. 6, a more detailed block diagram is shown of the MCB <b>404</b> within the EPSM <b>210</b>. The MCB configuration registers <b>448</b> are not shown in FIG. 6 though are included and are further accessible as necessary by many of the functional blocks, that will now be described. The MCB <b>404</b> includes a hash controller <b>602</b>, which is coupled to the MCB interface <b>414</b> through the bus <b>420</b>. The hash controller <b>602</b> optionally includes a hash cache table <b>603</b>, which stores data retrieved from the memory <b>212</b>. The hash cache <b>603</b> provides faster access to data recently pulled from the memory <b>212</b> rather than requiring another memory cycle to retrieve recently accessed information. The hash controller <b>602</b> includes Address/Length/Status (AD/LN/ST) outputs coupled to one multi-line input of a four-input address multiplexer (mux) <b>630</b> across a bus <b>610</b>. The AD/LN/ST outputs define an address for the memory <b>212</b>, the length of the transaction for determining whether a burst cycle is to be performed or not, and miscellaneous status signals such as a read/write (R/W) signal, byte enables, a page hit signal, a lock signal, etc. DRAM Request/Grant/Strobe/Control (DRAM RQ/GT/STB/CTL) signals <b>628</b> are coupled to a DRAM memory arbiter <b>638</b> and to DRAM RQ/GT/STB/CTL inputs of the hash controller <b>602</b>. The output of the mux <b>630</b> is provided to AD/LN/ST inputs of a DRAM memory controller <b>636</b>, which is further coupled to the memory <b>212</b> through the memory bus <b>214</b>. The hash controller <b>602</b> has a data input (DIN) for receiving data from a MemDataIn output of the DRAM controller <b>636</b> across a data bus <b>618</b>.

An RX HCB interface <b>601</b> is coupled to the bus <b>420</b> including the MDO[<b>31</b>:<b>0</b>] signals, and includes a data output (DOUT) for providing data to a first multi-line input of a four-input data mux <b>632</b> across a bus <b>620</b>, where the mux <b>632</b> provides its output to MemDataOut inputs of the DRAM controller <b>636</b>. The RX HCB interface <b>601</b> includes STB/CTL inputs for receiving the strobe and control signals of the DRAM RQ/GT/STB/CTL signals <b>628</b>. An RX controller <b>604</b> is coupled to the bus <b>420</b>, and has AD/LN/ST outputs coupled across a bus <b>612</b> to the second input of the mux <b>630</b>. The RX controller <b>604</b> has a data output DOUT coupled to the second input of the mux <b>632</b> across a bus <b>622</b>, a data input DIN coupled to the bus <b>618</b>, SRAM RQ/GT/STB/CTL inputs for receiving SRAM RQ/GT/STB/CTL signals <b>654</b> associated with a static RAM (SRAM) <b>650</b> and DRAM RQ/GT/STB/CTL inputs for receiving the DRAM RQ/GT/STB/CTL signals <b>628</b>.

A TX HCB interface <b>605</b> is coupled to the bus <b>420</b> including the MDI[<b>31</b>:<b>0</b>] signals, and has a data input DIN coupled to the bus <b>618</b> and STB/CTL inputs receiving the strobe and control signals of the DRAM RQ/GT/STB/CTL signals <b>628</b>. A TX controller <b>606</b> is coupled to the bus <b>420</b> and has AD/LN/ST outputs provided to the third input of the mux <b>630</b> across a bus <b>614</b>, a data output DOUT coupled to the third input of the mux <b>632</b> across a bus <b>624</b>, a data input DIN coupled to the bus <b>618</b>, SRAM RQ/GT/STB/CTL inputs for receiving the SRAM RQ/GT/STB/CTL signals <b>654</b> and DRAM RQ/GT/STB/CTL inputs for receiving the DRAM RQ/GT/STB/CTL signals <b>628</b>. The PCB interface <b>424</b> has AD/LN/ST outputs coupled to the fourth input of the mux <b>630</b> across a bus <b>616</b>, a data output DOUT coupled to the fourth input of the mux <b>632</b> across a bus <b>626</b>, a data input DIN coupled to the bus <b>618</b>, SRAM RQ/GT/STB/CTL inputs for receiving the SRAM RQ/GT/STB/CTL signals <b>654</b> and DRAM RQ/GT/STB/CTL inputs for receiving the DRAM RQ/GT/STB/CTL signals <b>628</b>.

The hash controller <b>602</b>, the RX controller <b>604</b>, the TX controller <b>606</b>, the PCB interface <b>424</b>, the RX HCB interface <b>601</b> and the TX HCB interface <b>605</b> each use the STB signal for synchronizing data flow, where assertion of the STROBE signal determines when data is valid for a read cycle or when data is retrieved for a write cycle. The CTL signals are miscellaneous control signals, such as, for example, a signal indicating when a data cycle is completed.

The DRAM arbiter <b>638</b> is further coupled to the DRAM controller <b>636</b> through memory control signals (MEMCTL), and provides mux control signals (MUXCTL) to the select inputs of the muxes <b>630</b>, <b>632</b>. The MEMCTL signals generally indicate the beginning and end of each memory cycle. In this manner, the hash controller <b>602</b>, the RX controller <b>604</b>, the TX controller <b>606</b> and the PCB interface <b>424</b> arbitrate for access to the DRAM controller <b>636</b> to execute a memory cycle to the memory <b>212</b> by asserting respective request signals. The DRAM arbiter <b>638</b> receives the request signals and asserts a corresponding grant (GT) signal to one of the requesting devices <b>602</b>, <b>604</b>, <b>606</b> or <b>424</b>, thereby granting access to that device. Once access is granted, the DRAM arbiter <b>638</b> asserts the MUXCTL signals to the muxes <b>630</b> and <b>632</b> to enable access of the DRAM controller <b>636</b> by the selected one of the devices <b>602</b>, <b>604</b>, <b>606</b> or <b>424</b> to perform memory cycles as desired, and one of the MEMCTL signals is asserted to indicate to the DRAM controller <b>636</b> the start of the cycle. The DRAM controller <b>636</b> asserts or negates one of the MEMCTL signals to indicate completion of a memory cycle.

The hash controller <b>602</b> communicates with the HASH REQ LOGIC <b>532</b> to perform the hashing procedure to determine how to handle a new packet header stored in the HASH REQ LOGIC <b>532</b>. The hash controller <b>602</b> detects the HASH_REQ* signal asserted, retrieves the source and destination media access control (MAC) addresses from the HASH_DA_SA[<b>15</b>:<b>0</b>] signals, and performs the hashing procedure for determining the HASH_STATUS[<b>1</b>:<b>0</b>] signals and for providing the destination port number on the HASH_DSTPRT[<b>4</b>:<b>0</b>] signals, if previously stored in the memory <b>212</b>. The RX controller <b>604</b> and the RX HCB interface <b>601</b> control and transfer data from the RX BUFs <b>520</b>, <b>522</b> to the memory <b>212</b>. The TX controller <b>606</b> and the TX HCB interface <b>605</b> primarily control and transfer data from the memory <b>212</b> to the TX BUFs <b>524</b>, <b>526</b>. The PCB interface <b>424</b> enables the CPU <b>230</b> more direct access to data within memory, including the memory <b>212</b> and the SRAM <b>650</b>.

The SRAM <b>650</b> is coupled to an SRAM controller <b>652</b>, which is further coupled to the RX controller <b>604</b>, the TX controller <b>606</b> and the PCB interface <b>424</b> across a bus <b>653</b>. An SRAM arbiter <b>651</b> is coupled to the SRAM controller <b>652</b> through control signals SCTL, and is also coupled to the SRAM RQ/GT/STB/CTL signals <b>654</b> for controlling access to the SRAM <b>650</b> by the PCB interface <b>424</b>, The TX controller <b>606</b> and the RX controller <b>604</b> across the bus <b>653</b> in a similar manner as the DRAM arbiter <b>638</b> controls access to the DRAM controller <b>636</b>.

The MCB <b>404</b> includes the SRAM <b>650</b> for storing packet control registers and other data as described further below. The packet control registers include a set of pointers to a RECEIVE SECTOR CHAIN per port, a TRANSMIT PACKET CHAIN per port and a FREEPOOL CHAIN of free memory sectors within the memory <b>212</b>. The packet control registers further include control information and parameters for enabling control of the flow of packet data in the network switch <b>102</b>. The memory <b>212</b> includes a packet memory section, which is organized as a plurality of contiguous and equal-sized sectors. The sectors are initially linked together using address pointers or the like forming the FREEPOOL CHAIN. As packet data is received from a port, the sectors are pulled from the FREEPOOL CHAIN and added to the RECEIVE SECTOR CHAIN for that port. Also, the packet is linked into one or more of the TRANSMIT PACKET CHAINs for the one or more destination ports to which the packet is to be sent for transmission. The bus <b>653</b> enables the RX controller <b>604</b>, the TX controller <b>606</b> and the CPU interface <b>436</b> to access the packet control registers, which include the pointers to the packet chains of data in the memory <b>212</b>.

The DRAM controller <b>636</b> further includes memory refresh logic <b>660</b> for maintaining the data within the memory <b>212</b>. The refresh logic <b>660</b> is adaptable to operate according to the type of memory coupled to the memory bus <b>214</b>, including FPM DRAM, EDO DRAM, or synchronous DRAM. In this manner, refresh functions are removed from the CPU <b>230</b> for more efficient operation and improved performance. A 10-bit memory refresh counter (MRC) located in the MCB configuration registers <b>448</b> defines the number of clock cycles between refresh requests. It is desired that the period be less than or equal to 15.625 μs. The default is <b>208</b><i>h</i>, where “h” denotes a hexadecimal value, which provides a refresh period of approximately 15.60 μsecs for a 30 ns CLK cycle. Upon timeout, the MRC counter asserts a signal REFREQ to the DRAM arbiter <b>638</b>, which asserts one of the MEMCTL signals to the DRAM controller <b>636</b> indicating for the memory refresh logic <b>660</b> to perform the refresh cycles. The MCB configuration registers <b>448</b> include a memory control register (MCR), which defines the memory type, speed and configuration of the memory <b>212</b>. For example, 2 bits of the MCR define whether the memory type is FPM, EDO or synchronous DRAM. Another bit defines memory speed as either 50 or 60 ns. Other bits define particular modes of the selected DRAM type and also indicate errors, such as parity errors.

Referring now to FIG. 7A, a more detailed block diagram is shown of the PCB <b>406</b>. The CPU bus <b>218</b> is coupled to CPU interface logic <b>700</b> within the CPU interface <b>432</b>, where the CPU interface logic <b>700</b> is further coupled through a bus <b>701</b> to a QC/CPU interface <b>702</b> for interfacing the QC/CPU bus <b>204</b>. The CPU interface logic <b>700</b> provides data to a 16-byte receive buffer RX BUF <b>706</b> within the FIFOs <b>430</b>, which asserts data on the MCB bus <b>428</b>. The MCB bus <b>428</b> provides data to a 16-byte transmit buffer TX BUF <b>708</b>, also within the FIFOs <b>430</b>, for providing data to the CPU interface logic <b>700</b>. The MCB interface <b>426</b> controls data flow between the CPU interface logic <b>700</b> and the MCB bus <b>428</b>. The CPU interface logic <b>700</b> is coupled to the RX BUF <b>706</b>, the TX BUF <b>708</b> and the MCB interface <b>426</b> through bus signals <b>703</b>.

The CPU interface logic <b>700</b> is coupled to the register interface <b>440</b> through the bus <b>442</b>, where the register interface <b>440</b> enables access to other configuration registers in the EPSM <b>210</b>. The CPU interface logic <b>700</b> is also coupled to a set of PCB registers <b>704</b> through the bus <b>442</b> for defining the input/output (I/O) space of the CPU <b>230</b>, such as interrupt registers, configuration registers, packet information registers, memory related registers, setup and status registers, interface and monitoring registers, statistics registers, mode registers, arbitration registers, etc.

During power up and configuration, the CPU <b>230</b> programs initial or default values in the PCB registers <b>704</b>. For example, the CPU <b>230</b> programs a PORT SPEED REGISTER in the PCB registers <b>704</b>, which is a bitmap defining the speed of each port, which is either 10 or 100 MHz in the embodiment shown. Also, a PORT TYPE REGISTER is programmed, which is a bitmap defining the type of port between QC and TLAN. These registers are typically not changed during operation, but may be re-programmed as desired.

Other registers in the PCB registers <b>704</b> are used during operation. For example, the PCB registers <b>704</b> include an INTERRUPT SOURCE register and a POLLING SOURCE register. The INTERRUPT SOURCE register includes a set of interrupt bits MCB_INT, MEM_RDY, PKT_AVAIL, BUF_AVAIL, ABORT_PKT and STAT_RDY. The PCT_AVAIL and BUF_AVAIL interrupts bits correspond to the PCB_PKT_AVAIL* and PCB_BUF_AVAIL* signals. At least one interrupt signal CPU_INT* is provided to the CPU <b>230</b>, which reads the INTERRUPT SOURCE register to determine the source of the interrupt when the CPU_INT* signal is asserted. The MCB_INT interrupt bit indicates to the CPU <b>230</b> that an interrupt has occurred in the MCB <b>404</b>. The MEM_RDY interrupt bit informs the CPU <b>230</b> that the requested data in the memory <b>212</b> is available in the FIFOs <b>430</b>. The PKT_AVAIL interrupt bit informs the CPU <b>230</b> that packet data is available for the CPU <b>230</b>. The BUF_AVAIL interrupt bit informs the CPU <b>230</b> that buffer space is available for the CPU <b>230</b> to send packet data. The ABORT_PKT interrupt bit informs the CPU <b>230</b> that the ABORT_IN* signal was asserted. The STAT_RDY interrupt bit informs the CPU <b>230</b> that requested statistical information from the QC devices <b>202</b> is in the FIFOs <b>430</b>. The POLLING SOURCE register includes a copy of each interrupt bit in the event the interrupts are masked and the polling method is used.

The CPU interface logic <b>700</b> provides data to a 64-byte receive buffer RX BUF <b>710</b> within the FIFOs <b>434</b>, which asserts data on the HCB bus <b>438</b>. A transmit buffer TX BUF <b>712</b> within the FIFOs <b>434</b> receives data from the HCB bus <b>438</b> for providing the data to the CPU interface logic <b>700</b>. The CPU interface logic <b>700</b> is coupled to the RX BUF <b>710</b>, the TX BUF <b>712</b> and the QC/HCB interface <b>436</b> through bus signals <b>705</b>. The QC/HCB interface <b>436</b> is coupled to the CPU interface logic <b>700</b>, the RX and TX BUFs <b>710</b>, <b>712</b> and the HCB bus <b>438</b> for controlling data transfers between the HCB <b>402</b> and the PCB <b>406</b>.

FIG. 7B is a more detailed block diagram of the CPU interface <b>700</b>. The CPU control and status signals <b>218</b>b are asserted by control logic <b>713</b>, which is further coupled to a CPU tracker state machine <b>717</b> and an alternate memory control state machine <b>718</b>. The address and data portion <b>218</b><i>a </i>of the CPU bus <b>218</b> is a multiplexed bus, where data from other portions of the PCB <b>406</b> are provided to data bus enable logic <b>716</b> for assertion on the CPU address and data portion <b>218</b><i>a </i>to the CPU <b>230</b>. The CPU <b>230</b> asserts addresses to address decode/request generation logic <b>714</b>, which provides a plurality of request signals to other portions of the PCB <b>406</b>, including the CPU tracker state machine <b>717</b> and the alternate memory control state machine <b>718</b>. A set of CPU information latches <b>715</b> receive addresses and data from the CPU <b>230</b> and asserts latched addresses and latched data to other portions of the PCB <b>406</b>, as described further below. CPU control signals are provided between the address decode/request generation logic <b>714</b>, the CPU tracker state machine <b>717</b> and the alternate memory control state machine <b>718</b> for monitoring and controlling CPU cycles.

FIG. 7C is a more detailed diagram of the QC/CPU interface logic <b>702</b>. The QC/CPU interface logic <b>702</b> generally operates to establish a relatively transparent interface between the CPU <b>230</b> and the QC devices <b>202</b>, such as converting between the 32-bit format of the CPU <b>230</b> and the 16-bit format of the QC devices <b>202</b>. A QC REGISTER REQUEST signal is provided from the address decode/request generation logic <b>714</b> to a CPU tracker state machine <b>720</b>, which is coupled to a disassembly/assembly state machine <b>722</b> for converting between 16-bit and 32-bit formats. The disassembly/assembly state machine <b>722</b> is coupled to a set of data, address and control signal drivers and receivers <b>724</b> for interfacing with the CPU interface <b>700</b> across the bus <b>701</b> and with the QC devices <b>202</b> through the QC/CPU bus <b>204</b>. A statistics buffer <b>726</b> receives statistics data and other information from the QC/CPU bus <b>204</b> for providing the data to the CPU interface <b>700</b> across the bus <b>701</b>. A QC STATISTICS REQUEST signal is provided from the address decode/request generation logic <b>714</b> to a statistics request state machine <b>728</b>, which is coupled to the disassembly/assembly state machine <b>722</b> and a QC/CPU bus state machine <b>730</b>. The QC/CPU bus state machine <b>730</b> is further coupled to the disassembly/assembly state machine <b>722</b> and the set of data, address and control signal drivers and receivers <b>724</b>. In this manner, the CPU <b>230</b> has relatively complete and independent access to the QC devices <b>202</b> for gathering statistics and other information of the ports <b>104</b>, and also for modifying the configuration of the ports <b>104</b>, without disturbing data flow and operation of the HSB <b>206</b>.

The CPU <b>230</b> requests the EPSM <b>210</b> to retrieve statistical and status information from the QC devices <b>202</b> by writing to a QC STATISTICS INFORMATION register within the PCB registers <b>704</b>. The CPU <b>230</b> requests statistical information by providing a number corresponding to one of the QC devices <b>202</b>, a port number, the number of the starting register for the indicated port, and the number of registers to be read for the indicated port. As shown in FIG. 7C, writing to the QC STATISTICS INFORMATION register causes the QC STATISTICS REQUEST signal to be asserted, where the statistics request state machine <b>728</b> makes the indicated requests on the QC/CPU bus <b>204</b> through the set of data, address and control signal drivers and receivers <b>724</b>. The CPU interface <b>700</b> performs the desired read cycles to the appropriate QC device(s) <b>202</b> using the appropriate CHIP_SELECTm* signals, and then writes the information into the statistics buffer <b>726</b>.

Once all the requested data is retrieved and stored in the statistics buffer <b>726</b>, the CPU interface <b>700</b> updates the STAT_RDY bit in the POLLING SOURCE register in the PCB registers <b>704</b>, and sets the STAT_RDY interrupt bit in the INTERRUPT SOURCE register. The EPSM <b>210</b> asserts the CPU_INT* signal to the CPU <b>230</b>, which responds by reading the INTERRUPT SOURCE register to determine the source of the interrupt. If interrupts are masked, the CPU <b>230</b> detects STAT_RDY bit in the POLLING SOURCE register during a polling routine. In this manner, the CPU <b>230</b> determines that the request is completed through either an interrupt, or a polling mechanism if the interrupts are masked. The STAT_RDY interrupt is programmatically masked, if desired, if the polling mechanism is to be used. The CPU <b>230</b> respondingly retrieves all of the statistics information from the statistics buffer <b>726</b> in one or more consecutive processor cycles. The processor cycles across the CPU bus <b>218</b> may be regular processor bus cycles, but are preferably burst cycles for transferring larger amounts of data.

Of course, several alternative embodiments are contemplated. In a first alternative embodiment, the CPU <b>230</b> simply provides a number corresponding to any one of the QC devices <b>202</b>, and the EPSM <b>210</b> correspondingly collects all of the data of all of the registers <b>306</b> of all of the ports of the QC device <b>202</b>. In a second alternative embodiment, the CPU <b>230</b> simply provides a global statistics request, and all of the registers <b>306</b> of all of the QC devices <b>202</b> are collected. It is noted, however, that the CPU <b>230</b> typically needs statistics information for one of the ports <b>104</b> at a time.

It is appreciated that the CPU <b>230</b> need only make a single request to the EPSM <b>210</b> to retrieve all the statistics information for any one of the ports <b>104</b>. In particular, the QC STATISTICS INFORMATION register is written by the CPU <b>230</b> in a single command to make the request. The CPU <b>230</b> is then freed to perform other tasks rather than being tied up waiting for responses by the QC devices <b>202</b>. Instead, the EPSM <b>210</b> performs all of the individual statistic read requests across the QC/CPU bus <b>204</b> and gathers all the data. The CPU <b>230</b> is informed through an interrupt signal or a polling mechanism, and is able to retrieve all of the requested information. This results in a more efficient use of CPU <b>230</b> processor time.

FIG. 7D is a more detailed block diagram of the interface between the CPU interface <b>700</b> and the MCB <b>404</b>. A memory request signal from the address decode/request generation logic <b>714</b> is provided to a memory FIFO access state machine <b>740</b>, which is coupled to address generation logic <b>746</b> and FIFO status and interrupt generation logic <b>742</b>. A FIFO block <b>748</b> including the RX BUF <b>706</b> and the TX BUF <b>708</b> is coupled to the address generation logic <b>746</b> and the FIFO status and interrupt generation logic <b>742</b>. The address generation logic <b>746</b> and the FIFO status and interrupt generation logic <b>742</b> are both coupled to a set of data, address and control signal drivers and receivers <b>744</b> for interfacing with the CPU interface <b>700</b> across the bus <b>703</b> and with the MCB <b>404</b> through the MCB bus <b>428</b>.

FIG. 7E is a more detailed block diagram of the interface between the CPU interface <b>700</b> and the HCB <b>402</b>. A packet read request signal from the address decode/request generation logic <b>714</b> is provided to a transmit packet state machine <b>760</b>, which is coupled to a transmit buffer <b>762</b> including the TX BUF <b>712</b>. A packet write request signal from the address decode/request generation logic <b>714</b> is provided to a receive packet state machine <b>768</b>, which is coupled to a receive buffer <b>770</b> including the RX BUF <b>710</b>. The transmit buffer <b>762</b> and the receive buffer <b>770</b> are both coupled to a set of data, address and control signal drivers and receivers <b>764</b> for interfacing with the CPU interface <b>700</b> across the bus <b>705</b> and with the HCB <b>402</b> through the HCB bus <b>438</b>.

Referring now to FIG. 8A, a simplified block diagram is shown more fully illustrating the TPI <b>220</b>. The TPI <b>220</b> transfers data between the HSB <b>206</b> and the PCI bus <b>222</b> to pass network data between the TLANs <b>226</b> and the EPSM <b>210</b>. The TPI <b>220</b> operates as a slave on the HSB <b>206</b>, responds to EPSM <b>210</b> polls, and transfers data to and from the EPSM <b>210</b> in a similar manner as the QC devices <b>202</b>. On the PCI bus <b>222</b> side, the TPI <b>220</b> transfers network data to and receives network data from each of the four TLANs <b>226</b> (PORT24, PORT25, PORT26 and PORT27) across the PCI bus <b>222</b>.

The TPI <b>220</b> includes an HSB controller <b>804</b>, a PCI bus controller <b>802</b>, and memory <b>806</b>. The PCI bus controller <b>802</b> interfaces the PCI bus <b>222</b> in accordance with PCI bus standards and facilitates data transfers between the TPI <b>220</b> and the PCI bus <b>222</b>. The PCI bus standards are defined by the Intel Architecture Lab along with their industry partners. The HSB controller <b>804</b> interfaces the HSB <b>206</b> in accordance with the defined operation of the HSB <b>206</b> and facilitates data transfers between the TPI <b>220</b> and the EPSM <b>210</b>. The memory <b>806</b> may be centralized or distributed and includes a plurality of data buffers <b>807</b> and a control list memory <b>808</b>. The data buffers <b>807</b> provide temporary storage to facilitate data transfer between the PCI bus <b>222</b> and the HSB <b>206</b>. The control list memory <b>808</b> facilitates bus master operation of the TLANs <b>226</b> on the PCI bus <b>222</b>.

Referring now to FIG. 8B, a more detailed block diagram of the TPI <b>220</b> is shown. The TPI <b>220</b> includes PCI bus interface logic <b>810</b>, which further includes buffers, drivers and related circuitry to interface the PCI bus <b>222</b>. The PCI bus <b>222</b> of the present embodiment has a data width of 32 bits and operates at a clock frequency of 33 MHz. It is understood, however, that the PCI bus <b>222</b> may have a different data width and may operate at any desired or available clock frequency, such as 66 MHz, for example. The TPI <b>220</b> includes a PCI arbiter <b>811</b>, which arbitrates between each of the TLANs <b>226</b>, the TPI <b>220</b> and the CPU <b>230</b> for access and control of the PCI bus <b>222</b>. In particular, each of the TLANs <b>226</b>, the TPI <b>220</b> and the CPU <b>230</b> assert a respective one of several request signals REQm to request control of the PCI bus <b>222</b>, where the REQm signals are received by the PCI arbiter <b>811</b>. The PCI arbiter <b>811</b> respondingly grants control to one of the requesting devices by asserting a respective grant signal GNTm. The PCI arbiter <b>811</b> performs round-robin arbitration in the illustrated embodiment, although the PCI arbiter <b>811</b> may use any other arbitration scheme desired. The PCI arbiter <b>811</b> asserts TLAN select signals (TSELm) to identify a particular TLAN <b>226</b> after granting it control of the PCI bus <b>222</b>.

The TPI <b>220</b> includes HSB data transfer interface logic <b>819</b> that includes buffers, drivers and related circuitry to interface the TPI <b>220</b> with the HSB <b>206</b>. The HSB data transfer interface logic <b>819</b> includes read latches <b>819</b><i>a </i>and write latches <b>819</b><i>b </i>for performing concurrent read and write cycles on the HSB <b>206</b>. The HSB data transfer interface logic <b>819</b> includes port status logic <b>820</b> for responding to EPSM <b>210</b> polls and for monitoring cycles executed on the HSB <b>206</b>. In particular, the port status logic <b>820</b> receives and detects assertions of the STROBE* signal by the EPSM <b>210</b> and responds by asserting the PKT_AVAIL*[<b>6</b>] and BUF_AVAIL*[<b>6</b>] signals in multiplexed fashion based upon the data status of the TPI <b>220</b>. The port state logic <b>820</b> also detects read and write cycles on the HSB <b>206</b> intended for the TPI <b>220</b> by detecting the READ_OUT_PKT[<b>6</b>]* and WRITE_IN_PKT[<b>6</b>]* signals, respectively. During transfers of packet data from the TPI <b>220</b> to the EPSM <b>210</b> over the HSB <b>206</b>, the port status logic <b>820</b> asserts the SOP* and EOP* signals during the HSB <b>206</b> bus cycle if transferring the start of packet or the end of packet, respectively. During transfers of packet data from the EPSM <b>210</b> to the TPI <b>220</b> over the HSB <b>206</b>, the port status logic <b>820</b> reads the SOP* and EOP* signals to determine whether the data being received is the start of a packet or the end of a packet, respectively.

The data buffers <b>807</b> include several bidirectional FIFO data buffers <b>807</b><i>a</i>, <b>807</b><i>b</i>, <b>807</b><i>c </i>and <b>807</b><i>d </i>(<b>807</b><i>a-d</i>), each including both a 32-bit wide transmit buffer (TPI TX FIFO) and a 32-bit wide receive buffer (TPI RX FIFO). In the embodiment shown, the data buffers <b>807</b><i>a</i>, <b>807</b><i>b</i>, <b>807</b><i>c </i>and <b>807</b><i>d </i>correspond to the ports PORT24, PORT25, PORT26 and PORT27, respectively. Each TPI RX FIFO receives data from a respective TLAN <b>226</b> across the PCI bus <b>222</b>, where the data is transmitted by the TPI <b>220</b> to the EPSM <b>210</b> across the HSB <b>206</b>. Each TPI TX FIFO receives data from the EPSM <b>210</b> across the HSB <b>206</b>, where the data is transmitted by the TPI <b>220</b> to a respective TLAN <b>226</b> across the PCI bus <b>222</b>.

Receive list decode logic <b>812</b> is coupled to the PCI bus interface logic <b>810</b> and stores at least one receive control list in a receive control list memory (RX CNTL LIST) <b>808</b><i>a</i>, which is part of the control list memory <b>808</b>. The receive list decode logic <b>812</b> responds to the assertion of a RECEIVE LIST MEMORY BASE ADDRESS asserted as an address on the PCI bus <b>222</b> by writing a receive control list from the RX CNTL LIST <b>808</b><i>a </i>as data to the PCI bus <b>222</b>. In the embodiment shown, the RX CNTL LIST <b>808</b><i>a </i>holds one receive control list at a time. In particular, each TLAN <b>226</b> gains control of the PCI bus <b>222</b> and asserts the RECEIVE LIST MEMORY BASE ADDRESS on the PCI bus <b>222</b> and receives a corresponding receive control list from the RX CNTL LIST <b>808</b><i>a</i>. The receive control list includes a PACKET DATA MEMORY BASE ADDRESS for use-by the TLAN <b>226</b>, which is an address indicating where to store the received data. In response to receiving a data packet from its respective port <b>110</b>, the TLAN <b>226</b> then re-gains control of the PCI bus <b>222</b> to transfer data from the received data packet to the TPI <b>220</b> using the stored address in the receive control list fetched earlier. As described further below, the TLAN <b>226</b> arbitrates and is granted control of the PCI bus <b>222</b>, and asserts the PACKET DATA MEMORY BASE ADDRESS during a write cycle on the PCI bus <b>222</b>.

Receive data decode logic <b>813</b>, PCI RX FIFO control logic <b>817</b>, the PCI arbiter <b>811</b> and FIFO synchronization logic <b>818</b> control the flow of received data from the PCI bus interface logic <b>810</b> into the corresponding TPI RX FIFO. The PCI RX FIFO control logic <b>817</b> includes an input to receive data from the PCI bus interface logic <b>810</b> and several selectable outputs, each coupled to the input of a corresponding TPI RX FIFO. The PCI arbiter <b>811</b> provides the TSELm signals to the FIFO synchronization logic <b>818</b>, which asserts corresponding PCI buffer select signals (PBSELm) to the PCI RX FIFO control logic <b>817</b> to select the appropriate TPI RX FIFO based on the particular TLAN <b>226</b> granted access to the PCI bus <b>222</b>. The receive data decode logic <b>813</b> receives and decodes the PACKET DATA MEMORY BASE ADDRESS asserted by the TLAN <b>226</b> executing a write cycle on the PCI bus <b>222</b>, and respondingly asserts a receive enable signal (REN) to the PCI RX FIFO control logic <b>817</b> to enable the PCI RX FIFO control logic <b>817</b> to pass data to the selected TPI RX FIFO.

It is noted that bidirectional data flow occurs between the PCI bus <b>222</b> and the HSB <b>206</b> through the data buffers <b>807</b>. The PCI bus <b>222</b> and the HSB <b>206</b> operate at the same speed in one embodiment, such as a 33 MHz clock, but may operate at different clock frequencies in alternative embodiments. For example, in another embodiment, the HSB <b>206</b> operates at 33 MHz while the PCI bus <b>222</b> operates at 66 MHz. The TPI <b>220</b> is implemented to handle and synchronize data flow in spite of differences in clock speed. Each TPI RX FIFO and TPI TX FIFO of the data buffers <b>807</b><i>a-d </i>is preferably implemented as a circular buffer, with pointers maintained on both sides for writing and reading data. The FIFO synchronization logic <b>818</b> generally operates to synchronize, maintain and update the pointers on both sides of each FIFO to ensure that data is properly written to or read from the appropriate TPI FIFO.

As stated above, each TPI RX FIFO is implemented as a circular buffer. The PCI RX FIFO control logic <b>817</b> includes several PCI receive pointers (PCI RX PTRs), one pointer for each TPI RX FIFO to point to or address the next location to receive a DWORD (32 bits) of data within the selected TPI RX FIFO. In a similar manner, HSB RX FIFO control logic <b>821</b>, located on the other side of each TPI RX FIFO, includes several PCI receive “synchronized” pointers (PCI RX SPTRs), each of which is a synchronized copy of a corresponding PCI RX PTR. Along with the PBSELm signals to select the appropriate TPI RX FIFO, the FIFO synchronization logic <b>818</b> also asserts a corresponding one of a plurality of PCI count signals (PCNTm) to synchronously update or increment the appropriate PCI RX PTR within the PCI RX FIFO control logic <b>817</b>. The FIFO synchronization logic <b>818</b> further asserts a corresponding one of a plurality of HSB count signals (HCNTm) to synchronously update or increment a corresponding PCI RX SPTR within the HSB RX FIFO control logic <b>821</b>. In this manner, a pointer is provided on both sides of each TPI RX FIFO to indicate where data is to be inserted.

PCI TX FIFO control logic <b>816</b> detects data in any of the TPI TX FIFOs and causes the TPI <b>220</b> to request and gain control of the PCI bus <b>222</b> for sending a command to a TLAN <b>226</b> corresponding to the TPI TX FIFO having data for transmission. The PCI TX FIFO control logic <b>816</b> accesses the address of the appropriate TLAN <b>226</b> from a set of TPI control registers <b>846</b>. The TPI <b>220</b> writes a command to the appropriate TLAN <b>226</b> and provides a TRANSMIT LIST MEMORY BASE ADDRESS to cause the TLAN <b>226</b> to subsequently request a transmit control list from the TPI <b>220</b> using the TRANSMIT LIST MEMORY BASE ADDRESS.

Transmit list decode logic <b>814</b> is coupled to the PCI bus interface logic <b>810</b> and stores at least one transmit control list in a transmit control list memory (TX CNTL LIST) <b>808</b><i>b</i>, which is part of the control list memory <b>808</b>. The transmit list decode logic <b>814</b> responds to the assertion of the TRANSMIT LIST MEMORY BASE ADDRESS asserted as an address on the PCI bus <b>222</b> by writing a transmit control list from the TX CNTL LIST <b>808</b><i>b </i>as data to the PCI bus <b>222</b>. In the embodiment shown, the TX CNTL LIST <b>808</b><i>b </i>holds one transmit control list at a time. In this manner, each TLAN <b>226</b> gains control of the PCI bus <b>222</b> and asserts the TRANSMIT LIST MEMORY BASE ADDRESS on the PCI bus <b>222</b> and receives a corresponding transmit control list from the TX CNTL LIST <b>808</b><i>b</i>. After retrieving the transmit control list, the TLAN <b>226</b> executes the transmit control list by requesting and gaining control of the PCI bus <b>222</b> to perform a read cycle to retrieve the data from the corresponding TPI TX FIFO of the TPI <b>220</b> using the PACKET DATA MEMORY BASE ADDRESS.

Transmit data decode logic <b>815</b>, the PCI TX FIFO control logic <b>816</b>, the PCI arbiter <b>811</b> and the FIFO synchronization logic <b>818</b> control the flow of data from each of the TPI TX FIFOs of the data buffers <b>807</b> onto the PCI bus <b>222</b>. The PCI TX FIFO control logic <b>816</b> includes an output to provide data to the PCI bus interface logic <b>810</b> and several selectable inputs, each coupled to an output of a corresponding one of the TPI TX FIFOs. When a TLAN <b>226</b> performs a read cycle on the PCI bus <b>22</b> to read data, the PCI arbiter <b>811</b> provides the TSELm signals to the FIFO synchronization logic <b>818</b>, which asserts the PBSELm signals to the PCI TX FIFO control logic <b>816</b> to select the corresponding TPI TX FIFO based on the particular TLAN <b>226</b> having control of the PCI bus <b>222</b>. The transmit data decode logic <b>815</b> receives and decodes the PACKET DATA MEMORY BASE ADDRESS asserted by the TLAN <b>226</b> and respondingly asserts an enable signal TEN to the PCI TX FIFO control logic <b>816</b> to enable transfer of data to the selected TPI TX FIFO. It is noted that the PBSELm signals are provided to both the PCI RX FIFO control logic <b>817</b> and the PCI TX FIFO control logic <b>816</b>, and that the TEN and REN signals select between the PCI RX FIFO control logic <b>817</b> and the PCI TX FIFO control logic <b>816</b> depending upon the type of cycle and direction of data flow.

Each TPI TX FIFO is implemented as a circular buffer in the embodiment shown. The PCI TX FIFO control logic <b>816</b> includes several PCI transmit pointers (PCI TX PTRs), one pointer each for each TPI TX FIFO to point to or address the next location where a DWORD of data is to be read from. In a similar manner, HSB TX FIFO control logic <b>822</b>, described further below, located on the other side of each TPI TX FIFO, includes several PCI transmit “synchronized” pointers (PCI TX SPTRs), each of which is a synchronized copy of a corresponding PCI TX PTR. The FIFO synchronization logic .<b>818</b> asserts a corresponding one of the PCNTm signals to increment the appropriate PCI TX PTR and a corresponding one of the HCNTm signals to increment the appropriate PCI TX SPTR each time a DWORD of data is provided to the PCI bus <b>222</b> from the PCI TX FIFO control logic <b>816</b>. In this manner, a pointer is provided on both sides of each TPI TX FIFO to indicate where data is to be read.

The HSB RX FIFO control logic <b>821</b> has several selectable inputs, each coupled to an output of a corresponding one of the TPI RX FIFOs. The HSB RX FIFO control logic <b>821</b> has an output for providing the data to the HSB data transfer interface logic <b>819</b> for assertion on the HSB <b>206</b>. The HSB TX FIFO control logic <b>822</b> has several selectable outputs, each coupled to an input of a corresponding one of the TPI TX FIFOs. The HSB TX FIFO control logic <b>822</b> has an input for receiving data from the HSB data transfer interface logic <b>819</b> from the HSB <b>206</b>.

The HSB RX FIFO control logic <b>821</b>, the port status logic <b>820</b> and the FIFO synchronization logic <b>818</b> control the flow of data between the TPI RX FIFOs of the data buffers <b>807</b><i>a-d </i>and the HSB <b>206</b> during data transfers from the TPI <b>220</b> to the EPSM <b>210</b>. The port status logic <b>820</b> detects assertion of the READ_OUT_PKT[<b>6</b>]* signal indicating a read cycle on the HSB <b>206</b>, and decodes the PORT_NO[<b>1</b>:<b>0</b>] signals to identify the corresponding TPI RX FIFO of the selected port. In particular, the EPSM <b>210</b> asserts PORT_NO[<b>1</b>:<b>0</b>] signals 00, 01, 10 or 11 to select the TPI RX FIFO of one of the data buffers <b>807</b><i>a</i>, <b>807</b><i>b</i>, <b>807</b><i>c </i>or <b>807</b><i>d</i>, respectively, for the port PORT24, PORT25, PORT26 or PORT27. The port status logic <b>820</b> asserts port select signals (PSELm) to the FIFO synchronization logic <b>818</b> to indicate the selected port, which respondingly asserts corresponding HSB select signals (HBSELm) to select one output of the HSB RX FIFO control logic <b>821</b> coupled to the corresponding TPI RX FIFO. Also, the port status logic <b>820</b> asserts an HSB enable signal (HREN) to enable the HSB RX FIFO control logic <b>821</b> to provide the data to the HSB data transfer interface logic <b>819</b> for assertion on the HSB <b>206</b>.

The HSB RX FIFO control logic <b>821</b> includes an HSB receive pointer (HSB RX PTR) for each TPI RX FIFO to locate the particular data within the TPI RX FIFO. The FIFO synchronization logic <b>818</b> asserts a corresponding one of the HCNTm signals to update or decrement the corresponding HSB RX PRT of the selected TPI RX FIFO for each DWORD read from the TPI RX FIFO. Also, the PCI RX FIFO control logic <b>817</b> includes a corresponding HSB receive “synchronized” pointer (HSB RX SPTR), which is decremented by the FIFO synchronization logic <b>818</b> by asserting a corresponding one of the PCNTm signals. In this manner, the HSB RX FIFO control logic <b>821</b> has two pointers for each TPI RX FIFO, including the PCI RX SPTR indicating where to write data, and the HSB RX PTR indicating where to read data. The port status logic <b>820</b> also accesses these pointers to derive the amount of valid data or number of valid data bytes in each TPI RX FIFO. This count is compared to a corresponding RBSIZE (corresponding to the TBUS value) for the HSB <b>206</b> for determining how to assert the PKT_AVAIL[<b>6</b>]* signals in response to the STROBE* signal.

The HSB TX FIFO control logic <b>822</b>, the port status logic <b>820</b> and the FIFO synchronization logic <b>818</b> control the flow of data between each TPI TX FIFO and the HSB <b>206</b> during data transfers from the EPSM <b>210</b> to the TPI <b>220</b>. The port status logic <b>820</b> detects assertion of the WRITE_IN_PKT[<b>6</b>]* signal and determines the port number from the PORT_NO[<b>1</b>:<b>0</b>] signals during a write cycle executed on the HSB <b>206</b> by the EPSM <b>210</b>. The port status logic <b>820</b> correspondingly asserts the PSELm signals and an HSB transmit enable signal (HTEN) to indicate the appropriate TPI TX FIFO. The FIFO synchronization logic <b>818</b> respondingly asserts the HBSELm signals to select the corresponding input of the HSB TX FIFO control logic <b>822</b> to the appropriate TPI TX FIFO. The HTEN signal enables the HSB TX FIFO control logic <b>822</b> to receive the data from the HSB data transfer interface logic <b>819</b> for assertion to the selected TPI TX FIFO.

The HSB TX FIFO control logic <b>822</b> includes an HSB transmit pointer (HSB TX PTR) for each TPI TX FIFO to locate the particular data location within the TPI TX FIFO to write data. The FIFO synchronization logic <b>818</b> asserts a corresponding one of the HCNTm signals to update or increment the corresponding HSB TX PRT of the selected TPI TX FIFO for each DWORD written to the selected TPI TX FIFO. Also, the PCI TX FIFO control logic <b>816</b> includes a corresponding HSB transmit “synchronized” pointer (HSB TX SPTR), which is incremented by the FIFO synchronization logic <b>818</b> by asserting a corresponding one of the PCNTm signals. In this manner, the HSB TX FIFO control logic <b>822</b> has two counters for each TPI TX FIFO, including the PCI TX SPTR indicating where to read data, and the HSB TX PTR indicating where to write data. The port status logic <b>820</b> also accesses these pointers for deriving the amount of available space or number of empty data bytes exists in each TPI TX FIFO. This count is compared to a corresponding XBSIZE (corresponding to the TBUS value) for the HSB <b>206</b> for determining how to assert the BUF_AVAIL[<b>6</b>]* signals in response to the STROBE* signal.

A set of TPI PCI configuration registers <b>835</b> is provided within the TPI <b>220</b> and coupled to the PCI bus interface logic <b>810</b> for access via the PCI bus <b>222</b>. Also, the TPI control registers <b>846</b> are provided and coupled to various devices within the TPI <b>220</b> and to the PCI bus interface logic <b>810</b> for access via the PCI bus <b>222</b>. The contents and structure of these registers <b>846</b> and <b>835</b> are described further below. The HSB data transfer interface logic <b>819</b> also includes a PACKET SIZE tag register <b>819</b><i>c</i>. The HSB data transfer interface logic <b>819</b> captures and stores the first DWORD of each data packet sent from the EPSM <b>210</b> in the PACKET SIZE tag register <b>819</b><i>c</i>, and then writes to contents of the PACKET SIZE register <b>819</b><i>c </i>to the TX CNTL LIST <b>808</b><i>b </i>of the transmit list decode logic <b>814</b>.

Referring now to FIG. 8C, a block diagram is shown illustrating the configuration and functionality of each of the TLANs <b>226</b>. The TLAN <b>226</b> includes an Ethernet port <b>110</b>, a PCI bus interface <b>824</b> and memory <b>825</b> coupled between the Ethernet port <b>110</b> and the PCI bus interface <b>824</b>. The Ethernet port <b>110</b> includes an appropriate receptacle to receive a compatible connector of a 100 Mb Ethernet segment <b>114</b> for receiving packet data from and for transmitting packet data to a corresponding network <b>112</b>. The Ethernet port <b>110</b> provides received packet data to data buffers <b>826</b> in the memory <b>825</b>. The Ethernet port <b>110</b> retrieves packet data from the data buffers <b>826</b> and transmits the packet data onto an Ethernet segment <b>114</b>.

The TLAN <b>226</b> includes a set of registers <b>828</b> within the memory <b>825</b> for controlling its operation. The registers <b>828</b> include a command register <b>828</b><i>a </i>for enabling an external device to insert commands through the PCI bus <b>222</b>. The registers <b>828</b> further include a channel parameter register <b>828</b><i>b </i>for storing an address to access a command list from an external memory through the PCI bus <b>222</b>. The command register <b>828</b><i>a </i>includes a GO bit (not shown) for instructing the TLAN <b>226</b> to retrieve and execute a command list. The command register <b>828</b><i>a </i>also includes an RX/TX bit (not shown) for instructing the TLAN <b>226</b> to retrieve and execute a receive command list (for the RX case) or a transmit command list (for the TX case). The memory <b>825</b> includes a list buffer <b>827</b> for storing current control lists, where the list buffer <b>827</b> further includes a receive control list buffer <b>827</b><i>a </i>for storing the current receive control list and a transmit control list buffer <b>827</b><i>b </i>for storing the current transmit control list.

The PCI bus interface <b>824</b> includes the appropriate logic to couple to the PCI bus <b>222</b> to control data transfers between the TPI <b>220</b> and the TLAN <b>226</b> by operating as a bus master of the PCI bus <b>222</b> during the data transfer. An external device, such as the TPI <b>220</b> or the CPU <b>230</b>, writes an address to the channel parameter register <b>828</b><i>b </i>and writes a command to the command register <b>828</b><i>a</i>. The TLAN <b>226</b> respondingly asserts its REQm signal to arbitrate for the PCI bus <b>222</b>. When its GNTm signal is received, the TLAN <b>226</b> executes a cycle on the PCI bus <b>222</b> to retrieve and store an indicated command list into the list buffer <b>827</b>. The command is considered a transmit command if the RX/TX bit is set for TX and a receive command if the RX/TX bit is set for RX.

To initiate receive operations, the CPU <b>230</b> writes the RECEIVE LIST MEMORY BASE ADDRESS to the channel parameter register <b>828</b><i>b </i>and a receive command to the command register <b>828</b><i>a </i>of each TLAN <b>226</b>. The TLAN <b>226</b> respondingly requests the PCI bus <b>222</b> to retrieve a receive control list using the RECEIVE LIST MEMORY BASE ADDRESS. The TPI <b>220</b> provides a receive control list to the TLAN <b>226</b>, and the TLAN <b>226</b> then waits to receive data before executing the receive control list. The receive control list includes a forward pointer as the next address for the TLAN <b>226</b> that it uses to retrieve the next receive control list to establish control list chaining. In the preferred embodiment, however, the TPI <b>220</b> loads the forward pointer of each receive control list with the same RECEIVE LIST MEMORY BASE ADDRESS. When data is received from the port <b>110</b> to the TPI <b>220</b>, the PCI bus interface <b>824</b> arbitrates and gains control of the PCI bus <b>222</b> and executes the receive control list in its receive control list buffer <b>827</b><i>a </i>to transfer data across the PCI bus <b>222</b> to the TPI <b>220</b>. Once the transfer of an entire data packet is completed, the TLAN <b>226</b> uses the RECEIVE LIST MEMORY BASE ADDRESS in the forward pointer of the current receive control list to request another receive control list.

For transmit operations, the TPI <b>220</b> detects data to transmit from any of its TPI TX FIFOs and respondingly arbitrates and gains control of the PCI bus <b>222</b>. The TPI <b>220</b> then writes the TRANSMIT LIST MEMORY BASE ADDRESS to the channel parameter register <b>828</b><i>b </i>and a transmit command to the command register <b>828</b><i>a </i>of each TLAN <b>226</b>. The TLAN <b>226</b> respondingly requests the PCI bus <b>222</b> to retrieve a transmit control list using the TRANSMIT LIST MEMORY BASE ADDRESS. Once the transmit control list is received, the TLAN <b>226</b> stores the transmit control list in its transmit control list buffer <b>827</b><i>b </i>and then executes the stored transmit control list to receive packet data. The transmit control list also includes a forward pointer, which is normally used as the next address for the TLAN <b>226</b> to use to retrieve the next transmit control list to establish control list chaining. In the embodiment shown, however, the TPI <b>220</b> loads the forward pointer of each transmit control list with a null value. Thus, after executing the transmit control list in its transmit control list buffer <b>827</b><i>b</i>, the TLAN <b>226</b> waits until the TPI <b>220</b> writes another transmit command.

Referring now to FIG. 8D, a diagram is shown illustrating a control list <b>830</b>, which is the format for both receive and transmit control lists and is also the format of the RX CNTL LIST <b>808</b><i>a </i>and the TX CNTL LIST <b>808</b><i>b</i>. The control list <b>830</b> includes a FORWARD_POINTER field <b>831</b>, a PACKET_SIZE field <b>832</b><i>a</i>, a CSTAT field <b>832</b><i>b</i>, a COUNT field <b>833</b> and a DATA_POINTER field <b>834</b>. Each field is 32 bits except for the PACKET_SIZE field <b>832</b><i>a </i>and the CSTAT field <b>832</b><i>b</i>, which are 16 bit fields.

The FORWARD_POINTER field <b>832</b> is generally used to chain control lists together. For receive operations, the TLAN <b>226</b> executes receive control lists provided by the TPI <b>220</b> from the RX CNTL LIST <b>808</b><i>a </i>over and over, since the FORWARD_POINTER field <b>831</b> is the same RECEIVE LIST MEMORY BASE ADDRESS in each case. In this manner, each TLAN <b>226</b> uses the RECEIVE LIST MEMORY BASE ADDRESS in the FORWARD_POINTER field <b>831</b> of its current receive control list to request the next receive control list when the next data packet is received from a network <b>112</b>. Thus, the TPI <b>220</b> does not have to issue start operation commands to the TLANs <b>226</b> for receive operations. For transmit operations, the TLAN <b>226</b> executes transmit control lists from the same TX CNTL LIST <b>808</b><i>b </i>each time. However, the TPI <b>220</b> sets the FORWARD_POINTER field <b>831</b> to a NULL value (0000h) so that the TPI <b>220</b> and a respective TLAN <b>226</b> perform one transmit operation when initiated by the TPI <b>220</b>. When data is detected within any of the TPI TX FIFOs and the TPI <b>220</b> is not currently performing any transmit operations on a TPI TX FIFO's respective TLAN port, then the TPI <b>220</b> issues a transmit command to a respective TLAN <b>226</b> to initiate a transmit operation. The respective TLAN <b>226</b> retrieves the transmit control list from the TX CNTL LIST <b>808</b><i>b</i>, executes the transmit control list, and then returns to a default state when encountering the NULL value in the FORWARD_POINTER field <b>831</b>.

The PACKET_SIZE field <b>832</b><i>a </i>generally indicates the size of a data packet. For receive operations, the TPI <b>220</b> initially sets the PACKET_SIZE field <b>832</b><i>a </i>in the RX CNTL LIST <b>808</b><i>a </i>to zero. After the TLAN <b>226</b> completes a transfer of a complete data packet to the TPI <b>220</b>, the TLAN <b>226</b> performs a final single DWORD write to the PACKET_SIZE field <b>832</b><i>a </i>and the CSTAT field <b>832</b><i>b </i>of the RX CNTL LIST <b>808</b><i>a</i>. The PACKET_SIZE field <b>832</b><i>a </i>is loaded with the actual packet data size, and a frame complete bit within the CSTAT field <b>832</b><i>b </i>is set. For transmit operations, the PACKET_SIZE field <b>832</b><i>a </i>of the TX CNTL LIST <b>808</b><i>b </i>is loaded with the size of a data packet to be transmitted by the TPI <b>220</b> to a TLAN <b>226</b>. The HSB data transfer interface logic <b>819</b> writes the packet size DWORD in the PACKET SIZE register tag <b>819</b><i>c </i>to the TX CNTL LIST <b>808</b><i>b </i>in the transmit list decode logic <b>814</b>. The TPI <b>220</b> then writes the transmit command to the corresponding TLAN <b>226</b> as previously described, and the contents of the TX CNTL LIST <b>808</b><i>b </i>is provided to a TLAN <b>226</b> as a transmit control list when requested.

The CSTAT field <b>832</b><i>b </i>is used to pass command and status information between the TPI <b>220</b> and the TLANs <b>226</b>. The TPI <b>220</b> initially sets the CSTAT field <b>832</b><i>b </i>of the RX CNTL LIST <b>808</b><i>a </i>to zero. When a packet data transfer from a TLAN <b>226</b> into a respective TPI RX FIFO has been completed, the TPI <b>220</b> sets the frame complete bit of the CSTAT field <b>832</b><i>b </i>(bit <b>14</b>) in the RX CNTL LIST <b>808</b><i>a </i>to represent that the packet data transfer has been completed. The TPI <b>220</b> indicates to the port status logic <b>820</b> that the data packet is complete to initiate a transfer over the HSB <b>206</b> to the EPSM <b>210</b>. The port status logic <b>820</b> then indicates that data is available in a respective TPI RX FIFO for transfer to the EPSM <b>210</b> in response to a poll by the EPSM <b>210</b>. This is true even if the amount of end of packet data does not meet the RBSIZE or TBUS value since the end of the packet must be transferred.

The TPI <b>220</b> sets the pass CRC (cyclic redundancy check) bit in the CSTAT field <b>832</b><i>b </i>of the TX CNTL LIST <b>808</b><i>b </i>based the state of the AI_FCS_IN* (or FBPN*) signal during receipt of a data packet from the EPSM <b>210</b>. The TPI <b>220</b> sets the CRC bit to indicate whether the data packet includes data used in a CRC. An Ethernet data packet including CRC contains four bytes of CRC data used for error checking in addition to the packet data.

The DATA_POINTER field <b>834</b> specifies the PCI address to be asserted by a TLAN <b>226</b> during a data transfer operation. The address is preferably the same for both transmit and receive operations, which is the PACKET DATA MEMORY BASE ADDRESS. During a data receive operation, a TLAN <b>226</b> asserts the PACKET DATA MEMORY BASE ADDRESS, and the receive data decode logic <b>813</b> decodes the address and a write cycle on the PCI bus <b>222</b> and enables the PCI RX FIFO control logic <b>817</b> to allow receipt of packet data into a selected TPI RX FIFO. During a data transmit operation, a TLAN <b>226</b> asserts the PACKET DATA MEMORY BASE ADDRESS, and the transmit data decode logic <b>815</b> decodes the address and a read operation and enables the PCI TX FIFO control logic <b>816</b> to facilitate the transfer of packet data packet from a selected TPI TX FIFO.

The COUNT field <b>833</b> specifies an amount of data present or the amount of buffer space available at the current value of the DATA_POINTER field <b>834</b>. During a receive data operation, the receive list decode logic <b>812</b> sets the COUNT field <b>833</b> to a value written into a RCV_DATA_COUNT register <b>847</b><i>b </i>(FIG. 8F) of the TPI control registers <b>846</b>. The value from the RCV_DATA_COUNT register <b>847</b><i>b </i>determines the largest packet size to be received by the TPI <b>220</b>. As a default, this value is 1518 bytes, which is the largest Ethernet data packet size with four bytes of CRC. During a transmit data operation, the TPI <b>220</b> sets the COUNT field <b>833</b> to the same value as the PACKET_SIZE field <b>832</b><i>a. </i>

Referring now to FIG. 8E, a diagram is shown illustrating a definition of the TPI PCI configuration registers <b>835</b> employed by the TPI <b>220</b>. The TPI PCI configuration registers <b>835</b> include registers common to all PCI bus architectures as well as additional registers unique to the TPI <b>220</b>. Registers common to all PCI buses include a DEVICE_ID register <b>836</b><i>a</i>, a VENDOR_ID register <b>836</b><i>b</i>, a STATUS register <b>837</b><i>a</i>, a COMMAND register <b>837</b><i>b</i>, a CLASS_CODE register <b>838</b><i>a</i>, a REV_ID register <b>838</b><i>b</i>, a BIST register <b>839</b><i>a</i>, a HDR_TYPE register <b>839</b><i>b</i>, a LATENCY register <b>839</b><i>c</i>, a CACHELSZ register <b>839</b><i>d</i>, a MAXLAT register <b>845</b><i>a</i>, a MINGNT register <b>845</b><i>b</i>, an INTPIN register <b>845</b><i>c </i>and an INTLINE register <b>845</b><i>d</i>. Registers unique to the TPI <b>220</b> include a TPI CONTROL IO BASE ADDRESS register <b>840</b>, a TPI CONTROL MEMORY BASE ADDRESS register <b>841</b>, a TRANSMIT LIST MEMORY BASE ADDRESS register <b>842</b>, a RECEIVE LIST MEMORY BASE ADDRESS register <b>843</b>, and a PACKET DATA MEMORY BASE ADDRESS register <b>844</b>.

After being initialized, the TPI CONTROL IO BASE ADDRESS register <b>840</b> contains a TPI CONTROL IO BASE ADDRESS for the TPI control registers <b>846</b>. The TPI CONTROL MEMORY BASE ADDRESS register <b>841</b> contains a TPI CONTROL MEMORY BASE ADDRESS for the TPI control registers <b>846</b>. In this manner, the TPI control registers <b>846</b> are accessible in both I/O and memory space of the PCI bus <b>222</b>. The TRANSMIT LIST MEMORY BASE ADDRESS register <b>842</b> contains the TRANSMIT LIST MEMORY BASE ADDRESS for the TX CNTL LIST <b>808</b><i>b </i>that is decoded by the transmit list decode logic <b>814</b>. The RECEIVE LIST MEMORY BASE ADDRESS <b>843</b> contains the RECEIVE LIST MEMORY BASE ADDRESS for the RX CNTL LIST <b>808</b><i>a </i>that is decoded by the receive list decode logic <b>812</b>. The PACKET DATA MEMORY BASE ADDRESS register <b>844</b> contains the PACKET DATA MEMORY BASE ADDRESS corresponding to the data buffers <b>807</b> of the TPI <b>220</b>. The PACKET DATA MEMORY BASE ADDRESS is decoded by both the transmit data decode logic <b>815</b> and the receive data decode logic <b>813</b>.

Referring now to FIG. 8F, a diagram is shown illustrating the definition of the TPI control registers <b>846</b> employed by the TPI <b>220</b>. The TPI control registers <b>846</b> include a RCV_DATA_COUNT register <b>847</b><i>b</i>, an XBSIZE3 register <b>848</b><i>a</i>, an XBSIZE2 register <b>848</b><i>b</i>, an XBSIZE1 register <b>848</b><i>c</i>, an XBSIZE0 register <b>848</b><i>c</i>, an RBSIZE3 register <b>849</b><i>a</i>, an RBSIZE2 register <b>849</b><i>b</i>, an RBSIZE1 register <b>849</b><i>c</i>, an RBSIZE0 register <b>849</b><i>d</i>, a NET_PRI3 register <b>850</b><i>a</i>, a NET_PRI2 register <b>850</b><i>b</i>, a NET_PRI1 register <b>850</b><i>c</i>, a NET_PRI0 register <b>850</b><i>d</i>, a TLAN0 MEMORY BASE ADDRESS register <b>851</b>, a TLAN1 MEMORY BASE ADDRESS register <b>852</b>, a TLAN2 MEMORY BASE ADDRESS register <b>853</b> and a TLAN3 MEMORY BASE ADDRESS register <b>854</b>.

The RCV_DATA_COUNT register <b>847</b><i>b </i>stores the maximum size of received data packets handled by the TPI <b>220</b>. The TPI <b>220</b> retrieves and places this value into the COUNT field <b>833</b> of RX CNTL LIST <b>808</b><i>a</i>. Each of the XBSIZE registers <b>848</b><i>a-d </i>hold a transmit burst size in DWORDs for respective ports, namely, XBSIZE0 for PORT24, XBSIZE1 for PORT25, XBSIZE2 for PORT26 and XBSIZE3 for PORT27. The XBSIZE transmit burst size values are used by the HSB TX FIFO control logic <b>822</b> and the port status logic <b>820</b> of the TPI <b>220</b> when determining whether there is enough packet buffer space in a respective TPI TX FIFO to request data from the EPSM <b>210</b> for the respective port. Each of the RBSIZE registers <b>849</b><i>a-d </i>hold respective HSB receive burst sizes in DWORDs for the respective ports, namely, RBSIZE0 for PORT24, RBSIZE1 for PORT25, RBSIZE2 for PORT26 and RBSIZE3 for PORT27. The RBSIZE receive burst size values are used by the HSB RX FIFO control logic <b>821</b> and the port status logic <b>820</b> when determining whether there is enough packet data in a respective TPI RX FIFO to request a transfer of received data to the EPSM <b>210</b> from the respective port. In the embodiment illustrated, values stored in the XBSIZE and RBSIZE registers <b>848</b>, <b>849</b> are equal to each other and to the TBUS value. However, the XBSIZE registers <b>848</b> and the RBSIZE registers <b>849</b> are programmed with any desired burst transfer values depending on the embodiment.

The NET_PRI registers <b>850</b> hold respective network priority values for the ports, namely, NET_PRI0 for PORT24, NET_PRI1 for PORT25, NET_PRI2 for PORT26 and NET_PRI3 for PORT27. These values are used by the transmit list decode logic <b>814</b> to set the transmit priority of respective ports. The TLAN0 MEMORY BASE ADDRESS register <b>851</b> holds a PCI memory address referred to as TLAN0 MEMORY BASE ADDRESS for PORT24. The TLAN1 MEMORY BASE ADDRESS register <b>852</b> holds a PCI memory address referred to as TLAN1 MEMORY BASE ADDRESS for PORT25. The TLAN2 MEMORY BASE ADDRESS register <b>853</b> holds a PCI memory address referred to as TLAN2 MEMORY BASE ADDRESS for PORT26. The TLAN3 MEMORY BASE ADDRESS register <b>854</b> holds a PCI memory address referred to as TLAN3 MEMORY BASE ADDRESS for PORT24. Each of these registers is initialized at startup by the CPU <b>230</b> after determining the addresses of each of the TLANs <b>226</b>. These values are provided to and used by the PCI TX FIFO control logic <b>816</b> to issue each transmit command on the PCI bus <b>222</b> to start transmit packet operations.

Referring now to FIG. 8G, a flowchart diagram is shown illustrating PCI initialization operations of the CPU <b>230</b> at initialization, startup or reset of the network switch <b>102</b>. At first step <b>855</b>, the CPU <b>230</b> configures the PCI bus <b>222</b>, maps the TLANs <b>226</b> into PCI memory space and writes this configuration into the TPI PCI configuration registers <b>835</b> via the PCI bus <b>222</b>. Steps for configuring the PCI bus <b>222</b> are known and will not be further described.

In particular, the DEVICE_ID register <b>836</b><i>a </i>is the standard PCI device ID register and its value is set to 0x5000h. The VENDOR_ID register <b>836</b><i>b </i>is the standard PCI vendor ID register and its value is set to 0x0E11h. The STATUS register <b>837</b><i>a </i>is the standard PCI device status register. The COMMAND register <b>837</b><i>b </i>is the standard PCI device command register. The CLASS_CODE register <b>838</b><i>a </i>is the standard PCI device class code register and its value is set to 0x060200h. The REV_ID register <b>838</b><i>b </i>is the standard PCI device revision ID register and its value is set to 0x00h. The BIST register <b>839</b><i>a </i>is the standard PCI BIST status register and its value is set to 0x00h. The HDR_TYPE register <b>839</b><i>b </i>is the standard PCI header type register and its value is set to 0x80h. The LATENCY register <b>839</b><i>c </i>is the standard PCI latency type register and it is initialized by the CPU <b>230</b>. The CACHELSZ register <b>839</b><i>d </i>is the standard PCI cache line size register and it is initialized by the CPU <b>230</b>. The MAXLAT register <b>845</b><i>a </i>is the standard PCI device maximum latency register and its value is set to 0x00h. The MINGNT register <b>845</b><i>b </i>is the standard PCI device minimum grant register and its value is set to 0x00h. The INTPIN register <b>845</b><i>c </i>is the standard PCI device interrupt pin register and its value is set to 0x00h. The INTLINE register <b>845</b><i>d </i>is the standard PCI device interrupt line register and it is setup by the CPU <b>230</b>.

Also at step <b>855</b>, the CPU <b>230</b> writes a value of 0xFFFFFFFFh into each of the following registers: the TPI CONTROL IO BASE ADDRESS register <b>840</b>; the TPI CONTROL MEMORY BASE ADDRESS register <b>841</b>; the TRANSMIT LIST MEMORY BASE ADDRESS register <b>842</b>; the RECEIVE LIST MEMORY BASE ADDRESS register <b>843</b>; and the PACKET DATA MEMORY BASE ADDRESS register <b>844</b>. After each write, the TPI <b>220</b> replaces the value in each register with a value indicating the amount of I/O or memory space required by the particular register indicated. The CPU <b>230</b> respondingly reads each new value in each register and then writes back a base address into each register to map the entity into PCI I/O or memory space.

In particular, after determining the amount of space required, the CPU <b>230</b> writes the TPI CONTROL IO BASE ADDRESS to the TPI CONTROL IO BASE ADDRESS register <b>840</b> to enable I/O space access of the TPI control registers <b>846</b>, the CPU <b>230</b> writes the TPI CONTROL MEMORY BASE ADDRESS to the TPI CONTROL MEMORY BASE ADDRESS register <b>841</b> to enable memory space access of the TPI control registers <b>846</b>, the CPU <b>230</b> writes the TRANSMIT LIST MEMORY BASE ADDRESS into the TRANSMIT LIST MEMORY BASE ADDRESS register <b>842</b> corresponding to the address of the TX CNTL LIST <b>808</b><i>b </i>memory block, the CPU <b>230</b> writes the RECEIVE LIST MEMORY BASE ADDRESS into the RECEIVE LIST MEMORY BASE ADDRESS register <b>843</b> corresponding to the address of the RX CNTL LIST <b>808</b><i>a</i>, and the CPU <b>230</b> writes the PACKET DATA MEMORY BASE ADDRESS into the PACKET DATA MEMORY BASE ADDRESS register <b>844</b> to correspond to the PCI address of the data buffers <b>807</b>.

At next step <b>856</b><i>a</i>, the CPU <b>230</b> queries each TLAN <b>226</b>, one by one, on the PCI bus <b>222</b> to determine the number of TLANs present and their corresponding PCI addresses. At next step <b>856</b><i>b</i>, the CPU <b>230</b> initializes the queried TLAN <b>226</b> to a known, quiescent state. The CPU <b>230</b> then determines whether there are any more TLANS <b>226</b> at next step <b>857</b>, and if so, returns to step <b>856</b><i>a </i>to query the next TLAN until all of the TLANs <b>226</b> on the PCI bus <b>222</b> are initialized. At this time, the TLAN0 MEMORY BASE ADDRESS, the TLAN1 MEMORY BASE ADDRESS, the TLAN2 MEMORY BASE ADDRESS and the TLAN3 MEMORY BASE ADDRESS values are known.

At next step <b>858</b>, the CPU <b>230</b> initializes the TPI control registers <b>846</b> to the appropriate values, as described above with reference to FIG. <b>8</b>F. This includes the TLAN0 MEMORY BASE ADDRESS, the TLAN1 MEMORY BASE ADDRESS, the TLAN2 MEMORY BASE ADDRESS and the TLAN3 MEMORY BASE ADDRESS values. At next step <b>859</b>, the CPU <b>230</b> begins initiation of the receive operation for each TLAN <b>226</b> by writing the RECEIVE LIST MEMORY BASE ADDRESS into the channel parameter register <b>828</b><i>b</i>. The initiation of the receive operation is completed at step <b>860</b>, where the CPU <b>230</b> writes to the command register <b>828</b><i>a </i>of each TLAN <b>226</b>. Initialized in this fashion, each TLAN <b>226</b> immediately begins a receive operation by requesting the PCI bus <b>222</b> to request a receive control list.

Referring now to FIG. 8H, a flowchart diagram is shown illustrating the receive operation of the network switch <b>102</b> for each of the TLANs <b>226</b>. Operation commences at first step <b>861</b><i>a</i>, where a TLAN <b>226</b> requests and receives control of the PCI bus <b>222</b> from the PCI arbiter <b>811</b>. The TLAN <b>226</b> asserts the RECEIVE LIST MEMORY BASE ADDRESS onto the PCI bus <b>222</b> at next step <b>861</b><i>b </i>to request a receive control list, and the TPI <b>220</b> provides a receive control list to the TLAN <b>226</b> at next step <b>861</b><i>c</i>. The receive control list includes the PACKET DATA MEMORY BASE ADDRESS to inform the TLAN <b>226</b> where, or how, to send a received data packet. At next step <b>861</b><i>d</i>, the TLAN <b>226</b> releases control of the PCI bus <b>222</b>.

A TLAN <b>226</b> eventually receives a data packet from a network <b>112</b> as indicated at next step <b>862</b><i>a</i>, and then requests and receives control of the PCI bus <b>222</b> at next step <b>862</b><i>b</i>. The TLAN <b>226</b> then writes a burst of data using the PACKET DATA MEMORY BASE ADDRESS as the address on the PCI bus <b>222</b> at next step <b>862</b><i>c</i>, while the TPI <b>220</b> writes the data into a selected TPI RX FIFO as indicated at next step <b>862</b><i>d</i>. Upon completion of the write burst, the TLAN releases the PCI bus <b>222</b> at next step <b>862</b><i>e</i>. At next step <b>865</b>, the TLAN <b>226</b> determines whether the entire data packet has been sent to the TPI <b>220</b>, which is indicated by a final DWORD write operation. If not, operation returns to step <b>862</b><i>b</i>, where the TLAN <b>226</b> once again requests the PCI bus <b>222</b> to send another burst of data.

After the TLAN <b>226</b> has sent the final portion of the data packet, it performs a final iteration to inform the TPI <b>220</b> of the end of the packet. In particular, the TLAN <b>226</b> executes a final single DWORD transfer to the PACKET_SIZE field <b>832</b><i>a </i>and the CSTAT field <b>832</b><i>b </i>within the RX CNTL LIST <b>808</b><i>a </i>of the TPI <b>220</b>. This DWORD transfer updates the RX CNTL LIST <b>808</b><i>a </i>with the packet size of the data packet just completed and updates the frame complete bit in the CSTAT field <b>832</b><i>b</i>. The TPI <b>220</b> detects this write operation as indicated at step <b>865</b>, and sets internal flags to represent that the operation is complete and passes the appropriate status to the port status logic <b>820</b> as indicated at step <b>866</b>. Operation returns to step <b>861</b><i>a </i>to request another receive control list.

Referring now to FIG. 8I, a flowchart diagram is shown illustrating a receive data transfer operation from the TPI <b>220</b> to the EPSM <b>210</b> across the HSB <b>206</b>. Operation commences at a first step <b>876</b>, where the port status logic <b>820</b> of the TPI <b>220</b> detects an amount of data in any one of the TPI RX FIFOs that equals or exceeds the respective RBSIZE as provided in the TPI control registers <b>846</b>, or the EOP for that port has been indicated by a TLAN <b>226</b>.

As indicated at next step <b>877</b>, the TPI <b>220</b> responds to EPSM <b>210</b> polls by properly asserting the PKT_AVAIL[<b>6</b>]* signals in multiplexed fashion, which indicate whether enough data is available in each of the TPI RX FIFOs. The polling occurs independently and is included for clarification. If the PKT_AVAIL[<b>6</b>]* signal indicates that enough data is in any TPI RX FIFO of the TPI <b>220</b>, the EPSM <b>210</b> eventually initiates a read cycle on the HSB <b>206</b> to the specified port at next step <b>878</b> if it has enough buffer space in an available receive buffer of the EPSM <b>210</b>.

The port status logic <b>820</b> of the TPI <b>220</b> detects the read cycle on the HSB <b>206</b>, selects the appropriate TPI RX FIFO to provide data at next step <b>879</b>. Then the TPI <b>220</b> transmits the data burst to the EPSM <b>210</b> over the HSB <b>206</b> at step <b>880</b>. During the data transfer of step <b>880</b>, if the port status logic <b>820</b> determines that the current data transfer across the HSB <b>206</b> is the start of packet as indicated at next step <b>881</b><i>a</i>, the TPI <b>220</b> asserts the SOP* signal on the HSB <b>206</b> at step <b>881</b><i>b </i>during the data transfer. Likewise, during the data transfer at step <b>880</b>, if the port status logic <b>820</b> determines that the current data transfer across the HSB <b>206</b> is an end of packet as indicated at next step <b>882</b><i>a</i>, the TPI <b>220</b> asserts the EOP* signal on the HSB <b>206</b> as indicated by step <b>881</b><i>b </i>during the data transfer. From step <b>882</b><i>a </i>or <b>882</b><i>b</i>, operation returns to step <b>876</b>.

Referring now to FIG. 8J, a flowchart diagram is shown illustrating a transmit data transfer operation for transferring packet data from the EPSM <b>210</b> to the TPI <b>220</b> across the HSB <b>206</b>. Operation commences at first step <b>890</b>, where the port status logic <b>820</b> of the TPI <b>220</b> detects that any one of the TPI TX FIFOs has an amount of available buffer space equaling or exceeding the corresponding XBSIZE. If so, operation proceeds to next step <b>891</b>, where the port status logic <b>820</b> responds to an EPSM <b>210</b> poll by properly asserting the BUF_AVAIL[<b>6</b>]* signal in multiplexed fashion to indicate available buffer space in the corresponding TPI TX FIFO. As described above, the polling occurs independently and is included for clarification. At next step <b>892</b>, the EPSM <b>210</b> initiates a write cycle on the HSB <b>206</b> to a port corresponding to the TPI TX FIFO having enough space when enough data is available for transmission by the EPSM <b>210</b> for that port. At next step <b>893</b>, the port status logic <b>820</b> of the TPI <b>220</b> detects the write cycle on the HSB <b>206</b> and selects the appropriate TPI TX FIFO for the indicated port. At next step <b>894</b>, the EPSM <b>210</b> transmits a burst of data to the TPI <b>220</b> over the HSB <b>206</b> and the TPI <b>220</b> writes the data to the corresponding TPI TX FIFO within the TPI <b>220</b>.

As indicated at step <b>895</b><i>a</i>, if the TPI <b>220</b> detects assertion of the SOP* signal during the data burst of step <b>894</b>, the first DWORD of the data holding the packet size is placed into the PACKET SIZE tag register <b>819</b><i>c </i>at step <b>895</b><i>b</i>. As indicated at step <b>896</b><i>a</i>, if the TPI <b>220</b> detects assertion of the EOP* signal during the data burst of step <b>894</b>, the TPI <b>220</b> sets a flag within the TPI <b>220</b> at step <b>896</b><i>b </i>to indicate the end of the data packet. From either step <b>896</b><i>a </i>or <b>896</b><i>b</i>, operation returns to step <b>890</b>.

Referring now to FIG. 8K, a flowchart diagram is shown illustrating a transmit operation of the network switch <b>102</b> for each of the TLANs <b>226</b>. At first step <b>867</b>, the TPI <b>220</b> detects data in any one of the TPI TX FIFOs, and respondingly requests and receives control of the PCI bus <b>222</b> from the PCI arbiter <b>811</b>. At next step <b>868</b>, the TPI <b>220</b> writes a transmit command to the command register <b>828</b><i>a </i>of the corresponding TLAN <b>226</b>. The TPI <b>220</b> then releases the PCI bus <b>222</b> at next step <b>869</b>.

At next step <b>870</b><i>a</i>, the TLAN <b>226</b> receiving the transmit command requests and receives control of the PCI bus <b>222</b> from the PCI arbiter <b>811</b>, and then requests a transmit control list from the TPI <b>220</b>. At next step <b>870</b><i>b</i>, the TPI <b>220</b> provides the transmit control list to the TLAN <b>226</b> in control of the PCI bus <b>222</b>, where the TLAN <b>226</b> provides the transmit control list to its transmit control list buffer <b>827</b><i>b</i>. At next step <b>870</b><i>c</i>, the TLAN <b>226</b> releases the PCI bus <b>222</b>, but immediately re-requests the PCI bus <b>222</b> as indicated at step <b>870</b><i>d</i>. Once the TLAN <b>226</b> again receives control of the PCI bus <b>222</b>, it commences execution of the transmit control list as indicated at step <b>871</b><i>a </i>by requesting a burst of data from the TPI <b>220</b>. In particular, the TLAN <b>226</b> asserts the PACKET DATA MEMORY BASE ADDRESS on the PCI bus <b>222</b> at step <b>871</b><i>a</i>. At next step <b>871</b><i>b</i>, the TPI <b>220</b> responds by selecting and enabling the corresponding TPI TX FIFO and provides the data to the TLAN <b>226</b> across the PCI bus <b>222</b>. After each data burst, the TLAN <b>226</b> releases control the of the PCI bus <b>222</b> as indicated at next step <b>871</b><i>c</i>. If transfer of a complete packet of data has not been completed as indicated at next step <b>872</b>, operation returns to step <b>870</b><i>d</i>, where the TLAN <b>226</b> again requests and eventually regains control of the PCI bus <b>222</b>.

If transmission of the packet was completed as determined at step <b>872</b><i>a</i>, operation passes to step <b>873</b><i>a</i>, where the TLAN <b>226</b> writes that the data transfer is complete to the TPI <b>220</b> and the TPI <b>220</b> correspondingly flags that the operation is complete. In particular, the TLAN <b>226</b> performs a final single DWORD write to the CSTAT field <b>832</b><i>b </i>of the TX CNTL LIST <b>808</b><i>b </i>to set a frame complete bit within the CSTAT field <b>832</b>. Also, the PACKET_SIZE field <b>832</b><i>a </i>of the TX CNTL LIST <b>808</b><i>b </i>is loaded with the size of a data packet to be transmitted by the TPI <b>220</b> to a TLAN <b>226</b>. Once the TLAN <b>226</b> has completed the write operation, it releases the PCI bus <b>222</b> at step <b>873</b><i>b</i>. From step <b>873</b><i>b </i>operation returns to step <b>867</b> for the next transmit operation.

It is now appreciated that after initialization by the CPU <b>230</b>, the TPI <b>220</b> is configured to cooperate with the TLANs <b>226</b> to allow the CPU <b>230</b> to perform other important tasks and functions of the network switch <b>102</b>. The CPU <b>230</b> initializes PCI memory and I/O space by determining the type and number of devices on the PCI bus <b>222</b> and assigning corresponding address values. The CPU <b>230</b> provides address values of the TLANs <b>226</b> to the TPI <b>220</b>. Also, the CPU <b>230</b> provides initial address values of the TPI <b>220</b> to each of the TLANs <b>226</b> and inserts a command to initiate operations. The TLANs <b>226</b> are configured to request a control list and then to execute the control list to read data from or write data to a memory located at an address within the control list. The TPI <b>220</b> is configured to update and provide each control list to each requesting TLAN <b>226</b>. Further, the TPI <b>220</b> is configured to initiate transmit operations by writing a command to the appropriate TLAN <b>226</b>, and then provide the corresponding transmit control list when subsequently requested. In this manner, after the CPU <b>230</b> performs initialization, it is free to perform other functions of the network switch <b>102</b>.

FIG. 9A is a block diagram illustrating the organization of the memory <b>212</b>. In the embodiment shown, the size of the memory <b>212</b> is between 4 to 16 megabytes (Mbytes), although the memory size may vary and may be as small or large as desired. The width of the memory section blocks shown in FIGS. 9A-9G, and thus the width of each memory line, is one DWORD or 32 bits. The memory <b>212</b> is divided into two main sections including a hash memory section <b>902</b> and a packet memory section <b>904</b>. The hash memory section <b>902</b> serves as a network device identification section for identifying one or more of the network devices in the networks <b>106</b>, <b>112</b> coupled to the network switch <b>102</b>. The size of the hash memory section <b>902</b> is programmable based on the number of devices and associated addresses and entries desired. In the embodiment shown, the hash memory section <b>902</b> includes 256 kilobytes (Kbytes) of memory for supporting at least 8K (K=2¹⁰=1,024) addresses up to 16K addresses. The hash memory section <b>902</b> may be located anywhere in the memory <b>212</b>, and is located at the beginning of the memory <b>212</b> in the embodiment shown. The size of the packet memory section <b>904</b> is the balance of the remaining memory <b>212</b> not used by the hash memory section <b>902</b>.

FIG. 9B is a block diagram of the organization of the hash memory section <b>902</b> of the memory <b>212</b>. The hash memory section <b>902</b> is shown to be 256 Kbytes in length, where it is understood that the hash memory section size is either fixed or programmable as desired. The hash memory section <b>902</b> is divided into two 128 Kbyte sections including a first 128 Kbyte primary hash entry section <b>906</b> for primary hash entries and a second 128 Kbyte chained hash entry section <b>908</b> for chained hash entries. Each of the sections <b>906</b>, <b>908</b> includes 8K entries, each 16 bytes in length.

FIG. 9C is a diagram illustrating the organization of a hash table entry <b>910</b> representative of each of the entries in the hash memory section <b>902</b>, including both the primary hash entry section <b>906</b> and the chained hash entry section <b>908</b>. Each entry <b>910</b> corresponds to one network device of the networks <b>106</b>, <b>112</b> coupled to the network switch <b>102</b>. Each of the primary entries are located at a hash address, which address is determined by “hashing” the MAC address for that device. In particular, each network device is assigned a 48-bit hardware address, also known as a physical address or a MAC address, which is a unique numerical value assigned to each network device during the manufacturing process or by setting jumpers or switches during network installation. One part of this MAC address is assigned to the manufacturer by the IEEE (Institute of Electrical and Electronics Engineers) and is common to all components from that manufacturer; the second part of the hardware address is a unique value assigned by the hardware manufacturer. The first 6 bytes, or bytes 5-0, of the hash table entry <b>910</b> contains the MAC address of the device associated with that entry. The network switch <b>102</b>, therefore, adds a hash table entry for each network device that sends a data packet including its source MAC address.

Each data packet sent from each network device in the networks <b>106</b>, <b>112</b> typically includes a source and a destination MAC address, which are both hashed according to one of several algorithms. In the embodiment shown, two portions of each MAC address are logically combined or compared to calculate a corresponding hash address. Each portion is 13 bits to 16 bits, which are combined using exclusive-OR (XOR) logic in a bit-wise fashion to form a 13 to 16 bit hash address. For example, the first 16 bits of a MAC address, or MA[<b>15</b>:<b>0</b>] are XOR'd in bitwise fashion with the next 16 bits of the MAC address MA[<b>31</b>:<b>16</b>] to obtain the hash address HA[<b>15</b>:<b>0</b>]. In one embodiment, the first 13, 14, 15 or 16 bits of the hashed result are used as the hash address HA. Alternatively, the first 13 bits of the MAC address MA[<b>12</b>:<b>0</b>] is hashed with the next 13 bits MA[<b>25</b>:<b>13</b>] to obtain a 13-bit hash address HA[<b>12</b>:<b>0</b>]. Or, the first 14 bits of the MAC address MA[<b>13</b>:<b>0</b>] is hashed with the next 14 bits MA[<b>27</b>:<b>14</b>] to obtain a 14-bit hash address HA[<b>13</b>:<b>0</b>], and so on. It is understood that many other different hashing algorithms are known and may be used to combine any particular combinations of the address bits as known to those skilled in the art, and that the present invention is not limited to any particular hashing scheme.

The hash address is used as the actual address or as an offset address to locate each of the hash entries of the primary hash entry section <b>906</b>. Although the MAC addresses are unique, the hash address may not be unique such that two different MAC addresses hash to the same hash address. The chained hash entry section <b>908</b> is provided to store duplicate hash addresses for different devices, as described further below. The organization including a primary hash entry section <b>906</b> accessible by the hash address and a chained hash entry section <b>908</b> accessible by a Link address located in the first entry of the primary section <b>906</b> eliminates at least one branch operation. Rather than using a list of pointers to access the table entries, the first entry in the memory <b>212</b> is retrieved in a single branch operation, the second entry in a second branch operation, etc. In this manner, the organization of the memory <b>212</b> provides more efficient access of the hash entries by eliminating at least one branch operation per access.

The next byte (6) of the hash table entry <b>910</b> contains a binary port number (PortNum) identifying the associated port number to which the device is connected, where the port number for PORT0 is zero, the port number for PORT1 is one, the port number for PORT28 (for the CPU <b>230</b>) is <b>28</b>, etc. The next byte (7) is a control and age information byte (Control/Age) including a valid bit (VALIDENTRY) identifying whether the entry is valid or not, where a logic “1” indicates the entry is valid and logic “0” indicates that the entry is not valid, otherwise called an empty entry. The Control/Age byte includes a binary age number (AGE) representing the elapsed time from the last source access associated with this device. A device may be aged and deleted from the hash entry by the CPU <b>230</b> after a predetermined amount of time of non-use since the last source access. The measurement of elapsed time is performed using any one of several methods, and may be measured in seconds or portions thereof, minutes, hours, etc. The predetermined amount of time before a device is aged is also programmable. In an alternative embodiment, the AGE number is a single bit which is used to indicate whether the device is considered “old” or not, which is set by an elapsed timer or the like.

The next four bytes (B:<b>8</b>) define a 29-bit virtual-LAN (VLAN) bitmap value representing port groupings, if used. Each bit of the VLAN value corresponds to a respective one of the ports and is set if the device or port is grouped with that port. Thus, the VLAN value identifies which of the other ports that the device is grouped with. This enables the networks <b>106</b>, <b>112</b> to be grouped in any desired combination to form a plurality of different LANs coupled to the network switch <b>102</b>. For example, if the first five ports port PORT0-PORT4 are grouped together, then the VLAN value for each is 0000001Fh, where “h” denotes a hexadecimal value. A BC packet sent from a device coupled to port PORT2 is repeated to the ports PORT0, PORT1, PORT3 and PORT4 rather than being repeated to all other ports of the network switch <b>102</b>. A VLAN value of all ones or 1FFFFFFFh denotes no groupings for that device. It is noted that it is possible for one device to be associated with more than one group. In an alternative embodiment, a VLAN field may be included for identifying more than one of several VLAN groups that each device belongs to, if any.

The last four bytes (F:C) of each hash table entry <b>910</b> is a link address (Link A[<b>31</b>:<b>0</b>] or Link Address) pointing to the next entry having an identical hash address, if any, in the chained hash entry section <b>908</b>. The next entry is stored in the next available location in the chained hash entry section <b>908</b>. In this manner, if two MAC addresses of two different devices hash to the same hash address, the first or “primary” entry is stored in the primary hash entry section <b>906</b>, and the second entry is stored in the chained hash entry section <b>908</b>, and the Link Address of the primary entry points to the second entry. If another MAC address hashes to the same hash address as the first two, then each additional entry is stored in the chained hash entry section <b>908</b> and linked together in consecutive order using the Link Addresses. Thus, the first points to the second, the second points to the third, and so on. Each entry follows the format of the hash table entry <b>910</b>. The format of the Link address may be defined in any convenient manner. The Link address typically includes a base address portion pointing to the hash memory section <b>902</b> within the memory <b>212</b>, and an offset portion to the actual entry within the hash memory section <b>902</b>. The lower address bits may be set to zero for byte alignment as desired. The last entry in each chain is identified by setting a portion of the Link address to zero. For example, the last entry may be denoted by setting the Link Address bits [A<b>31</b>:<b>28</b>] to zero.

FIG. 9D is a block diagram illustrating the organization of the packet memory section <b>904</b> of the memory <b>212</b>. In the embodiment shown, the packet memory section <b>904</b> is organized as a plurality of contiguous and equal-sized sectors <b>912</b>, where each sector <b>912</b> includes a sector information section, called a sector prefix <b>914</b>, and a packet section <b>916</b> including one or more packet data blocks. Each of the sectors <b>912</b> is preferably 2 Kbytes in size thereby corresponding to the page size of the memory devices implementing the memory <b>212</b> to simplify design and overhead. In the embodiment shown, FPM DRAM SIMMs are organized using 4 Kbyte page boundaries, and synchronous DRAM SIMMs are organized into 2 Kbyte page boundaries. Thus, a 2 Kbyte sector size is sufficient for the memory device types supported. The sectors <b>912</b> are initially empty but chained together with Link Addresses to form the FREEPOOL CHAIN of free memory sectors.

As new packets of information are received from each of the ports <b>104</b>, <b>110</b>, one or more sectors <b>912</b> are disconnected from the FREEPOOL CHAIN and linked together in a RECEIVE SECTOR CHAIN per port. Also, each packet is linked with other packets in the same or other RECEIVE SECTOR CHAINs to form a separate TRANSMIT PACKET CHAIN per port. In this manner, a packet in a RECEIVE SECTOR CHAIN for one port is also placed into a TRANSMIT PACKET CHAIN for another port. When all of the data in the packet section <b>916</b> of a sector <b>912</b> is transmitted to a destination port, that sector is freed from its RECEIVE SECTOR CHAIN and linked back into the FREEPOOL CHAIN. The RECEIVE SECTOR and FREEPOOL chains are implemented using link- addresses or pointers from one sector to the next in a manner described further below. Each TRANSMIT PACKET CHAIN is linked together from one packet data block to the next for each port using link addresses or pointers as described below.

FIG. 9E is a diagram illustrating the organization of each of the sector prefixes <b>914</b> for each sector <b>912</b> of the packet memory section <b>904</b>. The sector prefix <b>914</b> includes information of a corresponding sector <b>912</b> and further functions as a link to a next sector <b>912</b>, if any. It is noted that although a prefix is indicated, this information portion may be placed anywhere within the sector <b>912</b>. The first byte (0) defines a binary sector packet count (SecPktCnt) indicating the number of packets or packet pieces in the current sector <b>912</b>. The sector packet count is incremented as packet data is stored into the sector, and decremented when the data is read for transmission by the destination port. The sector is released to the FREEPOOL CHAIN when the sector packet count SecPktCnt decrements to zero and when the sector is not at the end of the RECEIVE SECTOR CHAIN. The next byte (1) is a sector source value (SecSource), which specifies the source port of the received packet. This value is desired to identify and decrement an appropriate receive port sector count (RxSecCnt) when the sector is released back into the FREEPOOL CHAIN. The next two bytes (3:2) are reserved or not used.

The next four bytes (7:4) in each sector prefix <b>914</b> forms a next link address (NextSecLink) to the next sector in a corresponding RECEIVE SECTOR CHAIN or FREEPOOL CHAIN. The same link address is used for both purposes, although a different link address could also be used. In the embodiment shown, the NextSecLink address is 32 bits including base and offset portions. The least significant “n” bits may be set to zero to byte-align the NextSecLink address according to the sector-size. The integer “n” is 12 for 4 Kbyte sectors, 11 for 2 Kbyte sectors, 10 for 1 Kbyte sectors, and 9 for 512 Kbyte sectors. In the embodiment shown, n is 11 for 2 Kbyte sectors, etc. In this manner, as one or more packets are received from a port <b>104</b>, <b>110</b>, a RECEIVE SECTOR CHAIN of sectors <b>912</b> are allocated to store the one or more packets received by that port. The sectors <b>912</b> are linked together in chain fashion using the NextSecLink address within the sector prefix <b>914</b> of each sector <b>912</b> in the chain. The packet data is stored sequentially within the packet section <b>916</b> of each of the sector <b>912</b> in each RECEIVE SECTOR CHAIN. It is noted that packet data for a single packet may cross sector boundaries in a RECEIVE SECTOR CHAIN. The final eight bytes (15:8) of the sector prefix <b>914</b> are reserved or otherwise not used.

FIG. 9F is a diagram illustrating the organization of an exemplary packet data block <b>917</b> representing each packet data block within the packet sections <b>916</b>. The packet data block <b>917</b> is further divided into two parts, including a packet block header <b>918</b> and a packet data section <b>920</b>. The packet block header <b>918</b> is preferably prepended to each packet by the MCB <b>404</b> to form a packet data block <b>917</b>. The first two bytes (1:0) in the packet block header <b>918</b> forms a 15-bit binary packet length (PktLength) value defining the packet length in bytes, and a 1-bit mid-packet CT value (MidPktCT), which is set if a CT mode packet is forwarded to the memory <b>212</b> due to a stalled port. The MCB <b>404</b> appends this first DWORD including the PktLength to the packet when transmitting to ports PORT24-PORT27 for the TLANs <b>226</b> and to port PORT28 for the CPU <b>230</b>. The next byte (2) of the packet block header <b>918</b> identifies the source port (SourcePort) number of the packet, which is an 8-bit Port ID binary number identifying the number of the port associated with the source address. The source port is also identified by the particular RECEIVE SECTOR CHAIN in which the packet is stored. The next byte (4) identifies the destination port (DestPort) number, which is an 8-bit Port ID binary number identifying the number of the destination port in a similar manner as the SourcePort value. The destination port is also identified by the particular TRANSMIT PACKET CHAIN to which the packet belongs.

Four bytes (11:8) of the packet block header <b>918</b> define a 32-bit next link address (NextTxLink) to the next packet or packet data block <b>917</b> in a TRANSMIT PACKET CHAIN. The end of the TRANSMIT PACKET CHAIN is indicated when a transmit packet count (TxPktCnt) is decremented to zero. The least significant bit A0 of the NextTxLink address is used as a BC packet bit (NextPktBC) indicating whether the next packet is broadcast or not. If NextPktBC=1, then the next packet is in broadcast format, described below, and if NextPktBC=0, then the next packet is non-broadcast. The next least significant bit A1 of the NextTxLink address is used as a SnF packet bit (NextPktSnF) indicating whether the next packet is SnF or not in a similar manner. It is noted that the least significant nibble (four bits) of the NextTxLink address may be assumed to be zero for byte alignment purposes, regardless of the actual value of the nibble. Thus, for example, when the NextTxLink address is read, bits A[<b>3</b>:<b>0</b>] are assumed to be zero regardless of their actual value, such as NextPktBC=1. This allows these bits to be used for alternate purposes. In the embodiment shown, the data structures are 16-byte aligned so that the least significant bits A[<b>3</b>:<b>0</b>] are assumed to be zero.

In the embodiment shown, the packet data section <b>920</b> immediately follows the packet block header <b>918</b>, where the length of the data field is defined in the packet header. It is noted, however, that the particular ordering of each sector and the particular locations of values in the embodiment shown is arbitrary and for purposes of illustration, and thus may be organized in any desired manner without going beyond the scope of the present invention.

As described previously, packets are retrieved from each of the ports PORT0-PORT28 and stored in corresponding RECEIVE SECTOR CHAINs of the sectors <b>912</b>, one RECEIVE SECTOR CHAIN per port. As shown in FIG. 9H, a first receive sector chain <b>930</b> is shown for PORT0 where a first sector <b>931</b> is linked to another sector <b>932</b> using the NextSecLink in the sector prefix <b>914</b> of the sector <b>931</b>. Further sectors may be linked as desired using the link addresses in the sector prefixes <b>914</b>. Also, a second receive sector chain <b>940</b> is shown for PORT1 where a first sector <b>941</b> is linked to another sector <b>942</b> using the NextSecLink in the sector prefix <b>914</b> of the sector <b>941</b>. For each packet received at a given port, the packet block header <b>918</b> is placed immediately after the previously received packet data block <b>917</b> in the packet section <b>916</b> of the current sector <b>912</b> of the corresponding RECEIVE SECTOR CHAIN, and the packet block header <b>918</b> is followed by its packet data section <b>920</b>. If the packet section <b>916</b> of the current sector <b>912</b> becomes full while storing a packet data block <b>917</b>, another sector <b>912</b> is allocated from the FREEPOOL CHAIN and linked into the RECEIVE SECTOR CHAIN for the port. In this manner, the packet data blocks <b>917</b> received from a port are placed contiguously within the corresponding RECEIVE SECTOR CHAIN for that port. Also, the packet section of a sector <b>912</b> may include entire packets and/or packet portions.

Thus, as shown in FIG. 9H, packet data blocks <b>934</b>, <b>935</b> and <b>936</b> received at port PORT0 are placed within the sectors <b>931</b> and <b>932</b> as shown. Note that packet data block <b>935</b> spans the sectors <b>931</b>, <b>932</b>. In a similar manner, packet data blocks <b>944</b> and <b>945</b> receive at port PORT1 are placed within the sectors <b>941</b> and <b>942</b> as shown, where packet data block <b>945</b> spans the sectors <b>941</b>, <b>942</b>.

Each packet is also associated with the TRANSMIT PACKET CHAIN of packets for each destination port, where the packets are linked together using the NextTxLink address. Packets in each TRANSMIT PACKET CHAIN are generally ordered based on when they are received by the network switch <b>102</b>, so that the order is maintained when transmitted to the associated destination port. For example, as shown in FIG. 9H, if the packet data blocks <b>934</b> and <b>944</b> are to be transmitted from port PORT10, and the packet data block <b>934</b> is to be transmitted just prior to the packet data block <b>944</b>, then the NextTxLink address of the packet block header <b>918</b> of the packet data block <b>934</b> points to the packet data block <b>944</b>. The NextTxLink address of the packet block header <b>918</b> of the packet data block <b>944</b> points to the packet data block to be transmitted next, and so on. The actual order for transmission is determined when a packet is linked into a TRANSMIT PACKET CHAIN. CT mode packets are linked when at the beginning when the packet is received, and SnF mode packets are linked after the entire packet is stored. Mid-packet interim CT mode packets are linked to the front of the corresponding TRANSMIT PACKET CHAIN to ensure proper ordering.

FIG. 9G is a block diagram showing a 128-byte packet header <b>922</b> used for BC packets, which replaces the normal packet block header <b>918</b>. For BC packets, the NextPktBC value is set in the previous packet indicating that the current packet is a BC packet. It is noted that each TRANSMIT PACKET CHAIN should be maintained for all ports that include the BC packet for transmission. Therefore, the BC packet header <b>922</b> includes a 4-byte link address (Port# NextTxLink), for each port numbered 0-28 (including ports <b>104</b>, <b>110</b> and the CPU <b>230</b>), where each NextTxLink address points to the next packet in the TRANSMIT PACKET CHAIN associated with the corresponding port identified by location in the list (Port#). Thus, NextTxLink addresses begin at bytes (11:8) and end at bytes (123:120). The first NextTxLink address entry (11:8) corresponds the next packet in the memory <b>212</b> for the first port PORT0, the second entry (bytes 15:12) is a NextTxLink address to the next packet in the memory <b>212</b> for the second port PORT1, etc.; up to the last entry (bytes 123:120), which is a NextTxLink to the next packet for the CPU <b>230</b>. Each BC link address also includes a next BC packet (NextPktBC) bit indicating whether the next packet in the respective transmit packet chain is a BC packet or not, and a next SnF packet (NextPktSnF) bit indicating whether the next packet in the respective transmit packet chain is a SnF packet or not.

The first four bytes (3:0) of the BC packet header <b>922</b> are similar to the final four bytes of the normal packet block header <b>918</b>, including the PktLength, MidPktCT, SourcePort and DestPort values, except that the MidPktCT value is zero for BC packets. The next four bytes (7:4) of the BC packet header <b>922</b> is a broadcast port bitmap (BC_Ports) in which each of the bits 28:0 corresponds to a port which will receive the BC packet data. Each bit is cleared when the packet is sent to the corresponding port. When all BC_Ports bits have been cleared, the SecPktCnt count, described previously, is also decremented accordingly.

Referring now to FIG. 10, an exemplary block diagram is shown illustrating several transmit packet links each incorporating the same BC packet <b>1010</b>. In this example, ports <b>1</b>, <b>5</b>, <b>11</b> and <b>12</b> are grouped together using the VLAN function or the like, so that the data of the BC packet <b>1010</b> received at one source port, such as port <b>12</b>, is duplicated to the remaining ports <b>1</b>, <b>5</b> and <b>11</b> in that group. Four transmit packet chains <b>1002</b>, <b>1004</b>, <b>1006</b> and <b>1008</b> are shown for ports <b>1</b>, <b>5</b>, <b>11</b> and <b>12</b>, respectively. The transmit packet chains <b>1002</b>, <b>1004</b> and <b>1006</b> link several generic non-broadcast packets <b>1000</b> with the BC packet <b>1010</b>. Since port <b>12</b> is the source port, the BC packet <b>1010</b> is not transmitted on port <b>12</b>, so it is not included in the transmit packet chain <b>1008</b>. The BC packet <b>1010</b> includes a BC packet header <b>1012</b>, which includes a list of link addresses, one for each port, including a link address <b>1016</b> pointing to the next packet <b>1000</b> in the transmit packet chain <b>1002</b> of port <b>1</b>, a link address <b>1018</b> pointing to the next packet <b>1000</b> in the transmit packet chain <b>1004</b> of port <b>5</b>, and a link address <b>1020</b> pointing to the next packet <b>1000</b> in the transmit packet chain <b>1006</b> of port <b>11</b>. In this manner, each of the transmit packet chains <b>1002</b>, <b>1004</b> and <b>1006</b> are maintained. It is also noted that each transmit packet chain may include one or more BC packets, which may appear non-consecutively or consecutively, as desired.

FIG. 11A is a block diagram illustrating MCB packet control registers <b>1102</b>, which set of registers is provided within the SRAM <b>650</b> and duplicated for each of the 29 ports <b>104</b>, <b>110</b> including the CPU <b>230</b> of the network switch <b>102</b>. The CPU <b>230</b> is treated as a “port” (PORT28) for certain purposes, such as for sending and receiving Bridge Protocol Data Units (BPDU's) for purposes of the spanning tree procedure. Each MCB packet control register <b>1102</b> includes a receive section <b>1104</b> and a transmit section <b>1106</b>. In the receive section <b>1104</b>, a 28-bit receive packet header base pointer (RxBasePtr) is a pointer to the base of the current receive packet header for the corresponding port, which is the beginning of the RECEIVE SECTOR CHAIN for that port. As described previously for the memory <b>212</b>, the data structures for the SRAM <b>650</b> are 16-byte aligned so that the least significant bits A[<b>3</b>:<b>0</b>] of all pointers are assumed to be zero. A 28-bit current receive pointer (RxCurPtr) is a pointer to the current data store location for the RECEIVE SECTOR CHAIN of the port. The least significant four bits of the RxCurPtr value are control bits, including a receive BC packet indication bit (RxBC), a receive transfer in progress (RxIP) bit used as a Start Of Packet (SOP) flag, a multiple sector packet (MultiSecPkt) bit <b>1</b> indicating whether the current packet crosses a sector boundary, and a SnF bit <b>0</b> indicating that the transmit link is updated at the end of the packet. The receive section <b>1104</b> further includes a Mid-packet CT bit (MidCT), a 16-bit receive packet length (RxPktLn) value equal to the length of the current packet received in bytes up to the RxCurPtr, a 16-bit receive port sector count (RxSecCnt) indicating the number of sectors currently in use by the corresponding port, and a 16-bit receive sector threshold (RxSecThreshold) value identifying a CPU-programmed maximum number of sectors allowed for each port or RECEIVE SECTOR CHAIN. The RxSecThreshold value is used to determine whether backpressure is to be applied for that port by comparing RxSecThreshold with RxSecCnt. If backpressure is disabled, the RxSecThreshold value is used to drop any further packets received at the corresponding port.

The receive section <b>1104</b> further includes an end of transmit queue pointer (EndOfTxQPtr), which is a 28-bit pointer to the base of the last packet in the TRANSMIT PACKET CHAIN for the corresponding port. Finally, an end of transmit queue BC (EOQ_BC) bit is set to indicate broadcast format for the last packet in the TRANSMIT PACKET CHAIN for the corresponding port.

The transmit section <b>1106</b> provides information for the TRANSMIT PACKET CHAIN for the corresponding port. A transmit base pointer (TxBasePtr) is a 28-bit pointer to the base of the current transmit packet header and another 28-bit transmit current pointer (TxCurPtr) points to the current data retrieval location for the corresponding port. A transmit broadcast (TxBC) bit is set to indicate that the packet header is in broadcast format. A transmit in progress (TxIP) bit is set to logic 1 to indicate that a transmit is currently in progress for the port and is used to indicate SOP. An 8-bit transmit source port (TxSrcPort) number is the source port number of the current transmit packet, which is read from the packet header at SOP. A 16-bit transmit packet length (TxPktLn) value is equal to the remaining bytes to be transmitted for the current transmit packet. When a packet is to be transmitted, the PktLength value in the packet block header <b>918</b> of the packet is copied into the TxPktLn value in the transmit section <b>1106</b>, and then the TxPktLn valued is decremented by the TX controller <b>606</b> as the packet is transmitted. When the TxPktLn is decremented to zero, the EPSM <b>210</b> generates the corresponding EOP* signal to indicate the end of the packet. A 16-bit maximum packet number (TxPktThreshold) value is equal to the CPU-programmed maximum number of packets allowed to be queued for each port. It is noted that packets destined for the CPU <b>230</b> are not subject to the TxPktThreshold or RxPktThreshold limits. Finally, a 16-bit transmit packet count (TxPktCnt) is equal to the number of packets currently queued for the corresponding port.

FIG. 11B is a block diagram illustrating freepool packet control registers <b>1108</b> located in the SRAM <b>650</b>, which registers are associated with the FREEPOOL CHAIN of registers. Each freepool register <b>1108</b> includes a pointer (NextFreeSecPtr) to the next free sector in the FREEPOOL CHAIN, a pointer (LastFreeSecPtr) to the last sector in the FREEPOOL CHAIN, a free sector count (FreeSecCnt) equal to the number of free sectors currently available, a free sector threshold (FreeSecThreshold) number equal to the CPU-programmed minimum number of sectors allowed before a memory overflow flag (MOF) is set for backpressure or filtering (dropping packets) purposes, a BC packet count (BC_PktCnt) equal to the number of BC packets currently in the memory <b>212</b>, and a BC packet threshold (BC_PktThreshold) count equal to a CPU-programmed maximum number of BC packets allowed in the memory <b>212</b>.

Referring now to FIG. 12A, a flowchart diagram illustrating the operation of the network switch <b>102</b> for receiving data packets into the memory <b>212</b> and for transmitting data packets in CT mode of operation. Data is typically received and transmitted by the ports PORT0-PORT27 of the network switch <b>102</b> in the form of packets in real time or in their entirety and are not subdivided while being transmitted across the segments <b>108</b>, <b>114</b>. However, the FIFOs within the network switch <b>102</b> are typically not large enough to store an entire packet. Thus, packet data is transferred within the network switch <b>102</b> from one FIFO to another in packet portions or subdivisions of packets.

In a first step <b>1200</b>, the EPSM <b>210</b> detects a new packet being received by one of the ports <b>104</b>, <b>110</b> through indication of the PKT_AVAILm* signals. At next step <b>1202</b>, the beginning portion or header of the packet is retrieved from the source port and read into the HASH REQ LOGIC <b>532</b>, where the header includes the destination and source MAC addresses. The HASH REQ LOGIC <b>532</b> provides the destination and source addresses and the source port number on the HASH_DA_SA[<b>15</b>:<b>0</b>] signals and asserts the HASH_REQ* signal to the MCB <b>404</b>. The MCB <b>404</b> respondingly invokes the hashing procedure for determining the appropriate action for the packet, where the source and destination addresses are hashed to determine if either of the addresses have been previously stored within the memory <b>212</b>. The MCB <b>404</b> asserts the HASH_DONE* signal when enough information is available for the HCB <b>402</b> to determine the appropriate action to take for the packet. The flowchart shown in FIG. 12A includes two primary portions for the destination and the source addresses, which will be discussed separately. In the embodiment shown, the destination address is hashed first, followed by the source address, although the procedures may be performed concurrently or in any desired order.

For the destination address, operation proceeds to step <b>1204</b>, where the hashing procedure is invoked to hash the destination address. Operation proceeds to step <b>1208</b> from step <b>1204</b> in response to the HASH_DONE* signal to check threshold conditions for both unicast and BC packets. At step <b>1208</b>, it is determined whether any relevant threshold conditions would be violated by the new packet. In particular, if the FreeSecCnt number is equal to or less than the FreeSecThreshold number, then there may not be enough room to store the packet in the memory <b>212</b>. Also, if the RxSecCnt is greater than or equal to the RxSecThreshold number for the source port, then the network switch <b>102</b> may determine to drop the packet. For BC packets, the BC_PktThreshold number is compared to the BC_PktCnt number, which is the actual number of BC packets, to determine if the maximum number of BC packets have already been received. For unicast packets, the TxSecThreshold number is compared to the TxSecCnt number for the destination port.

From step <b>1208</b>, operation proceeds to step <b>1205</b>, where the HCB <b>402</b> determines from the HASH_STATUS[<b>1</b>:<b>0</b>] signals and from comparison of any of the threshold conditions whether the packet is to be dropped. The packet may be dropped for a variety of other reasons as previously described, such as, for example, the source and destination ports are equal. If the packet is to be dropped, operation proceeds to step <b>1207</b> from step <b>1205</b>, where the packet is either dropped or backpressure is applied. Backpressure is applied if the FreeSecThreshold or the RxSecThreshold conditions are violated, and if backpressure is enabled and the source port is operating in half duplex mode. Otherwise, the packet is dropped. For backpressure, the EPSM <b>210</b> executes a backpressure cycle on the HSB <b>206</b> causing the source port to assert a jamming sequence to the sending device. The packet is dropped if the backpressure indication is not accepted by the source port (as indicated by the ABORT_OUT* signal) because it is provided too late to assert the jamming sequence. Also, the packet is dropped if the BC_PktThreshold condition is the only threshold condition that is violated. The network switch <b>102</b> continues to receive the rest of the dropped packet, but the packet is not stored nor sent to another port. From step <b>1207</b>, operation proceeds to step <b>1214</b>, where the appropriate statistics registers in the MCB configuration registers <b>448</b> are updated based on the action taken at step <b>1207</b>. The statistics registers indicate whether the packet was dropped or backpressured due to overflow conditions. For example, a per port “dropped packet—no buffer” count is incremented for the source port to indicate a packet is dropped due to overflow conditions, or a “packet backpressured” count is incremented if the packet is backpressured.

If the packet is not to be dropped, operation proceeds to step <b>1206</b> from step <b>1205</b>, where it is determined whether the destination address was found in the hash memory section <b>902</b> and whether the packet is to be broadcast or not. The packet is broadcast if the destination address is not recognized and thus the destination port is not known, or if the GROUP bit within the packet is set. If the destination address is not found or if the packet is otherwise a BC packet as determined at step <b>1206</b>, then the packet is to be broadcast and operation proceeds to step <b>1210</b>, where the MCB <b>404</b> of the EPSM <b>210</b> allocates another sector within the memory <b>212</b> for the new packet, if necessary. A new sector is not necessary if the current sector has enough room for the packet. Operation then proceeds to step <b>1216</b> indicating that the remainder of the packet, burst by burst, is buffered through the EPSM <b>210</b> and transferred to the memory <b>212</b>. Regardless of port settings, BC packets are handled with SnF mode where the entire packet is stored in the memory <b>212</b> before being transmitted. From step <b>1216</b>, operation proceeds to step <b>1217</b> to determine of the ABORT_OUT* signal was asserted during reception of the packet due to a packet error. Several error conditions are checked by the ports PORT0-PORT27, such as detection of a FIFO overrun, a runt packet, an oversized packet, the packet had a bad FCS (frame check sequence), or a PLL error was detected. If a packet error is detected at step <b>1217</b>, operation proceeds to step <b>1219</b>, where the packet is removed from the memory <b>212</b>.

If no packet errors are detected at step <b>1217</b>, operation proceeds to step <b>1218</b>, where the broadcast port bitmap BC_Ports in the packet header <b>922</b> of the BC packet is updated with the active ports from which the BC packet is to be transmitted. The BC packet is sent to all of the ports <b>104</b>, <b>110</b> except the following ports: the source port; any port not in FORWARDING state if the source port is the CPU <b>230</b> or any port in DISABLED state if the source port is the CPU <b>230</b>; and, any ports having a TxPktCnt number that is greater than or equal to the corresponding TxPktThreshold number. If VLAN is enabled, the VLAN bitmap value in the hash table entry <b>910</b> is also examined, which further limits the ports to active associated ports in the VLAN group. Also, miss BC packets, where the packet is broadcast due to an unknown destination address, are forwarded according to a MissBCBitMap register. It is noted that if the resulting BC_Ports bitmap is all zero's such that the packet is not to be sent to any ports, then this determination is either made at step <b>1205</b> and the packet is dropped at step <b>1207</b>, or the packet is removed from the memory <b>212</b> at step <b>1218</b>.

Operation proceeds to step <b>1220</b> from step <b>1218</b>, where the packet is added to the TRANSMIT PACKET CHAIN for each port in the resulting BC_port bitmap. In particular, each of the NextTxLink link addresses for each port designated in the BC_port bitmap in the packet header <b>922</b> is updated to insert the BC packet in the TRANSMIT PACKET CHAINs of the appropriate ports. All other associated register or count values and statistics in the network switch <b>102</b> are updated accordingly as well, such as, for example, the BC_PktCnt number.

Referring back to step <b>1206</b>, if the destination address is found and the packet is not a BC packet, operation proceeds to step <b>1222</b>, where the hash cache table <b>603</b> is updated. Operation then proceeds to next step <b>1224</b>, where it is queried whether either the source port or the destination port is set for SnF mode. If both ports are set for CT mode and the other CT conditions are met, such as equal port speed and the TBUS setting for the destination port is equal to the TBUS setting for the source port, operation proceeds to step <b>1225</b>, where it is queried whether the destination port path is busy. If operation is designated for SnF mode as determined at step <b>1224</b>, or if designated for CT mode but the destination port is busy as determined at step <b>1225</b> so that interim CT mode is initiated, operation proceeds to step <b>1226</b>, where the MCB <b>404</b> of the EPSM <b>210</b> allocates space within the memory <b>212</b> for the new packet, if necessary. From step <b>1226</b>, operation proceeds to step <b>1228</b>, where the remaining portion of the packet is retrieved into the EPSM <b>210</b> and transferred to the memory <b>212</b>. If a packet error occurs during the reception of the packet as indicated at step <b>1229</b>, which step is similar to step <b>1217</b>, operation proceeds to step <b>1219</b> to remove the packet from the memory <b>212</b>. Otherwise, operation proceeds to next step <b>1230</b>, where the packet is added to the TRANSMIT PACKET CHAIN of the destination port, and the appropriate Link addresses, counts and CHAINs are updated.

Referring back to step <b>1225</b>, if the destination port path is not busy, operation proceeds to step <b>1231</b>, where the source and destination ports are designated for normal CT operation for the current packet. For normal CT mode, each remaining packet portion is not sent to the memory <b>212</b>, but instead, is buffered through the CT BUF <b>528</b> to the destination port. The header of the packet is transferred from the RX FIFO of the EPSM <b>210</b> directly to the destination port. Next step <b>1232</b> indicates receiving data packet portions into the CT BUF <b>528</b> and transferring the packet portions to the destination port. During CT operation, next step <b>1233</b> queries whether the destination port or path becomes busy or unavailable. This query indicated at step <b>1233</b> is performed before data is received into the CT BUF <b>528</b> by the MAIN arbiter <b>512</b>. While the destination port remains available for more data, operation loops to step <b>1234</b> to query whether the entire packet has been transferred to the destination port, and if not, back to step <b>1232</b> to transmit more data. When the entire packet has been transferred in CT mode as determined at step <b>1234</b>, operation for that packet is completed.

If the destination port becomes busy or unavailable as determined at step <b>1233</b> during normal CT mode transfer, operation proceeds to step <b>1235</b> to receive the remaining portion of the packet into the memory <b>212</b> to initiate mid-packet interim CT mode. During mid-packet interim CT mode, the remaining portion of the packet is buffered through the memory <b>212</b>. Since the packet was in the middle of transmission, the remaining packet data sent to the memory <b>212</b> is placed at the beginning of the TRANSMIT PACKET CHAIN for that port to ensure proper packet ordering as indicated at next step <b>1236</b>. As in normal CT mode of operation, each data portion provided to the memory <b>212</b> during mid-packet interim CT mode is available for transfer to the destination port as soon as received.

Referring back to step <b>1202</b>, operation proceeds to step <b>1240</b> for hashing the source address. Operation then proceeds to next step <b>1242</b>, where it is queried whether the source address was found in the hash memory section <b>902</b> and whether the GROUP bit within the packet was set. If the source address was found and if the GROUP bit was not set, operation proceeds to step <b>1244</b>, where the AGE field of the hash memory section <b>902</b> is updated with the AGE information. For example, the AGE value is set to zero. It is noted that the source MAC address and source port number may no longer correspond with a previous entry. This could happen, for example, if a network or data device is moved from one port to another. This information is compared and updated at step <b>1244</b>.

Referring back to step <b>1242</b>, if the source address was not found or if the GROUP bit was set, operation proceeds to step <b>1246</b>, where an interrupt is generated to the CPU <b>230</b>, which performs the following steps. At next step <b>1248</b>, the CPU <b>230</b> allocates a hash table entry in the hash memory section <b>902</b> of the memory <b>212</b> or a least recently used (LRU) section of the hash cache table <b>603</b> for the new source port address. Operation then proceeds to step <b>1250</b>, where the values in the allocated hash entry, such as the source MAC address, the source port number and the AGE information, are updated.

FIG. 12B is a simplified flowchart diagram illustrating the general operation of the network switch <b>102</b> for transmitting data from the memory <b>212</b> to one or more destination ports. The transmission procedure generally applies to SnF and mid-packet interim CT modes of operation, and to BC packets, as qualified below. A first step <b>1260</b> generally represents that packet data is queued in the memory <b>212</b> according to procedures described previously. Operation proceeds to next step <b>1262</b>, where the MCB <b>404</b> indicates to the HCB <b>402</b> that packet data is available. For mid-packet interim CT mode, this indication is provided as soon as the first DWORD of data is sent to the MCB <b>404</b> for storage in the memory <b>212</b> since the data is almost immediately available for transfer to a destination port. For SnF mode, however, this indication is provided only after the last DWORD of data for a data packet is sent to the MCB <b>404</b> since the entire packet is stored prior to transmission. Once packet data is available for transmission, operation proceeds to step <b>1264</b>, where it is determined whether the destination port has buffer space available to receive packet data for transmission. Step <b>1264</b> generally represents the polling procedure performed by the EPSM <b>210</b> for polling each of the ports <b>104</b>, <b>110</b>, which respond with corresponding BUF_AVAILm* signals as described previously. Operation remains at step <b>1264</b> until the destination port indicates that it has buffer space available to receive packet data.

When the destination port indicates it has buffer space at step <b>1264</b>, operation proceeds to step <b>1266</b>, where the HCB <b>402</b> requests transfer of data for the destination port. At next step <b>1268</b>, a burst of data is transferred from the memory <b>212</b> to the destination port for transmission. Operation proceeds to next step <b>1270</b>, where it is queried whether all of the data in the memory <b>212</b> has been transferred to the destination port. If not, operation returns to step <b>1264</b> to wait until the destination port has more buffer space available for another transfer of data. Eventually, the entire data packet, in the SnF and interim CT mode case, or the remaining packet data, in the mid-packet interim CT mode case, is transferred as determined at step <b>1270</b>.

Operation then proceeds to step <b>1272</b>, where it is determined whether the packet is a BC packet or not. If the packet is a BC packet, operation proceeds to step <b>1274</b> to determine if the entire packet has been transferred to all of the active ports. If not, then operation is complete for the current packet. The procedure is executed again for each port until the packet is transferred to all active ports. It is noted that steps <b>1272</b> and <b>1274</b> are shown to represent that steps <b>1264</b> through <b>1270</b> are performed for each destination port for each BC packet. Thus, the entire BC data packet remains in the memory <b>212</b> until sent to all active destination ports for transmission. If the packet is not a BC packet or after the entire packet is sent to all active ports for BC packets as indicated at step <b>1274</b>, operation proceeds to step <b>1276</b>, where the buffer space in the memory <b>212</b> holding the BC packet is freed. In particular, the sectors holding the packet data are returned to the FREEPOOL CHAIN of free memory sectors within the memory <b>212</b>.

Referring now to FIG. 13, a flowchart diagram is shown illustrating hash lookup operation of the EPSM <b>210</b>. The steps in the flowchart of FIG. 13 are performed by the MCB <b>404</b>. An initial step <b>1302</b> detects a hash request as indicated by assertion of the HASH_REQ* signal. The HCB <b>402</b> identifies the header of the packet as a new packet, determines the source and destination addresses and the source port number and asserts the HASH_DA_SA[<b>15</b>:<b>0</b>] signals to the hash controller <b>602</b> of the MCB <b>404</b>. The MCB <b>404</b> then retrieves the source and destination MAC addresses and the source port number and performs the hashing procedure, which determines the appropriate action for the packet.

The MCB <b>404</b> generally takes one of four actions with each packet based on the source port number and the source and destination MAC addresses. In particular, the hash controller <b>602</b> determines the HASH_STATUS[<b>1</b>:<b>0</b>] signals, which are set to FORWARD_PKT to forward the packet to the destination port, DROP_PKT to drop and ignore the packet, MISS_BC if the destination MAC address is new and unknown so that the packet is broadcast to all other ports, or GROUP_BC if the packet is to be duplicated to and transmitted by a subset of associated ports. From step <b>1302</b>, operation proceeds to step <b>1304</b> to determine whether to drop the packet, which is determined by the following equation (1):

<maths><formula-text>DropPkt:=(SrcState=DIS) or (!FilterHit &amp; SrcState!=FWD)  (1)</formula-text></maths>

where SrcState identifies the spanning tree state of the source port, FilterHit is a bit which is asserted if the source MAC address falls within a predetermined range, the ampersand “&amp;” symbol represents the logic AND operation, the exclamation “!” symbol denotes logic negation, the symbol “!=” denotes the function “not equal to”, and the symbol “:=” denotes the function “set equal to”. Each port has one of five states provided in the HSB configuration registers <b>448</b> and as determined by the spanning tree function of the IEEE <b>802</b>.<b>1</b> specification, including learning (LRN), forwarding (FWD), blocked (BLK), listening (LST), and disabled (DIS). In the embodiment shown, the BLK and LST states are treated as the same. Thus, the packet is dropped if the source port is disabled, or if the source MAC address is not within the predetermined filter range and the state of the source port is not forwarding.

If DropPkt is true as determined at step <b>1304</b>, operation proceeds to step <b>1305</b>, where HASH_STATUS[<b>1</b>:<b>0</b>] signals are set equal to 00b=DROP_PKT to instruct the HCB <b>402</b> to ignore or otherwise drop the packet. If DropPkt is false, operation proceeds to step <b>1306</b>, where the FilterHit bit is examined to determine if the source MAC address is within the predetermined range. The predetermined range identifies packets sourced from or destined for the CPU <b>230</b>, including Bridge Protocol Data Units (BPDU's) that are sent to the CPU <b>230</b>. If FilterHit is true as determined at step <b>1306</b>, operation proceeds to step <b>1308</b> to identify the destination port (DstPrt). If the packet is from the CPU <b>230</b> (SrcPrt=CPU), then the destination port is set equal to a value FltrPrt set by the CPU <b>230</b> in a previous operation (DstPrt:=FltrPrt). Otherwise, the packet is sent to the CPU <b>230</b> (DstPrt:=PORT28). Operation then proceeds from step <b>1308</b> to step <b>1310</b> to determine whether to forward the packet (FwdPkt) according to the following equation (2):

<maths><formula-text>FwdPkt:=(DstPrt!=SrcPrt) &amp; ((DstState=FWD) or (SrcPrt=CPU &amp; DstState!=DIS))  (2)</formula-text></maths>

where DstState is the spanning tree state of the destination port (DstPrt) and “&amp;” denotes the logic AND operation. Thus, the packet is forwarded to the destination port if the destination and source ports are not the same and if the state of the destination port is forwarding, or if the source port is the CPU <b>230</b> and the state of the destination port is not disabled. The destination port is known even without hash lookup since it is either the CPU <b>230</b> or determined by the CPU <b>230</b> as FltrPrt. If FwdPkt is false, then operation proceeds to step <b>1305</b> to drop the packet. Otherwise, if FwdPkt is true, operation proceeds to step <b>1312</b>, where HASH_STATUS[<b>1</b>:<b>0</b>] signals are set equal to 11b=FORWARD_PKT indicating the packet is to be forwarded to the destination port. Also, the HASH_DSTPRT[<b>4</b>:<b>0</b>] signals are asserted with the DstPrt destination port number.

Referring back to step <b>1306</b>, if the source address is not within the predetermined range and thus outside the filtered MAC addresses, then operation proceeds to step <b>1314</b> to examine the GROUP bit within the received packet indicating whether the packet is a BC packet or not. If GROUP is false (GROUP bit=logic 0), operation proceeds to step <b>1316</b> to perform a hash lookup of the destination MAC address (DA). The MAC address is first hashed by taking two different sets of bits from the address and logically combining or comparing the two sets together on a bit-by-bit basis to form a corresponding 13-16 bit hash address, as described previously. Any bits of the MAC address may be chosen for purposes of the hashing procedure. The actual lookup procedure is performed by a separate routine or function, described below with reference to the flowchart of FIG. <b>14</b>.

The lookup procedure at step <b>1316</b> returns one or more values as desired, including a bit referred to as HIT, which is returned as DA_Hit for destination addresses, or SA_Hit for source addresses. The HIT bit determines whether the hashed address was found in the hash memory section <b>902</b>. From step <b>1316</b>, operation proceeds to step <b>1318</b> where the DA_Hit value is examined to determine whether the address was found or not. The address will be found in the memory <b>212</b> if the device corresponding to the destination MAC address previously sourced a packet. If DA_Hit is true, operation proceeds to step <b>1310</b> to determine whether to forward the packet as described previously. If the hash address was not found and DA_Hit is false, then operation proceeds to step <b>1320</b>, where the HASH_STATUS[<b>1</b>:<b>0</b>] signals are set to 10b=MISS_BC indicating a new MAC address. Since the port number associated with the destination device is not yet known, the packet is broadcast to all other active (and as qualified by VLAN and other logic) ports to ensure that the packet is transmitted to the appropriate destination device. Eventually, the destination device responds to the packet with a new packet including the same MAC address as a source address. The network switch <b>102</b> is then able to associate the MAC address with a port and port number and correspondingly update the hash memory section <b>902</b>. Referring back to step <b>1314</b>, if the GROUP bit is true (or logic 1), operation proceeds to step <b>1322</b> where the HASH_STATUS[<b>1</b>:<b>0</b>] signals are set to 01b=GROUP_BC indicating that the packet is to be broadcast to all other ports or to a group of ports specified by the VLAN function.

From any of steps <b>1305</b>, <b>1312</b>, <b>1320</b> or <b>1322</b>, operation proceeds to step <b>1324</b> to determine whether to search the hash memory section <b>902</b> for the source MAC address by examining a SrcLookUp value. The SrcLookUp value is determined according to the following equation (3):

<maths><formula-text>SrcLookUp:=(SrcState=(LRN or FWD)) &amp; SrcPrt!=CPU  (3)</formula-text></maths>

indicating that the MAC source address will be searched if the source port is in learning or forwarding mode and is not the CPU <b>230</b>. If SrcLookUp is true or asserted as determined at step <b>1324</b>, operation proceeds to step <b>1326</b>, where two values VLAN and SecurePort are examined. The VLAN bit is true if any of the VLAN modes are enabled, but is otherwise false. SecurePort is true or asserted if the source port is secure, where no new addresses are added to the hash memory section <b>902</b> and packets from unknown source addresses are dropped. If VLAN is not true and if the port is not secure, operation proceeds to step <b>1328</b>, where the HASH_DONE* signal is asserted and temporarily left asserted. At this point, the HASH_STATUS and HASH_DSTPRT signals are captured by the HCB <b>402</b>.

If VLAN is true or if SecurePort is true as determined at step <b>1326</b>, or after step <b>1328</b> is performed, the assertion of the HASH_DONE* signal is delayed until after the source address lookup. Operation then proceeds to step <b>1330</b>, where a hash lookup is performed on the source MAC address (SA) in a similar manner as described above for the destination MAC address. At step <b>1330</b>, a value SA_Hit is returned true if the hash address is found for the corresponding device. From step <b>1330</b>, operation proceeds to step <b>1332</b> where a value Src_Hit is examined. Src_Hit is related to SA_Hit by the following equation (4):

<maths><formula-text>Src_Hit:=SA_Hit &amp; (HshPrt=SrcPort)  (4)</formula-text></maths>

where Src_Hit is true if a source hit occurred (SA_Hit is true) and if the port number found in the entry in the hash memory section <b>902</b> is equal to the actual source port number where the packet was received. If the stored source port number is not equal to the actual source port number, then the device was likely moved to another port and the hash memory section <b>902</b> is updated by the CPU <b>230</b> as described below. If Src_Hit is true, then operation proceeds to step <b>1334</b>, where the HASH_DONE* signal is asserted if VLAN is false. Operation then proceeds to step <b>1336</b>, where the AGE number of the device is compared to zero. If AGE is not equal to zero, then the AGE number is set equal to zero at step <b>1338</b>. If the AGE number is equal to zero as determined at step <b>1336</b>, or after being set to zero at step <b>1338</b>, operation proceeds to step <b>1340</b>, where the VLAN bit is again examined. If VLAN is true, then operation proceeds to step <b>1342</b>, where a hash VLAN routine or procedure is executed to identify related ports as determined from the corresponding VLAN bitmap value in the hash table entry <b>910</b>. If VLAN is not true as determined at step <b>1340</b>, operation proceeds to step <b>1344</b>, where the HASH_DONE* signal is asserted or pulsed for a period of time, if not already asserted, and then negated. From step <b>1344</b>, operation for this procedure is completed. The negation of the HASH_DONE* signal terminates the hash lookup of the HCB <b>402</b>.

Referring back to step <b>1332</b>, if Src_Hit is false, operation proceeds to step <b>1350</b>, where it is determined whether the source port is learning disabled by examining a LearnDisPrt value. If not, operation proceeds to step <b>1352</b>, where the new information of the packet is loaded into appropriate registers and the CPU <b>230</b> is interrupted. The CPU <b>230</b> respondingly updates the hash memory section <b>902</b> with a new hash table entry <b>910</b>. If the source port is learning disabled as determined at step <b>1350</b>, or after the hash memory section <b>902</b> is updated at step <b>1352</b>, operation proceeds to step <b>1354</b> to examine the SecurePort bit. If SecurePort is true, operation proceeds to step <b>1356</b>, where the HASH_STATUS[<b>1</b>:<b>0</b>] signals are changed to 00b=DROP_PKT. In this case, the new packet will be dropped since the address is new and new addresses are not allowed on secure ports. Also, a security violation interrupt is asserted to the CPU <b>230</b>, if desired, to take appropriate measures in response to the security violation. From step <b>1356</b>, operation proceeds to step <b>1344</b>. Referring back to step <b>1354</b>, if the SecurePort bit is false indicating a non-secure port, operation proceeds to step <b>1340</b>. Referring back to step <b>1324</b>, if SrcLookUp is false, operation proceeds directly to step <b>1344</b>.

Referring now to FIG. 14, a flowchart diagram is shown illustrating a hash lookup procedure for searching all of the hash table entries <b>910</b> in the hash memory section <b>902</b>. In a first step <b>1402</b>, an address value A is set equal to the received hash address, such as would be sent from steps <b>1316</b> or <b>1330</b>. Operation proceeds to step <b>1404</b>, where the hash table entry <b>910</b> within the primary hash entry section <b>906</b> associated with the received hash address is read. Operation proceeds to step <b>1406</b>, where the VALIDENTRY bit is read and the MAC address of the new packet is compared with the stored MAC address. If the entry is valid and an exact match occurs between the MAC addresses, then operation proceeds to step <b>1408</b> where the HIT bit is set to true indicating a hash hit, and operation returns to the calling procedure or routine. Otherwise, if the entry is not valid or an address match did not occur, operation proceeds to step <b>1410</b> where the VALIDENTRY bit and the EOC (end of chain) values of the entry are examined. If the entry is not valid or if the EOC is reached, then operation returns with the HIT bit being false. Otherwise, the hash address is set equal to the link address within the hash entry (bytes F:C) at step <b>1412</b>, and operation returns to step <b>1404</b> to try the next chained entry within the chained hash entry section <b>908</b>. Operation loops between steps <b>1404</b>, <b>1406</b>, <b>1410</b> and <b>1412</b> until either a valid entry is found with a MAC address match or an invalid entry is found or the EOC value is encountered.

The following table (1) provides the CPU <b>230</b> input/output (I/O) space registers for a particular embodiment implemented according to the present invention. Table (1) is provided only as an example, where particular registers may or may not be implemented in particular embodiments or similar registers may have different nomenclature.

<img id="EMI-00001" file="US06233246-20010515-P00001.TIF" img-format="tif" /><img id="EMI-00002" file="US06233246-20010515-P00002.TIF" img-format="tif" /><img id="EMI-00003" file="US06233246-20010515-P00003.TIF" img-format="tif" /><img id="EMI-00004" file="US06233246-20010515-P00004.TIF" img-format="tif" /><img id="EMI-00005" file="US06233246-20010515-P00005.TIF" img-format="tif" /><img id="EMI-00006" file="US06233246-20010515-P00006.TIF" img-format="tif" /><img id="EMI-00007" file="US06233246-20010515-P00007.TIF" img-format="tif" /><img id="EMI-00008" file="US06233246-20010515-P00008.TIF" img-format="tif" /><img id="EMI-00009" file="US06233246-20010515-P00009.TIF" img-format="tif" /><img id="EMI-00010" file="US06233246-20010515-P00010.TIF" img-format="tif" /><img id="EMI-00011" file="US06233246-20010515-P00011.TIF" img-format="tif" /><img id="EMI-00012" file="US06233246-20010515-P00012.TIF" img-format="tif" /><img id="EMI-00013" file="US06233246-20010515-P00013.TIF" img-format="tif" /><img id="EMI-00014" file="US06233246-20010515-P00014.TIF" img-format="tif" /><img id="EMI-00015" file="US06233246-20010515-P00015.TIF" img-format="tif" /><img id="EMI-00016" file="US06233246-20010515-P00016.TIF" img-format="tif" /><img id="EMI-00017" file="US06233246-20010515-P00017.TIF" img-format="tif" /><img id="EMI-00018" file="US06233246-20010515-P00018.TIF" img-format="tif" /><img id="EMI-00019" file="US06233246-20010515-P00019.TIF" img-format="tif" /><img id="EMI-00020" file="US06233246-20010515-P00020.TIF" img-format="tif" /><img id="EMI-00021" file="US06233246-20010515-P00021.TIF" img-format="tif" /><img id="EMI-00022" file="US06233246-20010515-P00022.TIF" img-format="tif" /><img id="EMI-00023" file="US06233246-20010515-P00023.TIF" img-format="tif" /><img id="EMI-00024" file="US06233246-20010515-P00024.TIF" img-format="tif" /><img id="EMI-00025" file="US06233246-20010515-P00025.TIF" img-format="tif" /><img id="EMI-00026" file="US06233246-20010515-P00026.TIF" img-format="tif" /><img id="EMI-00027" file="US06233246-20010515-P00027.TIF" img-format="tif" /><img id="EMI-00028" file="US06233246-20010515-P00028.TIF" img-format="tif" />

It is now appreciated that a network switch with statistics read accesses gathers statistical information in a more efficient manner without substantially effecting network data flow through the switch and without forcing the processor into a significant number of wait states. In particular, the processor writes once to a statistics request register to initiate a statistics request and to specify the particular information to retrieve. The switch manager detects the request, gathers the information into memory, and then informs the processor when the request is completed. The processor is informed via an interrupt or via a register bit polled by the processor. Once informed, the processor executes cycles to retrieve all of the collected data from the switch manager. The transfer to the processor is preferably performed with burst cycles for more efficient and faster data transfer. In this manner, the processor is removed from direct connection to the statistics registers and free to complete other tasks while the information is being gathered by the switch manager, thereby increasing the efficiency of the processor and of the network switch.

Although a system and method according to the present invention has been described in connection with the preferred embodiment, it is not intended to be limited to the specific form set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the invention as defined by the appended claims.