[IBIS] RE: Comments on BIRD145

From: Muranyi, Arpad <Arpad_Muranyi@mentor.com>
Date: Mon Oct 17 2011 - 09:21:14 PDT

Regarding: "Model Call is intended to call IBIS Buffers
with I/V and V/T curves; To also call an External model
in this context is beyond what we intended to."

My comment was not about calling [Model] vs. [External Model].
I am saying that if we call [Model]s from [Model Call] we
have to make the same provisions for the tool which are already
in place with [Circuit Call] and [External Circuit], so that
the tool would know which [Model] to stimulate. The reasons
are described on the bottom half of pg. 133 in the current
specification.

True, [Model] bring an addition complication because it may
contain an [External Model] which may describe a true
differential buffer. This situation may be addressed either
by not allowing [External Model]s, or not allowing true
differential [External Model]s (both would be bad choices),
or making rules for supporting them. (Note that the rules
we have in the specification on how to deal with true
differential [External Model]s and [Diff Pin] entries
could be reused for this case also, see pg. 115).

Arpad
=============================================================

-----Original Message-----
From: Taranjit Kukal [mailto:kukal@cadence.com]
Sent: Monday, October 17, 2011 12:55 AM
To: Muranyi, Arpad; ibis@server.eda.org
Subject: RE: Comments on BIRD145

Thanks Arpad for detailed review. Overall, we would update the BIRD145 with your suggestions.

My comments marked #### to your feedback

rgds
..kukal
  

-----Original Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi, Arpad
Sent: Saturday, October 15, 2011 3:55 AM
To: ibis@server.eda.org
Subject: [IBIS] Comments on BIRD145

Dear BIRD 145 Authors,

I took some time to study BIRD 145 and have the following comments.

#1) Please use page number references to the PDF file version of the specification instead of line numbers. Most BIRDs are written that way, and not everyone has text editors with line number capabilities readily available.

#### would update as suggested

#2) The Statement of the Issue section says the following:

"In this BIRD, we show how an IBIS I/O model can be included in an [External Circuit] using the new [Model Call] keyword."

Two comments. BIRDs are not to "show" or "prove things" as in a scientific paper which explains / proves a new discovery or theory. A BIRD contains a proposal for the specification for correction, or improvement. Please change the wording to reflect that.

#### would update the text

Second, this BIRD doesn't seem to propose the inclusion (or encapsulation) of IBIS [Model]s into [External Circuit]s.
My reading of this BIRD gives me the impression that the proposal describes a syntax for cascading IBIS [Model]s and [External Circuit]s (side by side). Please try to say what you mean, otherwise people will get confused...

#### YES, would update the same.

#3) The following statement is strictly speaking not true:

| Description: This keyword is used to instantiate IBIS buffer [Model]s
| to connect their reserved ports to the die nodes or die pads
| of an [External Circuit]

because [External Circuit]s don't have die pads. They
are connected to the die pads, but don't have their own
pads. Please correct the wording.

#### YES, would update the same.

#4) This is not clear in the Usage Rules section:

" When a [Model]
| is called in a circuit,"

What do you mean by circuit? What circuit is this
referring to?

Also, "T-V" should be spelled "V-T" throughout the document
because it is voltage vs. time, not time vs. voltage.

#### Somehow we were thinking SPICE here; but in this case the Model is called in the IBIS file so yes we need to update text.

#5) The following sentence is inconsistent with the rest
of the concept in this BIRD:

" The A_signal
| port is connected to the die pad, to drive or receive an analog signal."

because the whole point of instantiating a [Model] from
[Circuit Call] is to cascade it with an [External Circuit],
and not to connect it directly to a die pad.

#### You rightly pointed out. This needs updation.

#6) The [Pin] section in the example is incorrect, because
the model_name of those pins which have [External Circuit]
has to be "CIRCUITCALL" according to pg. 133 in the specification:

| When a [Circuit Call] keyword defines any connections that
| involve one or more die pads (and consequently pins), the
| corresponding pins on the [Pin] list must use the reserved
| word "CIRCUITCALL" in the third column instead of a model
| name.

So the model name for pins 5 and 9 should show "CIRCUITCALL"
(or perhaps an equivalent to it called "MODELCALL"). If you
decide to use "MODELCALL" you will have to add modifications
of the corresponding places in the specification into this
BIRD.

#### You rightly pointed out. This needs updation.

#7) The existing specification has a few subparameters for
[Circuit Call] which should be also considered for [Model Call]:

Signal_pin,
Diff_signal_pins,
Series_pins

These have the purpose that the tool can find which buffer
to stimulate when the user picks a net they want to simulate.
I would highly recommend that we add these subparameters to
[Model Call] also. This would also make the two keywords
more consistent with each other. However, as opposed to the
prohibition of pseudo-differential buffers with [External
Circuit] calls (see pg. 129), I would also allow
pseudo-differential [Model]s or [External Model]s to be
placed behind an [External Circuit]. You will also have to
make provisions for having true differential models behind
[External Circuit], since [External Model]s can do that too.

#### While it can be done but it might complicate the BIRD. Model Call is intended to call IBIS Buffers with I/V and V/T curves; To also call an External model in this context is beyond what we intended to. We would leave that to you to propose later. Do we need Series_pins in this context?

#8) In Figure 1, the GND pin is #11, but inside the drawing
you show #12. Later in the examples you are using 12. I
think they should all be 11 or 12 but not mixed.

#### This is a typo, all should be 12.

That's all for now.

Thanks,

Arpad
==============================================================

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993
Received on Mon Oct 17 09:21:37 2011

This archive was generated by hypermail 2.1.8 : Mon Oct 17 2011 - 09:22:02 PDT