Re: accuracy BIRD

Greg,

I understand why you want to distinguish between the a waveform with and
without packaging parasitics. However, there is a another problem that I
think the "Golden Waveforms" specification you are coming up with can solve
with little impact.

The problem is that many model makers do NOT read the cookbook. Often the
most important waveforms (w/o the parasitics) are not present. If there is
going to yet another document that model makers will refer to when building
models, that document may suffer this same fate as the IBIS Cookbook. A
model maker may read one document and not the other.

If both documents are referring to the construction of VT waveforms, they
should probably be rolled into ONE document so that the "publicity" of one
is leveraged by the other. It creates one-stop-shopping for the model
maker. We want to make it easy for the model maker.

Stephen, do you approve/dissaprove of combining the documents?

If you must create a seperate document, then I think the "Golden Waveforms"
should INCLUDE the specification for waveforms found in the cookbook (w/o
parasitics) as the most important waveforms. So the LEVEL I would be w/o
parasitics, LEVEL II be with. At a minimum the new spec must make an
"imperative reference" to the cookbook for 3.2.2.

The bottom line is if a user only reads this new Accuracy specification and
not the Cookbook then all is lost because the maker wouldn't include the
most important waveforms and your goals would not be attainable (nor would
ours).

Thanks for your consideration,

Chris Rokusek
Viewlogic Systems

-----Original Message-----
From: gedlund@us.ibm.com <gedlund@us.ibm.com>
To: ibis-users@vhdl.org <ibis-users@vhdl.org>
Date: Monday, March 15, 1999 11:39 AM
Subject: Re: accuracy BIRD

>Stephen,
>
>Thanks for the insight. This clears up my question, and I believe Syed's,
>too. Actually, I went back and re-read section 3.2.2 of the Cookbook, and
>you said it quite well there. The simulator NEEDS the no-load VT tables to
>generate a realistic stimulus, if you will. The VT tables with a complex
>load are icing on the cake and useful for verifying simulator results.
>
>What the Accuracy Subcommittee is proposing is some new complex loads that
>involve transmission lines. (And we'll probably come up with more when we
>start looking at more advanced drivers.) We can use these extra loads to
>validate both lab results AND simulator results against the "golden
>waveforms" in the IBIS datasheet - a cool thing. The real question is,
>should we add some new keywords and/or subparameters to describe these new
>loads, thereby facilitating automated simulation and correlation, or should
>we count on comments to describe the load. I like the automated approach
>myself, but I agree with Bob Ross: let's not make the IBIS Accuracy Spec
>dependent on which of the two approaches we choose to use. That way we can
>proceed with getting it approved.
>
>Thank you all for your input.
>
>Greg Edlund
>Advisory Engineer, Critical Net Analysis
>IBM
>3650 Hwy. 52 N, Dept. HDC
>Rochester, MN 55901
>gedlund@us.ibm.com
>
>
>---------------------- Forwarded by Gregory R Edlund/Rochester/IBM on
>03/15/99 12:06 PM ---------------------------
>
>
>Stephen Peters <sjpeters@ichips.intel.com> on 03/15/99 11:54:07 AM
>
>To: Syed Huq <shuq@cisco.com>
>cc: ibis-users@vhdl.org, Gregory R Edlund/Rochester/IBM
>Subject: Re: accuracy BIRD
>
>
>
>
>
>
>Hello Syed, Greg:
>
> Sorry for the delayed response -- I was out of the office back week and
>am just now getting back to my mail. To elaborate: I was trying to make
>a distinction between at V/T table that is created by an output driving a
>pure, non-reactive impedance, and a V/T table created with the output
>driving
>a more complex load. The *former* V/T table contains the data the
>simulator
>needs/uses when building the output model. Specifically, it describes how
>the pullup and pulldown transistor turn on/off, and does not -- indeed,
>should
>not -- contain any extra time constants due to reactive elements. In the
>latter case (complex, reactive impedences) the inclusion of these waveforms
>is a check. Given the model that was build with the first V/T tables, the
>question is can the simulator produce the waveform of the second case.
>
>Hope this helps clarify things.
>
> Regards,
> Stephen Peters
> Intel Corp.
>
>
>> Hi,
>>
>> Since the V/T tables allow keywords such as C_dut, R_dut, L_dut, doesn't
>> that imply that it DOES use the package numbers. I am a bit confused
>about
>> Stephen's statement below regarding old VT tables..
>>
>> Syed.
>> Cisco Systems, Inc
>>
>> >
>> > On the question of "golden waveforms" vs. "regular old VT tables,"
>Stephen
>> > Peters mentioned that there is a difference between the two. Golden
>> > waveforms have the package while regular old VT tables do not. Is
>there
>> > any syntactical construct within IBIS to differentiate between the two?
>> > Care to embellish here, Stephen?
>> >
>> > Thanks all.
>> >
>> > Greg
>> >
>> >
>> >
>
>
>
>
>
>
Received on Mon Mar 15 12:30:46 1999