Leaving ibis@xxxxxxxxxxxxx off to avoid cross-post email bouncing.
Thanks, Michael, for the good review work. Some of these items are
editorial in nature, and might not necessarily warrant a revised BIRD if
we schedule a vote. However, functional change suggestions have been made
for both BIRDs and these probably should be discussed in ATM. In
particular we might want to look at a few places in IBIS 6.1 to see what
the #5 proposal for BIRD184.1 would look like.
Mike
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Monday, November 28, 2016 1:44 PM
To: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx); ibis@xxxxxxxxxxxxx
Subject: [ibis-macro] Comments on BIRDs 184.1 and 185.1
I have a few comments on the pending BIRDs eligible for a vote this
Friday:
BIRD185.1:
1) The new text still has an extra comma at the end of the "NA"
bullet. It should be removed.
2) There is a colon at the end of the new text. This should be a
period.
3) If BIRD184 were modified to extend the length of the pin_name
column, there would be no need for the CIRCUITCALL exception in the new
text and would simplify the rules overall.
BIRD184.1:
1) The phrase "pin_name" should be added to the second sentence of
"Usage Rules", to be more consistent with the rest of the specification
(as in, "The first column shall contain the pin name (this column is
referred to as pin_name elsewhere in this document).").
2) The pin_name column length can safely be extended to 13 characters
without violating the 120 character line limit. This would also enable
simplification of BIRD185.
3) I suggest that the sentence "All pins on a component shall be
specified" be removed. While I realize that this dates from early
versions of IBIS, this is an unenforceable rule and is frequently broken
in industry files.
4) The new text (in red) does not use "shall" in place of "must".
5) More controversially, I suggest changing the label "Sub-Params"
here to "Columns", and doing the same for [Diff Pin] and [Pin Mapping].
This would have no impact on the parser or EDA tools, but would make the
specification structurally consistent (and might enable true subparameters
in future).
Thanks in advance.
- MM
