[ibis-macro] Re: Question on seeting the EMD direction
- From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
- To: "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 26 Jun 2008 23:53:12 -0400
Arpad,
Not sure what you're getting at with your last point.
I think the first challenge we have with an interconnect modeling spec is
defining the problem we're
trying to solve, the intended applications and what assumptions we're willing
to make. Drawing from
an example earlier today, we need to state our assumptions about how things
like temperature and
process are represented.
There are two fundamental approaches to modeling interconnect as I see it:
1) An electrical equivalent modeling approach, providing a simulation model
that is precise and
accurate enough for an intended purpose
2) A physical description approach, describing the actual materials and
geometries so that
simulation tools can extract their own electrical equivalent models as needed
We've been talking about the first approach with EMD and ICM.
One challenge with simulation is the tradeoff between speed and accuracy
(actually, the tradeoff is
between speed and precision, but that's another discussion). Model detail is
one of the key
enabling elements of increased *precision*, and thus always gets caught up in
the argument. The
usual challenge to a given level of modeling detail is "yeah, but your model
doesn't represent such
and such a physical effect, and therefore it isn't accurate enough". Here as
before, we would be
better served if we distinguished between precision and accuracy.
The level of detail required is case-dependent, which is what makes these
discussions so difficult.
If you have a system that's close enough to the edge, physical effects that
don't matter in 9 out of
10 systems will still be the difference between success and failure in that one
case. If you try to
create the system (or language) that can represent any possible case, you'll
probably end up with a
system (or language) that no one wants to use (which is what I think Mike was
getting at).
So now what?
If I've followed the discussion correctly, thus far we've said we're interested
in created a spec
for modeling interconnect at the electrical level. I think we should spend
some more time hashing
out our mission statement - are we modeling interconnect for any purpose at
all? Over what
frequency range? For what purpose (for example, if we said we wanted to model
serial links for
periods < 10**17 bits, how big a factor would temperature variation be)?
The practical aspect here is that the more succinctly we can define our mission
statement, and the
more clearly we can articulate intended applications and fundamental
assumptions, the greater our
chance for success will be. If we can't clearly articulate these things, then
we're taking on a
very big task indeed.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi,
Arpad
Sent: Thursday, June 26, 2008 7:59 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Question on seeting the EMD direction
Let's put aside time constants, mechanical or cross talk
effects. My goal is to get a consensus on whether it is
safe to assume LTI for a new interconnect language (or
specification) we are just starting to develop for the
present day and future designs. I simply do not want it
to be obsolete by the time it is finished, or I do not
want to have to develop one specification after the other
because by the time one is done, another one is needed
because the one we just finished is not flexible enough
to take on some badly needed features.
I do not want to repeat history. To me it is quite
embarrassing that we spent 7 or so years on something
like ICM, or 3-4 years on something like the IBIS-AMS
extensions, etc... to find out that people are not
interested in using them for various reasons.
Lastly, regarding the old saying about user interfaces
(on the bottom of this message). I am a little
surprised to hear this quote from someone who favors
the C language for AMI modeling over other, somewhat
simpler, but limiting languages, such as VHDL-AMS,
Verilog-A(MS), Matlab, and the like... After all, C
is a "...language which is capable of expressing any
engineering problem..." isn't it? Either way, my
goal is not necessarily to achieve a language that is
capable of expressing ANY ENGINEERING problem, I just
want to propose a modeling language that is flexible
and expandable enough so that it doesn't paint itself
into the corner by the time it is released...
Comments?
Arpad
========================================================
-----Original Message-----
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Thursday, June 26, 2008 5:20 PM
To: Scott McMorrow
Cc: Muranyi, Arpad; IBIS-ATM
Subject: Re: [ibis-macro] Re: Question on seeting the EMD direction
Scott-
The whole area of crosstalk analysis is one in which our industry hasn't
had a lot of collective experience yet. There are several possible
techniques, and not a lot of agreement yet as to which techniques are
appropriate for which problems.
I'll be presenting a paper on the subject at the IEEE EMC conference in
Detroit this August. So as to avoid clogging up the e-mail reflector,
I'll send you a copy privately, and will be happy to send anyone else a
copy if they're interested.
Mike S.
Scott McMorrow wrote:
> Mike
>
> So now let's disregard a mechanical change to the system configuration
> and let's look at crosstalk impact on equalizer tap settings.
> How do you propose this be modeled and analyzed? How do you guarantee
> that you have selected the best possible settings?
>
>
> Scott
>
> Scott McMorrow
> Teraspeed Consulting Group LLC
> 121 North River Drive
> Narragansett, RI 02882
> (401) 284-1827 Business
> (401) 284-1840 Fax
>
> http://www.teraspeed.com
>
> TeraspeedR is the registered service mark of
> Teraspeed Consulting Group LLC
>
>
>
> Mike Steinberger wrote:
>> Scott-
>>
>> As regards mechanical configurations, I believe we agree.
>>
>> In particular, yes, we agree that if a channel can be put in an
>> unfavorable mechanical configuration, that mechanical configuration
>> must be analyzed.
>>
>> That still isn't a very good motivation for adding to the complexity
>> of an analysis for the majority of applications because someone could
>> think up an unusual case.
>>
>> Mike S.
>>
>> Scott McMorrow wrote:
>>> mike
>>>
>>> Where this becomes an issue is in equalizer training with low S/N
>>> ratio at the receiver, where very small changes in equalizer
>>> settings can result in very large changes in received BER. Some
>>> equalization training algorithms assume that the system is LTI
>>> during the training period. This may not be true for a card
>>> hot-swaped into a fully operational system, where crosstalk from
>>> adjacent channels is marginal at best. In order to test an
>>> equalization training algorithm pretty much requires that the time
>>> varying behavior of the network be considered. I've seen continuous
>>> linear analog equalizers that can be "tricked" by crosstalk into
>>> unstable operation.
>>>
>>> In the case of the vibrating vehicle and a twin-ax cable, it is
>>> quite possible to move the cable to a position where the
>>> multi-conductor transmission line develops a serious mode conversion
>>> issue at just the wrong frequency, causing a nasty S12 null. This
>>> happens with cables that have poor mechanical construction, or that
>>> are close to the edge of their operational range. If a mechanical
>>> vibration causes the shield to move a very small amount, it will
>>> drastically change the differential properties. Clearly this would
>>> cause increased BER, and it may be possible to re-equalize out of
>>> the problem, by boosting high frequency response within a specific
>>> frequency range.
>>>
>>> These are just considerations that designers must consider. (For
>>> example, selection of a cabling system with better mechanical
>>> stability.) But, since companies on this committee are tasked with
>>> developing modeling and simulation software to handle these sorts of
>>> communication channels, and generating equalizer coefficients is one
>>> of the most important tasks that has to be accomplished, then it
>>> might be necessary to consider non-LTI interconnect.
>>>
>>>
>>> regards,
>>>
>>> Scott
>>>
>>>
>>> Scott McMorrow
>>> Teraspeed Consulting Group LLC
>>> 121 North River Drive
>>> Narragansett, RI 02882
>>> (401) 284-1827 Business
>>> (401) 284-1840 Fax
>>>
>>> http://www.teraspeed.com
>>>
>>> TeraspeedR is the registered service mark of
>>> Teraspeed Consulting Group LLC
>>>
>>>
>>>
>>> Mike Steinberger wrote:
>>>> Arpad-
>>>>
>>>> Taking either Scott's case of a vibrating vehicle or Richard Ward's
>>>> even higher frequency case of a vibrating disk drive, how does the
>>>> highest frequency of vibration compare to the data rate of the
>>>> channel? I'm having a hard time imagining a significant harmonic
>>>> component above about 100kHz. Maybe I don't have much imagination,
>>>> so let's make it 1 MHz..
>>>>
>>>> Still, with that many orders of magnitude difference between the
>>>> mechanical frequencies and the electrical frequencies, any change
>>>> in electrical wave shape due to mechanical movement is going to be
>>>> insignificant, so the LTI approximation is still a good one.
>>>>
>>>> What I think these examples do suggest is that the designer of a
>>>> system that has mechanical vibration must analyze the channel
>>>> performance for a representative sample of the mechanical
>>>> configurations that will occur over the course of a cycle of
>>>> vibration. Thankfully, most of us won't have to execute that
>>>> procedure..
>>>>
>>>> I'm reminded of an old saying about user interfaces: "If an
>>>> interface is so easy to use that any fool could use it, only a fool
>>>> would." I think a similar statement applies to engineering
>>>> languages: "A language which is capable of expressing any
>>>> engineering problem is too complex to be useful for any engineering
>>>> problem."
>>>>
>>>> My 2c.
>>>> Mike S.
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
