[ibis-macro] Re: Samples_per_bit question

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 20 Jul 2011 23:12:38 +0000

Kumar,

Regarding:  " You cannot shield bad software practices. ",
the purpose of this parameter in my mind is not to shield
bad practices, it is exactly the opposite, to reveal those
bad practices by requiring the model makers to fess up and
publicly state in the .ami file how bad (or god) their
model is...

Currently nothing gets mentioned about this and the model
users have to find out the hard way why their model doesn't
work or crashes, etc...  I don't see how this would be solved
by putting a statement in the spec that models should treat
the incoming waveforms as if they were continuous, or state
that each model should faithfully mimic everything that is
in the hardware...  Model makers will try to get away with
as much simplification as they can, and if they are not forced
to publicly reveal what the capabilities of their model is,
they will try to get away with murder...

Thanks,

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


-----Original Message-----
From: ckumar [mailto:ckumar@xxxxxxxxxxx] 
Sent: Wednesday, July 20, 2011 5:42 PM
To: Muranyi, Arpad
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: Samples_per_bit question

<20110720220731.0E1EBE35AFD@xxxxxxxxxxxxxxxxxxxx> 
<EB55FD6CF8C21444BE032D68DDA5FB99015CA4@xxxxxxxxxxxxxxxxxxxxxxxxx> 
<B0AE4B30A1D8584FA3406A6E24DD49321696535630@xxxxxxxxxxxxxxxxxxxxxxxxxx> 
<EB55FD6CF8C21444BE032D68DDA5FB99015CFF@xxxxxxxxxxxxxxxxxxxxxxxxx>

Message-ID: <8aa31ecd4413bceda43b6db575a8ff59@xxxxxxxxxxx>
X-Sender: ckumar@xxxxxxxxxxx
User-Agent: RoundCube Webmail/0.3.1
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

You cannot shield bad software practices. We can put wording stating that
the input waveform  have to be treated as a continuous waveform exactly
like real devices do
On Wed, 20 Jul 2011 22:36:08 +0000, "Muranyi, Arpad"
<Arpad_Muranyi@xxxxxxxxxx> wrote:
> How are you going to enforce that?
> The parser is not going to look inside
> the DLL to see if they implemented it...
> 
> Arpad
> =========================================
> 
> -----Original Message-----
> From: ibis-macro-bounce@xxxxxxxxxxxxx
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
> Sent: Wednesday, July 20, 2011 5:31 PM
> To: ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: Samples_per_bit question
> 
> Arpad,
> That’s why I like Scott's suggestion of putting the language in the
> specification to 'explicitly require that the model perform sample rate
> conversion to any sample rate.' 
> 
> -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 Muranyi, Arpad
> Sent: Wednesday, July 20, 2011 6:24 PM
> To: ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: Samples_per_bit question
> 
> Kumar,
> 
> While this may be poor practice, how would you enforce any
> better practice without such a parameter in the spec?  Please
> remember, that the goal of using such a parameter is not to
> encourage the model maker to write models which work with a
> single option for samples per bit.  This parameter could define
> a discrete or continuous range of such values.  The point in
> having such a required parameter is to force the model makers
> to think about this issue.   I feel that the reason we currently
> see models which work only at certain samples per bit values
> is because (inexperienced) model makers don't even think about
> the possibility and consequences of different samples per bit
> values...
> 
> Arpad
> ==================================================================
> 
> 
> -----Original Message-----
> From: ibis-macro-bounce@xxxxxxxxxxxxx
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of ckumar
> Sent: Wednesday, July 20, 2011 5:08 PM
> To: Muranyi, Arpad
> Cc: ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: Samples_per_bit question
> 
> <3c6f80930a503e5239f03b667288450d@xxxxxxxxxxx>
> <EB55FD6CF8C21444BE032D68DDA5FB99015C12@xxxxxxxxxxxxxxxxxxxxxxxxx>
> Message-ID: <cf6b5e872690700b7a68d603a9e213ff@xxxxxxxxxxx>
> X-Sender: ckumar@xxxxxxxxxxx
> User-Agent: RoundCube Webmail/0.3.1
> Content-Transfer-Encoding: 8bit
> Content-Type: text/plain; charset=UTF-8
> 
> making it required reserved parametr is perpetuating an extremely poor
> practice
> 
> On Wed, 20 Jul 2011 22:04:59 +0000, "Muranyi, Arpad"
> <Arpad_Muranyi@xxxxxxxxxx> wrote:
>> Kumar,
>> 
>> The EDA tool can resample the waveform(s) between
>> the Tx and Rx calls according to their own needs...
>> 
>> Arpad
>> ====================================================
>> 
>> -----Original Message-----
>> From: ckumar [mailto:ckumar@xxxxxxxxxxx] 
>> Sent: Wednesday, July 20, 2011 5:00 PM
>> To: Muranyi, Arpad
>> Cc: ibis-macro@xxxxxxxxxxxxx
>> Subject: Re: [ibis-macro] Re: Samples_per_bit question
>> 
>> I do not agree with that. 
>> What happens if the tx and rx requires different samples per bit?
Things
>> can get convoluted very fast.
>> 
>> That is why the emphasis should be on that the models are always seeing
>> continuous signals. Any way that is what devices do in real life too.
> They
>> sample a continuous signal coming into them. Software should be no
>> different.
>> 
>> On Wed, 20 Jul 2011 21:47:23 +0000, "Muranyi, Arpad"
>> <Arpad_Muranyi@xxxxxxxxxx> wrote:
>>> Mike, Scott, Kumar,
>>> 
>>> First, the models I ran into recently were brand new models,
>>> probably not even released yet.  I don't know the reason, but
>>> it appears that the problem might be learning curve related
>>> on the author's part.
>>> 
>>> This is why I tend to not agree with requiring the models to
>>> do the re-sampling for themselves.  This is extra burden on
>>> the model makers which we should try to avoid.  EDA vendors
>>> are probably better at writing such algorithms, and if the
>>> EDA vendor knows what sampling rate the model works with
>>> (using the proposed required and reserved parameter for that),
>>> they can do the re-sampling for the model if necessary before
>>> executing it.
>>> 
>>> I would prefer to put this Sample_per_bit parameter in the
>>> AMI spec, and make it required, reserved.
>>> 
>>> 
>>> Ambrish,
>>> 
>>> I agree that "to require a certain samples_per_bit for the model to
> work
>>> is not good"
>>> but it does happen unfortunately.  But I am not sure what you mean
>>> by "We can deal with this at a tool level and not put anything in the
>>> spec".  How would
>>> the tool know how to deal with a certain model if it doesn't know
>>> what sample rate(s) the model works with?  I think the only way
>>> a tool can deal with this if every model would be required to
>>> tell the tool with a reserved parameter what its sampling rate
>>> needs/capabilities are.
>>> 
>>> Thanks,
>>> 
>>> Arpad
>>> =====================================================================
>>> 
>>> 
>>> From: ibis-macro-bounce@xxxxxxxxxxxxx
>>> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
>>> Sent: Wednesday, July 20, 2011 4:17 PM
>>> To: ibis-macro@xxxxxxxxxxxxx
>>> Subject: [ibis-macro] Re: Samples_per_bit question
>>> 
>>> Scott-
>>> 
>>> Moving forward, we could conceivably take the approach you suggest.
> That
>>> approach still doesn't address the models that are already out there,
>>> however. I, for one, don't want to be in the position of telling users
>> they
>>> can no longer run models that they've been running for years.
> (Actually,
>> I
>>> know for a fact that I personally won't be in that position, so it's
>> really
>>> a choice for others to make.)
>>> 
>>> Mike S.
>>> 
>>> On 07/20/2011 03:53 PM, Scott McMorrow wrote:
>>> Ambrish
>>> 
>>> Why not go the other direction, which would be to explicitly require
>> that
>>> the model perform sample rate conversion to any sample rate.
>>> 
>>> 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(r) is the registered service mark of
>>> 
>>> Teraspeed Consulting Group LLC
>>> 
>>> On 7/20/2011 4:49 PM, Ambrish Varma wrote:
>>> I think we all agree that to require a certain samples_per_bit for the
>>> model to work is not good. We can deal with this at a tool level and
> not
>>> put anything in the spec as this will most definitely give it more
>>> prominence. In other words, model makers will feel compelled to 'do
>>> something' with this parameter.
>>> My 2 cents.
>>> 
>>> -Ambrish.
>>> 
>>> 
>>> 
>>> 
>>> [cid:image002.gif@01CC46FB.CCC6FBB0]
>>> 
>>> 
>>> 
>>> Ambrish Varma   |  Member of Consulting Staff
>>> 
>>> P: 978.262.6431   www.cadence.com<http://www.cadence.com>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ________________________________
>>> From:
>>>
ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
>>> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Dmitriev-Zdorov,
>>> Vladimir
>>> Sent: Wednesday, July 20, 2011 4:25 PM
>>> To: msteinb@xxxxxxxxxx<mailto:msteinb@xxxxxxxxxx>;
>>> ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
>>> Subject: [ibis-macro] Re: Samples_per_bit question
>>> 
>>> 
>>> Agree,
>>> 
>>> 
>>> 
>>> We also encountered with such models. The problem is when something
> does
>>> not work it is difficult to guess what's the problem and even after
> that
>> it
>>> takes several tries to find an appropriate parameter.
>>> 
>>> 
>>> 
>>> Vladimir
>>> 
>>> 
>>> From:
>>>
ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
>>> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
>>> Sent: Wednesday, July 20, 2011 2:18 PM
>>> To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
>>> Subject: [ibis-macro] Re: Samples_per_bit question
>>> 
>>> Kumar-
>>> 
>>> We agree with you in principle, and on the two occasions (years ago
> now)
>>> when we encountered a model that required a specific number of samples
>> per
>>> bit, we did ask the model developers to make their models more
general.
>>> Unfortunately, neither the IBIS spec nor any customer required them to
>>> support an arbitrary number of samples per bit, so the model
developers
>> did
>>> not accept our suggestion.
>>> 
>>> These models have now been in widespread use for several years. Given
>>> that, how should we handle the problem? To date, the solution we've
>>> proposed is the Samples_per_bit reserved parameter.
>>> 
>>> Thanks.
>>> Mike S.
>>> 
>>> On 07/20/2011 03:07 PM, ckumar wrote:
>>> 
>>> the ami model should treat the waveforms as continuous. They should
>>> 
>>> resample it inside the model for their requirements.
>>> 
>>> Requiring specific sample size is an unnecessary constraint.
>>> 
>>> On Wed, 20 Jul 2011 19:44:03 +0000, "Muranyi, Arpad"
>>> 
>>> <Arpad_Muranyi@xxxxxxxxxx><mailto:Arpad_Muranyi@xxxxxxxxxx> wrote:
>>> 
>>> Hello everyone,
>>> 
>>> 
>>> 
>>> I recall that we asked Walter to remove the proposed Samples_per_bit
>>> 
>>> Reserved AMI parameter from BIRD 121, which he did in BIRD 121.1.
>>> 
>>> What I don't remember is whether we made this request because we
>>> 
>>> decided that we didn't want/need this reserved parameter in the AMI
>>> 
>>> specification at all, or whether we just didn't want to propose this
>>> 
>>> in BIRD 121, since it seemed unrelated to the rest of the BIRD 121
>>> 
>>> content.  Could someone please refresh my memory on that?
>>> 
>>> 
>>> 
>>> The reason I am asking is because just recently I ran across a couple
>>> 
>>> of AMI models which only work at certain samples per bit settings
>>> 
>>> but there was no documentation that I am aware of that came with the
>>> 
>>> model that stated that.
>>> 
>>> 
>>> 
>>> I am not sure if this was done intentionally by the model's authors,
>>> 
>>> but it seems that a required reserved parameter would at least serve
>>> 
>>> as a reminder to the model makers to document the value at which
>>> 
>>> their model works, if not remind them to write models that work at
>>> 
>>> any reasonable samples per bit values.
>>> 
>>> 
>>> 
>>> Based on this experience I tend to feel that a required, and reserved
>>> 
>>> parameter for Samples_per_bit would be very useful in the AMI spec...
>>> 
>>> 
>>> 
>>> Comments, suggestions are welcome.
>>> 
>>> 
>>> 
>>> 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<mailto: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
> 
> ��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��
> 
1�+�
��+^��i��0��Z��?�������f����u�p�����i�����y�h�m����
�y�b��(�������������{.n�+���zwZ�隊T艸���+�����-~���+-���+���-�{.n�+
 
1�+���+^��i��0��Z��?�������f����u�p�����i�����y�h�m�����y�b��(���������+�:.�˛���m��֧zf��:"n+&i�����z�_�祊�l�����rۧ���r��

Other related posts:

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