[EFM] Forwarded from Scott Simon
Scott used a reserved word. Can you guess which one?
Howard
-------- Original Message --------
Subject: Clause 45 major work and format overhaul
Hi All,
It's Scott Simon, your plucky Clause 45 editor here to clue you in on
all the exciting things happening in Clause 45 for the next draft. I've
sent this to the entire TF because I need the help of all the management
and logic heads in the group to review the draft and make comments.
Anyone who will be implementing 802.3ah Copper PHYs will also want to
pay attention. Feedback would be appreciated.
This is a LONG email. If you find a section you are not interested in,
please skip to the next one. There is likely something you care about
below it. Make this email window really wide if you can, it will
improve the formatting.
Here's a list of the major work to be done on Clause 45:
1) Fill out the 2BASE-TL registers. At the end of Clause 45, you'll
notice an editor's note that lists several registers that were commented
into the draft, but never defined.
Matt Squire has valiantly volunteered to perform this mighty task.
Thanks Matt!
2) Generate a PICS. It is my intention to do the PICS as a comment
against D1.732, reflecting the changes to the draft that we are
currently working on. The text for the PICS will be available by the
comment submission deadline.
3) Add lots of new MCM registers. Thanks, to Bernard for writing the
text for these. You'll see the new register bits in the next draft.
Unfortunately, I don't know what most of these bits do. I need a
volunteer to write detailed descriptions for the behavior of these bits
and to provide references in Clause 62 for their associated functions.
This needs to be in to me by Sunday night, or else the new MCM registers
will end up looking like the 2BASE-TL registers currently do in the
editor's note at the end of 45.6.1.
TX Window Length
FFT/IFFT Size
Tone Spacing Select
Tx/Rx PSD Mask selector for PBO
Reference PSD
I
Detailed Interleaver Setting Descriptor 1 US/DS
Q
Detailed Interleaver Setting Descriptor 1 US/DS
Mmin
Detailed Interleaver Setting Descriptor 1 US/DS
Mmax
Detailed Interleaver Setting Descriptor 1 US/DS
I
Detailed Interleaver Setting Descriptor 2 US/DS
Q
Detailed Interleaver Setting Descriptor 2 US/DS
Mmin
Detailed Interleaver Setting Descriptor 2 US/DS
Mmax
Detailed Interleaver Setting Descriptor 2 US/DS
I
Detailed Interleaver Setting Descriptor 3 US/DS
Q
Detailed Interleaver Setting Descriptor 3 US/DS
Mmin
Detailed Interleaver Setting Descriptor 3 US/DS
Mmax
Detailed Interleaver Setting Descriptor 3 US/DS
I
Detailed Interleaver Setting Descriptor 4 US/DS
Q
Detailed Interleaver Setting Descriptor 4 US/DS
Mmin
Detailed Interleaver Setting Descriptor 4 US/DS
Mmax
Detailed Interleaver Setting Descriptor 4 US/DS
EoC bytes/frame in US/DS
VoC bytes/frame in US/DS
4) Reorganize the "Remote" and "local" registers into separate MMDs.
This is a big one, it's largely an editorial change, but we would be
technically introducing a new MMD. This is all my own idea -- I
realized while working on D1.732 that the registers are getting out of
control and a better organization would greatly clean up the draft and
help remove some confusion. Keep in mind that my point here is not to
change the functionality of the registers, just to give them a better home.
If you read 45.1 in D1.732, you'll see that we're introducing the concept
of "Remote" registers. These registers allow the central office STA to
mananage a PHY at the customer premise. Currently, the "Remote"
registers are defined as part of the PMA/PMD MMD (#1) and their
definitions and tables are carbon copies of the "Local" versions of
these registers.
In D1.732, C45 has about 44 new registers pertaining to SCM management,
12 of these are "local" registers, with their corresponding 12 "remote"
registers. That means that there's 12 registers with essentially
duplicate registers and text. This is becoming unwieldy.
Furthermore, the current system is confusing. The "Remote" registers
live on the central office PHY, but take action on the customer PHY.
With both local and remote registers in the same MMD, it becomes
difficult to describe their relationship.
Below is a proposal. PLEASE read it and respond about giving the editor
(Scott Simon) license to make the changes in time for D1.732 to be
published. The changes are mostly editorial except for the general
concept of moving the "Remote" registers into the new MMD.
Thanks to everyone who is reading, commenting and thinking about how to
make Clause 45 a better text for everyone!
-=Scott
-------------Propsal for Cleaning up Clause 45-----------------------
1) Create a a new MMD, numbered 6, named "Remote PMA/PMD"
2) Change the text in 45.1 to describe:
"for $ub$criber network PHYs 10PASS-TS and 2BASE-TL, we have added a new
MMD, #6. MMD #6 is only defined for the 10PASS-TS-O and 2BASE-TL-0 port
subtypes. Some registers defined for MMD #1 have duals defined also in
MMD #6--when this is the case, it shall be noted in the register
description for the MMD #1 register. Registers in MMD #6 correspond to
parameters that influence the behavior of the link partner (10PASS-TS-R
or 2BASE-TL-R) PHY. . . etc. etc.
"The registers in MMD #6 have the same address as their dual in MMD #1.
For example, if the -O STA wants to configure the constellation on both
the -O and link partner -R, it would first write to register 3.xx and
then write to register 6.xx. Editor's note: xx to be replaced with the
same number once it is determined"
This should help to clear up the confusion about where the "remote"
registers live. They live on the -O port, but are in a new MMD to
indicate that they are really referring to the -R link partner.
3) Remove all the "Remote" registers from Clause 45. Change the bit
definitions of the "local" registers to describe their presence and
behavior in MMD #6.
4) Create a register 6.0 defined at "Remote PMA/PMD control". Bits in
this register correspond to the behavior of the current "Remote
Parameter Activate register" (45.4.1.1 in D1.732) and have to be
changed anyway to reflect all of the new controls we've added. The
description of the register bits changes to reflect the fact that the
controls that we're activating now live in MMD #6. The bits become:
6.0.15 "Retrieve link partner parameters"
instructs the -O PHY to update all other MMD #6 registers with values from
the -R PMA/PMD
6.0.14 "Retrieve link partner parameters result"
indicates if the 6.0.15 operation was sucessful
6.0.13 "Send link partner parameters"
instructs the -O PHY to send the contents of all other MMD #6 registers to
the -R PMA/PMD
6.0.12 "Send link partner parameters result"
indicates if the 6.0.13 operation was sucessful
6.0.11 "Activate link partner parameters"
instructs the -O PHY to instruct the -R PMA/PMD to begin using parameters
sent with 6.0.13
6.0.10 "Send link partner parameters result"
indicates if the 6.0.11 operation was sucessful
5) Add more text in 45.1 to describe:
"Register access to MMD #6 behaves the same as access to any other MMD.
However, the results of accesses are different. Because the the
behavior controlled by MMD #6 is not on the -O PMA/PMD, the -O PMD/PMD
needs to retrieve read values and to send written values to the -R link
partner. Register 6.0 allows the -O STA to control when values are sent
and received. In other words, a read to MMD #6 does not necessarirly
reflect the current state of the parameters on the -R, nor does a write
to MMD #6 immediately change the behavior of the -R.
"If the STA writes to an MMD #6 paramater register, the written value
shall be returned upon a read to that register. If the STA issues a
"Retrieve link partner parameters" command via register bit 6.0.15 and
that command completes successfully (register bit 6.0.14), then reads to
an MMD #6 parameter register shall reflect the parameters as retreived
from the -R PMA/PMD."
"The STA uses the "Send link partner parameters" command (register bit
6.0.13) to transmit the parameters, as they are currently set in MMD #6,
to the -R PMA/PMD. When this command completes sucessfully (register
bit 6.0.12), the -R has loaded the new parameters."
"The STA uses the "Activate link partner parameters" command (register bit
6.0.11) to have the -O PMA/PMD instruct the -R PMA/PMD to begin using
parameters that have changed as a result of the "Send link partner
parameters" command.
6) Create a few diagrams to show the architecture and procdure for using
MMD #6
7) Make a pretty table summarizing which registers in MMD #1 have their
duals in MMD #6
Except for the creation of the new MMD and register 6.0, these changes
are all editorial. If this sounds complicated, it is. It's actually
simpler in organization than the current C45 though, and more scalable,
too if we add PHYs with this capability in the future.
-------------------End of Proposal--------------