[ibis-macro] Re: Question on seeting the EMD direction
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 26 Jun 2008 16:58:57 -0700
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
>
> Teraspeed® 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
>>>
>>> Teraspeed® 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
Other related posts:
