Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] Forwarded from Scott Simon




"L I C E N S E" ?

-----Original Message-----
From: Howard Frazier [mailto:millardo@dominetsystems.com] 
Sent: Thursday, May 22, 2003 12:44 PM
To: stds-802-3-efm@ieee.org
Subject: [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--------------