[ibis-macro] Re: Question about the sliding window algorithm
- From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 16 May 2008 08:34:55 -0400
Kumar,
Now you've got me curious.
Just what, exactly, is a "continuous analog waveform" - in terms of something
that we can describe
and manipulate using a computer?
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
_____
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of C. Kumar
Sent: Friday, May 16, 2008 8:20 AM
To: Akshaye Sama; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Question about the sliding window algorithm
From th eda tool perspective the wave form is a continuous analog wave form
which is sampled at a
certain rate decided by the eda tool/user.
so if Tx mode requires 64 samples and the rx require 32, then the eda tool has
to produce two
different wave vectors sampled at those intervals.
also what happens when the devices become more complex and internally they
require both 64
samples/bit and 32 bit samples/bit.?
That is one of the reason i believe it is best to treat the waveform at the
interface as continuous
analog waveform
Akshaye Sama <akshaye.sama@xxxxxx> wrote:
Thanks for your reply Kumar.
Are there specific reasons for " 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"
If the model just exports what it supports for minimum wave_size and the
sample_interval(not even
required to be at run time) , the tool could just ensure that only the
supported values are used.
Although the values of sample_interval and wave_size will be model specific,
the algorithm that the
tool uses for selecting wave_size and sample_interval need not be model
specific. This would mean
that model does not need interpolation or buffering(some minor buffering would
be required to ensure
wave continuity between the AMI_Getwave calls).
1)Consider a case where TX used 64x sample_interval internally and RX also uses
the same. The EDA
tool has no way of finding out that this is the best sample_interval setting.
Although the most
logical value is 64x, this may not be visible to users.
2)if the model exports the minimum wave_size it requires to process, this would
remove the
requirement of buffering to collect samples for processing.
Rgds,
Akshaye
C. Kumar wrote:
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 <mailto:akshaye.sama@xxxxxx> <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
--
--------------------------------------------------------------------------
Akshaye Sama
Texas Instruments Ltd
800, Pavilion Drive,
Northampton NN4 7YL
United Kingdom.
Ph +44-1604-663804
--------------------------------------------------------------------------
Other related posts:
