RE: [EFM] Clause 45 major work and format overhaul
Scott,
I (and the rest of the team here) will take care of your item #3 here below.
Bernard Debbasch
GlobespanVirata, Inc.
Tel: + 1 (949) 737 4325
Fax: + 1 (949) 737 4303
mailto:bdebb@globespanvirata.com
-----Original Message-----
From: Scott Simon [mailto:ssimon@cisco.com]
Sent: Thursday, May 22, 2003 10:21 AM
To: stds-802-3-efm-copper@ieee.org; stds-802-3-efm@ieee.org
Subject: [EFM] 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 sibmission 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 sibscriber 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 sibtypes. 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--------------
******************Legal Disclaimer**************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email @globespanvirata.com, and delete the message. Thank you."
****************************************************************