Re: IBIS Open Forum 1/6/95 Meeting Minutes

The problem with I-V checking is that there is no "standard" load as
with V-T curves. We already went through this i-v standard load discussion
and dropped it because
of controvorsey. The reason I raised it because that I think that in
signal integrity situations the dc I-V characteristic has more has a dominant
effect on the resulting waveforms and we have no reference to check against.

>
>
> Text item: Text_1
>
> Hello IBIS gurus,
>
> In the last minutes Kumar suggested DC checking (see quote below). I am not
> sure what he means, but just as we can use V-T tables for AC checking, couldn't
> the I-V curves be used for DC checking?
>
> Arpad
> Intel Corporation
>
>
> > Compliance
> > Will pointed out that the V/T table can be used to as a type of compliance
> > test/sanity check. Kumar would like to see a DC check as well.
>
> > AR Kumar: Post an EGG for DC checking.
>
>
> 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: IBIS Open Forum 1/6/95 Meeting Minutes
> To: Randy_L_Wilhelm@ccm.fm.intel.com, Jerry_Budelman@ccm2.jf.intel.com,
> bWard@neosoft.com, IBIS@vhdl.org
> Message-Id: <950113103507_2@ccm.hf.intel.com>
> From: Derrick Duehren <Derrick_Duehren@ccm2.jf.intel.com>
> Date: Fri, 13 Jan 95 10:35:07 PST
> Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 13 Jan 95 10:35:07 PST
> Received: from ccm.hf.intel.com by relay.jf.intel.com
> (Smail3.1.28.1 #2) id m0rSqq5-000twhC; Fri, 13 Jan 95 10:35 PST
> Received: from relay.jf.intel.com by ormail.intel.com with smtp
> (Smail3.1.28.1 #7) id m0rSqq7-000Ug3C; Fri, 13 Jan 95 10:35 PST
> Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
> id AA09335; Fri, 13 Jan 95 10:40:26 PST
> Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 13 Jan 95 10
> Received: from hermes.intel.com by relay.jf.intel.com with smtp
> (Smail3.1.28.1 #2) id m0rSrDN-000twfC; Fri, 13 Jan 95 10:59 PST
>
Received on Tue Jan 17 07:00:29 1995