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.