Re: [STDS-802-3-EPOC] On PHY registers and MIB modules
I have heard some express the opinion that the MDIO/MDC
register space is severely limited. I agree that the address space is finite,
but there are many ways to get around this limitation.
When we originally defined the MDIO/MDC register space in
Clause 22, there were only 32 register addresses available.
16 of them were defined or reserved for future definition
by the IEEE 802.3 standard, and 16 were available for vendor
definition. Clause 45 introduced the ability to perform register
indirect addressing (what us old bit-bangers called double
clutching).
First you write the address of the register that you want to access into
a special register location, and then you can read or write to that indirectly
addressed register.
One can take this a step farther, and while I am not offering a specific
proposal, I will offer an example for illustrative purposes.
Suppose that you have a whole slew of OFDM subcarriers, and you want
to keep track of some statistics or control information for each subcarrier.
This could add up to a large number (many thousands) of MDIO/MDC
registers, which would burn up a lot of MDIO/MDC address space.
So, we could take the register-indirect addressing concept a step farther,
and define a subcarrier index register (I am not going to define the syntax
of this register in any greater detail at this time) that would point to a
given subcarrier. A group of subcarrier statistics and/or control registers
would then be defined, and the contents of these registers would be
correspond to the values for the indexed subcarrier.
In this fashion, the number of MDIO/MDC addresses that must be
allocated to keeping statistics per subcarrier can be kept to a
minimum, while the amount of per subcarrier information that can be stored in the
EPoC PHY and accessed via MDIO/MDC would be limited only by the
amount of silicon area that we are willing to devote to register storage in the PHY.
{Historical perspective: One of the main reasons that we defined
an address space of only 32 registers in the original MDIO/MDC specification
was because PHY designers were worried about burning too many gates
on management registers. 512 bits! Wow! Any more address space
and people would have voted against including MDIO/MDC at all. I kid you not.}
At some point, we will also need to concern ourselves with the data
transfer rate across MDIO/MDC, but that's a subject for another message.
Howard
From: Howard Frazier [mailto:hfrazier@xxxxxxxxxxxx]
Sent: Monday, February 18, 2013 2:20 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-3-EPOC] On PHY registers and MIB modules
I felt that I should weigh in on the topic of Clause 45 management
registers and MIB module object definitions. Please excuse the
lengthy email.
There are two ways defined within IEEE Std 802.3 to pass physical layer
statistics to upper layers and/or management. One is across the xMII
(a generic term coined by 802.3bf for any variation of the MII), and the
other is across MDIO/MDC.
The xMII contains receive error indicators (RX_ER in the case of MII/GMII,
Receive Error encoding of RXC/RXD in the case of XGMII) that are used
to indicate the occurrence of receive error events that are detected in
by the PHY, but which might not be detected in the MAC. These indications
can be counted "above" the xMII. In addition, statistics such as octets
received/transmitted, frames received/transmitted, unicast frames received/
transmitted, broadcast frames received/transmitted, multicast frames
received/transmitted, frames too long/frames too short received/transmitted,
may all be counted "above" the xMII.
Other PHY layer statistics are generally maintained in the PHY, and conveyed
to Station Management via MDIO/MDC. MDIO/MDC is very rigidly defined,
including electrical and timing parameters, as well as the framing protocol, the
register map, and the bit definitions for both control and status registers.
The MDIO/MDC register definitions are intended to give hardware designers
a concrete set of requirements for their design specifications. Basically, anything
that the PHY is supposed to detect and report to management, and anything that
management is supposed to be able to control within the PHY, must be defined
within the MDIO/MDC register space.
This can (and has, in the case of the EFM Copper PHYS, 10PASS-TS and 2BASE-TL)
include a set of statistics and/or control functions for a link partner PHY.
Recognizing that hardware resources can be limited, we have traditionally followed
a few guidelines when specifying Clause 45 MDIO/MDC registers:
1) Keep counter lengths to a reasonable size. MDIO/MDC is a polled interface,
so make the counter lengths long enough to reduce the polling rate,
while ensuring that they won't wrap between polling cycles. However,
much longer counters can be maintained by Station Management.
2) Don't count statistics that can be derived (using some known algorithm) from
other statistics. Leave it up to Station Management to perform the algorithm to
derive statistics from other available information whenever possible.
(i.e. no gratuitous math in the PHY, they must do enough math these days as it is!)
3) Do provide a generous amount of control and status information, but only
the information that is essential for interoperability and the desired level of
configurability. There are a nearly endless number of controls or statistical items
that can aid in debugging, but unless they are essential for interoperability between
the ends of a link, they should be left for vendors to define.
4) When specifying local copies of link partner statistic and control items, include only
those that must be accessible when an operational link (that can transport MAC frames)
is not available.
5) Remember that there are no "interrupt signals" across the xMII! The Station Management
Entity (abbreviated STA) can detect critical events or conditions by polling registers via
MDIO/MDC, but there is no asynchronous event signal.
Now, a few words about MIB modules: MIB modules, such as those defined in IEEE Std 802.3.1, are
intended to be used with the Simple Network Management Protocol (SMNP). They usually contain
object definitions for all of the statistics and controls that are provided by the hardware in each of
the sublayers (e.g. MAC Control, MAC, PHY [or MAU in management speak]) of a given interface.
MIB modules can also contain statistics that are derived from other statistics (see 2, above) and can
also contain actions (control functions) and notifications (warning or error messages). The objects in
a MIB module can be defined as read-only, read-write, or not-accessible. You can have tables of
objects with various indices. You can have a variety of object syntaxes, such as Boolean (TruthValue),
INTEGER, Integer32, Counter64, and you can define your own data types (e.g. dot3OUI). You can
have a rich and comprehensive set of link partner statistics, including link partner statistics that
are obtained through low-level PHY link signaling, as well as link partner statistics that are obtained
by the exchange of MAC frames (such as OAM or LLDP frames).
Think of it this way: The Clause 45 registers accessible via MDIO/MDC constitute a specification for
the hardware designers, while the MIB modules defined in 802.3.1 constitute a specification for the
software designers.
In the past, we followed the philosophy that "Management has pervasive access to all status and
control information in all sublayers, whether or not there were explicit interfaces between management
and those sublayers". For sublayers above the xMII, this is still true, but for sublayers below the xMII,
we now recognize that there must be a standard mechanism for accessing the status and control
information, and that it must be presented in a standard format. MDIO/MDC provides the access
mechanism, while the Clause 45 register definitions provide the format.
Another few words about MIB modules and IEEE Std 802.3.1: My plan of record for 802.3.1 is to revise
it whenever the 802.3 standard undergoes a revision, and to amend it if a particular project in 802.3
justifies an amendment (e.g. if it needs a new MIB module, or dramatic changes to an existing module).
I think that a good case can be made for introducing a new EPoC PHY MIB module, so that
SNMP could be used to manage this new PHY, which may well have a substantial set of new objects.
This would be similar to what was done for the EFM Copper PHYs, the MIB module for which is
provided in Clause 11 of IEEE Std 802.3.1. This amendment to 802.3.1 can be started later in the
process of 802.3bn, perhaps once it is in sponsor ballot, and the set of managed objects in the EPoC
PHY is well defined and stable.
I hope this is helpful.
Howard Frazier
Broadcom Corporation
chair and editor of IEEE Std 802.3u Clause 22 (which defined MDIO/MDC)
contributor to IEEE Std 802.3ae Clause 45
chair and editor of IEEE Std 802.3.1 MIB definitions for Ethernet
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1