Thread Links |
Date Links |
||||
---|---|---|---|---|---|

Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |

*To*: "'Lindsay, Tom'" <tlindsay@xxxxxxxxxxxxxxxxxxxx>, "THALER,PAT (A-Roseville,ex1)" <pat_thaler@xxxxxxxxxxx>, Mike Jenkins <jenkins@xxxxxxxx>*Subject*: RE: [802.3ae] Proposed modifications to CJPAT - round 3*From*: Boaz Shahar <boazs@xxxxxxxxxxxx>*Date*: Tue, 20 Nov 2001 09:26:17 +0200*Cc*: stds-802-3-hssg@xxxxxxxx*Sender*: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx

Did you discuss the option of rotating each of the lanes of CJPAT? (Lane 0 not rotated, lane 1 by quarter of a frame etc.) > -----Original Message----- > From: Lindsay, Tom [mailto:tlindsay@xxxxxxxxxxxxxxxxxxxx] > Sent: Tuesday, November 20, 2001 4:20 AM > To: THALER,PAT (A-Roseville,ex1); Mike Jenkins > Cc: stds-802-3-hssg@xxxxxxxx > Subject: RE: [802.3ae] Proposed modifications to CJPAT - round 3 > > > > Pat - see within. Thanks, Tom. > > -----Original Message----- > From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@xxxxxxxxxxx] > Sent: Monday, November 19, 2001 5:25 PM > To: Lindsay, Tom; Mike Jenkins > Cc: stds-802-3-hssg@xxxxxxxx > Subject: RE: [802.3ae] Proposed modifications to CJPAT - round 3 > > > Tom and Mike, > > The idea of CJPAT was to have a pattern that could be sent > and received > by a > MAC. That is why the pattern is encapsulated in a packet. The only way > to > control running disparity would be to have a test mode that is sourced > by > the PHY which would be a rather significant feature change at this > point. > Even then, it gets a bit tricky. If one has a transceiver where a full > X-PCS > and XGXS is implemented, then that would be producing its own idle and > would > need to source the pattern while if the transceiver had just a simple > retimer between the MDI and the XAUI, the pattern would need > to be sent > into > it. > > >>TAL - as I expected. Thanks, I guess... Sounds like true disparity > control is not possible. > > Some alternatives without controlling starting disparity: > > Build a new stress pattern using only disparity neutral codes - those > codes > that are the same in both disparity columns. I'm not > convinced one could > build as good a pattern this way. The high density part of the pattern > uses > a disparity neutral code already but the low density doesn't and there > may > not be a 3 transition disparity neutral code (and I don't have time to > look > at the moment). The EB and F4 are also not neutral. > > >>TAL - you are right, the pattern would not be as good. I have looked > into this already, and at this point would rather stay along the lines > of CJTPAT since it is "proven" in Fibre channel. By the way, Fibre > channel controls frame disparity via the end-of-frame - one of two > values is chosen based on incoming disparity such that the ending > disparity is always negative. > > There are two repeats of the pattern in the CJPAT packet. If one made > the > low density pattern repeat for an odd number of bytes per lane, one > would > test both disparities on the lane during one packet. Changing the > duration > of the low density pattern to 524 bytes would accomplish this. This > still > would mean the crosstalk is somewhat unknown since the starting > disparity of > each of the lanes is unknown. F4 and EB in the two disparities are not > inverses of each other but the bulk of the pattern (B5 and > 7E) is either > the > same or inverted for the two disparities so the frequency content and > therefore the crosstalk shouldn't be changed much based on the > disparity. > > >>TAL - the two repeats (in Option 1 only...) are there precisely for > disparity "inversion" - each repeat in each lane is the > opposite of the > other repeat in each lane. This was accomplished with selection of the > number of 7Es and the occasional AB bytes. I think Option 2, > which does > NOT repeat per packet, is dead because of the inability to precisely > control the IGP and therefore disparity - it could get > "stuck" in either > the correct (stressful) or incorrect (less stressful) disparity. > > >>TAL - by the way, I believe that even the less stressful portion of > the patterns will still be useful for general randomization, which may > flush out other unexpected issues or weaknesses. Time will tell. > > Even if one doesn't change the pattern, the idle is > randomized AKR which > will randomize the starting state of a lane at the start of the packet > so > successive repeats of the CJPAT packet should test both polarities of > the > pattern on each lane. (Since the same code is sent on each lane during > idle > and the pattern, the CRC for the current packet is composed of 4 > non-diaparity flipping codes and the start packet sequence is > non-disparity > flipping, the lanes will keep a constant disparity with > respect to each > other when CJPAT packets alternate with idles.) > > >>TAL - I agree, but I still feel there is strong value in > shifting the > contents of two of the lanes around. This is deterministic and > independent of disparity and probably the most important part of the > recommendation. > > Regards, > Pat > > -----Original Message----- > From: Lindsay, Tom [mailto:tlindsay@xxxxxxxxxxxxxxxxxxxx] > Sent: Monday, November 19, 2001 2:34 PM > To: Mike Jenkins > Cc: stds-802-3-hssg@xxxxxxxx > Subject: RE: [802.3ae] Proposed modifications to CJPAT - round 3 > > > fAJMYSF10643 > Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx > Precedence: bulk > X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx> > X-Listname: stds-802-3-hssg > X-Info: [Un]Subscribe requests to majordomo@xxxxxxxxxxxxxxxxxx > X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx > > > Hi Mike - > > As always, you understand all quite well. > > I do not know what control there can be in disparity. In terms of the > document, I would like to add a statement along the lines of > "For jitter > and other compliance testing with this pattern, it is recommended that > all lanes begin with negative running disparity and that the IPG be > strictly controlled as shown." > > Since this is a test mode, it should be possible to "jump" disparity > without upsetting too much. I suspect, however, that most > folks probably > don't have that level of control in their silicon?? (that is a > question). > > If running disparity at the start cannot be controlled, and there is > preceding traffic that sets them differently from eachother, then the > patterns will still work, but the desired disparity phasing obviously > will not be achieved. This is not a killer. > > Also, if the IPG is not controlled (to |T||A||R| and back to the start > (where |T| is comprised of /K//K//K//T/), then disparity will not be > strictly controlled from one repetition to the next. Can we > expect that > level of control?? (that is another question). If not, then I would > recommend Option 1. > > Getting back to probabilities of disparity - for crosstalk > and EMI, the > real question is how the 4 lanes match (to lane 3 for example). So if > disparity is truly random, then it comes down to 1/(2**3) (12.5%). > > The more important change in the recommended pattern is the > shifting of > high and low transition density cores within each lane - that > is lanes 2 > & 0 are shifted from what they are in the pattern presently in D3.4. > This change will have the most profound effect and is > independent of the > disaparity and IPG issues. > > Tom > > > -----Original Message----- > From: Mike Jenkins [mailto:jenkins@xxxxxxxx] > Sent: Monday, November 19, 2001 1:50 PM > To: Lindsay, Tom > Cc: stds-802-3-hssg@xxxxxxxx > Subject: Re: [802.3ae] Proposed modifications to CJPAT - round 3 > > > Tom, > > First of all, thanks for your ongoing efforts to develop the > best test pattern here. > > Please let me ask a couple questions to make sure I understand > the issues (since I can't do 8B10B encoding in my head). Where > I'm coming from is the need to understand what deterministic > 10-bit pattern(s) would constitute the patterns you propose. > At the serdes level without an 8B10B encode/decode function, > we need to test with fixed, pre-coded 10-bit patterns. > > So, if I understand correctly, each lane is assumed to have a > random starting disparity, yielding 2**4 possible starting > conditions. "Disparity flipping" bytes switch the disparity > in mid-pattern (option 1) or between consecutive patterns > (option 2). Hence, when viewed on the 10-bit side, options 1 > and 2 are almost identical, with a few more packet header > characters in the middle of the option 2 repeating 10-bit pattern. > In either case, the repeating 10-bit pattern in each lane is > approximately 380 10-bit characters long. Also, there are 2**4 > possible valid 10-bit repeating CJPAT patterns on the 4 lanes. > > I'd appreciate it if you could point out what I might have got > wrong in my understanding. (Also, at least one example of the > proposed pattern in 10-bit code would be quite useful.) > > Thanks, > Mike > > > Tom Lindsay wrote: > > > > All - > > > > As you may have seen on the reflector, I am proposing > changes to CJPAT > in > > Annex > > 48A. There were responses from my previous postings that raised some > > questions and confusion, so below, I will try to explain why I am > doing > > this. I plan to submit (one of) these as a comment in > sponsor ballot. > > > > CJTPAT, from Fibre Channel, was designed as a > single-channel tolerance > > pattern to stress the clock and data recovery process. It > also turned > out to > > be a useful jitter test pattern for general use. These > properties were > > carried over to each lane of Ethernet's CJPAT. > > > > CJPAT was "engineered" with a highly improbable bit > sequence. The most > > stressful feature in the pattern occcurs once per > repitition. Assuming > > completely random data, I estimate the probability of this type of > feature > > to be less than 1e-100. However, since 8B10B is > deterministic, and the > > sequence is legitimate, it is arguably acceptable for > reasonable worst > case > > testing. > > > > Hence, CJPAT was adopted, and without further thought, replicated on > all > > 4-lanes. This provides simultaneous jitter testing of all 4 lanes, > however, > > they carry identical and 100% in-phased bit sequences. This is quite > > unnatural, since In normal random traffic, <1% of the columns will > have > > edges switching in phase (across the 4 lanes). > > > > Three questions: > > 1. Is the replicated pattern still within the bounds of reasonable > worst > > case? Again assuming random data, we're now below a probability of > 1e-400, > > which is clearly not justifiable. > > 2. Is this what we want for crosstalk? Testing of real > hardware showed > that > > the simple replication led to improved signal properties (when > compared to > > single-lane only traffic). The improved signal properties > were caused > by > > constructive or supportive effects of in-phase crosstalk. > > 3. Is this what we want for EMI? EMI was not tested, but the same > mechanisms > > would lead to higher emissions than if the lanes were not > synchronous. > > > > I believe that these effects are artificial and must be addressed: > > a. The improved signal properties due to crosstalk are a concern > because a > > system that appears compliant with this pattern may not be able to > pass > > compliance with normal traffic. In fact, it would be possible to > > intentionally design crosstalk in a way that helps a unit pass > compliance. > > Conversely, it is possible that the crosstalk would be destructive, > failing > > an otherwise compliant system with normal traffic. > > b. If the pattern is used for EMI testing, the in-phase lanes may > cause > > compliance failure in a system that could pass with more normal > traffic. The > > present pattern is absurdly unrealistic. > > > > The proposed patterns have the following properties: > > 1. They retain the exact per-lane jitter properties of CJPAT. > > 2. They jumble/scramble the relative phases of the 4 lanes > to be much > more > > realistic. This is done via lane staggering and attempted disparity > control, > > and should greatly eliminate the effects of crosstalk and > reduce EMI. > In > > addition, it should be impossible to optimize a design around the > pattern. > > > > The latest proposals (11/16) are included again below. > > > > Thanks, > > Tom Lindsay > > Stratos > > 425-672-8035 x105 > > > > ************* > > OPTION 1: > > This option keeps the present CJPAT core in lanes 3 and 1, > EXCEPT that > they > > attempt to run with opposing disparity from each other due to an > inserted > > disparity flipper in the first byte in lane 1 (an inserted byte in > lane 3 > > does not flip disparity). I say "attempt" because > (relative) starting > > disparities can never be assured. The 2 cores will be > opposing only if > > disparities coming into the start of the pattern are the same, AND > there is > > nothing transmitted between repetitions of the pattern that > subsequently > > shifts their relative disparity. Note - if starting disparities are > not > > controlled to match as hoped, the disparity bytes causes the 2 lanes > to > > revert to synchronous transmission. > > > > Lanes 3 and 1 begin with low transition density then switch to high > > transition density. For option 1, this order is reversed in lanes 2 > and 0 - > > lanes 2 and 0 begin with high transition density then switch to low > > transition density. Therefore, lane pairs 3-1 and 2-0 will not be > > synchronous, regardless of disparities. Opposing disparity is also > attempted > > between lanes 2 and 0 with a disparity flipper in lane 0. > > > > Note that CJPAT's per-lane jitter properties require > specific starting > > disparity in each. Since starting disparities cannot be > assured, CJPAT > was > > designed so that all lanes switch their disparities 1/2 way through > the > > pattern, otherwise repeating the first half. Half of each lane's > pattern > > will have the appropriate jitter properties; the other half will not > (but > > will still provide useful "randomization". This characteristic of > CJPAT has > > not changed with proposed Option 1. > > > > 3 2 1 0 lane# > > > > 4x data # of column repeats > > 55 00 07 07 1 disparity control > > 7E B5 7E B5 40 > > 7E EB 7E EB 1 > > 7E F4 7E F4 1 > > 7E EB 7E EB 1 > > 7E F4 7E F4 1 > > 7E EB 7E EB 1 > > 7E F4 7E F4 1 > > 7E EB 7E EB 1 > > 7E F4 7E F4 1 > > 7E 7E 7E 7E 84 > > F4 7E F4 7E 1 > > EB 7E EB 7E 1 > > F4 7E F4 7E 1 > > EB 7E EB 7E 1 > > F4 7E F4 7E 1 > > EB 7E EB 7E 1 > > F4 7E F4 7E 1 > > AB 7E AB 7E 1 > > B5 7E B5 7E 40 > > EB F4 EB F4 1 > > F4 EB F4 EB 1 > > EB F4 EB F4 1 > > F4 EB F4 EB 1 > > EB F4 EB F4 1 > > F4 EB F4 EB 1 > > EB F4 EB F4 1 > > F4 AB F4 AB 1 > > 7E B5 7E B5 40 start 2nd half of pattern > > 7E EB 7E EB 1 > > 7E F4 7E F4 1 > > 7E EB 7E EB 1 > > 7E F4 7E F4 1 > > 7E EB 7E EB 1 > > 7E F4 7E F4 1 > > 7E EB 7E EB 1 > > 7E F4 7E F4 1 > > 7E 7E 7E 7E 84 > > F4 7E F4 7E 1 > > EB 7E EB 7E 1 > > F4 7E F4 7E 1 > > EB 7E EB 7E 1 > > F4 7E F4 7E 1 > > EB 7E EB 7E 1 > > F4 7E F4 7E 1 > > AB 7E AB 7E 1 > > B5 7E B5 7E 40 > > EB F4 EB F4 1 > > F4 EB F4 EB 1 > > EB F4 EB F4 1 > > F4 EB F4 EB 1 > > EB F4 EB F4 1 > > F4 EB F4 EB 1 > > EB F4 EB F4 1 > > F4 AB F4 AB 1 > > DD 09 AE 5B 1 CRC > > > > OPTION 2: > > Option 2 is ~1/2 the length of option 1. This is accomplished by > selecting > > disparity flipping bytes and resulting CRC in a manner that returns > the > > opposite starting disparities to the beginning of the pattern. Each > time the > > pattern runs, each lane alternates disparity so that like option 1, > half the > > time each lane achieves the desired jitter properties, and the other > half of > > the time it does not. > > > > Note that this assumes that the pattern repeats with an odd > number of > IPG > > rows as shown in 802.3ae draft 3.3 (12 bytes). If the length of the > IPG is > > continually an even number of rows, then the disparity will > not flip, > and > > the pattern could get "stuck" with either the correct of incorrect > jitter > > properties. > > > > Again, lanes 2 and 0 reverse the sequence of high and low transition > density > > with lanes 3 and 1. Also like option 1, lanes 3 and 1 > attempt relative > > opposing disparity, and lanes 2 and 0 attempt relative opposing > disparity. > > > > 3 2 1 0 lane# > > > > 4x data # of column repeats > > 55 55 07 07 1 disparity control > > 7E B5 7E B5 40 > > 7E EB 7E EB 1 > > 7E F4 7E F4 1 > > 7E EB 7E EB 1 > > 7E F4 7E F4 1 > > 7E EB 7E EB 1 > > 7E F4 7E F4 1 > > 7E EB 7E EB 1 > > 7E F4 7E F4 1 > > 7E 7E 7E 7E 84 > > F4 7E F4 7E 1 > > EB 7E EB 7E 1 > > F4 7E F4 7E 1 > > EB 7E EB 7E 1 > > F4 7E F4 7E 1 > > EB 7E EB 7E 1 > > F4 7E F4 7E 1 > > AB 7E AB 7E 1 > > B5 7E B5 7E 40 > > EB F4 EB F4 1 > > F4 EB F4 EB 1 > > EB F4 EB F4 1 > > F4 EB F4 EB 1 > > EB F4 EB F4 1 > > F4 EB F4 EB 1 > > EB F4 EB F4 1 > > F4 AB F4 AB 1 > > CC 08 09 CA 1 CRC > > > > In both options 1 and 2, START/PREAMBLE/SFD and IPG remain identical > to what > > are shown in 802.3ae D3.3. ALL data here is consistently shown in > little > > endian format. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Mike Jenkins Phone: 408.433.7901 _____ > LSI Logic Corp, ms/G715 Fax: 408.433.7495 LSI|LOGIC| (R) > 1525 McCarthy Blvd. mailto:Jenkins@xxxxxxxx | | > Milpitas, CA 95035 http://www.lsilogic.com |_____| > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > ----- End Included Message ----- >

- Prev by Date:
**RE: [802.3ae] Questions on section 49.2.5** - Next by Date:
**RE: [802.3ae] Proposed modifications to CJPAT - round 3** - Prev by thread:
**RE: [802.3ae] Proposed modifications to CJPAT - round 3** - Next by thread:
**RE: [802.3ae] Proposed modifications to CJPAT - round 3** - Index(es):