Re: [10GBASE-CX4] comments on latest CX4 revision
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>