Subject: RE: [IBIS] Re: BIRD 75.1
From: Reid, Chris (chris_reid@mentorg.com)
Date: Fri May 31 2002 - 09:17:19 PDT
Arpad,
I've put my comments interspersed with yours below.
Chris
-----Original Message-----
From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
Sent: Thursday, May 30, 2002 5:14 PM
To: 'ibis@server.eda.org'
Subject: [IBIS] Re: BIRD 75.1
To all,
I would like to post my comments on BIRD 75.1 on this list and hopefully
generate a lively technical discussion.
Aside from some smaller and mostly editorial comments (which I will discuss
with Bob separately) I have a few bigger items that I would like to bring
up for discussion in this forum.
1) The [External Model] section discusses the need and usage of D_to_A and
A_to_D adapters. The entire discussion is voltage oriented. Is there a
need
to define the thresholds as currents? I know currents and voltages can
always
be converted to one and another, but that can be is cumbersome some times...
<chris> If there really is a need here we could consider adding it,
but I think its better to keep the syntax simple.
2) The definition of the differential thresholds doesn't seem to make sense
to me. It says "-vdiff value for vlow, and the +vdiff value for vhigh".
Doesn't
this double the span of the threshold? Shouldn't it say "-(vdiff/2) value
for
vlow, and the +(vdiff/2) value for vhigh"?
<chris> The way it is specified is the same as what IBIS already does
in the [diff pin] section. Keeping it consistent with existing usage
seems like the right thing to do.
3) The [External Circuit] and [External Model] keywords are almost
identical.
The only difference I see is that the model version has a few additional
subparameters (D_to_A, and A_to_D). I feel it should be possible to make
all
this work with just one keyword and optional subparameters depending on the
usage of the keyword.
<chris> Yes, these keywords are used in very similar ways. However,
there is one big difference. [External model] exists inside a [model]
section, while [external circuit] stands on its own. This means that
when a parser sees [external circuit] it always ends whatever other
object it has been construcing (whether it is a [component], a [model],
or some other IBIS entity) and begins a new construct. In contrast,
when [external model] is encountered it must be part of a [model], and
it does not end the [model], but just adds data to it. Besides the other
differences, this seems to me to be enough to justify calling it a
different key-word.
4) The [Node Declarations] keyword is optional and provides redundant
information. I don't see any usefulness and wonder what its purpose is. I
wonder how many models would end up actually spelling out all the nodes, if
it is optional, and if the same nodes are listed under other keywords
anyway. I would simply remove this keyword completely.
<chris> This is a perennial debate between declaring things up-front
before you use them, versus implicitly creating them as you find them.
VHDL-AMS and C++ both require declarations of things before use. Verilog
and Perl both depend on implicit declarations. I prefer declaring things
before they are used because it allows more error checking. It could be
very difficult to debug problems caused by misspelled node names if they
do not have to be declared before use. Thus I'm strongly in favor of
declaring nodes before using them.
<chris> The [Node Declaration] section should be MANDATORY, not
optional.
5) It is not clear to me what the purpose of the various Cell_ports are.
Maybe
I didn't get it yet, but it seems to me that a Port_map could do it just as
well.
Again, I favor lean and compact specs, and wonder why all these variants of
ports
are necessary in the [Circuit Call] keyword?
<chris> The cell_port declarations tell the consuming software that a
particular [circuit call] is associated with a particular package pin.
Then the software can apply the correct stimulus and make the correct
voltage and logic measurements for the simulation requested by the user.
Consider the case we have now in IBIS 3.2. The consuming software
knows which models are associated with each device pin. It is the
software's job to apply the right pulse trains and to make the voltage
and logic (threshold) measurements as required by timing constraints,
crosstalk constraints, etc. The consuming software still needs this
information to use a [circuit call] in place of a simple IBIS buffer.
The cell_port keyword gives it that required information.
6) I would favor a shorter way of writing port maps too. Imagine a
connector
with several hundred or a (few) thousand pins. The [Circuit Call] keyword's
Port_map can have lines totaling twice the number of pins, and repeating the
words "Port_map" at the beginning of each line can unnecessarily increase
the
file size without providing any useful information.
<chris> Along with your own inclination for simple specifications, I think
the port_map is easy to understand as it is, so if we do come up with some
syntax to make mapping ports take less space, it should be similarly easy
to understand.
7) In the keyword interaction limits section, regarding [Pin Mapping], I
wonder
whether that conflict could be eliminated by using the override method, like
in
other cases?
8) In the same section the combination of Series_switch and [External
Model]
is mentioned. It seems to me that we may be better off not allowing such
weird
combinations. For one, the Series_switch model was not something I would
brag
too much about as far as the detail and accuracy is concerned. If one can
make a much better model with these languages for those devices, why should
we compromise the spec with allowing ill fated combinations, when a better
modeling is available, and the old method may not be ever used again...?
These are my main comments on BIRD 75.1. I would like to get some good
technical
discussion on this subject, because I feel this BIRD is very important. It
sets
up the scene for all of our future capabilities and pain if we mess up.
Thanks,
Arpad
============================================================================
====
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.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 email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.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 email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
This archive was generated by hypermail 2b28 : Fri May 31 2002 - 09:38:47 PDT