[ibis-interconn] Re: BIRD 189.5 draft 16 Comments

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: "IBIS-Interconnect" <ibis-interconn@xxxxxxxxxxxxx>
  • Date: Fri, 9 Feb 2018 13:49:46 -0500 (EST)

Bob,

Bob,

 

Answers below

 

Walter

 

Walter Katz

 <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx

978.461-0449 x 133

Mobile 303.335-6156

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Friday, February 9, 2018 1:25 PM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: BIRD 189.5 draft 16 Comments

 

All,

 

Suppose only A and B are in the group (without C and D).   Can pin 1 be
simulated?

There is no stated requirement that the "victim" or "Aggressor_Only" must
be documented as the full path for two Interconnect Models for BOTH
Buffer_I/O and Pin_I/O pin_names within an Interconnect Model Group.

 

WMK> There is no Model with Pin pin_name 1 as a victim, therefore this is
a group that cannot simulate pin 1 correctly with all of its aggressors,
and as I declared I do not want to spend any time on what an EDA tool
should do for pins that are not "victim".

 

Also, suppose A and B have 20 terminal lines and C and D have 6 terminal
lines to describe different coupling configurations or with other victims.
Are mismatched Interconnect Models B and C supposed to hook up?

 

WMK> For Pin_name 1 one can only use models that pin_name 1 is a victim,
therefore only B and C can be used. If there are missing aggressor nets on
either B and C, the parts that are missing should be shorted out. Again,
this is a poor model, and we should not be spending out time on poor
models.

 

Bob

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, February 9, 2018 8:45 AM
To: IBIS-Interconnect
Subject: [ibis-interconn] Re: BIRD 189.5 draft 16 Comments

 

All,

 

Regarding Bob's example:

 

Also, the page 7 bullets need to be expanded when we have a die pad
interface because these Interconnect Model references would be allowed in
one Interconnect Model Group:

 

[Interconnect Model] A

1    Buffer_I/O pin_name 1  Aggressor_Only

2    Pad_I/O    pin_name 1  Aggressor_Only

3    ...

 

[Interconnect Model] B

1   Pin_I/O    pin_name 1

2   Pad_I/O    pin_name 1

3   ...

 

[Interconnect Model] C

1   Buffer_I/O pin_name 1

2   Pad_I/O    pin_name 1

3   ...

 

[Interconnect Model] D

1   Pin_I/O    pin_name 1  Aggressor_Only

2   Pad_I/O    pin_name 1  Aggressor_Only

3   ...

 

The above case is legal because there is only one Aggressor_Only for
Buffer_I/O pin_name 1, and only one for Pin_I/O pin_name 1.  A can connect
to B, and C to D, but that produces two complete pin_name 1 Aggressor_Only
paths.  The rules need to be expanded to exclude this situation through
references within an Interconnect Model Group.

 

When I chose to simulate pin_name 1 an EDA tool would pick models B and C,
since they are victims. This is a unique choice. We do not care about
aggressor paths here, just victim paths. What is the problem.

 

Walter

 

 

Walter Katz

 <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx

978.461-0449 x 133

Mobile 303.335-6156

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Wednesday, February 7, 2018 12:54 AM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >
Cc: bob@xxxxxxxxxxxxxxxxx <mailto:bob@xxxxxxxxxxxxxxxxx
Subject: [ibis-interconn] BIRD 189.5 draft 16 Comments

 

Draft 16 Technical Comment:

 

Page 29, bottom, the rule on the last line at the bottom under
Aggressor_Only needs to be changed from:

 

If a particular terminal is identified as Aggressor_Only, then the entire
path of the associated pin_name is to be considered Aggressor_Only.

 

To:

If a particular terminal is identified as Aggressor_Only at one
Interconnect Model interface, then the corresponding terminal at the other
interface also shall be identified as Aggressor_Only to describe the
entire.

 

Reason:

 

Page 7 gives these rule under I/O pin_name rules:

 

o    No I/O pin_name in a component may appear as a Pin_I/O terminal
without the Aggressor_Only column in more than one Interconnect Model in
the Interconnect Model Group.

o    No I/O pin_name in a component may appear as a Buffer_I/O terminal
without the Aggressor_Only column in more than one Interconnect Model in
the Interconnect Model Group.

 

Without the suggested change, we can have Interconnect Models with
Aggressor_Only for just Pad_IO terminals and violate the intention of the
above statements (when we have pin to die pad and die pad to buffer
Interconnect Models referenced in the same Interconnect Model Group).
Furthermore, we can have one pin-to-buffer Interconnect Model with a
Pin_I/O terminal as Aggressor_Only, and a different pin-to-buffer
Interconnect Model with the same Buffer_I/O terminal as Aggressor_Only -
both referenced from the same Interconnect Model Group.

 

Also, the page 7 bullets need to be expanded when we have a die pad
interface because these Interconnect Model references would be allowed in
one Interconnect Model Group:

 

[Interconnect Model] A

1    Buffer_I/O pin_name 1  Aggressor_Only

2    Pad_I/O    pin_name 1  Aggressor_Only

3    ...

 

[Interconnect Model] B

1.      Pin_I/O    pin_name 1
2.      Pad_I/O    pin_name 1
3.      ...

 

[Interconnect Model] C

1.      Buffer_I/O pin_name 1
2.      Pad_I/O    pin_name 1
3.      ...

 

[Interconnect Model] D

1.      Pin_I/O    pin_name 1  Aggressor_Only
2.      Pad_I/O    pin_name 1  Aggressor_Only
3.      ...

 

The above case is legal because there is only one Aggressor_Only for
Buffer_I/O pin_name 1, and only one for Pin_I/O pin_name 1.  A can connect
to B, and C to D, but that produces two complete pin_name 1 Aggressor_Only
paths.  The rules need to be expanded to exclude this situation through
references within an Interconnect Model Group.

 

Bob

 

Other related posts: