Re: [BP] Simulations for EIT
Howard,
What I think Joel is saying, and I agree, is that the standard may allow
certain magnitudes for various parameters, but it doesn't follow from
anything that has been written down that all these extreme values must
mercenarily be combined into one super-worst case and be demonstrated to
work. Clearly there are trade-offs involved and here is where smart
system design that Joel is talking about comes in. The standard may alow
1200 mV TX amplitude, but it doesn't mean you can apply that to a system
with worst-case noise coupling, worst-case return and insertion loss,
and get away with it. If you have a design with a lot of coupling then
clearly you should dial your TX amplitude down, which means you can't
pre-emphasize as much, which means you need to improve the transmission
qualitieis of your channel and/or drill the vias out. Alterantively if
you don't want to do that then re-layout the channels and make them less
cross-talkey, and group the TX's and RXs. Now, worst case simulations
are good in that they increase one's understanding of limits of the
design capability, and that was the reason Molex originally provided 1 m
FR4 channels, but it's hard for me to see why at this stage of the draft
development simulations should be used to argue against individual
portions of the spec. 1200 mVpp should still be allowed even if it makes
a worst-case crosstalk channel fail, because someone may have a channel
not quite as bad.
Gourgen
-----Original Message-----
From: Howard A. Baumer [mailto:hbaumer@BROADCOM.COM]
Sent: Thursday, March 16, 2006 1:05 PM
To: STDS-802-3-BLADE@listserv.ieee.org
Subject: Re: [BP] Simulations for EIT
Joel,
I don't quite see what you're getting at. It has been a long time
since simulations have been run on these three channels and everyone
that wants their work to be part of the decision process needs to rerun
simulations based on what is in the draft. Magesh and I are going to
run simulations that are what has been spelled out plus worse casing the
transmitter (launch amplitude and transition time of thru vs crosstalk)
plus worse casing the delay relationship between the channel and the
transceiver which cannot be tested. These are all real life items that
do fall within the realm of good and proper design practices.
If the standard is going to allow 1200mVppd to be a valid
transmitter output drive strength then we better simulate with it. If
the standard is going to allow transition times from 24-47ps then we
better simulate with it. If there is something that cannot be tested
then we better simulate that as well. Since the group doesn't like to
rely on just one set of results I'm just asking others to contribute as
they have before.
If you don't think the channels that were chosen for these
simulations are the ones to use for simulations then what are the
channels we should be using?
The working group needs to show how the standard guarantees
interoperability. To do this we have to pick a set of channels that are
deemed "working". Demonstrate that a transceiver which passes the
standard will create a produce a working system when coupled with these
channels. If this has already been done then please point me to the
presentations that show this.
Howard
Joel Goergen wrote:
> Howard/John/Rich and all interested ...
>
> Though I don't agree completely with Howard's discussion, I see a
> theme appearing in this thread. When combined with comments that have
> been placed against the draft document, it looks as if we are covering
> the same ground already covered from day one. And to be blunt, it is
> getting old. Every time I think the working group is past an issue,
> it pops back up in some other form, but same message.
>
> Design Methodology combined with a Normative Channel:
> We can't agree on this in OIF where it is one company/one vote ... it
> would never happen with individual votes involved to write a document
> that details design criteria for a specific speed differential channel
> covering signal, material, tx, rx, power noise, connector, cross talk,
> chip and packaging. All this laying route to a normative definition
> of a channel set and connector that a five year old could design
> without issue.
>
> There are always cases out there that are going to stress the
> definition ( the draft ) we are working on. When do you stop trying
> to find cases and focus on what 80% of the designers would do in a
> channel ... maybe even as low as 60%? When do you stop dragging out
> the work efforts for cases that don't make sense and are really
> related to research a company or individual should have to design a
> channel?
>
> Cases That Don't Make Sense:
> Systems companies have to put a certain level of practical thought
> into a design. I realize that when a system doesn't work, the chip
> vendor is the one squeezed. But whose fault is that? Most vendors
> have detailed white papers on how to avoid poor design practices ...
> or at least defining them. If a system design does not follow
> recommended practice, how does that relate to the standard and why
> should a vendor panic to solve a problem beyond the scope of what is
> reasonable in the design. I know ... easier said, but still ... come
> on! Just once wouldn't you like to ask a customer what they were
> thinking when they did the design? Or at the very least suggest they
> tighten the bulb a bit?
>
> We defined early on the test cases we would use to verify the work.
> Are we adding to it or changing it, and if so, why? Back plane design
> is based on design methodology and channel design. We have done our
> best to identify practice along the way. But you will never prevent
> someone from doing the unforgiven. If we are not going to stop here,
> beyond the additional work we have all gone through the past two years
> to include minimum channels, then we should go on to identify chip
> packaging and pin placement, gate loading, trace width, pick a
> specific finish, and finally ... a connector. Where do you finally
> stop cases and definition?
>
> I think each of us needs to take a hard look at our comments and our
> input .... decide what is enough, and move on. Good work has been
> done here.
>
> thanks
> -joel
>
>
> Howard A. Baumer wrote:
>
>> Rich, John,
>> I'm not saying don't do the simulation set with the listed
>> conditions from Charles that have the victim (thru) and aggressors
>> (crosstalk) at the same level. I'm putting out there that everyone
that
>> is going to run simulations to also look at the condition when
>> everything is worse case. Because we allow 1200mVppd to exist there
>> could be a case where we have the victim at 800 and the aggressors at
>> 1200. Remember the aggressors are alien aggressors, that is you
can't
>> count on your transmitter as the largest source of next, the largest
>> source could be from another part where the silicon doesn't have
control
>> of the tx output amplitude. We will be simulating these more
extreme,
>> but allowed, conditions.
>>
>> Another note, I'd like to propose the first set of conditions
have
>> a transmit transition time of 42ps at the output of the package
model.
>>
>> Howard
>>
>>
>> Mellitz, Richard wrote:
>>
>> >Maybe next should be same as victim and Fext should be higher.
>> >... Ric
>> >
>> >-----Original Message-----
>> >From: DAmbrosia, John F [mailto:john.dambrosia@TYCOELECTRONICS.COM]
>> >Sent: Wednesday, March 15, 2006 7:16 PM
>> >To: STDS-802-3-BLADE@listserv.ieee.org
>> >Subject: Re: [BP] Simulations for EIT
>> >
>> >Howard,
>> >My only concern with your suggestion regarding the amplitude of the
>> >crosstalk is that we agreed to use the lower voltage because that is
>> the
>> >only level that can be guaranteed. Your simulation condition
supplies
>> >that the higher level is available, and ok that is fine, but if it
is
>> >available for the aggressor it would be available for the victim as
>> >well.
>> >
>> >John
>> >
>> >-----Original Message-----
>> >From: Howard A. Baumer [mailto:hbaumer@BROADCOM.COM]
>> >Sent: Wednesday, March 15, 2006 1:17 PM
>> >To: STDS-802-3-BLADE@listserv.ieee.org
>> >Subject: Re: [BP] Simulations for EIT
>> >
>> >Charles,
>> > When are we planning the next channel adhoc phone conference?
>> >Should we have one sometime next week? One possible set of goals
would
>> >be to report the results for the listed General Idea #1, simulation
of
>> >the selected channels with the selected conditions.
>> > I noticed an item missing from these conditions, the transmit
>> >transition time. What does the group thing we should put this at?
>> Also
>> >
>> >a second set of simulations on these channels under more worse case
>> >condtions should be done. I'd recommend the change to the
>> conditions to
>> >
>> >be: Tx amplitude target=800mVpp, crosstalk=1200mVpp; Tx equalization
>> for
>> >
>> >crosstalk set to the preset state; add ideal delays between the
>> >transmitter and channel and between the channel and receiver such
>> that a
>> >
>> >worse case result is obtained. Any other worse case conditions not
>> >already covered?
>> >
>> >Howard
>> >
>> >
>> >
>> >
>>