[ibis-macro] Re: Question about clock_times
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 28 Jan 2010 07:37:11 -0800
The point I was trying to make is that if the EDA tool initializes
the entire vector with -1, then the DLL doesn't have to put a -1
at the end, because it is there already by default. The DLL can
just write data and stop, and the next value will be -1 anyway.
Of course if we don't require for the EDA tool to initialize the
entire vector with -1, then the DLL should put the -1 at the end.
Either way, the spec should say something about the EDA tool
having to initialize this vector one way or another, since it
appears that there may be situations when the DLL doesn't write
anything to it, not even a -1...
Regarding #2, I can see your point about simplifying the rules for
the API, but I think this can waste a lot of memory, especially if
clock_times length = wave length. If we were able to make other
arguments optional, like AMI_parameters_out, why can't we figure
out a way to make this one optional, or at least say something
about the fact that for Tx, for example, it is not necessary to
allocate a huge amount of memory, only enough for a single number
containing a -1...
Arpad
====================================================================
-----Original Message-----
From: ckumar@xxxxxxxxxxx [mailto:ckumar@xxxxxxxxxxx]
Sent: Thursday, January 28, 2010 8:58 AM
To: Muranyi, Arpad
Subject: Re: [ibis-macro] Re: Question about clock_times
1."putting the value at the end" is required only if he dll sends clock
back.
If it is not c=doing anything with the clock it does not even need to
look at
it.
2. This is mainly done to simplify the API. Rule of thumb is you shoudl
keep th
API to minimum for documentation and programming simplicity. If it is
optional
then we have to create another API without clock.
Quoting "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>:
> Kumar,
>
> Thanks for the answers.
>
> If everyone agrees to what you said, then I would suggest to write
> this into the specification.
>
> #1) The spec doesn't say anywhere that this is supposed to be done
> by the EDA tool, it only says:
> "The last clock is indicated by putting a
value
> | of -1 at the end of clocks for the current wave sample. The
clock_time
> | vector is allocated by the EDA platform and is guaranteed to be
> greater
> | than the number of clocks expected during the AMI_GetWave call."
>
> If the EDA tool initializes the vector with a -1, the DLL wouldn't
have
> to do anything about that, so we wouldn't need to say:
>
> "by putting a value of -1 at the end" because it would be there
already.
> On the other hand, we should add "The clock_time vector is allocated
by
> the EDA platform AND INITIALIZED WITH -1 at least in the first
> location..."
> or something like that...
>
> #2 If this vector is not needed for the Tx, shouldn't clock_times be
> optional (like AMI_parameters_out, for example)? Currently it is
> required... I find it a little confusing to have something required
> when it is not used in half the cases. It makes me wonder what am I
> missing that it is required for...
>
> Thanks,
>
> Arpad
>
========================================================================
> ======
>
> -----Original Message-----
> From: ckumar@xxxxxxxxxxx [mailto:ckumar@xxxxxxxxxxx]
> Sent: Thursday, January 28, 2010 5:47 AM
> To: Muranyi, Arpad
> Subject: Re: [ibis-macro] Re: Question about clock_times
>
> Arpad:
>
> 1. The EDA tool allocates the clock memory and initializes that with a
> -1.
> If the Rx does not have a CDR, it will not modify this vector
>
> 2. For the Tx , whether the clock vector exists or not is irrelevant.
It
> should
> not be doing anything to that vector. (like logical don't care state)
>
> 3. clock length = wave length is a robust way of memory allocation. It
> is much
> more important to be robust than worry about 'efficiency' of memory
> allocation
>
> Quoting "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>:
>
> > A related question:
> >
> > Is an Rx DLL required to fill the clock_times memory
> > with good numbers, i.e. does it have to have a clock
> > recovery, or is even an Rx allowed to basically not
> > return anything useful?
> >
> > Related to this, are the Tx and Rx DLL-s required to
> > put a -1 in the first location of the clock_times
> > memory space if they do not have anything to return,
> > or is the EDA tool supposed to initialize the allocated
> > memory so that at least the first location would have
> > a -1?
> >
> > Thanks,
> >
> > Arpad
> > =======================================================
> >
> > ________________________________
> >
> > From: ibis-macro-bounce@xxxxxxxxxxxxx
> > [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
> > Sent: Wednesday, January 27, 2010 11:44 PM
> > To: IBIS-ATM
> > Subject: [ibis-macro] Question about clock_times
> >
> >
> > Hello AMI experts,
> >
> > I just noticed something in the AMI portion of the official IBIS v5
> > specification.
> >
> > Section 3.2.2.3 clock_times is not labeled as optional, yet the text
> > implies that this is only applicable to Rx models. Note the words
> > "clock recovery loop" towards the end:
> >
> >
> > | 3.2.2.3 clock_times
> > |
> > | Vector to return clock times. The clock times are referenced to
the
> > start
> > | of the simulation (the first AMI_GetWave call). The time is always
> > | greater or equal to zero. The last clock is indicated by putting a
> > value
> > | of -1 at the end of clocks for the current wave sample. The
> clock_time
> > | vector is allocated by the EDA platform and is guaranteed to be
> > greater
> > | than the number of clocks expected during the AMI_GetWave call.
The
> > clock
> > | times are the times at which clock signal at the output of the
clock
> > | recovery loop crosses the logic threshold. It is to be assumed
that
> > the
> > | input data signal is sampled at exactly one half clock period
after
> a
> > | clock time.
> >
> >
> > A Tx model would not have a clock recovery loop, so I would think
that
> > a Tx GetWave function would not return anything in clock_times. Is
> the
> > EDA tool still required to allocate memory for clock_times even for
> Tx?
> >
> > Also note that the spec doesn't spell out exactly how much memory
the
> > EDA
> > tool needs to allocate, only that it should be "greater than the
> number
> > of clocks expected". Since we have seen crashes due to a DLL
wanting
> to
> > write more clock_times than what we "expected" from it, and the
safest
> > thing to do would be to allocate as much memory as the number of
> > simulated
> > bits, this seems to be quite a waste if we had to allocate the same
> > amount
> > of memory to a Tx model's clock_times also...
> >
> > Isn't there a better way of doing this?
> >
> > Thanks,
> >
> > Arpad
> >
>
========================================================================
> > =====
> >
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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:
