Forwarded: Re: Re[2]: Bird38

(Forgot to copy the various committees on this.)

Bob Ross
Inteconnectix, Inc.

Date: Mon, 16 Sep 96 12:05 PDT
From: bob@icx.com ( Bob Ross)
To: John_M_Keifer@ccm.fm.intel.com
Subject: Re: Re[2]: Bird38
Status: R

John:

Another Road would be appropriate. I not given any consideration
with respect of overshoot proposals in IBIS and positioning within
RAIL (e.g., RAIL would be the practical design override) of any
given IBIS device specification if given (currently IBIS has nothing).
The time duration would be an additional parameter which IBIS may
consider. Anyway, a ROAD would be appropriate and also be useful
for an IBIS "Specification" committee meeting on Sept 24.

Bob

> Date: Mon, 16 Sep 96 09:56:00 PDT
> From: John M Keifer <John_M_Keifer@ccm.fm.intel.com>
> Message-ID: <Mon, 16 Sep 96 10:08:05 PDT_5@ccm.hf.intel.com>
> To: John.Fitzpatrick@ln.cit.alcatel.fr_at_smtpgate@ccm.hf.intel.com,
> omera@trailblazer.sps.mot.com_at_smtpgate@ccm.hf.intel.com,
> IBIS@vhdl.org, RAIL@vhdl.org
> Subject: Re[2]: Bird38
> Status: R

> Text item:

> Bob,
> An enhancement needs to be made to RAIL. I propose we simply add a width
> column to [Budgets] and a width parameter to [Clocks] that has a max of 6
> characters. The WIDTH parameter would simply state the maximum time a signal
> could overshoot high or low at the already specified level. Would you like me
> to type up another ROAD?
> John Keifer

> John and Ahmed:

> We have all had a "vacation" from IBIS committee discussions and
> need to get restarted in our discussions. I do not have answers
> to your questions, but this will be subject for discussion at the
> Friday Meeting. Along with Egg12, Ahmed Omera also submitted
> a dynamic noise proposal a long while ago which also in in the
> Specification enhancement category.

> Jon Powell had proposed a Specification sub-committee to consider
> all proposals together, but we have not acted on this yet.

> My preference is that any enhancement be simple. While some of the
> proposals involve tables, I suspect that the practical reality is
> that (1) there is too much data for anyone to really specify, and
> (2) very few vendors will consider processing that specific
> enhancement. Also, I favor consistency with the existing conventions
> and structure rather than adding very specific, special purpose,"warts".
> By this, any extension needs to work with all of the technologies and
> be meaningful for all of the columns.

> Anyway, this is what we can consider on Friday.

> Bob Ross,
> Interconnectix, Inc.

> > To: ibis@vhdl.org
> > Subject: Bird38

> > Hello all,

> > Since proposing bird 38, I have received little comment. As I was not
> > able to attend the last two meetings, this is probably my fault.

> > This bird is closely associated with egg12 i.e. it is a
> > specification addition.

> > Bird38 is basically a way to specify under- and overshoot limits.

> > A simplification of this bird would be to just give two numbers,
> > max_undershoot and max_overshoot. This is what a lot of simulators
> > do, and there is a place to stick these numbers into a RAIL file.

> > But in this case, over what time span is the over/undershoot allowed
> > to be present. I have read through the RAIL doc, but cannot find an
> > answer to this question.

> > What do people out there understand by over/undershoot limits, as
> > used in present simulators?

> > All feedback appreciated.
> >
> > Cheers,
> > John

> >
> > --
> > John Fitzpatrick <John.Fitzpatrick@ln.cit.alcatel.fr>
> > Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France
> > Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09

-------- End of Forwarded Message
Received on Mon Sep 16 12:27:35 1996