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

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 30 Sep 2011 00:32:59 +0000

All,

I would like to summarize this rather lively discussion on this
thread so we can move forward.  First, to be clear about my
intensions behind this proposal:

#1)  My proposal was NOT intended to provide 'an "out" for non-compliant
     models' (or to legalize something that is illegal in the spec)
#2)  My impression of the spec was/is that it does NOT state it in a
     clear and straightforward manner that all models are REQUIRED
     to operate at all (reasonable) sampling rates
#3)  Based on this understanding of the spec, (i.e. that it is legal 
     to make models which only work at certain sampling rates), I felt
     that it was necessary to define a mechanism by which the model
     maker is forced to tell the EDA tool the working sampling rates
     of the model

If we all agree that the intent of the specification is that all
AMI models are expected to work at any reasonable sampling rates,
I think we need to write a clarification BIRD to make that crystal
clear and very noticeable.  Ambrish made a suggestion earlier towards
that, I will revisit that and see if I can formalize it in a BIRD.

Although this approach solves the problem in theory, in practice we
will most likely continue to see non-compliant models in the future
because compliance with this requirement cannot be checked or enforced
by the parser.  None of the other suggestions about documenting the
degree of non-compliance in comments or special parameters/keywords,
or supporting documentation files would securely eliminate the
possibility of someone releasing a non-compliant model without any
indication (documentation) of that fact.  At the end we will still
encounter crashes, bad results, etc... when such models are circulated
and used in simulations.  The users of the models and the EDA vendors
will continue to have to spend countless hours to figure out what is
wrong, whether there is a bug in the EDA tool or whether the model is
bad.

While I agree that the ideal sampling rate is best determined by
the tool or its user depending on the edge rates and other design 
characteristics, I wonder whether leaving the limits of the sampling
rate completely up to the EDA tool is the best solution.

What if someone wants to do a quick assessment of the design and
selects 2 samples per bit?  Is that considered a reasonable selection?
What if the model's algorithms don't make any sense at that value?
On the opposite end, what if a user wants a super accurate simulation
and sets the sampling rate to a high value, not knowing that the
AMI model's algorithm is a memory hog, and therefore can't use such
a high number of samples per bit value without running out of memory?

Extending this thought a little further, if certain algorithms could
be made a lot more efficient with certain sampling rates (powers of 2,
for example), why should the model maker be forced to write more
general but less efficient algorithms to accommodate any sampling
rate, or be forced to add the overhead of sampling rate conversions?
I know computers are getting faster and faster, but aren't we coveting
BER numbers down to e-15 or lower?

For these reasons, I still think that it wouldn't be terribly bad idea
to allow the model to tell the tool something about sampling rates...
We could perhaps work out collectively what exactly that information
should consist of.

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