Method for exchanging information with physical layer component registers

A device and a method for exchanging information with registers of a physical layer component. The method includes allocating at least one receive buffer for receiving the status information; associating at least one receive buffer descriptor with the at least one receive buffer; sending to a physical layer component a request to read status information stored in a selected status register of the physical layer component; and writing the status information to the at least one receive buffer descriptor.

FIELD OF THE INVENTION

The invention relates to a method for exchanging information with physical layer component registers and especially with status and control registers of physical layer component and a device having control and status information exchanging capabilities.

BACKGROUND OF THE INVENTION

In today's communications, digital networks transport large amounts of information. Network services can be, for example, traditional voice phone, facsimile, television, audio and video broadcast, and data transfer.

Buffers and buffer descriptors are used to convey data. Buffers store data to be transmitted or received while buffer descriptors point to these buffers. Various examples of data transmission devices and methods using buffer descriptors are illustrated in the following U.S. patents and patent applications, all being incorporated herein by reference: U.S. Pat. No. 6,212,593 of Pham et al., U.S. Pat. No. 6,735,210 of Lindeborg et al., U.S. Pat. No. 6,154,460 of Kerns et al., U.S. Pat. No. 6,298,396 of Loyer et al., U.S. patent application 2004/0073724 of Wilson et al., U.S. patent application 2002/0176430 of Sangha et al., U.S. patent application 2005/0243816 of Wrenn et al., U.S. patent application 2005/0093885 of Savekar et al., U.S. patent application 2005/0068956 of Liao et al., and U.S. patent application 2002/0161943 of Kim.

Various communication protocols as well as various management protocols were developed in order to support a variety of services and configurations.

The IEEE defined two management interface named MII management and GMII management that use a two-wire serial interface to connect between a management entity and managed physical layer (PHY) components. GMII can support faster communication protocols than the MII. An exemplary device that includes such a serial interface is described in PCT patent application publication serial number WO 01/17166 of Kalapatapu which is incorporated herein by reference.

Each PHY component has multiple registers that can be accessed by using the MII management or GMII management interface. These registers can be accessed in order to control the PHY components and gathering status from the PHY components.

The management interface includes a pair of signals (clock and information signals), a management frame, a set of registers that can be read and written using the management frames, and a protocol specification that defines the manner in which the management frame is transferred between the management entity and the PHY components. The basic (mandatory) set of registers of the MII management includes a control register and a status register. The MII management and the GMII management use the same management frames and use the same signals. The GMII management includes an additional basic register that is referred to as extended status register.

The control register is known as register0. The status register is known as register1. The extended status register is known as register15. Registers2-10belong to an extended register set. This extended register set includes PHY identifier registers (registers2and3), auto-negotiation advertisement register (register4), auto-negotiation link partner base page ability register (register5), auto-negotiation expansion register (register6), auto-negotiation next page transmit register (register7), auto-negotiation link partner received next page register (register8), MASTER-SLAVE control register (register9) and MASTER-SLAVE status register (register10).

FIG. 1andFIG. 2illustrates the content of control register10, status register30and the extended status register50.

Control register10includes the following fields: reserved (not used) field11, speed selection fields (LSB and MSB)12and19, collision test enable field13, duplex mode field14, restart auto-negotiation field15, isolate field16, power down field17, auto-negotiate enable field18, loopback field20and reset field21. These fields control the manner in which the PHY component operates.

Extended status register50includes the following fields: 1000BASE-T half duplex field51, 1000BASE-T full duplex field52, 1000BASE-X half duplex field53and 1000BASE-X full duplex field54. It also includes reserved bits (not shown).

Fields31-54indicate the status of the PHY component. For example, they indicate the communication protocols it supports and the state of an auto-negotiation session conducted with that PHY component.

A single communication controller may be required to write control information to physical layer component control registers and also to read status information from physical layer component status registers. One method for doing it involved polling the status register and control registers and determining whether data can be transferred, as well as using dedicated registers within a register file to save parts of the status information or control information. Registers are more expensive than simple memory unit entries. Accordingly, using registers was resource consuming.

The polling method required a lot of processor intervention in order to know when the access is done so valid data can be read.

FIG. 3illustrates a management frame80. Management frame8C is serially transferred over a first line while a second line is used to convey a clock signal. Multiple physical layer components are connected in parallel to the information line and to the clock line.

The management frame80starts by a preamble field81(can be thirty two bits long) that is followed by a two bit long start of frame indication82(value of ‘01’), a two bit long opcode83that indicate if the frame is being transferred during a read operation (from the register of the physical layer component to the management entity) or a write operation, a five bit long physical layer component address84, a five bit long register address85, a two bit long turnaround field86, and a two-byte long data field87.

The complexity of status information and control information management increases as the number of physical layer registers increase.

There is a need to provide an efficient method and device for reading status information from status registers of physical layer components.

SUMMARY OF THE PRESENT INVENTION

A method for exchanging information with physical layer component registers and a device having control and status information exchanging capabilities, as described in the accompanying claims.

DETAILED DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention illustrated in the accompanying drawings provide a method. The method includes: allocating at least one receive buffer for receiving the status information; associating at least one receive buffer descriptor with the at least one receive buffer; sending to a physical layer component a request to read status information stored in a selected status register of the physical layer component; and writing the status information to the at least one receive buffer descriptor.

Embodiments of the present invention illustrated in the accompanying drawings provide a device. The device includes a serial peripheral interface that is adapted to send to a physical layer component a request to read status information stored in a selected status register of the physical layer component. The device is also adapted to: allocate at least one receive buffer for receiving the status information; associate at least one receive buffer descriptor with the at least one receive buffer; write the status information to the at least one receive buffer descriptor.

FIG. 4illustrates a communication device100, according to an embodiment of the invention.

Communication device100includes a first processor, such as general-purpose processor180, a security engine170, system interface unit140, communication engine200and multiple ports (not shown). Components180,170,140and200are connected to each other by central bus190.

The general-purpose processor180can include multiple execution units such as but not limited to an integer unit, a branch processing unit, a floating point unit, a load/store unit and a system register unit. It can also include various cache memories, dynamic power management unit, translation look aside buffers, and the like.

The general-purpose processor180controls the communication device100and can execute various programs according to the required functionality of communication device100. The general-purpose processor180can be a member of the PowerPC™ family but this is not necessarily so.

The security engine170can apply various security mechanisms including encryption based mechanisms and the like.

Communication device100can be connected to multiple memory units as well as other components. These components are interfaced by system interface unit140. System interface unit140may include some of the following components: external memory controllers142, external DDR interface unit144, PCI bridge146, local bus148, bus arbitrator150, Dual UART unit152, dual12C unit154, a four channel DMA156, interrupt controller158, protection and configuration unit160, system reset unit162and clock synthesizer164. It is noted that other interfacing components can be used.

FIG. 5illustrates a communication engine200, according to an embodiment of the invention.

It is noted thatFIG. 5illustrates an embodiment of the invention and that other communication engines (including those who have a single processor or more that two processors) can be used.

The communication engine200is a versatile communication component that can manage multiple communication ports that operate according to different communication protocols. It includes two RISC processors220and222that can work substantially independently from each other.

The communication engine200includes two RISC processors220and222, DMA controller210, a shared data RAM memory unit230, a shared instruction RAM memory unit232, eight universal communication controllers denoted UCC1-UCC8241-248, one multi-channel communication controller (MCC)251, two serial peripheral interfaces denoted SPI1-SPI2252-253, two UTOPIA POS controllers261and262, two time slot assigners264and266and two communication interfaces270and274. Time slot assigner264assigns time slots for accessing communication interface270. Time slot assigner266assigns time slots for accessing communication interface274.

Each of the serial peripheral interfaces is adapted to manage transmissions and receptions of data, status information and control information between the communication engine200and other components (such as PHY components) using serial communication protocols.

The first communication interface270is connected to multiple time division multiplex (TDM) ports that are collectively denoted271, a UTOPIA-packet over SONET (POS) port272, as well as four RMII ports collectively denoted273, and four NMSI ports collectively denoted274.

The second communication interface274is connected to another UTOPIA-packet over SONET (POS) port275, four RMII ports collectively denoted276, and four NMSI ports collectively denoted274. It is noted that other communication protocols can be supported by communication device100.

Each RISC processor out of220and222can access the shared data RAM memory unit230and the shared instruction RAM memory unit232. RISC processor220can control half of the multiple communication controllers and ports. For example, RISC processor220can control UCC1-UCC4241-244, MCC251and SPI1252. It can also communicate with UTPOIA POS controller260and time slot assigner264.

Conveniently, a UCC can support the following communication protocols and interfaces (not all simultaneously): 10/100 Mbps Ethernet, 1000 Mpbs Ethernet, ATM protocol via UTOPIA interface, various types of HDLC, UART, and BISYNC.

Conveniently, MCC251supports two hundred and fifty six HDLC or transparent channels, one hundred and twenty eight SS#7 channels or multiple channels that can be multiplexed to one or more TDM interfaces.

In addition, the communication engine200can include a controller (not shown) as well as an interrupt unit that coordinates the various components of the communication engine, as well as to enable the communication engine200to communicate with general-purpose processor110, security engine62and system interface unit140.

The first RISC processor220is connected to a first hardware accelerator223. The first hardware accelerator223can access the shared data RAM memory unit230. The second RISC processor222is connected to a second hardware accelerator224.

The DMA controller210is connected to an external memory unit212.

FIG. 6illustrates an exemplary configuration of communication device100, and its environment, according to an embodiment of the invention.

Communication device100is illustrated as supporting a data path of a DSL line card302. This DSL card302, as well as many other DSL line cards can belong to a DSLAM.

Line card302also includes two DDR DRAM units310and310, as well as a flash memory unit330, all being connected to communication device100via the system interface unit140.

The communication engine200is configured as an xDSL line card and is connected to multiple Ethernet PHY components330and332, as well as to an ADSL PHY component340. The communication device100supports ATM multi-PHY subscriber lines and an Ethernet uplink.

FIG. 7illustrates a serial peripheral interface (SPI1)252, according to an embodiment of the invention. It is assumed that SPI2is equivalent to SPI1and that each serial peripheral interface operated independently.

SPI1252includes an SPI register file430, a SPI controller440, a transmit path (TX path)450, a reception path (RX path)460, a shift register470and a pins interface480. It can access a parameter data structure540.

The SPI controller440executes commands and can perform various read and write operations, and especially capable of transmitting and receiving data, control information and status information over serial lines such as MDC482and MDIO482.

MDC482is a serial clock output signal. MDIO482is serial data line.

The SPI controller440is connected to the SPI register file430, to TX path450and to RX path460. The shift register470is used to perform serial to parallel conversions and parallel to serial conversions. It is controlled by the SPI controller440. The shift register470is connected to the TX path450, to the RX path460and to the pins interface480.

The TX path450and the RX path460can receive or transmit information from/to the multiple bit bus that is connected to first RISC processor220. They can also send/get data to/from the shift register that in turn sends/gets the data in a serial manner via pins interface480.

Conveniently, the SPI register file430is accessed by general purpose processor180. It includes various registers such as SPI command register420and SPI mode register400. The SPI command register430includes reserved bits422and a start transmit instruction field412.

The SPI mode register400includes the following fields: (i) Emergency request (EM) field401that is used to indicate that an emergency request should be sent to RISC230, (ii) LOOP field402that indicates if the SPI operates normally or whether the RX path and the TX path form a closed loop; (iii) Clock invert (CI) field403indicating what is the inactive state of MDC, (iv) Clock phase (CP) field404indicating whether the serial clock signals starts to toggle at the beginning or during the middle of the data transfer, (v) DIV16field405indicating the baud rate of the clock signal, (vi) data order (REV) field406indicating whether the least significant bit or the most significant bits of data are received or transmitted first, (vi) Master/slave (M/S) field407that indicates if the SPI operates in slave more or in master (or MII) mode, (vii) Enable (EN) field408that indicates if the SPI is enabled, (viii) character length (LEN) field409, (ix) clock pre-scale division (PM) field410, (x) Operational mode (OP) field411indicating if the SPI1is controlled by the general purpose processor180or the first RISC processor230, (xi) MII mode (MII) field412indicating if the SPI operates in MII mode or in normal (data) SPI mode, and (xii) Clock gap (CG) field412indicating the gap between two consecutive characters.

FIG. 8illustrates various data structures540-589, according to an embodiment of the invention.

The various data structures illustrated inFIG. 8includes parameter data structure540(stored in shared data RAM memory unit230), a receive buffer descriptor table550, a transmit buffer descriptor table560, multiple transmit buffers (collectively denoted580) and multiple receive buffers (collectively denoted570).

Transmit buffers such as TX BUFFERs581-589can store data or control information. At least one transmit buffer can be located in external memory units such as external memory unit212while at least one other transmit buffer can be located in an internal memory unit such as shared data RAM memory unit230.

Receive buffers such as RX BUFFERs571-579can store data or status information. At least one receive buffer can be located in external memory units such as external memory unit212while at least one other receive buffer can be located in an internal memory unit such as shared data RAM memory unit230.

Each receive buffer is associated with a receive buffer descriptor. RX BUFFERs571-579are associated with RX_BDs551-559. Each transmit buffer is associated with a transmit buffer descriptor. TX BUFFERs581-589are associated with TX_BDs561-569.

Each receive buffer descriptor includes a frame status field, a data length field and a buffer pointer. For example, RX_BD551includes a frame status field551(1), data length field551(2) and buffer pointer field551(3). Frame status field551(1) indicates whether the buffer is full, is BD_RX551the last buffer descriptor of table550, whether to generate an interrupt in response to the state of the buffer, whether the buffer contains the last character of a message, if the buffer had overrun and the like. Data length field551(2) indicates the length of received data. Buffer pointer field551(3) stores a pointer to RX BUFFER571.

Each transmit buffer descriptor includes a frame status field, a data length field and a buffer pointer. For example, TX_BD569includes a frame status field569(1), data length field569(2) and buffer pointer field569(3). Frame status field569(1) indicates whether the buffer is ready for transmitting, if TX_BD569the last buffer descriptor of table560, whether to generate an interrupt in response to the state of the buffer, whether the buffer contains the last character of a message, if the buffer had underun and the like. Data length field569(2) indicates the length of data to be transmitted from the buffer. Buffer pointer field569(3) stores a pointer to TX BUFFER589.

The parameter data structure540includes multiple entries such as RBASE441, TBASE442, RX BUS MODE443, TX BUS MODE444, MRBLR445, RBPTR446and TBPTR447.

RBASE441is the base address of receive buffer descriptor table550. TBASE442is the base address of transmit buffer descriptor table560. RX BUS MODE443and TX BUS MODE444are bus mode register that store transition specifications associated with DMA accesses to external memories such as memory unit212. These accesses are conveniently made via the bus that is also connected to the first RISC processor230.

MRBLR445is the maximal receive buffer length. This value does not affect the length of the transmit registers. RBPTR446points to the current receive buffer descriptor (from table550) that is being used or to the next receive buffer descriptor to be serviced when the SPI is idle. Its value can be initialized to RBASE (or indicate zero offset from RBASE). It can be an offset from RBASE.

TBPTR447points to the current transmit buffer descriptor (from table560) that is being used or to the next transmit buffer descriptor to be serviced when the SPI is idle. Its value can be initialized to TBASE (or indicate zero offset from TBASE). It can be an offset from TBASE.

Up to thirty-two PHY components can be connected in parallel to MDC481and MDIO482. Each PHY component can include up to thirty-two registers. Thus, five bits are required to select between the PHY components and five bits are required to select between the registers of the selected PHY component.

The following example will further illustrate the various stages that are executed when device100wishes to read status information from a certain status register of a certain PHY register. It is assumed that the status register is register1, that the PHY component is the third PHY component connected to device100, that RX BUFFER571, RX_BD551, TX BUFFER581and TX_BD561participate in the reception process, that the address of RX BUFFER571is 0x000—1000, that the address of TX_BUFFER581is 0x0000—2008, and that two status bytes are read from the status register of the third PHY component.

When device100wishes to read the content of a certain status register of a certain PHY component that is connected to SPI1252it performs the following stages: (a) Configure pins interface480to enable MDC481and MDIO482. (b) Write TBASE and RBASE to the parameter data structure540. (c) Configure the bus mode registers, RX BUS MODE443and TX BUS MODE444. (d) Set MRBLR445to four bytes (size of MII management frame). (e) Initialize the frame status field555(1), data length field551(2) and set buffer pointer field551to point to 0x000—1000. (f) Initialize the frame status field, data length field and set buffer pointer field of TX_BD561. The buffer pointer field points to 0x000—2008. (g) Write fields81-85of frame80to TX BUFFER581. The preamble field81is thirty bits long. The value of fields82-85can be: 01 (start of frame82), 11(read operation, two-bit long opcode field83), 00011 (third PHY component, five bit PHY address field85), 00001 (register1, five bit register address field85), and eighteen bits that are irrelevant (don't care) in fields86and87. (h) writing a predefined value to SPI mode register400such as to indicate that SPI1252operates in a MII mode, operates as a master, sets the clock rate. (i) writing a start transmit command to SPI command register420.

It is noted that some of the mentioned above stages are optional.

When these stages are executed the SPI will transmit the first portion of frame80to the physical layer devices, wait after the TA period expired and then receive the status information from register1of the third PHY component and store it at RX BUFFER571. The relevant status information includes the last two bytes. TX buffer581is used to transmit the request to receive the status information.

The timing of the status read operation can be easily controlled by writing the appropriate instructions to the SPI at the required timing.

FIG. 9illustrates method600according to an embodiment of the invention.

Method600starts by stage610of allocating at least one receive buffer for receiving the status information. Referring to the example set forth in previous drawings, the number of allocated receive buffers is responsive to the length of the received buffer and to the length of data that is supposed to be received. Typically, the buffers are implemented in a memory units, thus they can be larger and even much larger than two bytes.

Stage610is followed by stage620of associating at least one receive buffer descriptor with the at least one receive buffer. This conveniently includes setting a pointer from a buffer descriptor to a corresponding buffer. Typically, each buffer is associated with a single buffer descriptor.

Stage620is followed by stage630of allocating at least one transmit buffer for transmitting the request. Referring to the example set forth in previous drawings the SPI transmits the beginning of the transmission frame, thus the beginning of the frame can be stored in a transmit buffer.

Stage630is followed by stage640of associating at least one transmit buffer descriptor with the at least one transmit buffer. This conveniently includes setting a pointer from a buffer descriptor to a corresponding buffer.

Stage640is followed by stage650of defining a timing of the request to read status information. The definition can be responsive to events, to a predefined status checking policy, and the like. By including status read instructions that initiate the reading of status from the status registers within a code that is executed by either one of the RISC processors230and232, the general purpose processor180, or even the SPI252the timing of the read instruction can be easily defined.

Stage650is followed by stage660of fetching a status read instruction. The fetching is part of the execution of the previously mentioned code.

Stage660is followed by stage670of sending to a physical layer component a request to read status information stored in a selected status register of the physical layer component. The request can be included within the beginning of a frame.

Stage670is followed by stage680of writing the status information to the at least one receive buffer descriptor.

Method600can also includes stage710of allocating at least one receive buffer for receiving the data. Stage710is followed by stage720of associating at least one receive buffer descriptor with the at least one receive buffer. Stage720is followed by stage780of writing the data to the at least one receive buffer descriptor.

Conveniently, method600further includes stage810of writing control information from a register within the management entity to control information of the physical layer component.

It is noted that stages710-780as well as stage810can be executed before or after stages610-680.

FIG. 10is a flow chart of method810, according to an embodiment of the invention.

Method810can be executed as a part of method600or can be executed independently from method600.

Method810starts by stage812of associating at least one transmit buffer descriptor with the at least one transmit buffer. This conveniently includes setting a pointer from a buffer descriptor to a corresponding buffer. Typically, each buffer is associated with a single buffer descriptor.

Stage812is followed by stage813of allocating at least one transmit buffer for transmitting control information. Referring to the example set forth in previous drawings, the number of allocated transmit buffers is responsive to the length of the transmit buffer and to the length of control data that is going to be transmitted. Typically, the buffers are implemented in a memory units, thus they can be larger and even much larger than two bytes.

Stage813is followed by stage814of defining a timing of the transmission of control information. The definition can be responsive to events, to a predefined status checking policy, and the like.

Stage814is followed by stage815of fetching a control write instruction. The fetching is part of the execution of the previously mentioned code.

Stage815is followed by stage816of sending to a certain control register of a certain physical layer component control information, using the at least one transmit buffer.