[ibis-macro] Re: An AMI Overview
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 15 Oct 2009 12:21:22 -0700
Kumar,
I am sure we can figure out a way to do multiple
GetWave calls without mixing in signal processing
code into any Init function(s), and without mixing
the "LTI process" function(s) with "non-LTI process"
function(s).
The point I am trying to make that in the current
specification we are mixing the concepts of initializing
with the concepts of LTI and non-LTI flows. This seems
to cause part of the confusion and disagreements in
our discussions on what the best flow would be...
Arpad
==========================================================
________________________________
From: C. Kumar [mailto:kumarchi@xxxxxxxxx]
Sent: Thursday, October 15, 2009 2:02 PM
To: ibis-macro@xxxxxxxxxxxxx; Muranyi, Arpad
Subject: Re: [ibis-macro] Re: An AMI Overview
what i meant was te eda tool has to call getwave multiole times with
blocks of waveform.
--- On Thu, 10/15/09, Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx> wrote:
From: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>
Subject: [ibis-macro] Re: An AMI Overview
To: ibis-macro@xxxxxxxxxxxxx
Date: Thursday, October 15, 2009, 2:40 PM
Kumar,
I can see why you want to split the task of GetWave
into different blocks of algorithms. But that could
still be done within a single function called GetWave
which may have different partitions (or sub function
calls) inside. I don't see how this would justify Init,
(a truly initializing function) to perform signal
processing...
Arpad
========================================================
________________________________
From: C. Kumar [mailto:kumarchi@xxxxxxxxx]
Sent: Thursday, October 15, 2009 1:35 PM
To: ibis-macro@xxxxxxxxxxxxx; Muranyi, Arpad
Subject: Re: [ibis-macro] Re: An AMI Overview
algorithms using getwave are usually more complicated and may not be
required for all devices. Further more getwave is usually called
multiple times and so programming is also more involved and there is a
need to use persistent data structures
that is the reason the api is split into two main calls
--- On Thu, 10/15/09, Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx> wrote:
From: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>
Subject: [ibis-macro] Re: An AMI Overview
To: ibis-macro@xxxxxxxxxxxxx
Date: Thursday, October 15, 2009, 2:28 PM
Why can't the channel info be fed directly into GetWave?
Why can't the parameters be fed into GetWave directly?
Why does the Init function do any convolutions (i.e. signal
processing) if its purpose is the above two?
Arpad
============================================================
________________________________
From: C. Kumar [mailto:kumarchi@xxxxxxxxx]
Sent: Thursday, October 15, 2009 1:24 PM
To: ibis-macro@xxxxxxxxxxxxx; Muranyi, Arpad
Subject: Re: [ibis-macro] Re: An AMI Overview
i do not thing that the fundamental issue here is the question of doing
lti or non lti analysis. the init function gives the device the channel
info (impulse response). another important function of the init is to
deliver the device parameters.
This delivery of parameters is equally or even more important. if the
device has getwave then it simply returns the wave form. it may elect to
choose the channel information it obtained in the init or may not.
--- On Thu, 10/15/09, Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx> wrote:
From: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>
Subject: [ibis-macro] Re: An AMI Overview
To: ibis-macro@xxxxxxxxxxxxx
Date: Thursday, October 15, 2009, 2:08 PM
Oh well... I will throw in my $ 0.02 worth on this topic.
I think we are mixing two things here, and our terminology
doesn't help either. One is that we have this notion of
"Init", meaning initializing the computer memory, etc... in
a computer science sense, and the other is the two types of
flows, LTI and non-LTI. To be honest, I never liked the idea
of calling the "Init" function "Init", when its purpose was
to execute the LTI algorithms.
If this flow topic is now becoming such a big deal regarding
Init and GetWave, why don't we give things a little more
descriptive names? Let's have an Init (if necessary) to
really do nothing but initializing memory, etc... and then
have another function, say "LTI_algorithms" to do the LTI
signal processing, and a third function that will do the
non-LTI signal processing.
The reason I am suggesting this is because it seems that the
most confusing thing in this discussion is that the GetWave
functions are not complete by themselves, they rely on Init
to do part of the algorithms. But Init may do different
things depending on whether there is a GetWave or not. Why
don't we just have a function that does a complete LTI
analysis, and another function that does a complete non-LTI
analysis?
Arpad
============================================================
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
fangyi_rao@xxxxxxxxxxx
Sent: Thursday, October 15, 2009 11:57 AM
To: dkirsanov@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: An AMI Overview
Hi, Danil;
I think we are on the same page. The fundamental problem is that
current AMI spec allows two usages of Init and GetWave as stated at the
end of the BIRD.
Further discussion identified that
two different styles of modeling were possible and should be
supported. In the default case, the
AMI_Init and AMI_Getwave calls represent filtering performed by
sequential stages of a device, and
the results should therefore be chained together. In the second
case, the AMI_Init and AMI_Getwave
calls each represent the overall device. For example, the
AMI_Init call could provide an LTI model
for the device while the AMI_Getwave call provides a
time-varying model. In this case, results from
the AMI_Init and AMI_Getwave calls should be treated as
independent.
The first case obviously can't support statistical simulation.
There are different approaches to make the AMI standard to
support both time domain (pattern depend) and statistical simulations.
The two-model approach suggested by Kumar is one of them. Walter and
Arpad prefer to stay with one model by dropping support to the first
case in AMI since practically no model of this usage exists.
I want to take this opportunity to suggest another solution with
one model. In AMI we should separate the interface for time domain
simulation from that for statistical by adding a third function named
GetImpulseForStatistical(). It takes impulses of victim and aggressors
and returns modified impulses.
Regards,
Fangyi
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Danil Kirsanov
Sent: Thursday, October 15, 2009 8:30 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: An AMI Overview
Fangyi,
Could you please clarify it? I agree that it might be reasonable
to put the linear part of the model in Init and non-linear part in
Getwave, so that together they characterize the model (statistical
simulator uses only the linear part, while the pattern-dependent always
uses both).
But I strongly disagree that inside one model Init and GetWave
can provide different approximations of the same algorithm (i.e.
introducing double-counting), where statistical simulator uses Init and
pattern-dependent simulator uses GetWave. I believe this behavior should
be prohibited, since it makes the flow more complicated, and we can
easily achieve the same result providing two different models (or having
internal option to switch the model between the statistical and
non-linear mode).
If we have this simple rule (non-linear simulator we always uses
Init and Getwave), the behavior of the EDA does not depend on the fact
whether GetWave exists or not, and GetWaveExists flag becomes
unnecessary (if the Simulator at some point figures out there is no
GetWave, it just does not use it).
Are we on the same page here?
Best,
Danil
From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Wednesday, October 14, 2009 7:48 PM
To: kumarchi@xxxxxxxxx; ibis-macro@xxxxxxxxxxxxx;
dkirsanov@xxxxxxxxxx
Subject: RE: [ibis-macro] Re: An AMI Overview
Hi, Kumar;
What if a model wants to support non-linear time domain
simulation by GetWave and statistical simulation by returning a LTI
approximation in Init?
Thanks,
Fangyi
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of C. Kumar
Sent: Wednesday, October 14, 2009 4:23 PM
To: ibis-macro@xxxxxxxxxxxxx; dkirsanov@xxxxxxxxxx
Subject: [ibis-macro] Re: An AMI Overview
i agree..
if the model modifies the init it is the only thing it should be doing.
there should not be any getwave
--- On Wed, 10/14/09, Danil Kirsanov <dkirsanov@xxxxxxxxxx> wrote:
From: Danil Kirsanov <dkirsanov@xxxxxxxxxx>
Subject: [ibis-macro] Re: An AMI Overview
To: ibis-macro@xxxxxxxxxxxxx
Date: Wednesday, October 14, 2009, 6:59 PM
Dear colleagues,
I would like to clarify one basic principle of AMI modeling, hoping that
all of us agree with it.
I believe that the model writer should never do a double-counting: if he
modified the channel impulse response in Init() to model some effect, he
should not model this effect in Getwave(). So he cannot put the "true"
model in GetWave() and it's linear approximation in Init(). If both
types of behavior are expected, there should be two models (or some
internal flag that changes the behavior of the model).
If this assumption is true, statistical (linear) simulator always works
with Init() function of the model, while pattern-dependent (non-linear)
simulator works with both Init() and GetWave() and I do not see any
necessity for Get_Wave_Exists flag.
Best,
Danil
Other related posts:
