RE: Clause 49 /A/ /K/ /R/ on XGMII question
Justin,
I'm not sure of your perspective in this message. Are you talking about
checking characters at the X decoder, the RS, or the R PCS?
If the perspective is the RS, then it should have some text saying what it
does if it gets a garbage input. Even if the X PCS never generated an /A/,
/K/, or /R/ to the XGMII presumably there could be a failure condition where
it got one of them or an unassigned value of control code. The logical
behavior in response to that is:
When in a frame, make sure the frame gets a FrameCheckError, and
Either leave DATA VALID unchanged or deassert DATA VALID
The first would be the same as the response to an /E/. The second would
treat an abnormal XGMII control character as a combination of /E/ and /T/.
If the RS is receiving garbage, it is sensible to stop trying to receive
data so I would choose the latter.
If the perspective is the X decoder, by examining the code tables in clause
36, you can see that decoding from the 10B representation to the 8B plus C
representation can be done with a fairly simple set of logic gates rather
than some kind of look up table. If you use this kind of standard 8B/10B
decoder implementation, 10B /A/, /K/, and /R/ will be turned into their 8B
equivalents rather than into the 8B Idle control character. So, after the
8B/10B decoder, one either has a circuit per lane that detects /A/, /K/, and
/R/ and replaces them with /I/ or one has a circuit that detects when when
there is an ||A||, ||K|| or ||R|| column and replaces the whole column with
||I||. That requires the per lane detectors plus a 4 input AND gate. Note
that one already needs to detect an ||A|| for alignment and, if one's XGMII
interface is not synced to the recovered receive clock, an ||R|| detector
for clock compensation.
If I ruled the world, I would replace /A/, /K/, and /R/ with /I/ rather than
their column equivalents because it is slightly simpler. I submitted a
comment on D2.0 suggesting that which was rejected. However, the
simplification allowed is nearly trivial - a gate or two. Neither choice is
broken.
If the perspective is the R PCS, it means we have to have encoding/decoding
for /A/, /K/ and /R/ characters, but we had already included that anyway.
Partly we included that so that the encoding could be used in a generic
8B/10B environment. Even if the X definition were changed so that it always
converted those characters to idle, I expect we would leave the R code table
with reserved entries for them as currently defined.
Perhaps since there are circumstances where they occur on the XGMII with the
current X definition, the control character names for them in Table 49-1
should be changed from reservedn to something else.
Bottom line, it is a choice that had to be made. It isn't broken now and the
impact of the choice either way is pretty small.
Regards,
Pat
-----Original Message-----
From: Justin Gaither [mailto:jgaither@xxxxxxxxxxxxxxx]
Sent: Friday, February 16, 2001 7:12 AM
To: THALER,PAT (A-Roseville,ex1)
Cc: Steve Haddock; 'Grow, Bob'; stds-802-3-hssg@xxxxxxxx
Subject: Re: Clause 49 /A/ /K/ /R/ on XGMII question
Pat,
The problem I have with this is that now, I have to check for these
3
control characters which should never happen. Why not, just check for
the ones that should be there, like /S/,/T/, /I/, /Q/, and everthing
else becomes /E/?
Or is this some sorta protection for later drafts, or proprietary
implementations?
--
Justin Gaither Phone: 512-306-7292 x529
RocketChips a Division of Xilinx Fax: 512-306-7293
500 N. Capital of TX Hwy.
Bldg 3 email: jgaither@xxxxxxxxxxxxxxx
Austin, TX 78746 WWW: www.rocketchips.com