[ibis-macro] Re: FW: [IBIS-Users] AMI convolution
- From: "Eric Sweetman" <esweet@xxxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 19 Nov 2009 09:55:11 -0800
Scott, Vladimir and Mike,
Using only a differential model (SDD11, SDD12, SDD21, SDD22)works OK if
everything is balanced and AC-coupled. It ignores TX/RX common-mode
effects in DC-coupled architectures and system interconnects with skew
(unbalanced connector path lengths, unbalanced BGA fanouts, etc.). At
10 Gbps we can probably still get away with these assumptions but,
beyond that, I'm not sure.
Eric Sweetman
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Dmitriev-Zdorov,
Vladimir
Sent: Thursday, November 19, 2009 9:34 AM
To: scott@xxxxxxxxxxxxx; msteinb@xxxxxxxxxx
Cc: richard.mellitz@xxxxxxxxx; wkatz@xxxxxxxxxx; IBIS-ATM
Subject: [ibis-macro] Re: FW: [IBIS-Users] AMI convolution
Scot,
You correctly pointed out to existing limitation of the current AMI
approach. Working with single response only, we cannot consider some
effects, for example conversion of the Tx common signal into Rx
differential. The scalar waveform is thought either as voltage in single
ended connector or as differential signal in differential connection.
If we assume that all we need is difference signal at Rx input, and the
Tx's analog output assumed LTI, then we'd suffice with only two transfer
responses: diff at Tx to diff at Rx and common at Tx to diff at Rx. But
if we also decide to consider non-linearity of Tx analog output, then
we'd need a couple more, for example input admittance of the channel as
seen from Tx, both difference and common mode.
Vladimir
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Thursday, November 19, 2009 10:17 AM
To: msteinb@xxxxxxxxxx
Cc: richard.mellitz@xxxxxxxxx; wkatz@xxxxxxxxxx; IBIS-ATM
Subject: [ibis-macro] Re: FW: [IBIS-Users] AMI convolution
It seems to me that a 2-port interface from a driver or receiver to the
interconnect environment would be sufficient to characterize all
multi-conductor interconnect modes, assuming that there is no
driver-to-driver, receiver-to-receiver, or receiver-to-driver analog
interactions on the silicon.
Mike Steinberger wrote:
> Rich-
>
> The output of the algorithmic model is a one dimensional waveform. If
> you want to model modal behaviors, that will have to be done in the
> analog model. For example, that's where the S parameter behaviors you
> refer to are modeled; and depending on the EDA platform, those S
> parameters can be multiconductor.
>
> By the way, what important modes do you think should be modeled?
>
> Mike S.
>
> Mellitz, Richard wrote:
>>
>> Hi Walter,
>>
>> I was thinking about this some. Does this flow preclude a modal
>> impulse response flow? The single channel voltage transfer impulse
>> response really requires 4 entities based on s11, s21, s12, and s22.
>> A multi-conductor response requires more.
>>
>> ... Rich
>>
>> *From:* ibis-macro-bounce@xxxxxxxxxxxxx
>> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Walter Katz
>> *Sent:* Wednesday, November 18, 2009 12:14 PM
>> *To:* IBIS-ATM
>> *Subject:* [ibis-macro] FW: [IBIS-Users] AMI convolution
>>
>> All,
>>
>> In case you are not in ibis-users@xxxxxxx .
>>
>> Walter
>>
>> Walter Katz
>>
>> 303.449-2308
>>
>> Mobile 720.333-1107
>>
>> wkatz@xxxxxxxxxx
>>
>> www.sisoft.com
>>
>> -----Original Message-----
>> *From:* Walter Katz [mailto:wkatz@xxxxxxxxxx]
>> *Sent:* Wednesday, November 18, 2009 12:00 PM
>> *To:* Eric Monteiro; ibis-users@xxxxxxx
>> *Subject:* RE: [IBIS-Users] AMI convolution
>>
>> Eric,
>>
>> Asking who is responsible for convolution is like asking who is
>> responsible for Fourier Transform. Convolution is a mathematical
>> technique that EDA tools can use on the input and output of AMI
>> models, and convolution is a mathematical technique that can be used
>> inside of the AMI model to apply a filter. The following describe who
>> may or must use convolution for the "Preferred Flows". Preferred
>> flows assume both the Tx and Rx model have Init_Returns_Filter=True
>> and Use_Init_Ouput=True.
>>
>> Assuming a preferred statistical flow, the EDA tool supplies an
>> impulse response of the channel to the TX Init function. Inside the
>> Tx Init function (i.e. inside the AMI model), the model would compute
>> an impulse response of its filter and return it to the EDA tool. The
>> EDA tool would convolve this impulse response with the impulse
>> response of the channel and present these results to the Rx Init. The
>> Rx Init would determine the impulse response of its filter, and
>> return it to the EDA tool. The EDA tool would then convolve it with
>> the impulse response that was presented to Rx Init to determine the
>> impulse response of the channel equalized by both the Tx an Rx
>> filters. The EDA tool will process this and may use the convolution
>> mathematic technique (e.g. on probability distribution functions) to
>> generate bathtub curves and bit error rates. So in the preferred
>> statistical flow the EDA tool does convolution and the AMI model
>> might not. I could image that the AMI models may use the convolution
>> technique to generate the impulse response of the filter.
>>
>> Assuming the preferred time domain flow, the EDA tool must first run
>> the statistical flow (it need not analyze the results of Rx Init).
>> The EDA tool supplies a stimulus waveform to Tx GetWave. The EDA tool
>> may or may not use the convolution generate this waveform. The Tx
>> GetWave will generate an equalized stimulus waveform with techniques
>> that may or may not use convolution. The EDA tool must us uses
>> convolution to apply the impulse response of the channel with this Tx
>> equalized stimulus waveform. The waveform is then presented to Rx
>> GetWave. Rx GetWave may or may not used convolution to apply its
>> equalization filter to it's input. The output of Rx GetWave is a
>> waveform, and clock ticks. The EDA tool may or may not use
>> convolution to analyze this waveform to generate bathtub curves and
>> bit error rate. So in the preferred time domain flow, the EDA tool
>> must use convolution, and the AMI model might not.
>>
>> Walter
>>
>> Walter Katz
>>
>> 303.449-2308
>>
>> Mobile 720.333-1107
>>
>> wkatz@xxxxxxxxxx
>>
>> www.sisoft.com
>>
>> -----Original Message-----
>> *From:* owner-ibis-users@xxxxxxx [mailto:owner-ibis-users@xxxxxxx]*On
>> Behalf Of *Eric Monteiro
>> *Sent:* Wednesday, November 18, 2009 10:55 AM
>> *To:* ibis-users@xxxxxxx
>> *Subject:* [IBIS-Users] AMI convolution
>>
>> Hi everyone,
>>
>> I was hoping someone could clarify who is responsible for convolution
>> in IBIS-AMI (EDA tool, or the modeler).
>>
>> Clearly the convolution involving an FIR filter is upon the modeler,
>> the convolution I speak of is the one that is done with the channel
>> response.
>>
>> My understanding has been as follows: (please correct me if I'm
wrong)
>>
>> (a) -- (Tx IC) -- (passive channel) --(b)--(Rx IC)
>>
>> You force an impulse at (a), measure the response at (b). (b) is the
>> analog channel response hAC(t). GetWave then needs a wave, which
>> should be an ideal bit train, convolved with the bit period (creates
>> a piece wise linear wave) which is then convolved with hAC(t) to
>> produce the wave fed into GetWave. There was discussion as to whether
>> the modeler or the EDA tool should do the above convolution. Has it
>> been decided who this task falls on?
>>
>> Best Regards,
>>
>> Eric Monteiro
>>
>>
------------------------------------------------------------------------
>>
>> This communication contains confidential information intended only
>> for the addressee(s). If you have received this communication in
>> error, please notify us immediately and delete this communication
>> from your mail box.
>>
>>
>> --
>> This message has been scanned for viruses and dangerous content by
>> *MailScanner* <http://www.mailscanner.info/>, and is believed to be
>> clean.
>>
>
> ---------------------------------------------------------------------
> 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
>
>
--
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(r) is the registered service mark of Teraspeed Consulting
Group LLC
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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:
