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

  • From: <radek_biernacki@xxxxxxxxxxx>
  • To: <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 29 Sep 2011 17:39:15 -0600

Arpad,

There is no need for the EDA platform to interpret the content of the 
AMI_compliance info. Acting upon the content of this info is up to the user, 
including possible rejection of the model, or (perhaps reluctantly) setting the 
simulation parameters consistent with model limitations, assuming such settings 
are available in the EDA platform being used.

As already pointed out by others, your solution legitimizes such limitations.

Radek

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Muranyi, Arpad
Sent: Thursday, September 29, 2011 4:24 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Samples per bit for AMI

Radek,

Ironically, this idea of introducing a reserved parameter for
"AMI_compliance" is really no different from my proposed
"Samples_per_Bit" reserved parameter idea.  Here is why:

Let's say there is a non-compliant model which only works with
a few specific sampling rates.  What would you suggest to put
into the AMI_compliance parameter?  I would think that you
would suggest that the model maker should list the sampling
rates at which the model works.

Isn't this the same as my proposed Samples_per_Bit parameter?
The only difference I see is that with your keyword the model
maker could address any non-compliant "features" of the model,
while mine addresses only one.  But the advantage of my
proposal is that the EDA tool can interpret it and act on
it.  I am not sure what syntax we could use to add automation
to your suggestion.

Thanks,

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

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of radek_biernacki@xxxxxxxxxxx
Sent: Thursday, September 29, 2011 2:35 PM
To: Dmitriev-Zdorov, Vladimir; scott@xxxxxxxxxxxxx; ambrishv@xxxxxxxxxxx
Cc: ibis-macro@xxxxxxxxxxxxx; wkatz@xxxxxxxxxx
Subject: [ibis-macro] Re: Samples per bit for AMI

Perhaps we could modify Scott’s idea by introducing a new reserved parameter 
“AMI_compliance” which would be required for any non-compliant model, or 
optional for fully compliant models. That parameter would contain a string 
value stating all the exceptions (or confirming full compliance). The EDA 
platform would then be required to display such a string prominently enough so 
that the user is properly warned about the model non-compliance and any 
specific limitations. The responsibility of updating the AMI file for any 
reported and confirmed cases should stay with the model owner.

This might also be a solution for the unfinished discussion about model 
specific parameters of usage Out and InOut.

Radek

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Dmitriev-Zdorov, Vladimir
Sent: Thursday, September 29, 2011 11:58 AM
To: scott@xxxxxxxxxxxxx; Ambrish Varma
Cc: ibis-macro@xxxxxxxxxxxxx; wkatz@xxxxxxxxxx
Subject: [ibis-macro] Re: Samples per bit for AMI

This is a good idea. However, the creator of the model may not know or 
recognize all its limitations (i.e. overlook some of them) at a time of 
release. Can we propose a mechanism of adding notes on found limits to already 
existing models? Very often, the problems are discovered later by parties other 
than model developer, should then be somewhere an independent instance keeping 
all these records?


-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Scott McMorrow
Sent: Thursday, September 29, 2011 12: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

��i�����ס���
0y֨�鹿�n+?��+�jz\"��!#r�+y�^r�+��i��0���zX���+��b���n+&i��N�����r��zǧu�ޙ��N���ɚr�+z�����y�b��(��n7���칻�&
 1�+�
��+^��i��0��Z��?�������f����u�p�����i����y�h�m����
�y�b��(��������+�:.�˛���m��֧zf��:"n+&i���z�_�祊�l�����rۧ���r��
��i�����ס���
0y֨�鹿�n+?��+�jz\"��!#r�+y�^r�+��i��0���zX���+��b���n+&i��N�����r��zǧu�ޙ��N���ɚr�+z�����y�b��(��n7���칻�&

Other related posts:

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