Questions regarding 11-036r2 (Transmitter training)

[Karthikeyan, Kishore K]

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

Dear all
I assume everybody is busy with SOP/PQI discussions but I would really
appreciate if I can get some clarifications on this TX training draft
proposal.
Thanks
Kishore
From: Karthikeyan, Kishore K
Sent: Wednesday, April 27, 2011 6: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