Pat,
You missed my point entirely ..... see below.
Pat Thaler wrote:
Joel,
If we take that view, why do any
standard at all? We do a standard because we want to allow for
interoperability between independently designed implementations. In
backplane, we aren't specifying form factors, connectors, etc. so the
interoperability goal is between the transcievers.
The issue is 'when will it be good enough?' If we didn't take that
view, we would still be working on DMD fibers from gigE.
Whether the channel model is
normative or informative, the only way we have to analyze whether we
have acheived the interoperability goals of a standard is to look at
the combination of transmitter, channel, and receiver with interference
from other transmitter/channel/receiver sets where each component is
operating within the bounds of the standard.
I agree ... and we have a set we agreed to test and verify with. No we
want to add additional verifications/channels/concepts and I do not
understand why. Is it because someone has a chip that they cannot make
work to the draft ... or that they believe won't work to the proposed
draft? I'm not hearing any vendors say this draft won't work for them
or the end users.
I don't know of any case where
we have aimed our interoperability goal as low as 80%. Usually our goal
has been something like 99%. I don't mean 99% with any kind of awful
channel that someone could create, but 99% when the channel is within
the model we put in the standard and the transmitter and receiver are
within spec.
That is not what I said ... re-read it. I said the designer ... not
the operability of the design. I was referring to the design rules
that 80% or 60% of engineers would apply to this type of model ... then
base your test concepts to capture 100% of that. Design philosophy is
the key here. A designer has to have a certain level of knowledge that
we should not have to put into the standard to train them on what is
good or bad.
If the standard allows for some
transmitters to be operating at 800 mV while others are at 1200 mV, we
need to simulate the system under those conditions and see that it
works.
Pat ... the standard allows for all kinds of stuff. Just like every
other standard. We don't want to limit the solution set. Yes ...
there are cases that could happen. But this isn't a state machine
here. There are cases that just should not happen because it is bad
design. if Howard's case is a legitimate good design practice/result,
then his idea maybe should be included. I didn't disagree. I merely
asked when will it be enough?
Further, if we add this case, then we should add every case involving
material reflections, glass combinations, trace geometry, and trace
length ... as well as every tx and rx. And what about the guy who adds
more tx and rx taps then everyone else? We would be doing simulations
forever.
no, I don't support a poor standard. I do support the work and effort
that goes into a good one. I simply believe that a designer needs to
have a certain level of experience to design what we are drafting.
-joel
Pat
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
>
>
>
>
|