[ibis-macro] Re: Updated AMI Flow BIRD

  • From: "Ken Willis" <kwillis@xxxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 29 Sep 2010 10:05:02 -0400

Hi Arpad,

This version is indeed spelled out more clearly with your updates, as it
explicitly covers the various combinations.

I have a question regarding your step 6d:

| Step 6d. If Tx GetWave_Exists is True and Rx GetWave_Exists is False, the
|          output of Step 5 is convolved with the output of Step 1 and the
|          Impulse Response of the Rx filter by the simulation platform and
|          the result is passed on to Step 8.  (The Impulse Response of the
|          Rx filter may be obtained by deconvolving the output of Step 3 by
|          the input of Step 3).

Would the following note be technically correct?

        Note: For the scenario where the Tx AMI_Init function does NOT
include         equalization effects (i.e. does not modify the impulse
response of the         channel), Step 6d is functionally equivalent to
simply convolving the   output of Step 5 with the output of Step 3.

If this is technically correct, please consider placing it after Step 6d.

Thanks,
 
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
 

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, September 29, 2010 1:47 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Updated AMI Flow BIRD

Ambrish,

Fangyi is absolutely correct, your new sentence in step 5b does not
solve
the double counting of the channel impulse response.  In addition, the
integrity of the reference flow is further degraded by adding this
sentence
because we are really dealing with another "truth table" in these steps,
depending on the Tx and Rx GetWave exists Booleans, but the discussion
of
these four conditions is spread out in many different places in the
reference
flow, which makes it very hard for the reader to understand what needs
to
be done under what circumstance.

This was exactly the reason I wrote my 9/23 version the way I did, by
adding another step number between Steps 5 and 6.  The problem with the
current Step 5a/b is that it only talks about Tx GetWave, and Step 6a/b
only talks about Rx GetWave.  In reality we cannot talk about these in
isolation, because the three different convolutions (plus the
deconvolution)
the EDA tool has to do depends on the COMBINATION of the Tx and Rx
GetWave
Booleans.  This is also the reason why I felt that the mention of
deconvolution is in a better place around Steps 5/6 than in the notes
of Step 3.

Your additional sentence from today is an attempt to start addressing
these
Booleans together like that, but it is only a baby step towards a clear
description including all possible combinations.

I spent a considerable amount of time in preparing my 9/23 version to
get
this right, which I think I did actually achieve.  It was fluffed off in
a big hurry, probably without due consideration of why it was written in
the way it was, and with a full understanding of what I actually wrote,
most likely because it did appear to be as if it was a lot of changes
for
no reason.  Well, I hope that you will understand now what the real
reason
was.  Please look at it one more time and read it a little more
carefully
and attentively.

I also owe you a response to your email from 9/24 (which was your reply
to
my 9/23 version of this draft), and say that I did not imply in any way
that
deconvolution is the only way.  If that's what you are getting out of my
writing, you are doing too much speed reading...  You wrote:

"In the last draft you mailed, the changes you made (and your statements
in the email) show that you believe that deconvolution is the only way
to achieve the final aim of accurate simulation when there is a TX dual
model and an RX Init model."

This is plain wrong!  Please note that I didn't change the text under
Step 3 which says that "the EDA tool can operate in one of several ways,
two of which are documented here".  I didn't change the wording "can be
obtained" in the following sentence either:

                            "the impulse response of the Rx filter can
|      be obtained by deconvolving the output of Step 3 with the input 
|      presented to Step 3"

which means it is not required to be done that way...

Also, in Step 6d of my 9/23 version I wrote:

                                              "(The Impulse Response of
the
|          Rx filter may be obtained by deconvolving the output of Step
3 by
|          the input of Step 3)"

Notice the words "may be", which expresses an option, not a requirement.

Regarding: "Your reference to doing Statistical Simulation in section
3.2 is plain wrong",
you misunderstood me there too.  I didn't say that the reference flow in
3.2 was to
be used for statistical simulations, I was just saying that those EDA
vendors who wish
to do statistical simulations together with time domain simulations
could benefit from
not having to run the Init functions one way for one simulation and
another way for
another simulation.  But this is only a small point in this discussion.

So, having said all this, I am attaching a new version of the BIRD draft
in which I went back to my 9/23 version of the reference flow in Section
3.2
without removing the latest additions about Use_Init_Output, and taking
care
of Bob's recent editorial requests in his 9/28 email that was sent out
after
the ATM teleconference.

I would like to make a special request to Fangyi to look at this version
of
the reference flow to be sure that I didn't make a mistake..., but
comments
from everyone else are welcome.

Thanks,

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



-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
fangyi_rao@xxxxxxxxxxx
Sent: Tuesday, September 28, 2010 6:46 PM
To: ambrishv@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Updated AMI Flow BIRD

Hi, Ambrish;

Can you explain to me how the double-counting of channel impulse
response is fixed? Take the case Tx_GetWave_Exists=False and
Rx_GetWave_Exists=False.

Step 1 output: h_AC

Step 3 output: h_TE*h_AC*h_RE

Step 4 output: p(t) (bit stream)

Step 5b output: h_AC*p(t)
(new sentence "if Rx GetWave_Exists is also False, the output of Step 4
is convolved with the output of Step 1" you add to 5b.)

Step 6b: h_AC*p(t) * h_TE*h_AC*h_RE
("If the Rx GetWave_Exists is False, the output of Step 5 is convolved
with the output of Step 3")

So h_AC is counted twice. Did I miss something?

Thanks,
Fangyi

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Tuesday, September 28, 2010 2:41 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Updated AMI Flow BIRD

Fangyi,
Thanks for pointing out the double counting in step 6 in section 3.2
during the call. I have added a sentence in step 5b that should fix the
issue. Please let me know if it addresses the issue you have raised.

Thanks,
Ambrish. 
 
 
Ambrish Varma   |  Member of Consulting Staff
P: 978.262.6431   www.cadence.com

---------------------------------------------------------------------
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: