Re: Bird 70.3 open issues - 2nd call

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 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 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.

>
> 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.

I agree.

> 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 would use Case 4, not Case 1 for this.

> I don't see any
> differences between Case 1 and Case 3. Are there 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.

>
> 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.

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

>
> 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 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
> objections?

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.

>
> Greg Edlund
> Electrical Packaging
> IBM Server Technology Development
> 3605 Hwy. 52 N, Dept. HDC
> Rochester, MN 55901
> gedlund@us.ibm.com
 
Received on Fri Jul 20 17:36:57 2001