Paul and Stephen,
Here are some comments regarding items #1 and #2.
#1 ################################################################################
Technically I believe the intention was to require that ANY column which contains
a MIXTURE of NA and Numerical Data MUST have as the FIRST and LAST entry in that
column a NUMERICAL entry. Furthermore, "min" and "max", but NOT "typ" columns may
consist entirely of NAs.
In the minutes for the 7/30/93 meeting over a year ago and just prior to IBIS Version
1.1 ratification and the conclusion of the IBIS_CHK check project, there were stated
some requirements:
"Requirements:
* NAs are acceptable in linear regions
* There must be no NAs in the first or last place in a column. The parser must
check for conformance to this rule.
* There should be a strict algorithm (linear interpolation) for generating missing
points
* There should be no interpolation between columns"
At that time there was controversy over the usage and meaning of "NAs". Whether the
second requirement correctly captured the context could be open for interpretation
because a subtantial part of the discussion was focused on the typical column. In any
case, the original IBIS_CHK program checks for compliance to the second requirement
only for the "typ" column, but NOT for the "min" and "max" columns, as you stated.
There are three choices for action:
(1) Do nothing, IBISCHK2 is consistent with IBIS_CHK and does NOT check min and max
columns.
(2) Introduce the check into IBISCHK2 based on the interpretation that any column
with numerical data must start and end with numerical data. Produce an ERROR
message if this is violated.
(3) Same as (2) but produce a WARNING message for a violation in the min and max
columns only.
My personal preference is to go with (3) as a compromise posiiton to capture the
intention of the specification, but also to preserve compliance with the previous
interpretation (although I do not know of any practical models that violate the
strict interpretation). My second choice and "official" recommendation is to go with
(2) since one intent of requiring a beginning and ending numerical entry for all
columns is to allow parsering of all columns containing numerical data to be done
in a consistent manner (by the same procedures). This also should make your task
easier.
I have other reasons why (2) is acceptable, but I do not want to get into the
details at this time.
#2 ################################################################################
Paul, your point is well taken that there are some confusing portions with respect
to the Terminator model keywords.
The reference diagram in the specification titled "Terminator Model" gives a model
which contains the [Rpower], [Rgnd], [Rac], and [Cac] elements AND also the
[Power clamp] and [Gnd clamp] elements. Also the C_comp, L_pkg (or L_pin),
C_pkg (or C_pin), and R_pkg (or R_pin) parameters are shown.
| |<-------------TERMINATOR Model--------------->|
|
| [Voltage Range] or
| [POWER Clamp Reference]
| o
| |
| POWER_ o---o---o
| clamp | |
| |--o--| \
| | | /
| | VI | \ Rpower [Package] Keyword
| | | / Sub-parameters
| |--o--| | |<----------------->|
| | |
| | | PIN
| o-----o-------o-----o-----/\/\/\--@@@@@@---o--o
| | |GND_ | | R_pkg L_pkg |
| | |clamp | | |
| | |--o--| | | |
| | | | \ | |
| | | VI | /Rgnd | |
| | | | \ \ |
| | |--o--| / / Rac |
| | | | \ |
| | o---o---o / |
| | | | |
| C_comp === o === Cac C_pkg ===
| | GND or | |
| | [GND Clamp Ref] | |
| | | |
| o-------------------o----------------------o
| |
| o
| GND
With the exception of the ADDITIONAL components [Rpower], [Rgnd], [Rac], and [Cac]
the Terminator model is the same as the Input model. However, unlike the Input
model, it does not require Vinh and Vinl entries.
Because the keywords [Rpower], [Rgnd], [Rac], and [Cac] may be treated differently
in different simulators and because these new elements most likely do not exist
in everyone's Input model, a restriction was imposed that if these keywords exist,
then the Model_type MUST be Terminator.
What is NOT stated is the converse. The Terminator model may contain ANY (consistent
with their individual requirements) of the elements of the reference diagram. Thus
a Terminator model may consist of only the [Gnd clamp] or [Power clamp] models
since diode "terminators" are classified in practice with the selection of available
terminators. Moreover, a Terminator type input can be constructed WITHOUT any of
the keywords, but with just the package and C_comp elements (requried even if set to 0)
alone. This is consistent with the Input model rules.
In the [Model] keyword description, there is another clarifying statement:
| Terminator This model type is an input-only device that
| can have analog loading effects on the
| circuit being simulated but has no digital
| logic thresholds. Examples of Terminators
| are: capacitors, termination diodes, and
| pull-up resistors.
###################################################################################
Attached for reference is the previous discussions on these subjects. I hope this
helps.
Bob Ross,
Interconnectix, Inc.
From: Paul Munsey <73053.721@compuserve.com>
To: Stephen Peters <speters@ichips.intel.com>
Cc: Ron Neville <75123.3477@compuserve.com>, Bob Ross <bob@icx.com>
Subject: More Parser Bugs
Message-Id: <941120024232_73053.721_GHB29-1@CompuServe.COM>
Status: RO
Stephen,
In reference to item #1, it could well be that I've misread the spec. I assume
you're referring to where it says:
All four columns are required under these keywords, however
data is only required in the typical column. If minimum
and/or maximum current values are not available, the reserved
word "NA" must be used. "NA" can be used for currents in the
typical column, but numeric values MUST be specified for the
first and last voltage points on any V/I curve.
It seems to me that you're interpretting "any V/I curve" (in the last sentence)
to refer to the typical, minimum, and maximum columns. I interpreted it to refer to
"pullup", "pulldown", "gnd clamp", and "power clamp". Thinking that way,
along with the first sentence saying "however data is only required in the typical
column", I've only checked the typical column for 'NA' in it's first and last voltage
points. This was also true in the v1.1 parser, so I've duplicated it's behavour here.
Since there's the opportunity for confusion here I've cc'd Bob Ross to verify/clarify
this.
In reference to item #2, I think some of the wording in the spec leads to
confusion here, so any clarification is useful. Here's some of the spec that seems
to speak to this:
In the [Rgnd], ... section it says "When [Rgnd], [Rpower], or [Rac] and [Cac]
are specified, the Model_type must be Terminator". It also says under the
"Required" entry, "Yes, if they exist in the device". Both of these are consistent
with what you've stated. However, in the "Other Notes" section of keyword
"[Model]" it says "A Terminator model uses one or more of the [Rgnd], [Rposer],
[Rac], and [Cac]." The term "one or more" is why I made the decision to give an
error if none of them were specified for Terminator.
Bob, could you clarify both of these for me just to make sure I get it
correct? I'll wait for your response before I fix these.
Stephen, thanks for your input.
Paul Munsey
---------- Forwarded Message ----------
From: Stephen Peters, INTERNET:speters@ichips.intel.com
TO: Paul Munsey, 73053,721
(unknown), 71436,1314
(unknown), 74012,21
DATE: 11/18/94 5:46 PM
To: 73053.721@compuserve.com
Cc: ibis@vhdl.org
Subject: More Parser Bugs
Date: Fri, 18 Nov 1994 17:30:30 -0800
From: Stephen Peters <speters@ichips.intel.com>
Hello Paul: While testing out the latest version of the parser (ibischk2b) I have
uncovered the following problems.
1. The parser allows a minimum or maximum I-V column to begin/end with NA
(it does flag an error if this occurs with the typical column). This
situation is illegal for all three columns.
2. It is legal for a terminator model to have only the [GND clamp]
and [POWER clamp] keywords and not use any of the [Rgnd]/[Power]/[Rac]/
[Cac] keywords. If this occurs the parser currenly flags this as an error.
3. The parser does not recognize the word 'Sparse_matrix' as a legal argument
to any of the [Matrix] keywords in the package model section.
Other that the above the parser looks very clean. If you receive other
feedback please have the person(s) mail the reflector so I can update the
test matrix. Thanks.
Best Regards,
Stephen Peters
Intel Corp.
Received on Mon Nov 21 14:54:53 1994
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT