Re: Clause 33 comments
Pat,
Thanks very much for you thorough review of the Clause. I am glad you are taking
the time to review what we are doing and would encourage everybody else to spend
some time reviewing this clause as well. It was a pity that we ran out of time
at the Interim in September to do a review with the group.
As far as your specific comment please see below:
1/ I am probably missing something here but I am not too sure what you are
referring to when you say that 'In previous MDIO registers, we have allowed for
this by defining values for things like "Unknown" or "Serial, unknown
wavelength."'. The nearest equivalent to what you suggest that I can find is in
Clause 30 where, for example, we have the MAU Management attribute aMAUType
(30.5.1.1.2). In this attribute, for example, we have the 1000BASE-X
enumerations as follows:
1000BASE-X X PCS/PMA as specified in Clause 36 over undefined PMD, duplex
mode unknown
1000BASE-XHD X PCS/PMA as specified in Clause 36 over undefined PMD , half
duplex mode
1000BASE-XFD X PCS/PMA as specified in Clause 36 over undefined PMD, full
duplex mode
1000BASE-LX X fiber over long-wavelength laser PMD as specified in Clause
38, duplex mode unknown
1000BASE-LXHD X fiber over long-wavelength laser PMD as specified in Clause
38, half duplex mode
1000BASE-LXFD X fiber over long-wavelength laser PMD as specified in Clause
38, full duplex mode
1000BASE-SX X fiber over short-wavelength laser PMD as specified in Clause
38, duplex mode unknown
1000BASE-SXHD X fiber over short-wavelength laser PMD as specified in Clause
38, half duplex mode
1000BASE-SXFD X fiber over short-wavelength laser PMD as specified in Clause
38, full duplex mode
1000BASE-CX X copper over 150-Ohm balanced cable PMD as specified in Clause
39, duplex mode unknown
1000BASE-CXHD X copper over 150-Ohm balanced cable PMD as specified in Clause
39, half duplex mode
1000BASE-CXFD X copper over 150-Ohm balanced cable PMD as specified in Clause
39, full duplex mode
Now these options seem to be most similar to what you are suggesting, but as far
as I am aware the only bits provided in the MDIO/MDC register in relation to
1000BASE-X was simply that the PHY was capable of operating as a Half and/or
Full duplex 1000BASE-X PHY (see 22.2.4.4), there were no bits to support the
indication of what wavelength the PHY was operating at.
I however agree with your point that we should provide the ability to report
things like "Serial, unknown wavelength." through the registers. A similar set
of enumerations to 1000BASE-X above are provided for 10GBASE in the Clause 30
MIB draft and it makes sense that, as we are now providing MDC/MDIO access to
the PMA/PMD sublayer we should provided the register in that sublayer to support
the Clause 30 MIB. Due to this, and in combination with the need to now support
850nm parts voted in recently, I propose to change the single bit we have today
to indicate 1300/1500nm to a bit per wavelength, 1300nm serial, 1500nm serial,
850nm serial and 1310nm WWDM. We also need to consider if we should have a bit
per wavelength for ability and a bit per wavelength for actual wavelength (this
could accommodate tuneable lasers). I'll bring a proposal to the November
meeting for separate 'ability' and 'selected' bits.
We therefore could have the case in an implementation where both the WIS/PCS and
PMA/PMD devices are accessible and we can therefore report both the mode and
wavelength, 10GBASE-LX for example. We could also have the case where we only
have an MDC/MDIO accessible WIS/PCS, in that case we would only report the mode,
10GBASE-X for example. We could also have the case of a non-compliant PMA/PMD
register set that does not report any wavelength where again 10GBASE-X would be
reported.
2/ Management Data Input/Output (MDIO) Interface sounds good. I regard this as
an editorial change and shall globally apply this to Clause 33.
3/ My thinking behind combining the WIS and PCS was to avoid chewing up all the
device addresses, especially as the 64/66 PCS only has two PCS-specific bits. I
figured that if someone really wanted to do a two chip implementation with a
proprietary interface between them then they could put the MDIO logic in the WIS
and send a couple of control/status signals over to the 64/66 chip.
4/ I propose a solution to this : Each MDIO 'device' (sublayer(s)) has a 32 bit
read only register (split over two registers) that is a bitmask indicating the
'devices in component'. This would show which 'devices' are implemented in the
chip. Functionality such as reset would be set by writing to any of the
'devices' in the chip and would reset all 'devices' in the chip. Since this is a
fairly technical change, involving the addition of registers, I'll bring it as a
proposal to the November meeting for discussion and voting.
5/ I would be keen to keep a loopback in each sublayer, even if multiple
sublayers are implemented in each chip. If multiple sublayers are implemented in
one device, you are correct in that you cannot conformance test if the loopback
is implemented correctly. What can be tested however is that loopback operates
correctly if any sublayer in the one device is set into loopback.
6/ I didn't intend the PMD to transmit anything whilst in loopback. I had used
the word 'data' loosely, intending it to cover idle as well as packets. How
about changing it to 'data and idle' ? I think the PMD should power off it's
transmitter during loopback, but we should probably vote on that.
7/ I think this can be covered by the solution in 4. The only exception I can
think of is the WIS, which would need to be by-passed and possibly powered down
when in LAN mode. I believe however that this case is covered by the WIS Enable
and WIS/PCS Status bits.
8/ Covered by 4.
9/ The PMA would have to be told of the PMD's speed capability through a pin.
10/ PCS high BER and PCS sync done are direct reports of the 64/66 variables
hi_ber and sync_done (49.2.11.1.2, D1.0, P169). I will add additional words to
re-direct the reader to the 64/66 clause for the definition (editorial change).
11/ I'm going to re-assess bit requirements for SUPI and will add these in since
SUPI is an approved part of the standard.
12/ This is a big issue. The PCS registers at the moment just cover the 64/66
codec. The question is whether the WWDM PCS is covered by the DTE XGXS device ?
13/ Tied to issue 12.
14/ The intent was to require response to all registers but allow for optional
support by allowing the register to have a value of all zeros. I shall add some
words to this effect.
15/ I'm not sure I quite understand this one ! My intent for WIS loopback was
that the scrambled SONET data stream was looped from the transmit path at the
bottom of the WIS layer and fed back to the receive path with nothing being
transmitted out to the PMA. However, I think that the WIS group is best
qualified to determine what happens when loopback is selected and I invite them
to consider this one for us.
16/ Agreed.
17/ This issue ties in with 12. 'Where is the PCS in WWDM ?'
18/ I shall change the wording to your suggestion.
19/ The word immediately is not required and I'll remove it. The MMD shouldn't
forget the last address it received and as long as it doesn't receive another
address frame it will remain valid until it receives a data access frame.
20/ Point taken. I'll re-word it.
21/ The note was not supposed to imply that a read-inc will retain the same
address. There is one address pointer stored which is always overwritten by the
contents of an 'address' frame and is incremented by either a 'write-inc' or
'read-inc' frame. I'll modify the wording of this note to make it clearer.
22/ I agree that read was specified in the TF presentation, but at the time of
the presentation there was some discussion and a request to change it to
write-increment (which was not opposed). Several people said that these were
just details of the proposal to be worked out later and we were just voting in
the general principle of the method. That being said, I will change the access
type from write-inc to read and bring a proposal to the next meeting to change
it to write-inc.
23/ Agreed. I'll update the words.
24/ I shall put in a statement on <01> response.
Thanks again,
Ed
pat_thaler@xxxxxxxxxxx on 22/09/2000 03:06:37
Sent by: pat_thaler@xxxxxxxxxxx
To: Edward_Turner@xxxxxxxx, David_Law@xxxxxxxx
cc: stds-802-3-hssg@xxxxxxxx (Edward Turner/GB/3Com)
Subject: 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.