[ibis-editorial] Re: Unusual topic for Wednesday: BIRD161 vs. BIRD189

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, <ibis-editorial@xxxxxxxxxxxxx>
  • Date: Mon, 26 Jun 2017 12:27:19 -0400 (EDT)

MM,

 

I agree with Arpad, I started writing a response, so I am including it
with Arpad's response.

 

I just read BIRD 161, which is currently tabled in the Open Forum.

 

There should be no issues with this and BIRD 189. It is likely that the
interconnect model set would just include the pins in the "incomplete
case", although a full package IMS file would contain pins that are not in
the component pin list.

 

For Buffer Only, the R_Pin, L_Pin, C_Pin would include on-die
interconnect, or the on-die interconnect can be represented by either
buf-to-die, or buf-to-pin. 

 

So when BIRD 161 get approved, we want to make sure that the parser does
not give false negative errors or warnings. This make require a new
component sub parameter that says this is a buffer only component.

 

Since EDA tools already support buffer only IBIS models (the package
models do not include any package interconnect), then BIRD 189 is OK as
is, it is simply a matter of the package model maker just including any
on-die interconnect in buf-to-pin model, or in the buf-die model, and
making the die-to pin model a 0 Ohm resistor. 

 

Since we do not formally support partial or buffer only IBIS files, these
work-arounds would enable model makers to create IBIS partial or buffer
only IBIS files with BIRD 189 models in IBIS 7.0, which should work with
no change when BIRD 161 is approved in a future IBIS release.

 

Walter

 

Walter Katz

 <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx

Phone 303.449-2308

Mobile 303.335-6156

From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, June 26, 2017 12:21 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Unusual topic for Wednesday: BIRD161 vs.
BIRD189

 

Mike,

 

I would suggest to leave BIRD189 alone and let it get approved ASAP.
Putting BIRD161

content into 189 might delay it and that is the last thing we want to do
at this point.

 

As a result, I think we should consider updating BIRD161 with BIRD189
content if

necessary.  If that is quick and the BIRD gets approved by the time needed
for it to be

included in the next IBIS release, fine.  If it becomes a long dragged out
discussion and

can't make it for the next release, we will add it to a later version.
But that would and

should not delay BIRD189 to appear in the next IBIS version.

 

Thanks,

 

Arpad

====================================================================

 

From: ibis-editorial-bounce@xxxxxxxxxxxxx
<mailto:ibis-editorial-bounce@xxxxxxxxxxxxx>
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Monday, June 26, 2017 10:43 AM
To: ibis-editorial@xxxxxxxxxxxxx <mailto:ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Unusual topic for Wednesday: BIRD161 vs. BIRD189

 

All,

 

I have convened the IBIS Editorial Task Group for Wednesday to address an
unusual topic: whether to update BIRD161 with BIRD189 information, or
whether BIRD189 should be updated to include BIRD161 features.  Both
approaches have been suggested in separate conversations.  Given the Open
Forum will be considering BIRD186 and 189 in the next two meetings, it's
important to resolve this while there's time for the IBIS community to
review any BIRD189 updates.

 

If you have suggestions on the best path for BIRD161, including dropping
it entirely, please feel free to bring them up on this reflector or in the
meeting.  Thanks in advance.

 

*       MM

 

Other related posts: