[ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference

  • From: Ambrish Varma <ambrishv@xxxxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 21 Apr 2010 21:08:24 -0700

Arpad,
Your observations are correct. Use_Init_Output does allow the model maker to 
have effectively the same algorithms in Init and Getwave. It's a case of 'can' 
and 'should' as you pointed out in one of your earlier mails. I keep pointing 
out to you the intent of section 2.1 and 2.2 and the default value in the 
definition of Use_Init_Output and not the possibilities. This is how I 
understand what the intent was: in section 2.1, we don't need a getwave, why - 
because init was necessary and sufficient. In section 2.2, however, we do need 
a getwave - why - because Init is NOT sufficient.
But - as you said, we did leave the door open ...

When I wrote to you about separating the TD flow and the Stateye flow - I meant 
separating it visually, in your slides - to fix the issue Walter pointed out 
yesterday. Basically when the user wants a Stateye type simulation, the EDA 
tool takes into account only Init and is done. The path would look like this:
Obtain Channel Impulse Response (hAC(t)) --> Tx_Init call (hAC(t) x hTEI(t))--> 
Rx_Init call (hAC(t) x hTEI(t) x hREI(t)) --> Stateye type analysis.

What you have already in the slide can be kept as is for TD simulation. I have 
attached a crude representation.

Thanks,
-Ambrish.

________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Muranyi, Arpad
Sent: Wednesday, April 21, 2010 7:24 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference

Ambrish,

I would like to see how you came to the conclusion that
"If you separate the Stateye flow with the TD flow, we will have what the spec 
says currently".

I re-read the spec once again to find out how you came to that
conclusion, but my reading resulted in the opposite conclusion.

1)  pg. 181, 2.1 Linear, Time-invariant Equalization Model:

[cid:image001.jpg@01CAE1AF.2AA67980]

This implies (although not stated), that for the LTI (or Stateye) flow
the Init_Returns_Impulse Boolean must be set to true.

2)  On pg.182, 2.2 Nonlinear, and / or Time-variant Equalization Model
    I read the following:

[cid:image002.jpg@01CAE1AF.2AA67980]

This is now talking about the non-LTI flow.  Note that it says that
"AMI_Init may also compute the impulse response of the block...".
This means that the Init function can still return a modified impulse
response even if we are doing a non-LTI analysis with GetWave.

3)  pg. 144, GetWave_Exists says:

[cid:image003.jpg@01CAE1AF.2AA67980]

Note that is says "if Init_Returns_Impulse is set to "False"..." basically
GetWave must exist.  This means that the only time Init is allowed not to
return a modified impulse response is when we do a non-LTI analysis with
GetWave.  But notice that it doesn't say that if GetWave exits, 
Init_Returns_Impulse
must be False, or in other words, it doesn't say that when we are ding a
non-LTI analysis with GetWave, the Init function is not allowed to calculate
a modified impulse response.

There are several things we can conclude from this:

- if the Init function doesn't calculate the modified impulse response,
GetWave will have to include the algorithm to do that calculation

- the spec doesn't say anything that this algorithm may not be duplicated
in the Init and GetWave functions, i.e. this duplication is not forbidden

- this means that the model writer has a choice to put the algorithm
that is responsible for calculating the modified impulse response into
either the Init or the GetWave function or both

- if there is a duplication of this algorithm in both Init and GetWave,
the model maker may set Use_Init_Output to False so that double counting
is prevented in the results

- with this approach one can build a parallel path for the LTI (or Stateye)
and non-LTI (or TD) calculations within the same model without the danger
of double counting for any effects


Clearly, the authors of the specification left it up to the model maker
to decide whether the modified impulse response is calculated in the
Init or the GetWave function or both.  One approach could be to "factor
it out" and put the LTI part of the algorithm into the Init function and
put the non-LTI portions of the algorithm into the GetWave function,
but one could also put the entire thing into the GetWave function and
have a duplicate LTI algorithm or a similar LTI approximation in the
Init function.

This is what I am reading from the EXISTING specification.  I would like
to get a similar detailed analysis from you that explains how you arrived
to the opposite conclusions based on the current specification.  I am not
asking this to give you a hard time, I am making this request to find out
why the existing specification can be interpreted in such completely
different ways so that we can fix the spec and eliminate the possibilities
for such misinterpretations in the future.

Thanks,

Arpad
============================================================================


________________________________
From: Ambrish Varma [mailto:ambrishv@xxxxxxxxxxx]
Sent: Wednesday, April 21, 2010 3:52 PM
To: Muranyi, Arpad
Subject: RE: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference
Arpad,
If you separate the Stateye flow with the TD flow, we will have what the spec 
says currently. I think the issue with what you had yesterday was the mixing of 
the 2 flows together.
Let me know if you want me to elaborate.
-Ambrish.

JPEG image

JPEG image

JPEG image

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 04-2010