Re: [BP] Revised S-parameters

[Ali Ghiasi <aghiasi@xxxxxxxxxxxx>]

Title:

Adam 

Please see my comments below in red.

Healey, Adam B (Adam) wrote:

Hi Ali,

 

The location of TP1 and TP4 (refer to slide 8 of http://ieee802.org/3/ap/public/jul04/goergen_03_0704.pdf) are similar to TP-1 and TP-4 from PICMG 3.1 and the T and R compliance points for OIF CEI.

I do agree with TP-1 and TP-4 definition.

 

They are located at the "component edge" of the transmitter and receiver respectively.  The definition of "component edge" includes any external termination components required by the transmitter/receiver and the AC-coupling capacitors, when used. 

 

This implies that the backplane connectors (and mezzanine connector, when used) are part of the "channel" specification.  Channel return loss requirements would need to be satisfied looking into the channel at either TP1 or TP4.  Transmitter return loss requirements would be defined looking into TP1.  Receiver return requirements would be defined looking into TP4.

 

Channel return loss, based on the conventions that we are using, will likely be dominated by the first mated connector as you point out.

 

To include the interaction between the transmitter/receiver and the channel, a cascaded system model is required.  This can be accomplished a variety a ways (cascaded T-parameters for example, refer to OIF).  I suspect that this is something the signaling ad hoc will need to address.  The charter of the channel model ad hoc, like the cabling ad hocs 802.3 has had in the past, is to define the channel return loss looking into TP1 and TP4.  I use the word "channel" rather than backplane, as it now should be clear the our definition of TP1 and TP4 is not only the backplane but the trace on the node/hub (line, daughter, whatever naming convention you prefer) cards as well.

 

I apologize if you already understood this.  Of course, you may not agree with the above methodology, which is fine.  Let's discuss it on the reflector.  It sounds like you are advocating that we define the backplane connector, which is something I think we have been trying to avoid.  Please clarify.

Adam, I was not advocating specifying a backplane connector and looks like based on the the definition
of goergen_03_0704 you already have connector as part of the channel.  The part I am puzzled is the return loss
associated with current channel model "-14 dB up to 15 GHz".  Based on my data and experience specifying such
low return loss is not practical unless you introduce significant loss on the daughter-board.   With 14 dB return loss at
TP1/TP4 toward the channel you are practically ignoring the most significant effect "double reflection between the connector and the IC"! 

Thanks,
Ali

 

Thank you,

-Adam

 

 

 

-----Original Message-----
From: Ali Ghiasi [mailto:aghiasi@broadcom.com]
Sent: Wednesday, August 18, 2004 3:22 PM
To: joel@force10networks.com
Cc: STDS-802-3-BLADE@listserv.ieee.org; Jeff Cain; Peter Tomaszewski; John DAmbrosia; Scott Bardone; Steve Dreyer; Joe M Abler; Glen Koziuk; goleynick@fciconnect.com; Graeme Boyd; j.mitchell@winchesterelectronics.com; m_oltmanns@littoninterconnect.com; Petre Popescu; Kok-Wui Cheong; Brian Seemann; Mike Lerer; Hoss Rahbar; Schelto Van Doorn; Anthony Sanders; Pete Hanish; Cathy Liu; john.cagle@hp.com; Majid Barazande-Pour; Bill Woodruff; Luke Chang; William Peters; Healey, Adam B (Adam); Michael Altman; Richard Wolcott; Herman Eiliya; Zhi Wong; Bill Hoppin; Tom Gray; David Law; Doug Day; Charles Moore; David McCallum; Roland Moubarak; Tom Palkert; mike_resso@agilent.com; Mary Mandich
Subject: Re: [BP] Revised S-parameters

Joel

Joel Goergen wrote:

Ali,
We have been focusing on this for several months now.  I think Steve has presented nothing new that hasn't been published and, at a min, agreed to in some form of straw poll.

I am not disagreeing that these were agreed in the straw poll, I just didn't participated in some
of earlier meeting.

I would like to offer a thought ...
For the channel ... we use the SMA and SMA foot print that allows for a clean launch.  At both ends of the channel.  This allows us to see the SDD11/SDD22 without doing a major de-embedding and still allow for freq to 12.5Ghz.

How can you define a channel "backplane" but not define a minimum attribute for the connector.
There is no reason to de-embed the connector as the connector is part of the channel.  A compliant
channel must meet an specified transmission and reflection property which include connector.

For the tp1 and tp4 ... we then let the tx (tp1) handle the BGA and via, the rx(tp4) handle the via, both cap pads, both via and BGA pad.  It will be easier to do the de-embedding and specify the SDD11/SDD22 as seen by the chip from the channel.

The methodology specified currently in BP is suitable for chip to chip applications but not for backplane.
Where do you handle connector effect and multiple reflection between the connector-IC?  In 4Gig FC we addressed some of these issues and do specify the channel which include the connector. 

Thanks,
Ali

Just my own thoughts .....
-joel

Ali Ghiasi wrote:

Steve

Looking at your channel model, I see the return loss up to 15 GHz is
better than 12 dB.
How do you get -12 dB return loss at 15 GHz with connectors, what kind
of connector
are you assuming?   The most challenging effect are the primary
reflection between
silicon and the connector at this speed.

Thanks,
Ali

Stephen D. Anderson wrote:

   All:

   I updated the synthesized S-parameter files that I presented in
Portland.  The new revision provides a much better NEXT file.  The Thru
file was also improved so that SDD11 magnitude has ripples.  You may
recall that the previous SDD11 magnitude was flat over most frequencies
of interest and that this was viewed as unrealistic.

   These are intended to match the NEXT and Thru templates that we have
thus far agreed on.

   If you see anything blatantly wrong with the files, please let me
know.

   Regards,

   Steve A.

begin:vcard
fn:Ali Ghiasi
n:Ghiasi;Ali
org:Broadcom
adr;dom:;;3151 Zanker Road;San Jose;CA;95134
email;internet:aghiasi@broadcom.com
title:Chief Architect
tel;work:(408)922-7423
tel;cell:(949)290-8103
url:http://www.broadcom.com
version:2.1
end:vcard