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

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 29 Sep 2011 00:48:29 +0000

Kumar, Scott,

So what do you do if a user of your favorite EDA platform
gets stuck because they have a model that only works at
one and only one sampling rate, but the customer has no
idea what that is, and as a result they get trash instead
an eye and think that the EDA tool has a bug in it?  First,
having had several such customer requests, I am getting
tired of keep debugging our tool, just to find out that
it is the model that is bad.  But are you suggesting that
we should tell that customer (user) to delay their product
delivery because they have to wait for the model maker to
rewrite their model first?

While I agree that theoretically a model should behave as
the real chip does, and I do not want to encourage bad
modeling / programming practices, making models like that
may not always make sense or be feasible.  When I took a
Verilog-AMS modeling class from Ron Vogelsong (Cadence at
that time), he told the class that you should model only
what you need, not what you can (referring to the practically
unlimited capabilities of Verilog-AMS).  I think he had a
point in that.

On the other hand, a reserved parameter to document what the
model's capabilities are should not be viewed as encouraging
bad modeling practices.  To the contrary, this is encouraging
good documentation practices!!!  Even with this parameter in
place, the model maker can still make models which treat the
waveform as a continuous waveform.  They just have to document
what they did with a corresponding 0 to infinite Range in the
Samples_per_Bit reserved parameter.  If you think using Integer
for Samples_per_Bit is not sufficient, we can change my BIRD
draft so that float values are also allowed...

The point here is that you can't enforce good modeling practices
with our specification or parser utility, but you can enforce good
documentation practices...

Sincerely,

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

From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
Sent: Wednesday, September 28, 2011 7:27 PM
To: ckumar@xxxxxxxxxxx
Cc: IBIS-ATM; Muranyi, Arpad
Subject: Re: [ibis-macro] Re: Samples per bit for AMI


I violently agree!

Scott McMorrow
President
Teraspeed Consulting Group LLC
(401) 284-1827
On Sep 28, 2011 8:23 PM, "ckumar" 
<ckumar@xxxxxxxxxxx<mailto:ckumar@xxxxxxxxxxx>> wrote:
> Fixing samples ber bit is a bad idea and encourages poor
> modeling/programming practice.
>
> The model has to take its input as continuous waveform and do any
> resampling inside the model as real devices do.
>
>
> On Wed, 28 Sep 2011 23:41:19 +0000, "Muranyi, Arpad"
> <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>> wrote:
>> Hello everyone,
>>
>> I ran across yet another model today which was misbehaving
>> in our tool because it turned out that it would only work
>> with 64 samples per bit and the user unaware of this used a
>> different value.
>>
>> When I wrote about this topic some time ago, I was wrestling
>> with another AMI model that would only work with 32 samples
>> per bit. Neither of these models came with any documentation
>> on what samples per bit settings they will work with. The
>> problem is that when such models are misbehaving, all kinds
>> of "fun stuff" is starting to happen, anywhere from crashes
>> to explosions :-).
>>
>> I believe that the most robust solution would be to add a
>> reserved parameter for samples per bit to the IBIS-AMI
>> specification so that the model makers would be forced to
>> document in the .ami parameter file sampling rate(s) the
>> model will work with. Making blanket statements in the spec
>> is not going to guarantee that the model maker will actually
>> do anything about it, they may not even read that part of
>> the specification at all...
>>
>> Please look over the attached BIRD draft in which I attempt
>> to solve this problem by adding a reserved parameter to the
>> specification.
>>
>> Questions, comments 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
>

Other related posts:

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