Re: [10GBASE-CX4] comments on latest CX4 revision
Mike,
It was decided that the Transmit template would not changed to take into
account the effect of 2" of FR4 that were were using in our simultations.
Since, as Dan stated, the template is measured at TP2 it is left to the
implementer (silicon vendor and customer) to set the pre-emphasis within the
silicon to achieve the desired waveform at TP2. The same holds for the receive
end. Also as Steve Dryer ponited out when we get more simulation / measured
data that includes more real life ringing in the flat low frequency portion
that fails the current template yet works in the system we will entertain
opening that section of the template up.
Howard
ddprocurve@antelecom.net wrote:
> Hi Mike,
>
> We chose 2" for the purpose of making a reasonable limitation on the PCB
> requirement. We could have made it 6" but the group felt that would be
> unnecessary.
>
> The transmit spec is at TP2, which is on the outside of the box.
>
> This means that your silicon has to be better than what is measured at TP2.
> You can account for 2" of PCB and still be compliant but you would be
> marginal. You can account for 6" and be compliant with margin. That is your
> perogative.
>
> As a system supplier, I would prefer a part that has margin, but we had to
> draw a line and we are trying to get things done in rapid order. We believe
> that the current spec is robust enough to meet most applications.
>
> If you go check out the 10 100 or 1000BASE-T specs you will see
> that their transmitters are also spec'ed at the MDI. They don't even
> provide any indication of channel loss through the PCB or connector. What
> we are doing is consistent with that approach.
>
> Regards,
>
> Dan
>
> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
> Steve, Howard,
> <p>Thank you for the detailed responses. I understand some of the
> issues and anticipated measurement techniques regarding the transmitter
> template better now.
> <p>Still, I have serious reservations. I think my concern is illustrated
> in your presentation where adding 2 inches of FR4 induced a change in the
> mask. Real silicon might pass on a given package and a given PCB
> yet fail on a different package and PCB. That is the real world (for
> us, at least). We could not sell a product if we required an ASIC
> customer to use only certain pins of certain packages and constrain their
> PCB layout in such a tight fashion.
> <p>I suspect that such variations will cause a lot of product to fail the
> template test, even though they would perform fine in the application.
> That is, small reflections or resonances which transgress the TX template
> could be due to high frequency energy which would be virtually eliminated
> by attenuation at the receiver where the pre-emphasis actually does its
> magic. I might provide some comparable hardware measurements to show
> non-compliance, but don't see how one example proves anything. That
> is, is it the test which would be flawed or the part under test?
> <p>Compliance tests which allow product to pass while failing in the
> application
> are certainly a disaster, but tests which fail perfectly good product are
> also a big problem. I see no clear reason why the template is a
> <i>necessary</i>
> condition for a product to perform in the application.
> <p>The approach which XAUI used and which I had proposed to CX4 -- a
> Compliance
> Interconnect -- avoids these difficulties. But the group has decided
> to go in a different direction. I guess we'll just have to agree
> to disagree and see how it comes out. I don't enjoy being a nay-sayer,
> but I have to call it as I see it -- the same as we all do -- for this
> process to work.
> <p>Regards,
> <br>Mike
> <p>ps: An afterthought -- maybe you could repeat the simulations
> with some random variations built into the package and PCB models to get
> an idea of the sensitivity?
> <br>
> <p>"Dreyer, Steve" wrote:
> <blockquote TYPE=CITE> <span class=516543017-01032003><font
> face="Arial"><font color="#0000FF"><font
> size=-1>Mike,</font></font></font></span><span
> class=516543017-01032003></span><span class=516543017-01032003><font
> face="Arial"><font color="#0000FF"><font size=-1>My
> answers to your comments below in blue.</font></font></font></span><span
> class=516543017-01032003></span><span class=516543017-01032003><font
> face="Arial"><font color="#0000FF"><font
> size=-1>Steve</font></font></font></span>
> <blockquote
> style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid;
> MARGIN-RIGHT: 0px">
> <div class="OutlookMessageHeader" lang="en-us" dir="ltr"><font
> face="Tahoma"><font size=-1>-----Original
> Message-----</font></font>
> <br><font face="Tahoma"><font size=-1><b>From:</b> Mike Jenkins [<A
> HREF="mailto:jenkins@lsil.com";>mailto:jenkins@lsil.com</a>]</font></font>
> <br><font face="Tahoma"><font size=-1><b>Sent:</b> Friday, February 28,
> 2003 4:56 PM</font></font>
> <br><font face="Tahoma"><font size=-1><b>To:</b> DOVE,DANIEL J
> (HP-Roseville,ex1)</font></font>
> <br><font face="Tahoma"><font size=-1><b>Cc:</b> 'clarkf@mxim.com';
> 'stds-802-3-10GBCX4@ieee.org'</font></font>
> <br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: [10GBASE-CX4]
> comments on latest CX4 revision</font></font>
> <br> </div>
> Dan,
> <p>I share Clark's concerns. The only related presentation I found
> for February (cx4_electrical_specs_02_18_03_Raleigh.pdf) showed
> simulations,
> not hardware.
> <ul>
> <li>
> These simulations used up all the space in the template, passing only when
> the pre-emphasis was adjusted a couple percent (which is easy to do in
> simulations, but tough, slow and expensive in silicon). <span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1> </font></font></font></span></li>
> </ul>
> <span class=516543017-01032003><font face="Arial"><font
> color="#0000FF"><font size=-1>
> The original template was based on simulations from myself and Howard
> Baumer,
> and there was plenty of margin</font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> against these simulations. . Zeev Roth from Mysticom </span><span
> class=516543017-01032003>then
> contributed the more detailed simulations for the
> </font></font></font></span><span class=516543017-01032003><font
> face="Arial"><font color="#0000FF"><font size=-1>
> presenatation. Zeev's simulations were deemed to be close </span><span
> class=516543017-01032003>to
> worst case, so we tentatively decided to keep
> </font></font></font></span><span class=516543017-01032003><font
> face="Arial"><font color="#0000FF"><font size=-1>
> the template limits that barely encompased Zeev's results. The template
> can be adjusted further, but the</font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> group needs to see sim results to be able to do that, if you have some
> specific results which show problems,</font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> please submit to the group so those can be factored in.
> </font></font></font></span><span class=516543017-01032003></span><span
> class=516543017-01032003></span><span class=516543017-01032003><font
> face="Arial"><font color="#0000FF"><font size=-1>
> As far as pre-emphasis tolerance goes, there is some allowance. In
> case there is any confusion, a </font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> waveform is first normalized in amplitude so that the flat pre-emphasis
> section is sitting on 50% point.</font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> So, the actual pre-emphasis value is that 50% point relative to the peak
> in the template. The peak amplitude</font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> template varies from 0.875 to 1.175. Calculating this out shows that
> the pre-emphasis can be between</font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> 42.5-57.5 percent and meet the template. The group thought this was
> reasonable from an implementation</font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> standpoint. </span><span
> class=516543017-01032003>Of course, these
> numbers can be adjusted </span><span
> class=516543017-01032003>if
> somneone has data/results to indicate a
> problem.</font></font></font></span><span
> class=516543017-01032003></span>
> <ul>
> <li>
> The need to change the pre-emphasis was due to modelling 2 inches of PCB.
> What if it's 3 inches instead? or a different dielectric? or
> a different package? <span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1> </font></font></font></span></li>
> </ul>
> <span class=516543017-01032003><font face="Arial"><font
> color="#0000FF"><font size=-1>
> The group spent a lot of time debating how much "system" tolerance to build
> in to the spec. It was decided that</font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> 2" of FR4 was a reasonable goal. This doesn't preclude anyone from
> building an IC that accomodates</font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> longer lengths and different materials, as long as the spec is met at TP2
> anything can be done.</font></font></font></span>
> <ul>
> <li>
> Assumptions in this simulation included <i>perfect</i> impedance matching
> and no reflections. I very much doubt that a GigaCN-to-SMA adapter
> board would meet those assumptions. <span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1> </font></font></font></span></li>
> </ul>
> <span class=516543017-01032003><font face="Arial"><font
> color="#0000FF"><font size=-1>
> Agree. No one had any reflection data to present. It was discussed,
> and most felt that reflections might
> require</font></font></font></span><span class=516543017-01032003><font
> face="Arial"><font color="#0000FF"><font size=-1>
> an opening up of the template along the flat pre-emphasis section.
> But it was decided to leave as is pending </font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> sim results showing a problem and
> solution.</font></font></font></span><span class=516543017-01032003></span>
> <ul>
> <li>
> No tolerance is allowed for jitter or amplitude noise.<span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1> </font></font></font></span></li>
> </ul>
> <span class=516543017-01032003><font face="Arial"><font
> color="#0000FF"><font size=-1>
> The DJ spec of 0.18UI was factored in the template. The RJ=0.17UI
> part was </span><span
> class=516543017-01032003>was kept as a separate
> spec.</font></font></font></span><span class=516543017-01032003><font
> face="Arial"><font color="#0000FF"><font size=-1>
> See working paper draft 3.1.</font></font></font></span>
> <ul>
> <li>
> Margin for amplitude noise is 10% max, including ringing & reflections.
> <span class=516543017-01032003><font face="Arial"><font
> color="#0000FF"><font size=-1> </font></font></font></span></li>
> </ul>
> <span class=516543017-01032003><font face="Arial"><font
> color="#0000FF"><font size=-1>
> This was addressed by allowing a lot of room on the top of the template
> on the short pulse section.</font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> The amplitude limits go from 0.875 to 1.175, which everyone thought was
> adequate to address ringing and</font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> refrlections. If someone brings in more data to show a problem, the
> template can be adjusted accordingly.</font></font></font></span>
> <ul>
> <li>
> Depending on how you model it, slow risetimes (0.41 UI) either just make
> it or just miss <i>with everything else perfect</i>.<span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1> </font></font></font></span></li>
> </ul>
> <span class=516543017-01032003><font face="Arial"><font
> color="#0000FF"><font size=-1>
> Agreed. At last meeting, the group decided to add an additional
> separate rise and fall time spec of </font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> 60-130ps (same as XAUI), this was </span><span
> class=516543017-01032003>added
> to working paper 3.1.</font></font></font></span><span
> class=516543017-01032003></span><span
> class=516543017-01032003></span>Apologies
> if I've missed a presentation with actual hardware compared to this
> template.
> But if we're proceeding without any hardware experience, I am frankly
> concerned
> that this approach will be a measurement nigntmare. <span
> class=516543017-01032003></span><span class=516543017-01032003></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>As
> far as measurement goes, it is true that doing any measurement degrades
> the signal being observed, but </font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>commonly
> the effects of the measuring equipment are subtracted from the result to
> determine what the observed</font></font></font></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>signal
> actually is. This is true of XAUI measuremnets today where
> everyone routinely subtracts the effects</font></font></font></span><span
> class=516543017-01032003></span><span
> class=516543017-01032003><font face="Arial"><font color="#0000FF"><font
> size=-1>
> of SMA connectors, loss of scope cables, degradation due to FR4,
> etc.</font></font></font></span><span class=516543017-01032003></span><span
> class=516543017-01032003></span>Regards,
> <br>Mike"DOVE,DANIEL J (HP-Roseville,ex1)" wrote:
> <blockquote TYPE="CITE">Hi Clark,
> <p>I believe a lot of your questions would have been addressed
> <br>at our meetings. We have had numerous presentations with
> <br>measurements of cable assemblies and devices where the first
> <br>thing that is done, is determine the impact of the connectors
> <br>and PC board, and other impairments on the measurement.
> <p>Nobody is claiming this is easy, that is not required. It is
> <br>necessary to ensure compliance that we have a transmitter that
> <br>meets an objective template, and a channel that meets a set of
> <br>objective specs, and a receiver that works when connected to
> <br>the two former items. Verification is required, but those of
> <br>us who have been working on this have spent a substantial
> <br>amount of time doing just that.
> <p>The reason we spec'ed TP2 at the back side of the mated
> <br>interface was specifically so that we could get a physical
> <br>point as a reference plane.
> <p>Regards,
> <p>Dan
> <p>-----Original Message-----
> <br>From: Clark Foley [<a
> href="mailto:clarkf@mxim.com";>mailto:clarkf@mxim.com</a>]
> <br>Sent: Thursday, February 27, 2003 10:30 AM
> <br>To: 'ddprocurve@antelecom.net'; 'stds-802-3-10GBCX4@ieee.org'
> <br>Subject: RE: [10GBASE-CX4] comments on latest CX4 revision
> <p>Dan,
> <p>Has such a correction for impairments been demonstrated at 3.125Gb/s?
> <p>Clark
> <p>On Wednesday, February 26, 2003 10:11 PM, ddprocurve@antelecom.net
> <br>[SMTP:ddprocurve@antelecom.net] wrote:
> <br>>
> <br>> Hi Clark,
> <br>>
> <br>> We discussed this and the conclusion was that there will be some
> <br>impairment
> <br>> caused by the fixturing (loss, etc) but that must be calibrated out
> by the
> <br>> user. We did not want to get into mandating how much loss, what kind
> of
> <br>> SMAs, etc. Rather, we spec the signal at the interface and rely upon
> the
> <br>> user to be able to make that measurement.
> <br>>
> <br>> This is consistent with 1000BASE-T and other 802.3 technologies where
> the
> <br>> measurement requires some calibration by the user to compensate for
> probe
> <br>> effects.
> <br>>
> <br>> Dan
> <br>> >
> <br>> >
> <br>> >54.7.3.6 Differential Output Template and Figure 54-3
> <br>> >The interconnect from the MDI to the scope for measuring against
> this
> <br>> >template has not been adequately described. I could not find
> any
> <br>> >information on the plumbing. A tight template like this one
> must be
> <br>> spec'd
> <br>> >along with the interconnect hardware.
> <br>> >
> <br>> >Please consider readily available adapters and cables for this.
> I
> <br>suggest
> <br>>
> <br>> >that the test interface be comprised of a 1m, 24AWG cable to connect
> <br>> >between the MDI and a GigaCN-to-SMA adapter board. If you
> don't have one
> <p>> >of these boards yet, you will soon! From the SMA to the scope,
> we can
> <br>use
> <br>>
> <br>> >short, high quality cable. This is easy and convenient.
> <br>> >
> <br>> >
> <br>> >Regards,
> <br>> >Clark Foley
> <br>> >Maxim Integrated Products
> <br>> >(503) 547-2018
> <br>> >
> <br>> ></blockquote>
>
> <pre>--
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Mike Jenkins Phone: 408.433.7901 _____
> LSI Logic Corp, ms/AH260 Fax: 408.433.2840 LSI|LOGIC| (R)
> 1873 Barber Lane <a
> href="mailto:Jenkins@LSIL.com";>mailto:Jenkins@LSIL.com</a> | |
>
> Milpitas, CA 95035 <a
> href="http://www.lsilogic.com";>http://www.lsilogic.com</a> |_____|
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</pre>
> </blockquote>
> </blockquote>
>
> <p>--
> <br><tt>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~</tt>
> <br><tt> Mike Jenkins
> Phone: 408.433.7901
> _____</tt>
> <br><tt> LSI Logic Corp, ms/AH260 Fax: 408.433.2840
> LSI|LOGIC| (R)</tt>
> <br><tt> 1873 Barber Lane
> <A HREF="mailto:Jenkins@LSIL.com";>mailto:Jenkins@LSIL.com</a> |
> |</tt>
> <br><tt> Milpitas, CA 95035
> <A HREF="http://www.lsilogic.com";>http://www.lsilogic.com</a>
> |_____|</tt>
> <br><tt>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> pc</tt>
> <br> </html>