[ibis-macro] Re: Updated AMI Flow BIRD
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 24 Sep 2010 10:35:18 -0700
I guess I can live with this version too.
The last question I need to ask about this BIRD draft
is how we should handle the deprecation of Use_Init_Output
at the end of the BIRD. From what I think I heard in the
last ATM meeting, we said that we will not allow this
Boolean in the new specification. If that is correct,
we should make changes at the end of the BIRD to reflect
that decision.
Any comments, suggestions?
Thanks,
Arpad
===========================================================
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, September 24, 2010 11:49 AM
To: kwillis@xxxxxxxxxxx; ambrishv@xxxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: Updated AMI Flow BIRD
All,
This draft also looks good to me, I concur.
Walter
Walter Katz
303.449-2308
Mobile 303.883-2120
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Ken Willis
Sent: Friday, September 24, 2010 11:48 AM
To: ambrishv@xxxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: Updated AMI Flow BIRD
Hi,
This draft also looks good to me and am ready to move forward with it.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Friday, September 24, 2010 1:19 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Updated AMI Flow BIRD
Arpad,
Your changes in response to 2 seem correct and I am glad we are on the
same page with 1 and 3 as well. With respect to 4, however, your changes
(both addition and removal) breaks the 'flow' - not literally but how
they are presented.
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. The way we presented in the last version,
however, shows that it is *one* of the ways. There is a difference.
Responses to your objections are inline:
4) You cannot make that deconvolution part of Step 3 depending on
the existence of Tx GetWave and the value of Init_Returns_Impulse,
and the EDA tool's (or its user's) decision on how to avoid the double
counting, because conceptually if an EDA tool wants to do statistical
and time domain simulations in one shot, they would want to use the
real output of Step 3 in both analyses.
>> Your reference to doing Statistical Simulation in section 3.2 is
plain wrong. We are talking about Time domain flow in this section and
time domain flow alone. Statistical flow is covered in 3.1. Besides, the
EDA tool should know when it is doing a time domain and statistical
simulation and create inputs for them as required. It is just a matter
of writing an if else loop.
Also, the output of Step 3 may
be used as is in the case when neither GetWave functions exist, so
to me it feels that talking about deconvolution as part of Step 3 is
not appropriate.
>> Of course the output of step 3 may be used as is when neither GetWave
function exists. This whole discussion is for when there is a dual mode
at the TX and Init only model at RX. I quote:
| Step 3. The output of Step 2 is presented to the Rx model's AMI_Init
| function and the Rx AMI_Init function is executed.
Thus the default output of step 3 is IR--> TX_Init --> RX_Init.
In addition, your sentence "In this case, the output of Step 3 will
include only the equalization effects from the Rx AMI Init function."
bothers me because I have no idea what you mean by "equalization
effects".
>> By equalization effects I mean the actual RX filter or h_REI(t). I
have changed the wordings to say that it returns the impulse response of
the RX Filter.
I have accepted the changes for 1, 2 and 3 and rolled back your changes
for 4 (with the changes in step 3). I believe that this is a good draft
and we should move ahead with this.
Best regards,
Ambrish.
Ambrish Varma | Member of Consulting Staff
P: 978.262.6431 www.cadence.com <http://www.cadence.com>
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, September 23, 2010 8:53 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Updated AMI Flow BIRD
Ambrish,
As promised in the last ATM meeting, I am now continuing the discussion
of these comments in email.
I agree with your changes for comments 1 and 3. As far as I am
concerned,
we are done with those comments.
However, I do not agree with your changes you made for comment #4, and
with your response to comment #2.
2) Step 9 of Section 2.2 mentions very explicitly that if Tx GetWave
doesn't exist, the output of Step 7 (which is the bit pattern) is
convolved with the channel's impulse response in the EDA tool. The
reason this is wrong is because later in the reference flow (Section
3.2)
we say something different for the case when Tx GetWave doesn't exist.
There we say that we take the output of Tx Init (and not just the IR
of the channel) for the convolution with the bit pattern. We have to
match what we are saying in these two places. I made changes to fix
this in the attached version of the BIRD draft.
4) You cannot make that deconvolution part of Step 3 depending on
the existence of Tx GetWave and the value of Init_Returns_Impulse,
and the EDA tool's (or its user's) decision on how to avoid the double
counting, because conceptually if an EDA tool wants to do statistical
and time domain simulations in one shot, they would want to use the
real output of Step 3 in both analyses. Also, the output of Step 3 may
be used as is in the case when neither GetWave functions exist, so
to me it feels that talking about deconvolution as part of Step 3 is
not appropriate.
In addition, your sentence "In this case, the output of Step 3 will
include only the equalization effects from the Rx AMI Init function."
bothers me because I have no idea what you mean by "equalization
effects".
I would like to keep the output of Step 3 the output of the Rx Init
function, and deal with the deconvolution later, in Step 6b. This
would make a lot more logical sense, since in Steps 5a, 5b, 6a and
6b we are already addressing the different actions due to different
conditions. The need for deconvolution is one of these conditions,
and its discussion belongs to this area of the flow.
I am attaching another version of this BIRD draft with changes I made
to fix these problems. In this version I removed the two sentences
you added to Step 3 and Steps 5 and 6 became Steps 5-6a/b/c/d-7.
Thanks,
Arpad
========================================================================
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Tuesday, September 21, 2010 12:40 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Updated AMI Flow BIRD
Hi Arpad,
Thanks for reviewing (and fixing) the BIRD. I have tried to address the
issues that you have brought up with a new version (attached). I have
accepted all of the previous changes so we have a clean doc to work
with.
Briefly, the edits are: (corresponding to your points)
1. I removed the revised section you are talking about. In my
opinion, the original text is good enough and there is no need to revise
the original text.
2. I disagree with you on this one. We are not talking about a Tx,
Rx (system) simulation here - so cannot say anything about Tx_Init. We
have to include Tx_GW, however, because input to Tx_GW is different from
Rx_GW.
3. I have taken care of this by removing this line from 2.1 and
2.2 (they are not system simulation anyway). Good catch - thanks.
4. I have clarified that if the EDA tool chooses deconvolution,
the output of Step 3 is h_REI(t). However, if the EDA tool chooses to
implement choice 1, it will contain h_TEI(t) * h_REI(t) but ignore Tx
GetWave. (it's the EDA tool's call and we have decided (as a group) to
give that option to the EDA tool)
Again, thanks for reviewing the BIRD. We can discuss any further issues
in the upcoming conference call.
Regards,
Ambrish.
Ambrish Varma | Member of Consulting Staff
P: 978.262.6431 www.cadence.com <http://www.cadence.com>
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, September 21, 2010 2:11 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Updated AMI Flow BIRD
Hello everyone,
I was hoping to send this out last week, but didn't get to it,
apologies for that.
I am attaching a new version of the draft BIRD with a bunch of
editorial changes. Since I am getting tired of writing long
comments on this BIRD draft and no actions following them, I
decided to write in the changes on my own. I did not change
the meaning of anything intentionally by doing so. The
observations which require more substantial reorganization or
changes to the meaning of the BIRD text are written into this
message.
1) At the beginning, in the big chunk of the red text, I have
a problem with a few things. Why is it necessary to explain
this:
The algorithmic model of a Tx model represents the
| signal processing that is performed on the stimulus or input to the Tx
| model. This signal processing is also known as equalization or
filtering.
The reason this bothers me is the sentence at the end of this
paragraph:
| There is no limitation that the equalization has to be linear and time
| invariant.
In light of the above, it comes across that the words "equalization"
or "filtering" are used as terminology that applies to the Tx
signal processing. It leaves the Rx out of the picture, since none
of the above mentions Rx. With that in the back of my mind, the
last sentence seems to imply that the Tx algorithmic model can be
non-LTI, but the Rx algorithmic model must be LTI, since it is not
mentioned here. This is grossly misleading, because the Rx has
usually more reasons to have non-LTI algorithms than Tx with DFE
and similar stuff that usually goes into it. I feel this is
ambiguous and should be re-written to be clear.
By the way, it seems that whoever wrote this paragraph didn't
notice that at the beginning of section 2 later down, the thoughts
about the algorithmic models not being required to be LTI for the
time domain simulations were already explained along the thoughts
that statistical simulations require LTI algorithmic models. Why
is this mentioned here again? This gives the impression of a
disorganized spec to the reader...
I would suggest to explain these thoughts in one and only one place,
and do it right there... In my opinion, it was good the way I
wrote it at the beginning of section 2 in the original draft BIRD
from which this was copied over...
2) Step 9 in Section 2.2 is incorrect:
| 9. For the AMI_GetWave function of the receiver, the EDA platform
takes the
| output from the transmitter AMI_GetWave (if it exists) or the output
from
| step 7 and combines it (for example by convolution) with the channel
| impulse response to produce an analog waveform and passes this result
to
| the receiver AMI_GetWave function for each time segment of the
simulation.
|
From the drawing on slide 17 at:
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20100713/toddwesterh
off/IBIS-AMI%20Flows/Flows_July2010-v2.pdf
if Tx GetWave doesn't exist, the EDA tool should combine the output of
Tx Init with the Digital Stimulus in step 9 and present that to Rx
GetWave.
The words in the BIRD draft says something different...
3) This sentence seems to be repeated three times. I am not sure
it is really necessary...
| A system simulation usually involves a transmitter (Tx) and a receiver
| (Rx) model with a passive channel placed between them.
4) Step 6b states that:
| Step 6b. If the Rx GetWave_Exists is False, the output of Step 5 is
| convolved with the output of Step 3.
and Step 3 (with my current modifications) states that:
| Step 3. The output of Step 2 is presented to the Rx model's AMI_Init
| function and the Rx AMI_Init function is executed. The Rx AMI_Init
| function may modify the impulse response or choose to leave it
unchanged.
while the drawing on slide 17 of the above presentation states
that in the absence of the Rx GetWave the output of Step 5 is
convolved with the Rx filter, in other words h_REI(t) and not
the output of Step 3, which is:
h_AC(t) * h_TEI(t) * h_REI(t)
which is clearly incorrect.
I would like to ask the authors to review the changes I made in
the attached Word document, verify that I didn't change any technical
content with them, and address the additional comments presented
in this message, and be ready to discuss it in the upcoming ATM
teleconference.
Thanks,
Arpad
====================================================================
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Thursday, September 16, 2010 10:39 PM
To: IBIS-ATM
Subject: [ibis-macro] Updated AMI Flow BIRD
All,
Attached is the updated AMI flow BIRD.
Please feel free to send your comments/suggestions regarding the latest
edits that are highlighted in the doc - or any other section of the
BIRD.
Thanks,
Ambrish.
Other related posts:
