If you have the V_Load then you do not need to have waveform tables and you will
be able to model limited data more accurately without incurring the overhead of
waveform tables(e.g. if the source of the
data is data book ).
- kumar
>
>
> Text item:
>
> You are correct in observing that there is no V_load specified in IBIS2.0 with
> the key word Ramp. To explain what happened here requires a little history.
>
> In IBIS1.1 R_load was a fixed 50 Ohm resistor, which was connected to Vcc or
> GND. (See "Notes on data derivation method" section of IBIS1.1). In IBIS2.0 we
> added the sup-parameter R_load to the Ramp keyword, because a ramp measurement
> with a very weak buffer could result in a very small voltage swing which
> significantly reduces the accuracy of the measurement. Using a different R_load
> overcomes this problem. This sub-parameter was added for those who want to
> continue to use the ramp keyword rather than the [Rising Waveform] and [Falling
> Waveform] keywords provided by IBIS2.0.
>
> However, when using the waveform keywords, which are a superset of the Ramp
> definition, you can have an arbitrary waveform with any R_load and V_load
> specified. Since a ramp can be considered a special case of a waveform (or V-T)
> curve (which replace the Ramp keyword), I do not see any reason to retroactively
> add a V_load specification for Ramp.
>
> Arpad Muranyi
> Intel Corporation
>
>
> This raises an interesting point. How reliable is the value of C_comp itself?
>
> Anyway I am not in favor any "implied" quantities associated with waveform
> tables. Every parasitc associated with that wave should be explicitly
> stated. So for example C_dut can include the effects of C_comp.
>
> While I am at it I also want to raise another point regarding ky word Ramp.
> That specification includes R_load. But there is no provisison for V_load.
>
> If we look at the notes on Ramp rates there are situations in which V_load is
> vendor specified and there is no place in IBIS models where thie information
> is
> carried.
>
> Text item: External Message Header
>
> The following mail header is for administrative use
> and may be ignored unless there are problems.
>
> ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
>
> Subject: Re: BIRD24 COMMENT
> To: ibis@vhdl.org, bob@icx.com
> Message-Id: <9412071427.AA12235@hot>
> From: cpk@cadence.com (C. Kumar)
> Date: Wed, 7 Dec 94 09:27:20 -0500
> Received: by hot (5.65+/1.5)
> id AA12235; Wed, 7 Dec 94 09:27:20 -0500
> Received: from hot by cadence.Cadence.COM (5.61/3.14)
> id AA01900; Wed, 7 Dec 94 06:26:32 -0800
> Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via sma
> id sma015993; Wed Dec 7 06:27:27 1994
> Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA1601
> Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
> id AA15684; Wed, 7 Dec 94 06:32:07 PST
> Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 7 Dec 94 06:
> Received: from hermes.intel.com by relay.jf.intel.com with smtp
> (Smail3.1.28.1 #2) id m0rFNhb-000twwC; Wed, 7 Dec 94 06:50 PST
>
Received on Wed Dec 7 09:38:52 1994
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT