[ibis-macro] Re: Samples per bit for AMI

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 29 Sep 2011 22:13:51 +0000

Scott,

I did a search on "sample_interval" in the current spec, and
found these occurrences (in meaningful text):

pg. 185:

| 3.1.2.1 impulse_matrix
| ======================
|
| 'impulse_matrix' is the channel impulse response matrix.  The impulse values
| are in volts and are uniformly spaced in time.  The sample spacing is given
| by the parameter ‘sample_interval’.

pg. 186:

| 3.1.2.4 sample_interval
| =======================
|
| This is the sampling interval of the impulse_matrix. Sample_interval is
| usually a fraction of the highest data rate (lowest bit_time) of the
| device.  Example:
|
|   Sample_interval = (lowest_bit_time/64)

pg. 188:

| 3.2.2.1 wave
| ============
|
| A vector of a time domain waveform, sampled uniformly at an interval
| specified by the ‘sample_interval’ specified during the init call.  The
| wave is both input and output. The EDA platform provides the wave.  The
| algorithmic model is expected to modify the waveform in place by applying
| a filtering behavior, for example, an equalization function, being
| modeled in the AMI_Getwave call.


None of these areas spell out who determines the sample_interval
and how.  (And I don't recall reading about that elsewhere in the
spec either, but correct me if I am wrong).  Is it the model or the
EDA tool?  The closest we get to this question is the sentence
"The EDA platform provides the wave.", but this doesn't necessarily
mean that the sample_interval is also determined by the EDA tool.

Unfortunately the spec doesn't state whether the sample_interval
argument to the AMI_Init function is an input or output either,
so one could argue this question any whichever way...

I am still not convinced that the spec makes a clear and unambiguous
statement "that AMI models MUST work at the sample_interval that
is provided by the EDA tool".  Please let me know if I am missing
something.  If that was made unmistakably clear in the spec, I am
willing to give up on the proposal to add the Samples_per_Bit
parameter.

Thanks,

Arpad
=====================================================================




-----Original Message-----
From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx] 
Sent: Thursday, September 29, 2011 4:27 PM
To: Muranyi, Arpad
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: Samples per bit for AMI

Arpad
See below
> Scott,
>
> Two comments on your suggestion:
>
> #1)  Without putting a statement in the spec that all
> AMI models MUST work at any sampling rate, all models
> are compliant even if they only work at one sampling
> rate.
No, it is already specified that AMI models MUST work at the 
sample_interval that is provided by the EDA tool, since there is no 
specified  mechanism for the DLL to deny a specific request of the EDA 
platform.  This is a hard requirement.  The original intent was that the 
DLL would process the discrete time equivalent of the continuous time 
waveform that the EDA tool provides, and that the sample_interval be 
defined by the EDA tool.  Therefore, if a model works at only one 
sample_interval, it is not compliant.

> #2)  Documentation in comments is totally useless because
> comments cannot be enforced.  If the model maker doesn't
> feel like putting it in the .ami file for whatever reason,
> (laziness, being embarrassed about the low model quality,
> etc...) it won't happen.  So I am very pessimistic about
> the "always" part of your conclusion:
>
> "... documented in a place that will always be
> included in the model tree ..."
Then we are at an impasse.  Teraspeed Consulting does not agree with 
providing an "out" for non-compliant models by providing  a 
Samples_per_bit parameter.  We do believe that requiring documentation 
in the model of non-compliant limitations is the best way to proceed.


>
> Thanks,
>
> Arpad
> ============================================================
>
>
> -----Original Message-----
> From: ibis-macro-bounce@xxxxxxxxxxxxx 
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
> Sent: Thursday, September 29, 2011 1:40 PM
> To: Ambrish Varma
> Cc: ibis-macro@xxxxxxxxxxxxx; wkatz@xxxxxxxxxx
> Subject: [ibis-macro] Re: Samples per bit for AMI
>
> I might suggest that we add a section to the specification on
> Requirement for Documentation of Non-Fully Compliant Models
>
> Requirement for Documentation of Non-Fully Compliant Models - If a model
> is not fully compliant with the IBIS-AMI specification, all model
> limitations must be fully documented within comment lines within the AMI
> file.
>
> This way the limitations are recognized as not fully compliant with the
> specification, but are documented in a place that will always be
> included in the model tree. Limitations on samples per bit can be easily
> documented here.
>
>
> Scott
>
> Scott McMorrow
> Teraspeed Consulting Group LLC
> 121 North River Drive
> Narragansett, RI 02882
> (401) 284-1827 Business
> (401) 284-1840 Fax
>
> http://www.teraspeed.com
>
> Teraspeed® is the registered service mark of
> Teraspeed Consulting Group LLC
>
>
> On 9/29/2011 2:01 PM, Ambrish Varma wrote:
>> I agree with Kumar and Scott,
>> The moment we add something like 'Samples per Bit' in the spec and 
>> legitimize models that only work at 1 particular number, I suspect model 
>> makers will start producing models based on that.
>>
>>
>> Here is some suggested text that could go in the new BIRD:
>>
>> On page 186 in Section 10 after the lines:
>>
>> | 3.1.2.4 sample_interval
>> |
>> | This is the sampling interval of the impulse_matrix. Sample_interval is
>> | usually a fraction of the highest data rate (lowest bit_time) of the
>> | device.  Example:
>> |
>> |   Sample_interval = (lowest_bit_time/64)
>>
>> Add the following text:
>>
>> | The fraction (64 in the above example) is a number that is decided by
>> | the EDA tool based on the rise time of the analog drivers, simulation
>> | speed,  or other factors. The AMI model must be able to produce valid     
>> | results at any sample_interval.
>>
>>
>> Please add/amend anything to make it more meaningful - or even suggest 
>> something to add at some other place to make it absolutely clear to the AMI 
>> model maker what to expect.
>>
>> Thanks,
>> Ambrish.
>>
>> Ambrish Varma   |  Member of Consulting Staff
>> P: 978.262.6431   www.cadence.com
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: ibis-macro-bounce@xxxxxxxxxxxxx 
>> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
>> Sent: Thursday, September 29, 2011 10:45 AM
>> To: scott@xxxxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
>> Subject: [ibis-macro] Re: Samples per bit for AMI
>>
>> Scott,
>>
>> I do not disagree with your comments. I think you propose that IBIS 5.1
>> require that a model accept any samples per bit and that if the model
>> implementation does have such an internal limitation then the model should
>> do the Torque Conversion. SiSoft would accept this resolution.
>>
>> Walter
>>
>> -----Original Message-----
>> From: ibis-macro-bounce@xxxxxxxxxxxxx
>> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
>> Sent: Thursday, September 29, 2011 10:28 AM
>> To: ibis-macro@xxxxxxxxxxxxx
>> Subject: [ibis-macro] Re: Samples per bit for AMI
>>
>> Walter
>>
>> I'm on the same page as Kumar.  The EDA tool can set the sample_interval to
>> anything that it desires, to generate uniformly sampled data that is as
>> accurate as required.  A model that requires a fixed sample_interval is
>> contrary to the spec and is non-compliant.  There is nothing new here.  If a
>> model is non-compliant, it needs to be sent back to the model maker and get
>> fixed.  How is this different than any other non-compliant IBIS model?
>> Sometimes an IBIS model quality problem can be fixed by the user.  Sometimes
>> it cannot be fixed.  Any fix at the EDA
>> tool level using re-sampling is like putting lipstick on a pig.   In the
>> end, it's just a pig that does what it wants to do, not what it should do.
>>
>> Scott
>>
>> Scott McMorrow
>> Teraspeed Consulting Group LLC
>> 121 North River Drive
>> Narragansett, RI 02882
>> (401) 284-1827 Business
>> (401) 284-1840 Fax
>>
>> http://www.teraspeed.com
>>
>> TeraspeedR is the registered service mark of Teraspeed Consulting Group LLC
>>
>>
>> On 9/29/2011 10:19 AM, Walter Katz wrote:
>>> Kumar,
>>>
>>> On page 188 of IBIS 5.0:
>>>
>>> | 3.2.2 Arguments
>>> | | 3.2.2.1 wave
>>> |
>>> | A vector of a time domain waveform, sampled uniformly at an interval
>>> | specified by the ‘sample_interval’ specified during the init call.
>>> | The wave is both input and output. The EDA platform provides the
>>> | wave. The algorithmic model is expected to modify the waveform in
>>> | place by applying a filtering behavior, for example, an equalization
>>> | function, being modeled in the AMI_Getwave call.
>>>
>>> The waveform in and out of AMI_GetWave is " sampled uniformly at an
>>> interval specified by the ‘sample_interval’ specified during the init
>>> call"
>>>
>>> I think this is "uniformly sampled data". So your comment "Your
>>> proposal will prevent the eda tool to pass continuous waveform as
>>> accurately as possible." Is not logical and does not apply. What did
>>> you mean by "Your proposal will prevent the eda tool to pass
>>> continuous waveform as accurately as possible."
>>>
>>> Walter
>>>
>>>
>>> -----Original Message-----
>>> From: ibis-macro-bounce@xxxxxxxxxxxxx
>>> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of ckumar
>>> Sent: Thursday, September 29, 2011 10:09 AM
>>> To: Arpad_Muranyi@xxxxxxxxxx
>>> Cc: IBIS-ATM
>>> Subject: [ibis-macro] Re: Samples per bit for AMI
>>>
>>> there are various ways of "digitizing". You probably meant uniformally
>>> sampled data. Your proposal will prevent the eda tool to pass
>>> continuous waveform as accurately as possible.
>>>
>>> On Thu, 29 Sep 2011 13:54:40 +0000, "Muranyi, Arpad"
>>> <Arpad_Muranyi@xxxxxxxxxx>    wrote:
>>>> Kumar,
>>>>
>>>> Regarding: "It does not make any sense for the eda tool to be doing
>>>> the part of the models job.", I don't think this is what I am suggesting.
>>>> In the computer world there is no such thing as continuous waveform.
>>>> Everything is sampled, digitized.  I don't see how we can go without
>>>> knowing how things are digitized.
>>>>
>>>> Thanks,
>>>>
>>>> Arpad
>>>>
>>> ======================================================================
>>> ===
>>>> -----Original Message-----
>>>> From: ibis-macro-bounce@xxxxxxxxxxxxx
>>>> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of ckumar
>>>> Sent: Thursday, September 29, 2011 7:25 AM
>>>> To: twesterh@xxxxxxxxxx
>>>> Cc: IBIS-ATM
>>>> Subject: [ibis-macro] Re: Samples per bit for AMI
>>>>
>>>> I do not agree. Resampling may part of a adc(analog to digital
>>> conversion)
>>>> which may be more or less complex. The key part is that the model
>>>> should treat the incoming waveform as an analog/continuous waveform
>>>> and take it from there. It does not make any sense for the eda tool
>>>> to be doing the part of the models job.
>>>>
>>>> On Thu, 29 Sep 2011 08:10:46 -0400 (EDT), "Todd Westerhoff"
>>>> <twesterh@xxxxxxxxxx>    wrote:
>>>>> I'm with Arpad on this (which should surprise no one).
>>>>>
>>>>>
>>>>>
>>>>> This is a practical issue - there are models out there with
>>> undocumented
>>>>> requirements (e.g. samples per bit) and this is a standardized way
>>>>> of documenting those requirements so that users (and tools) can do
>>>> something
>>>>> about them.  The mere act of documenting a requirement should serve
>>>>> as
>>> a
>>>>> hint to the model developer that generalizing the model might be a
>>>>> good idea.
>>>>>
>>>>>
>>>>>
>>>>> What bothers me most are models that have an undocumented
>>>>> requirement,
>>>> run
>>>>> when that requirement isn't met, but produce incorrect results.
>>>>> What's the chance that the user notices a problem and does something
>>>>> about it?
>>>>> Virtually nil, in my experience.  The models that flatline or crash
>>>> (I've
>>>>> seen both) are actually doing the user a favor.  Better to have no
>>>> result
>>>>> than the wrong one.
>>>>>
>>>>>
>>>>>
>>>>> No one is suggesting that having a fixed (or limited)
>>>>> Samples_Per_Bit setting is a good idea.  We're not promoting bad
>>>>> programming practices; we're trying to ensure good simulation
>>>>> results.  If others are willing
>>>> to
>>>>> tell system designers to wait while suppliers rewrite algorithmic
>>>> models,
>>>>> great.  Seems silly to me, but maybe their users are more patient
>>>>> than mine.
>>>>>
>>>>>
>>>>>
>>>>> Todd.
>>>> ---------------------------------------------------------------------
>>>> 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
>>>>
>>>>
>>> 1 +    +^  i  0  Z  ?       f    u p     i     y h m      y b  (    
>>> {.n +   zwZ 隊T艸   +     -~   +-   +   - {.n +
>>> ---------------------------------------------------------------------
>>> 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
>>>
>> ---------------------------------------------------------------------
>> 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
>>
> ---------------------------------------------------------------------
> 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
>
>   1�+�
��+^��i��0��Z��?�������f����u�p�����i����y�h�m����
�y�b��(��������+�:.�˛���m��֧zf��:"n+&i���z�_�祊�l�����rۧ���r��e===

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 09-2011