A transmitter transmits a data frame as an uninterrupted stream of codeblocks of predefined size on a first 10 Gigabit/second data path between a mac and PHY. It inserts a first idle block of predefined size within the data frame if there is insufficient data. A receiver receives a second idle block on a second data path, the second idle block including a request to slow down the transmission on the first data path. The receiver causes the transmitter to insert a third idle block in response to receiving the second idle block. The transmitter may further send a stream identifier including an identifier for a data stream and a bandwidth factor. The transmitter may send one codeblock chosen from data blocks for the data stream and idle blocks, and then send the bandwidth factor number of codeblocks chosen from data blocks for other data streams and idle blocks.
|
9. A method of transmitting data between a media access controller (mac) and a physical layer (PHY), the method comprising:
transmitting, from a transmitter that is part of the mac, a data frame from the mac as an uninterrupted stream of codeblocks of a predefined size on a first 10 Gigabit/second data path between the mac and the PHY, the transmitting from the mac including inserting a first idle block within the data frame if there is insufficient data, idle blocks being of the predefined size and including only characters chosen from a set of control characters that are undefined such that idle blocks are invalid codeblocks.
1. A device for transmitting data between a media access controller (mac) and a physical layer (PHY), the device comprising:
a transmitter that is part of the mac and that transmits a data frame from the mac as an uninterrupted stream of codeblocks of a predefined size on a first 10 Gigabit/second data path between the mac and the PHY, the data frame transmitted from the mac as the uninterrupted stream of codeblocks by insertion of a first idle block within the data frame if there is insufficient data, idle blocks being of the predefined size and including only characters chosen from a set of control characters that are undefined such that idle blocks are invalid codeblocks.
2. The device of
to receive a second idle block on the second data path, the second idle block including a request to slow down the transmission on the first data path, and
to cause the transmitter to insert a third idle block in the data frame in response to receiving the second idle block.
3. The device of
4. The device of
5. The device of
6. The device of
7. The device of
8. The device of
sends a stream identifier block during an inter-frame period between successive data frames, the stream identifier block including an identifier for a data stream having a net data rate of less than 10 Gigabit/second and a bandwidth factor that indicates a number of codeblocks that will be sent between successive data blocks for the data stream;
sends one codeblock chosen from a group consisting of data blocks for the data stream and idle blocks; and
sends the bandwidth factor number of codeblocks chosen from a group consisting of data blocks for other data streams and idle blocks.
10. The method of
receiving a second idle block on a second 10 Gigabit/second data path between the mac and the PHY, the second data path transferring data in an opposite direction from the first data path, the second idle block including a request to slow down the transmission on the first data path; and
inserting a third idle block in the data frame in response to receiving the second idle block.
11. The method of
12. The method of
13. The method of
14. The method of
15. The method of
16. The method of
sending a stream identifier block during an inter-frame period between successive data frames, the stream identifier block including an identifier for a data stream having a net data rate of less than 10 Gigabit/second and a bandwidth factor that indicates a number of codeblocks that will be sent between successive data blocks for the data stream;
wherein transmitting data in the data frame between the mac and the PHY includes
sending one codeblock chosen from a group consisting of data blocks for the data stream and idle blocks, and
sending the bandwidth factor number of codeblocks chosen from a group consisting of data blocks for other data streams and idle blocks.
|
|||||||||||||||||||||||||
1. Field of the Invention
The present invention relates generally to a system and method for providing an interface between an Ethernet physical media interface (PHY) and a Media Access Controller (MAC). More specifically, the present invention relates to an interface that accommodates a PHY with a lower data rate than the MAC.
2. Relationship to the Related Art
In computer network systems there is typically a natural division between chips handling the physical layer, which is responsible for transmitting data on the network, and the system chips, which perform logical operations with data transmitted on the network. Ethernet hubs, routers and switches are composed of multiple ports, and may be generically referred to as multi-port Ethernet devices. Each port is typically composed of a system chip, which includes a media access controller (“MAC”) layer, and a physical layer or “PHY.” Modern multi-port Ethernet devices typically integrate multiple MACs into one system chip (MAC chip) as well as multiple PHYs into another chip (PHY chip). An interface is required on each chip to transfer signals between the MACs and the PHYs.
IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements, Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, IEEE Std 802.3™-2005, provides a standard for Ethernet local area network operation including interfaces between the MACs and the PHYs.
Section 4 of Part 3 of IEEE Std 802.3™-2005 provides for a 10 Gigabit/second (Gb/s) baseband network and connection of a 10 Gb/s capable MAC to a 10 Gb/s PHY. Interfaces that can connect a 10 Gb/s capable MAC to a 10 Gb/s PHY include 10 Gigabit Media Independent Interface (XGMII), 10 Gigabit Attachment Unit Interface (XAUI), 10 Gigabit Sixteen-Bit Interface (XSBI), and the high speed serial electrical interface for 10 Gb/s small form-factor pluggable transceiver (XFP) modules (XFI).
Various 10 Gigabit/second interfaces may be used between the MAC 410 and the PHY 420. For example, a 10 Gigabit Interface Media Independent Interface (XGMII) in which each sixty-four bit block consists of two consecutive sets of thirty-two data bits with a corresponding 4 bits of controls may be used. The thirty-two data bits and 4 control bits are communicated over 4 lanes in which each lanes carries an octet of data and an associated control bit. 4 lanes are provided for data to be transmitted on the attached media. An independent 4 lanes are provided for data received on the attached media.
Another interface that may be used between the MAC 410 and the PHY 420 is a 10 Gigabit Attachment Unit Interface (XAUI) in which each sixty-four bit block consists of two consecutive sets of four 8B/10B codewords, 8 bits of data and 2 control bits. Still another interface that may be used between the MAC 410 and the PHY 420 is a high speed serial electrical interface for 10 Gb/s small form-factor pluggable transceiver (XFP) modules (XFI) in which each sixty-four bit block consists of one 64B/66B codeword, 64 bits of data and 2 control bits.
10 Gb/s communication between the MAC 410 and the PHY 420 is specified as operating at a fixed clock frequency corresponding to the nominal 10 Gb/s bit rate. Independent transmit and receive data paths are provided between the MAC 410 and the PHY 420. Data is communicated in data frames that begin with a preamble <preamble> and start of frame delimiter <sfd> and end with an end of frame delimiter <efd>. Data within each data frame is communicated in 64 bit code blocks. An inter-frame <inter-frame> period during which no frame data activity occurs separates successive data frames. The inter-frame period can vary in length.
PHYs connected to a 10 Gb/s capable MAC may be required to support the 10 Gb/s MAC data rate. A PHY that is connected to physical media that provides less than a 10 Gb/s data rate may be required to use inter-frame period idle control characters to compensate for the difference in data rates, such as in the mechanism provided by Section 46.1.3, Rate of Operation, of IEEE Std 802.3™-2005 for XGMII. The PHY may buffer one complete frame of incoming data to transmit a data frame to the MAC at the 10 Gb/s MAC data rate. The PHY may buffer more than one complete frame of outgoing data received from the MAC at the 10 Gb/s MAC data rate. A data frame may be up to sixteen kilobytes of data for Ethernet systems. Thus a PHY that is connected to physical media that provides less than a 10 Gb/s data rate may need a significant amount of buffer memory.
In view of the foregoing, it would be useful if the buffer memory requirements could be reduced for a PHY that is connected to physical media that provides less than a 10 Gb/s data rate.
A transmitter transmits a data frame as an uninterrupted stream of codeblocks of a predefined size on a first 10 Gigabit/second data path between a MAC and PHY. The transmitter inserts a first idle block of the predefined size within the data frame if there is insufficient data. In some embodiments, a receiver receives a second idle block on a second data path, the second idle block including a request to slow down the transmission on the first data path. The receiver causes the transmitter to insert a third idle block in response to receiving the second idle block.
In some embodiments, the transmitter may further send a stream identifier including an identifier for a data stream and a bandwidth factor during an inter-frame period. The transmitter may then send one codeblock chosen from data blocks for the data stream and idle blocks, and then send the bandwidth factor number of codeblocks chosen from data blocks for other data streams and idle blocks. This permits multiple streams to be defined and interleaved over a single data path.
These and other features and advantages of the present invention will be presented in more detail in the following specification of the invention and the accompanying figures which illustrate by way of example the principles of the invention.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
Reference will now be made in detail to various embodiments of the invention. Examples of these embodiments are illustrated in the accompanying drawings. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to any particular embodiments. On the contrary, they are intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. The present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.
It is a requirement of IEEE Std 802.3™-2005 that the data interfaces operate at a fixed clock frequency corresponding to the nominal 10 Gb/s bit rate, where the exact clock frequencies are a function of the interfaces as provided by the standard. Further, it is required that data be transferred in an uninterrupted stream of codeblocks. The codeblocks have a predefined sized for and given interface. For example, for the 10 Gigabit Interface Media Independent Interface (XGMII) each codeblock consists of two consecutive sets of thirty-two data bits with corresponding controls. For the 10 Gigabit Attachment Unit Interface (XAUI), each codeblock consists of two consecutive sets of four 8B/10B codewords. For the high speed serial electrical interface for 10 Gb/s small form-factor pluggable transceiver (XFP) modules (XFI), and each codeblock consists of one 64B/66B codeword. In all cases the codeblock include 64 data bits that may represent eight data octets as specified by IEEE Std 802.3™-2005. The codeblocks further include control bits as determined by the interface in use.
It is important that the clock frequency be fixed and that the transfer of codeblocks be uninterrupted so that data transfers can be reliably carried out at the 10 Gb/s bit rate. Rather than buffer a full data frame before transmitting as would be required to fully comply with IEEE Std 802.3™-2005, the transmitter 112 according to the present invention inserts an idle block of the same predefined size as the codeblocks that carry data within the data frame if there is insufficient data. Idle blocks may include characters chosen from the set of control characters that are undefined, and hence invalid, by IEEE Std 802.3™-2005. For example, the idle block may be of the form:
Sync Ob10; Control type 0x1e; 7 x Idle 0x00
i.e. 0x2—1E00—0000—0000—0000
The idle block is an invalid codeblock in a normal data stream according to IEEE Std 802.3™-2005. The idle blocks inserted into the data frame by the transmitter 112 of the source device 110 must be removed by the receiver 164 of the destination device 160 for the stream provided by the first data path 120 to appear normal.
It will be appreciated that the MAC 100 and PHY 150 form a symmetrical system in which the PHY may use a device 160 that is similar to the device 110 used by the PHY to transmit data. The device 160 in the PHY 150 may use the same mechanism as described above to insert idle block within the data frame if there is insufficient data. This may be advantageous if the PHY 150 is receiving data from media 172 that does not provide data at a 10 Gb/s rate either because it is legacy media or because it is operating at less than the intended speed, perhaps due to deficiencies in the media.
It may be noted that the data flowing through the MAC 100 and the PHY 150 may be described as transmit data or receive data based on whether it is transmitted or received on the media connected to the PHY. Thus the transmitter 112 of the MAC 100 transfers transmit data that is received by the receiver 164 of the PHY 150 for transmission on the outbound media 170. The inbound media 172 provides receive data that the transmitter 162 of the PHY 150 transfers to the receiver 114 of the MAC 100.
The device 110 may further include a receiver 114 coupled 116 to the transmitter 112 and to a second 10 Gigabit/second data path 122 between the MAC 100 and the PHY 150. The second data path 122 transferring data in an opposite direction from the first data path 120.
For the MAC 100, the first data path 120 carries the transmit data destined for the outbound media 170 and the second data path 122 carries the receive data from the inbound media 172. For the PHY 150, the first data path 122 carries the receive data from the inbound media 172 and the second data path 122 carries the transmit data destined for the outbound media 170. Note that the term first data path and second data path are applied with respect to the transmitter and receiver respectively of the device being described. The first data path 120 for the device 110 on the MAC 100 is also the second data path 120 for the device 160 on the PHY 150.
The receiver 114 of the device 110 may receive a second idle block on the second data path 122. The second idle block may include a request to slow down the transmission on the first data path 120. Idle blocks with a slow down request may include characters chosen from the set of control characters that are undefined, and hence invalid, by IEEE Std 802.3™-2005. For example, the idle block may be of the form:
Sync Ob10; Control type 0x55; 7 x Idle 0x00
i.e. 0x2—5500—0000—0000—0000
If the receiver 114 receives the idle block with a slow down request on the second data path 122, the receiver signals the transmitter 112 of the same device 110 to insert an idle block in the data frame being transmitted on the first data path 120. The transmitter 112 responds to the signal 116 by inserting one or more idle blocks in the data frame. The idle block inserted by the transmitter 112 of the first device 110 may or may not include a request to slow the data being transmitted by the second device 160. That is, both the MAC and the PHY can send idles with a slowdown request and independently slow the effective data transfer rate in both directions. It will be appreciated that if the transmitter 112 is not transmitting a data frame when it receives the signal 116 requesting a slow down, it responds by continuing to send the idle blocks normally sent during the inter-frame period as called for by IEEE Std 802.3™-2005.
The receiver 112 may respond to the signal 116 by inserting two idle blocks in the data frame. Thus two idle blocks are transmitted when one request to slow down the transmission is received. This permits the sending device 160 to completely halt the sending of data to its receiver 164 while permitting its transmitter 162 to send data in every other codeblock.
The receiver is required to respond to the signal requesting insertion of idle blocks within a predefined period of time after the receiver receives the request to slow down the transmission. The predefined period may be 384 bit times or the time required to send six codeblocks using XGMII. This predefined period establishes the size of buffer required to accommodate characters received until the slowdown request is honored.
The facility provided by the idle blocks with a slow down request may be extended to provide support for multiple sub-rate streams using a 10 Gb/s single data path. The special idle block may also include a stream identifier and a bandwidth factor. The stream identifier may be an eight bit identifier containing a unique number associated with a data stream. The stream identifier may be limited to a range of values such as 1 through 127. The bandwidth factor may be an eight bit ratio number representing the number of idles blocks for every data block. For example, the idle block with a slow down request for stream 1 with a 1:10 bandwidth factor (1 data block and 9 idle blocks) may take this form:
Sync Ob10; Control type 0x55; (ident); (ratio); OxE5;
O-code=0; O-code=0; (ident); (ratio); OxD5
i.e. 0x2—5501—09D5—0001—09E5
It may be noted that a bandwidth factor of 0 means that a single stream uses all available bandwidth to provide a 10 Gb/s stream. The stream identifier can be ignored for a single stream. Thus the example of an idle blocks with a slow down request is a special case of the idle blocks with a slow down request given here.
The idle block with stream identifier and bandwidth ratio, hereafter stream identifier block, according to the present invention is sent during the inter-frame period. At least one stream identifier block may be required to be sent in each inter-frame period. A stream identifier block may be required to be sent periodically during long inter-frame periods, such as at least once for every 128 idle blocks sent.
Additional streams can be defined so that they send data at the times the previously defined streams have defined as being filled with idle blocks. When multiple streams are defined, an “idle block” can be a data block for another stream.
When the available bandwidth is divided into multiple streams by stream identifier blocks, each stream represents an independent data transmission. Each stream will have data frames and inter-frame periods that are not aligned with other streams.
When multiple streams have been defined, the transmitter 112 sends one codeblock chosen from a group consisting of data blocks for the data stream and idle blocks. The transmitter then sends the bandwidth factor number of codeblocks chosen from a group consisting of data blocks for other data streams and idle blocks. It will be appreciated that the mechanisms of inserting an idle block within the data frame if there is insufficient data and in response to idle blocks including a request to slow down may be used with multiple streams.
If a second idle block including a request to slow down the transmission on the first data path is received 204—Yes on a second 10 Gigabit/second data path between the MAC and the PHY, a third and fourth idle blocks are inserted 208 in the data frame in response to receiving the second idle block, such that two idle blocks are transmitted when one request to slow down the transmission is received. The two idle blocks are transmitted within a predefined period of time after receiving the request 204 to slow down the transmission.
The method may provide for sharing a data interface amongst several streams of data by sending a stream identifier block 218 during an inter-frame period between successive data frames. The stream identifier block includes an identifier for a data stream having a net data rate of less than 10 Gigabit/second and a bandwidth factor that indicates a number of codeblocks that will be sent between successive data blocks for the data stream.
Transmitting data in the data frame between the MAC and the PHY for the stream occurs in selected codeblocks 220 as determined by the bandwidth factor. When the stream is designated to send one codeblock 220—Yes, a codeblock is chosen for sending from a group consisting of data blocks for the data stream 206 and idle blocks 208, 210. When the stream is not designated to send a codeblock 220—No, the bandwidth factor number of codeblocks 222 chosen from a group consisting of data blocks for other data streams and idle blocks are sent. Data blocks for other data streams may be considered idle blocks for this stream.
If the receiving device 160 determines that a slowdown of the transmission of data by the transmitter 112 is required 306—Yes, the transmitter 164 of the receiving device 160 inserts an idle block with a slowdown request 308 in the data stream being sent to the receiver 114 of the transmitting device 110. If a slowdown is not required 306—No or after a slowdown request is inserted 308, the receiving device 160 continues to receive additional blocks 300.
While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art.
| Patent | Priority | Assignee | Title |
| 11923978, | May 13 2021 | Marvell Asia Pte Ltd | Multi-port transceiver |
| 8787402, | Jul 22 2006 | Cisco Technology, Inc. | Systems and methods to control flow and to define and interleave multiple channels |
| 9160604, | Mar 12 2013 | Cisco Technology, Inc.; Cisco Technology, Inc | Systems and methods to explicitly realign packets |
| RE46523, | Aug 23 2006 | CAVIUM INTERNATIONAL; MARVELL ASIA PTE, LTD | Method and system for a multi-rate gigabit media independent interface |
| RE48506, | Aug 23 2006 | CAVIUM INTERNATIONAL; MARVELL ASIA PTE, LTD | Method and system for a multi-rate gigabit media independent interface |
| Patent | Priority | Assignee | Title |
| 5953345, | Jun 02 1998 | Cisco Technology, Inc | Reduced pin-count 10Base-T MAC to transceiver interface |
| 6385208, | Jun 02 1998 | Cisco Technology, Inc | Serial media independent interface |
| 6631138, | Jun 02 1998 | Cisco Technology, Inc. | Reduced pin-count 10Base-T MAC to transceiver interface |
| 6741566, | May 08 2000 | Advent IP LLC | Remote management ethernet network and device |
| 6816505, | Feb 09 2000 | MARVELL INTERNATIONAL LTD | Chip-to-chip interface for 1000 BASE T gigabit physical layer device |
| 6980563, | Apr 13 2000 | International Business Machines Corporation | Method and system for fast ethernet serial port multiplexing to reduce I/O pin count |
| 7031258, | Jan 13 2000 | SHENZHEN XINGUODU TECHNOLOGY CO , LTD | Digital data system with link level message flow control |
| 7031333, | Jun 02 1998 | Cisco Technology, Inc | Reduced pin count media independent interface |
| 7177325, | Jul 25 2002 | Microchip Technology Incorporated | Operations, administration and maintenance (OAM) systems and methods for packet switched data networks |
| 7257129, | Nov 22 2000 | UNIVERSAL CONNECTIVITY TECHNOLOGIES INC | Memory architecture with multiple serial communications ports |
| 7418514, | Feb 21 2003 | CAVIUM INTERNATIONAL; MARVELL ASIA PTE, LTD | Multi-speed serial interface for media access control and physical layer devices |
| 7664134, | Sep 23 2003 | AVAGO TECHNOLOGIES GENERAL IP SINGAPORE PTE LTD | Programmable Q-ordered sets for in-band link signaling |
| 7719970, | Aug 20 2004 | Altera Corporation | Serial communications system with optional data path and control plane features |
| 20010014104, | |||
| 20020126684, | |||
| 20020191603, | |||
| 20030188026, | |||
| 20030217215, | |||
| 20040022238, | |||
| 20040123190, | |||
| 20040202198, | |||
| 20050019036, | |||
| 20050102419, | |||
| 20050163149, | |||
| 20050259685, | |||
| 20060109784, | |||
| 20060268938, | |||
| 20070047572, | |||
| 20070110103, | |||
| CN1522522, | |||
| WO2008014145, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Jul 22 2006 | Cisco Technologies, Inc. | (assignment on the face of the patent) | / | |||
| Aug 10 2006 | BARRASS, HUGH | Cisco Technology, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 018130 | /0201 |
| Date | Maintenance Fee Events |
| Mar 04 2016 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Mar 04 2020 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Mar 02 2024 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
| Date | Maintenance Schedule |
| Sep 04 2015 | 4 years fee payment window open |
| Mar 04 2016 | 6 months grace period start (w surcharge) |
| Sep 04 2016 | patent expiry (for year 4) |
| Sep 04 2018 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Sep 04 2019 | 8 years fee payment window open |
| Mar 04 2020 | 6 months grace period start (w surcharge) |
| Sep 04 2020 | patent expiry (for year 8) |
| Sep 04 2022 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Sep 04 2023 | 12 years fee payment window open |
| Mar 04 2024 | 6 months grace period start (w surcharge) |
| Sep 04 2024 | patent expiry (for year 12) |
| Sep 04 2026 | 2 years to revive unintentionally abandoned end. (for year 12) |