Re: [BP] Simulations for EIT
Rich,
This is exactly what I was asking for. Let's do the resonable constraint
that Charles first published and then also look at the more worse case
constraint as well. We can then discuss which constraints we can
control, which ones cause the most difference and which ones we feel
confortable changing in the draft, if any.
Howard
Mellitz, Richard wrote:
> Ya know… I just did a statistical analysis of the probability of units
> failing the return we just voted on. Under some assumptions I made, I
> came up with 2.5 units per 1000 would fail RL and still pass. I heard
> folks thought this might be something like 90%. The design question is
> what quality level is acceptable. I understand this from a business
> perceptive because I can relate it to cost. I don’t know how to apply
> this to standard work. Maybe it does mean all limits at the worst case
> must work regardless of the likelihood. Maybe this is a Pandora’s Box
> too. I think our cost is not dollars but delay producing a workable
> standard.
>
> The 80% Joel was talking about was design engineers. This is not the
> statistics of a design’s quality. If I +/-3 sigma all our limits in
> the spec, I think we are more like in the 99.9+% quality range right now.
>
> The task at hand was to determine if the informative channel spec
> sufficiently predicted confidence related to the EIT receiver test.
> That why we used the term “confidence” and not “limit.” Remember that
> is why we chose the channel to be informative. We showed we couldn’t
> constrain all 3 (tx, channel, rx) and create a reasonable and
> marketable solution. So in light of that I believe we should constrain
> the analysis to reasonable. Maybe we should do it both ways and
> discuss what is reasonable at April 19 meeting.
>
> … Rich
>
> ------------------------------------------------------------------------
>
> *From:* Joel Goergen [mailto:joel@FORCE10NETWORKS.COM]
> *Sent:* Thursday, March 16, 2006 6:06 PM
> *To:* STDS-802-3-BLADE@listserv.ieee.org
> *Subject:* Re: [BP] Simulations for EIT
>
> 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
>
> ------------------------------------------------------------------------
>
> *From:* Joel Goergen [mailto:joel@force10networks.com]
> *Sent:* Thursday, March 16, 2006 9:32 AM
> *To:* STDS-802-3-BLADE@listserv.ieee.org
> <mailto:STDS-802-3-BLADE@listserv.ieee.org>
> *Subject:* Re: [BP] Simulations for EIT
>
> 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
> <mailto: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
> <mailto: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
>>
>>
>>
>>
>