[ibis-macro] Re: Question about the sliding window algorithm
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 15 May 2008 08:27:49 -0700
Kumar,
The wave_size will have to change in most realistic cases
if you consider that the waveform's total length may not
necessarily be an integer multiple of wave_size. The last
call to GetWave therefore will almost always get a shorter
wave_size unless your EDA tool decides to throw out those
"left over" points for the sake of keeping wave_size constant...
Arpad
===============================================================
________________________________
From: C. Kumar [mailto:kumarchi@xxxxxxxxx]
Sent: Thursday, May 15, 2008 10:19 AM
To: akshaye.sama@xxxxxx; ibis-macro@xxxxxxxxxxxxx; Muranyi, Arpad
Subject: Re: [ibis-macro] Re: Question about the sliding window algorithm
akashaye:
You are right . ami model has to be sophisticated and must have
1. internal buffering
yes you may have to collect data form multiple getwave before the model can
do anything useful
2. in a realistic case you do not expect the wave_size to change between calls.
But you are right, as it stands today the model is not guaranteed constant size
form call to call.
also as you have already figured, resampling is very crucial. Buffering and
resampling merits careful attention from the ami model developer. Proper
implementation of these two features is a must for robust eda-ami_model
interaction.
I am of the view the sampling is internal to the model and EDA tool should not
be doing something special thing for each model. Such an activity will only a
promote a false sense of simplicity and will end up reducing the robustness of
both the eda tool and the model
Akshaye Sama <akshaye.sama@xxxxxx> wrote:
AMI experts,
As the wave_size is an input to the AMI_Getwave, I think the model
should be capable of accepting any number for this parameter. Hence, it should
also be capable of
1) collecting data from multiple calls if the data from one call is not
sufficient for it to process - buffering. (no minimum specified, so theoretical
cases of wave_size = 1 are also possible!)
2) dealing with this parameter varying with each call to the
AMI_Getwave in a simulation. So, not assuming that the wave_size remains
constant over the simulation.
A very related thing is that sample_interval is also an input to the
AMI model (AMI_Init). Hence, any model must also be capable of interpolation,
if it internally works on a constant sample_interval. Both for increasing or
reducing the sample_interval for internal use. Practically, i can see that many
Serdes RX models would be operating on a constant sample_interval internally.
Both the above complexities (buffering and possibly interpolation) will
be in the AMI model (possibly, EACH AMI model). I'm thinking about additional
model verification complexity because of the above two variables. To have these
functions in the execution environment/EDA tool would be another possibility.
Was it considered?
Thanks,
Akshaye
Muranyi, Arpad wrote:
Todd and Kumar,
Thanks for your messages. My conclusion from your words
is that the intent was certainly to support multiple calls
to GetWave. In fact, the whole purpose of architecting
Init, GetWave and Close the way it is seemed to have
happened to allow multiple calls to GetWave and then do
the Close when it is all over.
However, I can't seem to find much on this in BIRD104.1
and this bothers me. Please tell me if I am missing
something, but if this is not explained in the BIRD,
consequently in the IBIS specification, we will get
all kinds of models in which people will forget to
write the additional code to make the multiple calls
work properly.
So I would suggest that if we all agree that this should
be a required feature for each AMI model, we should write
some text to spell it out (if this is indeed missing).
The above sentence made me think once again. Does it
really have to be required? After all, there is a
parameter called wave_size in the arguments. But wave_size
and the total length of the waveform may not be the same.
So who decides what the wave_size is, the EDA tool, or
the model? Seems like the EDA tool when it calls the
GetWave function. If it was the model, then the model
could tell the EDA tool how to deal with multiple calls.
Should we do something along these lines?
On the other hand, if the capability of doing multiple
calls to GetWave is required, I would also request that
the Cadence Rx model should be updated with that feature
included. We should set a good example in models which
are used to teach the newcomers to this not so easy
modeling task...
Thanks,
Arpad
============================================================
--
--------------------------------------------------------------------------
Akshaye Sama
Texas Instruments Ltd
800, Pavilion Drive,
Northampton NN4 7YL
United Kingdom.
Ph +44-1604-663804
--------------------------------------------------------------------------
---------------------------------------------------------------------
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:
