| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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.
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 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.
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 From: Joel Goergen [mailto:joel@force10networks.com] Sent: Thursday, March 16, 2006 9:32 AM To: STDS-802-3-BLADE@listserv.ieee.org Subject: Re: [BP] Simulations for EIT 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:
|