Subject: [IBIS] Re: BIRD 75.1
From: Muranyi, Arpad (arpad.muranyi@intel.com)
Date: Thu May 30 2002 - 17:14:28 PDT
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...
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"?
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.
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.
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?
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.
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
This archive was generated by hypermail 2b28 : Thu May 30 2002 - 17:36:22 PDT