[ibis-macro] Re: [ibis-interconn] Re: Two or more I/O pins with the same signal_name ...

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: "IBIS-Interconnect" <ibis-interconn@xxxxxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 26 Aug 2020 09:03:46 -0400 (EDT)

Arpad,

 

Thank you for your comments. I am enclosing the updated BIRD.

 

Walter

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<ibis-interconn-bounce@xxxxxxxxxxxxx> On Behalf Of Muranyi, Arpad
Sent: Wednesday, August 26, 2020 12:49 AM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx>;
ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-interconn] Re: Two or more I/O pins with the same
signal_name ...

 

Walter,

 

Thanks for the draft.  Regarding the suggested new text:

 

"With a pin has a model_name that is not CIRCUITCALL or NC then all other
pins with the same

signal_name as this pin shall have the same model_name."
 
The first word "With" should probably be an "If" or :When".  But requiring
that the model names should be
the same when the signal_name is the same doesn't tell us yet whether each
of those pins should have their
own [Model] instance, or just one.  From the discussion in today's ATM
meeting I was getting the impression
that you want to have only one [Model] instance for all those pins which
have the same signal_name.  Taking
this thought a little further, this requirement could only apply to I/O
signal_names, because for power and
ground signal names you don't want to limit the number of [Model]s to just
one or to be all the same.
 
Assuming that this is what you want, and we find a way to express that,
the next question is where are these
signals "joined" together.  In legacy IBIS, whenever we said pin, we
really meant pad, for example, the series
models are supposed to be connected to the pad, even though it talks about
pins, and [Pin Mapping] groups
pads together into a short (buss), not pins.  We only invented the
possibility to make such shorts at the pins
(or pads, or buffer terminals) with the new interconnect modeling
keywords.  But because of all this history,
this BIRD will have to spell out where the joining should take place when
the IBIS file has a legacy package
model, or when it uses the new interconnect model syntax.
 
Thanks,
 
Arpad
==========================================================================
===========

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, August 25, 2020 10:09 PM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-interconn] Two or more I/O pins with the same signal_name
...

 

All,

 

It turns out that there is no rule that prohibits two I/O pins from having
the same signal_name, and in fact they can have the same signal_name and
different model_names. The proposed BIRD (attached)  adds a new rule that
prohibits two pins with the same signal_name to have different
model_names, and clarifies how package models deals with this this
situation.

 

Walter

Attachment: BIRD_Dup_signal_name.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document

Other related posts:

  • » [ibis-macro] Re: [ibis-interconn] Re: Two or more I/O pins with the same signal_name ... - Walter Katz