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

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

*To*: Boaz Shahar <boazs@xxxxxxxxxxxx>, "'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*: "THALER,PAT (A-Roseville,ex1)" <pat_thaler@xxxxxxxxxxx>*Date*: Tue, 20 Nov 2001 11:08:30 -0700*Cc*: stds-802-3-hssg@xxxxxxxx*Sender*: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx

Tom and Boaz, I didn't notice when I looked at the pattern that 7E/AB portion of the pattern flipped the disparity. I agree with Tom that it is better to leave it that way and test both disparities within each packet. Given that each disparity is checked in each packet, I don't think we need to worry about controlling the starting disparity since the crosstalk from one disparity of that particular pattern should be negligibly different from that of the other disparity. That just leaves Boaz's question. The current pattern is pretty close to a max size packet. It is 1514 bytes (if I've counted correctly). A significant contribution to the stress produced is that there is a constant period of low density pattern which lets the PLL settle in on it followed by a pattern with phase jumps. If one rotates the pattern by something like a quarter of a lane per packet, then one won't be able to fit 2 sets of 528 bytes of 7E on each lane (so each disparity is tested for that stress). Also, more than half the packet (1052 bytes) is spent in the low density pattern which presumably with its energy shifted lower in frequency will create less crosstalk than the phase jump part of the packet even when the phase jumps pattern is the same on each lane. While it has been asserted that in-phase data produces less channel degredation than out of phase traffic, I haven't seen a quantification of how much less. The current pattern produces a reasonably worst case pattern stress, so if the crosstalk difference isn't too much, that should be an adequate stress test. If we feel that we do need to vary the data on the channels to increase crosstalk, I can see a few alternatives. 1) Don't try to stress all 4 lanes maximally with the same packet. Create a CJPAT1 and a CJPAT2. For CJPAT1, leave the data on lanes 0 and 2 the same as in the current CJPAT and put some mixed frequency pattern on the other two lanes. For CJPAT2, lanes 1 and 3 get the current CJPAT pattern and the others get mixed frequency. 2) Find an alternative pattern to EB F4 that is an equally bad but different phase jump pattern and put it on two of the lanes so that they aren't synchronized. One possiblity is to just switch the alternation so that two of the lanes start with F4 instead of EB. 3) Stagger the lanes slightly so they EB F4 pattern isn't absolutely in sync on each lane. For instance, instead of having the first low density pattern start with 132 7Es on each lane, start with 132 on some of the lanes and 133 on others. Regards, Pat -----Original Message----- From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx] Sent: Monday, November 19, 2001 11:26 PM To: 'Lindsay, Tom'; THALER,PAT (A-Roseville,ex1); Mike Jenkins Cc: stds-802-3-hssg@xxxxxxxx Subject: RE: [802.3ae] Proposed modifications to CJPAT - round 3 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] Proposed modifications to CJPAT - round 3** - Next by Date:
**RE: [802.3ae] Questions on section 49.2.5** - 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):