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

Clause 33 comments




1.    33.1.2.2 - page 71, line 10,
The device with the PMA/PMD MDIO functionality may 
have no way of identify the wavelength of the 
of the optical transceiver. In previous MDIO registers, 
we have allowed for this by defining values for
things like "Unknown" or "Serial, unknown wavelength." 
I'm not sure we need the former, but we should
at least have the latter.

2.    33 - page 67, line 1,

The title of the clause is MDIO/MDC management interface. 
Calling an interface by its two signal names
is awkward and it is not consistently applied - in 
many places such as register names MDIO is used rather
than MDIO/MDC. This is the only interface named that way. 
Could we call this the Management Data Input/Output (MDIO) 
Interface? 

3.    33.3.1 - page 69, line 9,

The WIS and PCS should be separate devices. Though there 
isn't a compatibility interface defined between 
them, they may be implemented in separate chips using 
a proprietary interface. It is difficult to have two 
chips respond to one device address. It is easy to have 
one chip respond to two device addresses and there
is no need to compress these two layers to one address.

4.    33.3.1.1.1 - page 69, line 44,

Several sublayers may be implemented within a single chip. 
Some of the functions will be difficult or 
impossible to implement so that they effect a single 
sublayer within a chip. Reset is one of those functions.
We should define it in a way that it is simple for 
multi-sublayer chips to implement. Two possibilities: 
A reset to any sublayer within a chip may cause a reset 
to all sublayers within the chip or a reset will only be 
responded to when it is sent to the highest (nearest the MAC) 
within a chip and it will then reset all sublayers within 
the chip. 

5.    33.3.1.1.2 - page 70, line 20

Loopback is defined for each sublayer. If a chip 
implements multiple sublayers, is it required to implement
a loopback in each sublayer or is it just required to 
implement one loopback? My preference would be for
just one (and I don't see how anything else could be 
enforced).

6.    33.3.1.1.2 - page 70, line 21

It isn't enough to specify what the PMD doesn't transmit 
during loopback. We need to specify what it does
transmit. Neither the PMD nor the PMA know what is data 
and what is idle. Generation of idle is not trivial
for any of our sublayers. Is the PMD to power off its 
transmitter during loopback? 

7.   33.3.1.1.3 - page 70, line 33,

See my comment on 33.3.1.1.1. It would be extremely 
difficult if not impossible to power down one sublayer 
within a chip without powering down others. I suggest 
the same sort of remedy as for reset.

8.   33.3.1.3 - page 71, line 31

Does a device with multiple sublayers have a different 
identifier for each? It would be preferable if we 
specified that the same identifier was reported at 
each sublayer. That way, the manager could know that 
the sublayers were part of the same component and that 
reset, power down, etc would effect the whole
component. Another possibility would be to add a 4 bit 
object to report the highest sublayer within the 
component. 

9.  33.3.1.4.1 - page 71, line 42

The PMA and the PMD may not be in the same component 
and the PMD may be on a plugable module.
How does the PMA know what speed the PMD supports? 
Similarly for 33.3.1.4.2. 

10. 33.3.2.2.2 - page 75, line 2

The PCS does not actually measure bit error rate. 
Also, phrases like "detecting a BER rate of > x" really
require the measurement period to be defined to have 
a meaning and the PCS can only estimate BER 
since they detect code violations but never know how 
many bits were in error to cause the code violations
and some errors do not cause a code violation. 

What the PCS does have is monitors of link status that 
are designed such that they have a high probability of 
being in the link good state if BER is good (< 10^-9) 
and a high probability of being in the link bad state
if BER is bad (> 10^-4). If BER is somewhere in between 
then the monitor may be in either state. 

Therefore, it would be more accurate to call this 
something like "link status", "link health" or "link lock".

For the 64b/66b code, this bit is really the same as 
PCS Sync done. 

11.  33.3.1 - page 68, line 51

Some of our PMAs have more functionality than 
traditional PMAs and we may need to add some bits 
to monitor them. For instance, they are likely to 
have retimers which may be able to tell whether they 
have lock. It would be good to provide a status 
bit for transmit and one for receive that can be used
to report loss of lock though it should be optional 
for a PMA to have the capability of detecting the 
condition. Also, the WAN to WWDM PCS (which was 
being called SUPI) has to acquire sync to 
deskew and demux the data. There should be a bit 
for it to report its sync status.

12.  33.3.2.4 - page 75, line 24

There should be bits in the capability register to 
indicate whether this is a 64b/66b or an 8B/10B PCS.
Actually the proper names for them are type 10GBASE-R 
PCS and type 10GBASE-X PCS, rather than their block 
code names.

13.  33.3.2.2.3 - page 75, line 7

The 10GBASE-X PCS also can be in sync (byte lock 
and deskew sync'ed) or out of sync. 

14.  33 - page 71, line 1

In the clause 22 MDIO/MDC, some registers were 
optional and some were extended. This clause
does not identify any registers as extended for 
a particular device. Was the intent here to require 
response to all registers but allow for optional 
support by allowing the register to have a value of 
all zeros as is done for the device identifier 
registers. If so, that is fine, but the clause 
should probably explain that since it is different 
from clause 22. 

15. 33.3.2.1.2 - page 72, line 51

The WIS does not have the capability to generate 
idle. It does not know the meaning of the scrambled
data it is forwarding. Therefore, if the WIS/PCS 
is looping back data "encompassing as much of the 
WIS/PCS circuitry as is practical", it has no way 
of not transmitting data onto the medium (other than 
perhaps ceasing to emit Sonet Frames at all, but 
I don't know if that is a good idea). The lowest point
in a WAN phy stack that can loopback and generate 
idle for the output at the same time is the PCS above 
the scrambler. To go any lower in the stack would 
require duplicating part of the stack.

The possible alternatives are:
	Loopback at the WIS is not necessary. Loopback 
		in PCS is good enough,
	During loopback, the WIS doesn't send Sonet 
		frames to the PMA, or
	During loopback, the WIS may send the data it 
		is looping back to the medium.

16.  33.1.2 - page 69, line 1

There is no reference to the figure. Presumably 33.1.2 
would be an appropriate place for the reference.

17.  33.1.2 - page 69, line 2

The same device may in some circumstance be a DTE 
XGXS and in some a 10GBASE-X PCS. For some
implementations, which it is may depend on what has 
been plugged into a XAUI interface. It would therefore 
be helpful if the register structures for the two 
were as similar as possible. Right now, 2.1.8 and
4.1.4 seem to have the same function. Other than 
that, the register maps seem consistent.

18.  33.3.5 - page 84, line 49

"shall increment and store the address of the register 
accessed."  Wouldn't "shall increment the address
of the register accessed and store the result" be 
more precisely correct. (Pretty picky I know.)

19.  33.3.5 - page 84 , line 45

How fast is "immediately"? Isn't the important thing 
that there shouldn't be any intervening operations?
Or do you mean that the device is allowed to forget 
the address if the controller waits too long? If so a 
time would need to be specified.

20.  33.3.5 - page 84, line 39

This statement isn't true. a sequence of incremented 
reads or writes does not require two frames for each
read or write operation. What is required is one extra 
frame - the address frame - for each sequence of 
reads or writes.

21.  33.3.5 - page 85, line 5

The note implies that a write followed by another 
operation such as read-increment retains the same 
address, but the text does not state that. please 
add text to state that the address is retained and 
if not over-written by another address operation 
the stored address is used regardless of whether
the prior operation caused an increment.

22.  33.3.5 - page 84, line 34

Only 1 of the layers has more than 1 write-able 
register - the WIS and in that case, the two are
not sequential.  Therefore, the write-increment 
is not useful for the current defined registers.
It would be useful to be able to read a register 
repeatedly without intervening address operations.
For instance, the link may not have sync and the 
controller may want to keep reading status to
see if sync has been acquired or the controller 
may have issued a reset and may want to read
repeatedly to see when the reset has completed. 
Therefore, Write-Increment should be replaced
with Read. 

Also, Read was what the task force approved in 
the proposal. We do not have a task force vote
approving the change the editor made.

23.  33.3.5 - page 84, line 20

It looks like all the necessary information from 
22.2.4.5 has been added to this section so this 
reference is unnecessary and could confuse people 
since some things from 22.2.4.5 do not apply. 
For instance, we do not support preamble suppression. 
If you want, you could point out that this interface 
uses a similar frame format to that in Clause 22, 
but such a statement should not say that 22.2.4.5 
is supplying the definition for frame format in Clause 33.

24.  33.3.5.3 - page 85, line 22

We should specify what the interface does if it sees 
a 01 instead. Presumably it should do nothing.