Questions regarding 11-036r2 (Transmitter training)

[Penokie, George]

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1105032_f.htm">HTML-formatted message</a>

Kishore,
I have looked closer are your comment #5:
Issue #5:
In PTT_T2: Tx_Training state, in page 58, the condition for setting
TRAIN_COMP bit seems to be a deadlock condition. Won't	points a) and b)
cause a deadlock? Basically why should we have to wait for local phy's
transmitter training complete message to set the training complete bit?
Setting the TRAIN_COMP bit should only depend on receiving a TX_FIXED = 1
|from the attached phy or Attached Phy's Transmitter optimized message
received.
I do not believe there is a deadlock as you suggest.
In PTT_T2 there are two conditions that may occur.
1)     The local SP receiver completes the training of the attached
transmitter before the local SP transmitter is trained. In this case PTT_T2
receives the Local Phy's Transmitter Training Complete message and just
remembers that (i.e., it takes no other action because of that message). At
some point PTT_T2 receives an Attached Phy Optimized message from the SP
receiver. When that happens, then and only then will PPT_T2 set the
TRAIN_COMP bit to one and transmit that in the next 6 TTIUs. After that the
training is over and there is a transition to PTT_T0.
2)     The attached SP receiver completes its training of the local
transmitter before the local SP transmitter is trained. In this case PTT_T2
receives the Attached PHY Optimized message from the SP receiver causing an
immediate transition to PTT_T3. The first thing that happens in PTT_T3 is
that the TRAIN_COMP bit is set to one and transmitted. PTT_T3 waits until it
receives a Local Phy's Transmitter Training Complete message then the
training is over and there is a transition to PTT_T0.
That was the sequence before I broke it based on yours and others comments.
But I see no deadlock in that sequencing and am going to put it back because
now it really is broaken. This is because I removed item a) in section
5.11.4.4.6 causing an inconsisantcy between when the 1,2,3 list is supposed
to be processed and the transition to PTT_T3 requirements, they now are
supposed happen under the same conditions. That is an error.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Karthikeyan,
Kishore K
Sent: Wednesday, April 27, 2011 8:47 PM
To: t10 at t10.org
Cc: Karthikeyan, Kishore K
Subject: Questions regarding 11-036r2 (Transmitter training)
Hi all
I was reading the 11-036r2 version of the transmitter training proposal and
had the following questions/clarifications.
Issue #1:
Section 5.7.4.2.3.4.2 Pattern marker  of the proposal defines what a "valid
pattern marker" message is. But there is no section that defines what an
"invalid pattern marker" message is. This definition is required because the
PTT_PL state machine uses both valid and invalid messages to make its state
transitions. If it is not defined, then depending on implementation an
"invalid pattern marker" message can be generated even during the 58 dwords
of scrambled and 8b/10b encoded data of the Tx training pattern.
I took an initial stab at the definition of "invalid pattern marker" as
follows.
During the Train_Tx-SNW if the phys receiver detects:
1.     A differential high signal level for greater than 10 but less than 19
UIs or
2.     A differential low signal level for greater than 10 but less than 19
UIs or
3.     A differential high signal for greater than 21 UIs or
4.     A differential low signal for greater than 21 UIs.
Then the pattern marker shall be invalid.
Issue #2:
The proposal does not say whether SSC can be enabled/disabled during Tx
Train-SNW. For all other windows the standard clearly mentions if SSC can be
enabled. The SP28SAS_TrainSetup state has a statement that implies that SSC
can be enabled in Tx_Train-SNW but it would be helpful to call it out
explicitly
Issue #3:
Proposal doesn't define the action that needs to be taken for invalid
Manchester Encoding received during Transmitter training information unit.
Meaning if the Manchester decoding does not result in either 1 or 0, what do
we do?
Issue #4:
In PTT_T1:Initialize state, why are we setting the TX_FIXED bit to one? Why
is it not defaulted to zero? If the local phy's pattern lock s/m does not
lock and hence the local phy don't receive any Transmitter Training
Information unit, it will continue to transmit this initial pattern with
(TX_FIXED = 1), but since the attached phy's pattern lock s/m got locked, it
will transition to PTT_T2:Tx_Training state and think that my transmitter
does not support Tx_Training (TX_FIXED = 1).  Am I reading this wrong?
Issue #5:
In PTT_T2: Tx_Training state, in page 58, the condition for setting
TRAIN_COMP bit seems to be a deadlock condition. Won't	points a) and b)
cause a deadlock? Basically why should we have to wait for local phy's
transmitter training complete message to set the training complete bit?
Setting the TRAIN_COMP bit should only depend on receiving a TX_FIXED = 1
|from the attached phy or Attached Phy's Transmitter optimized message
received.
Issue #6:
This question might be dumb but since I am not a phy expert, please bear with
me.
When we are doing Tx_Training, aren't we essentially training our receivers
too? Then why did we design the proposal such that if Train_Tx-SNW was
successful, we have to follow it with a Train_Rx-SNW? Is the intent to keep
our receiver coefficients constant during Train_Tx-SNW and only Train the
attached phy's TX coefficients and then modify the local phy's Rx
coefficients during Train_RX-SNW?
Issue #7:
Page 8, note k:
I think it should read --> (eg MTXT) is nominally 500.5 ms equals MTTT+RCDT
Issue #8:
Page 57, line 1.
I think it should read --> c) six or more Train_Tx Pattern Transmitted
messages.
Thanks in advance.
Kishore