[ibis-macro] Re: FW: [IBIS-Users] AMI convolution
- From: "Mellitz, Richard" <richard.mellitz@xxxxxxxxx>
- To: Mike Steinberger <msteinb@xxxxxxxxxx>
- Date: Mon, 23 Nov 2009 11:18:46 -0700
Hi Mike,
Please help me understand. I don't really follow port 1-4. The simplest view to
me is a source, load, and channel. How does port 1-4 map? If you are referring
to the following
+---------+
1 ---| channel |---2
3 ---| |---4
+---------+
I understand. You can replace Sxy with SDDxy below and Gamma_aa with
Gamma_Diff_aa. That's why I used a simple flow analysis.
The effect of port loss on VTF is a rational function. I don't understand how
to do arithmetic decomposition of the VTF unless we know gamma and channel
return loss.
... Rich
-----Original Message-----
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Monday, November 23, 2009 11:24 AM
To: Mellitz, Richard
Cc: Scott McMorrow; wkatz@xxxxxxxxxx; IBIS-ATM
Subject: Re: [ibis-macro] Re: FW: [IBIS-Users] AMI convolution
I haven't checked your equation, but it looks about right for a single
ended transmission path (which we never use).
The next step is to make the path a differential transmission path. To
keep things simple, define H12(w) to be the voltage transfer function
for the two port network in your example, and suppose further that port
1 is the true input port and port 2 is the true output port.
Now define port 3 as the complement input port and port 4 as the
complement output port. Calculate H34(w) as the transfer function from
complement to complement and calculate H14(w) and H32(w) as the transfer
functions for the cross-coupling between true and complement ports, and
vice-versa. Note that these additional transfer functions require at
least two port S parameters for the driver and receiver and four port S
parameters for the network.
Then the differential mode transfer function from input port pair to
output port pair is
Hdd(w) = H12(w) + H34(w) - H14(w) - H32(w)
This is what we typically use in subsequent communications analysis as
the transfer function of the channel.
You and others have quite correctly observed that there is a common mode
as well as a differential mode, and that the common mode can't be
altogether ignored. Brian Kirk also presented a paper on the subject at
DesignCon2009. Thus, there is a common mode transfer function
Hcc(2) = ( H12(w) + H34(w) + H14(w) + H32(w) )/2
and there are similar transfer functions for cross-coupling between
differential and common modes, and vice-versa.
Since we're consistently assuming that the electrical network is linear,
all of these transfer functions can be calculated from two port S
parameters for the driver and receiver and four port S parameters for
the network. Note also that that's more degrees of freedom than the
algorithmic model has available to it, but that the analog model has
already has all those degrees of freedom at its finger tips.
Hope this helps.
Mike S.
Mellitz, Richard wrote:
> Let's take this one step at a time. Let's start with port loss. I don't want
> to mix metaphors by going directly modal issue yet. I may be missing
> something in IBIS-AMI so help me understand this "baby step".
>
>
> It look to me like we are taking about the voltage transfer function (VTF).
> Forget the other modes for now. If I have a step response of a channel and
> don't know the impedance (really s11, s22) how can I find system voltage
> transfer function. In the frequency domain; for a channel, source, and load
> the VTF is.
>
> (Gamma_src-1)*s21*(Gamma_ld+1)
>
> ---------------------------------------------------------------------------------
> 1-s12*s21*Gamma_src*Gamma_Ld+s11*s22*Gamma_src*Gamma_Ld-s11*Gamma_src-s22*Gamma_ld
>
>
> Gamma_src=Source reflection
> Load_ld=load reflection
> S11,s22,s21,s12 = 2 port channel s-parameter
>
> This if is we consider all is linear.
>
>
> ...Rich
>
> -----Original Message-----
> From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
> Sent: Thursday, November 19, 2009 12:17 PM
> To: msteinb@xxxxxxxxxx
> Cc: Mellitz, Richard; wkatz@xxxxxxxxxx; IBIS-ATM
> Subject: Re: [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
>>
>>
>>
>
>
---------------------------------------------------------------------
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:
