To IBIS Members:
The response to the letter ballot on SP-4557 for ratification of IBIS
Version 3.2 as EIA-656-A is 17 Yes and 0 No.
Four of the Yes votes contained comments. Some proposed responses to the
comments are given below for discussion and possible ratification at the
IBIS meeting on July 23, 1999.
We may revise our DRAFT responses to some comments based on the discussion
at the meeting.
These DRAFT responses were generated and contain input from Bob Ross (Mentor
Graphics), Stephen Peters and Arpad Muranyi (Intel Corporation) and
Guy de Burgh (Viewlogic Systems).
Bob Ross
Mentor Graphics
*******************************************************************************
EIA IBIS COMMITTEE RESPONSE TO MENTOR GRAPHICS COMMENTS TO STANDARDS
PROPOSAL NO. 4557
Mentor Graphics: 1
Editorial
Suggested Change: We support the approved BIRD58.3 editorial changes to be
implemented in the document.
Response: We agree with this Suggested Change. The approved version of
EIA-656-A will contain the BIRD58.3 changes.
Mentor Graphics: 2
Editorial
Suggested Change: We support correcting minor grammatical and consistency
mistakes that may be encountered as part of the final document preparation
process.
Response: We agree with this Suggested Change. The approved version of
EIA-656-A will correct obvious grammatical and consistency errors discovered
by the document preparation team.
*******************************************************************************
EIA IBIS COMMITTEE RESPONSE TO ANIGMA, INC. COMMENTS TO STANDARDS PROPOSAL
NO. 4557
Anigma, Inc: 1
Technical
Reference: Page 22
Keyword: [Model Spec]
Required: No
Suggested Change: Change from Required: No to Required: Yes
Rationale: Test load parameters Vmeas, Vref, Cref and Rref are critical
to the timing analysis part of SI simulation.
Therefore the parameters Vmeas, Vref, Cref and Rref should be accurately
preset in every "driver" model.
Response: No Change will be made.
Reason: The suggested change also relates to the [Model] keyword and
the subparameters Vmeas, Vref, Cref and Rref described on pages 20-22.
While many members of the committee will support your position in practice,
we are rejecting this suggested change for the following reasons:
Committment to Backward Compatibility. We making Vmeas and other
subparameters required would conflict with one item in our Statement of
Intent on Page 5. Valid Version 2.1 IBIS models that do not have the
optional Vmeas and other subparameters would no longer be valid. In other
words, some IBIS models that are valid according to ANSI/EIA-656 would
be invalid according to EIA-656-A.
Furthermore, the test load parameters are only useful for delay measurement,
which either may not be needed or generated in some simulators.
However, in the related Cookbook document we strongly support the practice
of adding the appropriate optional subparameters to models so that they
contain all of the information needed for all simulators.
*******************************************************************************
EIA IBIS COMMITTEE RESPONSE TO INTEL CORPORATION COMMENTS TO STANDARDS
PROPOSAL NO. 4557
Intel: 1
Editorial
Suggested Change: Remove any reference to "tab" in the phrase "must be
separated by at least one white space or tab character". This occurs
thruout the document.
Response: We agree with this suggest change. Only "white space" will be
used. Also, in some locations a subsequent sentence related to not
recommending using the "tab" character will be removed since it is now
out of context.
Note: This text has existed since Version 1.1.
Intel: 2
Editorial
Reference: Page 42
Suggested Change: Is [Add Submodel] the only keyword that is position
dependent (within the file). This seems ugly.. this keyword should contain
an explicit reference to the top level model.
Response: No change will be made.
Reason: The paragraph referenced below states that the [Add Submodel]
keyword can be positioned anywhere among the keywords after the initial
subparameters of the [Model] keyword. This is consistent with all of
the other keywords under [Model] with the exception of the [Model Spec]
keyword. Since the [Model Spec] keyword describes subparameters, it
is positioned after the list of subparameters.
The syntax checker ibischk3 detects only the position of [Model Spec].
It accepts [Add Submodel] in any location under [Model].
For reference the confusing paragraph is stated below:
| When special-purpose functional detail is needed, the top-level model can
| call one or more submodels. The [Add Submodel] keyword is positioned
| after the initial set of required and optional subparameters of the [Model]
| keyword and among the keywords under [Model].
|
There is no need to explicitly reference the top-level model since [Add
Submodel] is a keyword positioned within that specific [Model].
Intel: 3
Editorial
Reference: Page 11
Suggested Change: Last sentence of the Usage Rules section of the [Component]
description appears to have a typo.. remove the word 'and'.
Response: We agree with this suggest change. The word "and" will be deleted.
Intel: 4
Editorial
Reference: Page 20
Suggested Change: The last sentence in the introductory paragraph of usage
rules is redundant and should be removed. Sentence begins "Model names
with reserved...".
Response: We agree with this suggest change. The redundant sentence will be
deleted. Also, the document format for that paragraph which contains
shortened lines will be fixed.
Note: This text has existed since Version 1.1.
Intel: 5
Editorial
Reference: Page 23
Suggested Change: When describing the Vinh, Vinl rules and the typ column,
clarify if the typ column either does or doesn't override that declared
elsewhere. The phrase "would be expected to" isn't clear at all.
Response: We agree with this observation. The words "would be expected
to" are deleted since the intent is to describe exactly what subparameters
override other subparameters.
Intel: 6
Editorial
Reference: Page 23
Suggested Change: Delete paragraph about reversing Vinh, Vinl to mimic
hystersis. While this my be true, we have explicit parameters that
describe this functionality and we should not document or encourage an
alternate method.
Response: We agree with this suggest change. The paragraph will be
deleted since it also describes an interpretation that has not been
standardized.
Intel: 7
Editorial
Reference: Page 24
Suggested Change: the whole discussion on dynamic and static overshoot is
confusing. I can't figure out if static or dynamic overshoot implies an
absolute maximum rating or device destruction or what. Not sure how to fix,
but this does need to be clarified.
Response: We agree with this section may not be clear. We plan to add
a figure (in reponse to another letter ballot comment) to clarify this.
Intel: 8
Editorial
Suggested Change: Change all "S" to "s" when it is used as the abbreviation
for the unit of time as in seconds. Capitol "S" stands for the unit of
conductance, Siemens, and not time. This should be done also where it
appears with prefixes, such as "n" for nano, etc.
Rationale: In general, we should follow the official standard spelling
rules of units and prefixes everywhere.
Response: We agree with this suggest change. We intend to use standardized
abbreviations throughout the document. We will correct all occurences.
Intel: 9
Editorial
Suggested Change: I found two occurrences of "VI" in an ASCII drawing
which should be changed to "IV" to be consistent with the spelling in
section 9, "Notes on Data Derivation Method", and BIRD58.2.
Rationale: These curves are plotted current verses voltage, and the proper
order for the symbols "I" and "V" therefore is IV, not VI.
Response: We agree with correcting the problem. We will change the occurences
of VI in the diagram to I-V. We will also change all occurences of "V/I" and
"IV" to "I-V" for consistency.
Note: The term "V/I" has existed since Version 1.1. However, we need to
provide consistent nomenclature throughout the document.
*******************************************************************************
EIA IBIS COMMITTEE RESPONSE TO CISCO SYSTEMS COMMENTS TO STANDARDS
PROPOSAL NO. 4557
Cisco Systems: 1
Editorial
Reference: Page 24
Suggested Change: Add a hysteresis diagram showing all the sub-parameters.
Rationale: Would clarifiy usage of Vinh+, Vinh-, Vinl+, Vinl-,
S_overshoot_high, S_overshoot_low, D_overshoot_high, D_overshoot_low,
D_overshoot_time, Pulse_high, Pulse_low, Pulse_time.
Response: We agree with this suggest change. We will add an illustration or
illustrations to clarify the meaning of the subparameters.
Cisco Systems: 2
Editorial
Reference: Page 31
Suggested Change: Change from
"..of one note per V/I table if .."
to
".. of one warning per V/I table if ..",
and change from
"Note: Line 300, Pulldown .."
to
"Warning: Line 300 Pulldown ..".
Response: We agree with this suggest change. We will make the changes
from "note" to "warning" as suggested.
Cisco Systems: 3
Editorial
Reference: Page 40-41
Suggested Change: Should provide example with 4 V/T tables instead of the
two shown. Model developers are providing 2 V/T tables following the
conditions illustrated on Page 40 & 41. Since 4 V/T tables have been
discussed extensively in the forum for accuracy reasons, please provide
example of all four cases:
1) [Rising waveform] with 50 Ohms to vdd
2) [Rising Waveform] with 50 Ohms to gnd
3) [Falling waveform] with 50 Ohms to vdd
4) [Falling Waveform] with 50 Ohms to gnd.
Response: No change will be made.
Reason: While we agree with the intent of the suggestion, the document intends
to illustrate only the syntax or protions thereoff. Adding two more tables
would be redundant. Complete examples and guidelines are contained in other
documents.
Cisco Systems: 4
Editorial
Reference: Page 69
Suggested Change: Need a diagram clarification of parameters used.
Response: We agree with this suggest change. Each of the three examples will
have a corresponding diagram.
*******************************************************************************
Received on Wed Jul 21 13:32:57 1999
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:30 PDT