Subject: Bird 70.3 open issues - 2nd call

From: "Gregory R Edlund" <[email-masked]>
Date: Fri, 13 Jul 2001 08:36:24 -0500

I am resending a note that I sent out before the Summit in hopes of
getting further discussion before the Open Forum call on 7/20.  I have
gotten one response already in the positive.  I propose we make the
changes mentioned below and vote at the following Open Forum.

Greg

Issue 1:  Different inverting and non-inverting drivers

This is a legal scenario within IBIS and should be covered by BIRD 70.3.  I
propose we add a new subparameter Driver_model_inv under [Test Data].  This
subparameter is only legal when Test_data_type is differential.

I think this is a pretty straight-forward solution to the issue.  Any
discussion?

Issue 2:  Legal combinations of Test_data_type and Test_load_type

Here are the possible combinations:

Case 1:  Test_data_type = Single_ended, Test_load_type = Single_ended
Case 2:  Test_data_type = Single_ended, Test_load_type = Differential
Case 3:  Test_data_type = Differential, Test_load_type = Single_ended
Case 4:  Test_data_type = Differential, Test_load_type = Differential

Cases 1, 2 and 4 are clear.  Cases 1 and 4 are clearly allowed, and Case 2
is clearly NOT allowed.  In my opinion, Case 3 should be illegal.  If one
wanted to capture singled-ended waveforms for a differential driver, one
could use Case 1 and just specify the differential driver.  I don't see any
differences between Case 1 and Case 3.  Are there any?

Incidentally, this also implies that [Rising Waveform] (and its companions)
is legal only for Test_data_type = Single_ended and [Diff Rising Waveform]
is legal only for Test_data_type = Differential.  I like this solution.
It's simple, and it covers the space defined by IBIS.

Al Davis proposed a new keyword, [Common Mode Rising Waveform Near], but my
gut reaction to this is negative.  First, I want to close the BIRD since
it's been on the table a long time and is holding up IBIS 4.0.  Second, it
seems somewhat verbose.

I propose that Cases 1 and 4 be legal but Cases 2 and 3 be illegal.  Any
objections?

Greg Edlund
Electrical Packaging
IBM Server Technology Development
3605 Hwy. 52 N, Dept. HDC
Rochester, MN 55901
[email-masked]

---

From: Bob Ross <[email-masked]>
Date: Fri, 20 Jul 2001 17:36:52 -0700

Greg:

Sorry for the delay in responding to your messages.  Per the discussion
at the IBIS Meeting today, I am documenting my comments in your text.

I hope that they will be considered and that a BIRD70.4 can be issued
by next week in time for voting.

BIRD70.3 incorrectly documents Test_data_type as a subparameter of
[Test Load] in several places.  You have agreed to fix this.

Bob Ross
Mentor Graphics

> Gregory R Edlund wrote:

I agree.  I would also add for completeness the a Receiver_model_inv
subparameter to the [Test Load] keyword in case we have to support
unsymetrical receivers with internal terminations.

> is clearly NOT allowed.

I agree.

> In my opinion, Case 3 should be illegal.  If one
> could use Case 1 and just specify the differential driver.

I would use Case 4, not Case 1 for this.

> I don't see any

I view Case 3 can be a subset of Case 4, but with the Rdiff*
entries omitted or set to a high value.  Case 3/4 is needed to specify
differential drivers.  Case 1 should imply only Single_ended nets.  The
"inverting" side is not given or implied.

> It's simple, and it covers the space defined by IBIS.

I think Single_ended golden waveforms should be permitted for the Differential
driver case.

> it's been on the table a long time and is holding up IBIS 4.0.  Second, it

I agree.  While there may be merit in Al's proposal, it adds another level
of complexity beyond the Single_ended and Differential set of validation 
waveforms.

> I propose that Cases 1 and 4 be legal but Cases 2 and 3 be illegal.  Any

I agree.  We can live with just Case 1 and Case 4.  Case 2 and 3 should be
illegal.  Case 4 with Rdiff* omitted or set to a large value can be used
if Case 3 situations are needed.

For Case 1, some added text is needed under [Test Data] and [Test Load]
regarding what keywords and subparameters are used.  For example, the
differential golden waveforms [Diff ...] and the *_inv models and the
Rdiff* entries would be ignored.  The parser itself can issue a Warning
if this data exists.

For Case 4, a statement is needed that any Single_ended response for 
different non-inverting and inverting models (unsymmetrical differential
operation) would be referenced to the non-inverting side.  If the model
provider needed the single-ended inverting golden waveforms, then a 
different [Test Data] and [Test Load] keyword set would be used, but
with the model entries interchanged.  So there is no techical limit.  Because
of symmetry, this is not a concern if the non-inverting and inverting models
are identical.

This resolution is slightly different than what you proposed.  You stated
that Case 4 should be for differential golden waveforms only.  I am
proposing that it support both differential and single-ended waveforms
because the EDA tool probably can display and output both at the same time in
differential mode.