======================================================================
IBIS INTERCONNECT MODELING AD HOC TASK GROUP MEETING MINUTES AND AGENDA
http://www.eda.org/ibis/adhoc/interconnect/
Mailing list: ibis-interconn@xxxxxxxxxxxxx
======================================================================
Next Meeting
Wednesday, December 3, 2008
8 AM US Pacific Time
Telephone Bridge Passcode
916-356-2663 3 923-3240
(for international numbers, contact Michael Mirmak)
LiveMeeting: https://webjoin.intel.com/?passcode=9233240
Agenda:
- Call for patents
- Opens
- Final Touchstone 2.0 feature approval
======================================================================
Minutes from November 19:
Attendees:
----------
(* denotes present)
Agilent - Radek Biernacki*, John Moore, Ken Wong
Ansoft - Denis Soldo
Cadence Design Systems - Terry Jernberg, Brad Griffin
Green Streak Programs - Lynne Green
Hewlett-Packard - Rob Elliott*
Intel - Michael Mirmak*
Mentor Graphics Corp. - John Angulo*, Vladimir Dmitriev-Zdorov
Micron Technology - Randy Wolff
Sigrity - Sam Chitwood, Raymond Y. Chen, Tao Su, Brad Brim
SiSoft - Walter Katz
Teraspeed Consulting Group - Bob Ross*
========================================================================
No patents were announced.
During opens, Bob noted that he held some offline discussions, during
Which some suggested that blocking of data into an information section
might remove need for [Number of Frequencies].
Michael asked whether a meeting would be held next week. No objections
were raised.
Michael called for comments on the current draft Touchstone 2.0 specification.
Bob noted that, if we create an information block, it should appear at the very
end,
of the specification, even past the noise parameters, instead of putting
elsewhere in the main
documents. Port Groups would be moved within this block.
Michael asked whether Interconnect Port Groups is similar to IBIS measurement
parameters?
Bob responded that this was a tough analogy; agreed on the basis of it being a
throwaway
keyword. Example: a distinction is made by some vendors that a database can be
symmetrical
or reciprocal. The off-diagonal terms are equal in a reciprocal network.
Therefore, the matrix format keyword can be used to reduce (almost) half of
the existing data. Symmetrical means the network can be "flipped" end-for-end,
meaning that S11 and S22 can be identical. Therefore, some mathematical tests
could be used to determine the actual data arrangement, and may conflict with
the
given port arrangement.
SPICE connections to Touchstone files are widely used as a connection mechanism.
Bob advised that this external connection to the file should override anything
within the file.
Rob observed that VNAs measuring differential transmission lines and feeding
that into StatEye
do not require a SPICE-style connection.
Bob revised his earlier comments to suggest the actual [Begin Information]/[End
Information]
contents in any Touchstone 2.0 file should appear after [Version] and [Number
of Ports]
but before any data blocks.
John added that the arrangement in both cases makes sense.
Radek suggested that the file contents may be overridden by user decision, as
proposed above,
based on how the SPICE connections are made. This would make the information
section
and port arrangement acceptable.
Michael noted that no actual header section is mentioned in the specification.
Should the
group define a header section? In addition, could a math-intensive parser can
be defined
for passivity and symmetry checking, making the interconnect port groups a
parsable
non-comment data set?
Radek answered that parsing could be done but asked whether it is the job of
the parser
to make an interpretation of data usage? Can port names, as a keyword,
accomplish the
same Interconnect Port Groups task? What is meant by "parsable comment"?
Earlier discussion
on the reflector may have outlined a useful approach.
Radek added that "the data is the data." For whatever reason, the data may not
fit the other
assumptions in the keywords.
Rob responded that this is the reason why some are asking for the keyword.
Bob clarified that the keyword is not always applicable and not always
required. In IBIS, many keywords
are required (related to measurement). If it isn't required, it should be
assumed not
to exist. In tools, you might have a manual display to help connect the data.
Tools may
adjust data called "passive" that really isn't.
Bob added that putting in "passive, causal, reciprocal" into a file will not
change whether the
data actually defines an amplifier.
Michael suggested that "parsable comment" means the keyword is defined by the
specification
and is checked for consistency with other keywords, but may be ignored.
Radek responded that some vendors may use it, some may ignore it but this is
not the purpose of a standard.
We may already have unstructured comments.
Bob answered that this data might be usable if it exists.
Radek added that, if a user sees the data and keywords causing one behavior in
one tool and different
behavior in another, the standard is not operating as a standard.
Bob summarized that Touchstone 2.0 compliance means to the 8 required keywords;
informational keywords would
be optional. Source data may not have been generated with the additional
keywords supported
(VNA); or, a model-maker may choose not to put it in. No tool is expected to
support all or even
any of the keywords in the information section. External connections (such as
S-elements in
some SPICE implementations) will override internal information.
Bob added that the options include defining bracketed phrases as keywords, but
leave the contents
free-form (and tool-specific), or define rigid rules for keywords within the
information section.
Bob noted that Walter's position appears to be to enforce consistency between
the information
block and other keywords elsewhere in the file. If no rules exist, industry
rules may be enforced
by individual user groups.
Radek commented if other groups own the problem, they should be able to define
the format of the information.
Rob added that comments today can convey the information, but the point of the
keyword is to contain
parsable information without the requirement to use it.
Bob answered that industry-level keyword definitions would not necessarily
check each others' keyword
entries as parsable comments.
Rob suggested that bracketed keywords offsetting noise data are a highly useful
addition for StatEye
(to prevent crashes)
Michael asked the team bluntly whether they were individually accepting of
having a [Begin Information]
/[End Information] block with parsable, defined contents to be left to a future
revision.
Bob answered that he would prefer not to have the data there at all, but can
live with this format.
Radek asked why not have it outside the block, if it's rigidly defined? If
left to users to include
or not, he would be fine with that.
Bob asked how to handle unknown text in that section. The team agreed that
this was not a
free-form area, if it's controlled by the specification.
John added that the committee has to control what goes inside the keyword
block, but it's understood that these
would be special-use. We want parsers not to choke. For major revision,
perhaps the in-block
keywords can be promoted. Revision of the parser would be a bigger
undertaking. A block defines
usage for a smaller community.
Bob suggested making the section an appendix B in the specification. The
information block would be
defined later, per Walter's proposal to pull out the interconnect port groups
section.
Bob asked about removing the [Number of Frequency] keyword, as raised in the
opens.
Radek stated that this would make allocating memory and parsing less
convenient, which are the
primary purposes for the [Number of Frequency] and similar keywords. Bob
agreed to drop the
Suggestion.
Bob asked about data blocking. This will be covered at the next meeting.
Filename extension rules will also be closed at the next meeting.
AR: Bob to provide draft text of [Begin Information]/[End Information] section
========================================================================
Team Objectives:
1) complete ICM-IBIS linking BIRD and any associated changes to the
ICM specification
2) update the ICM specification, if needed, to clarify the mapping of
ICM nodes to S-parameter ports
3) complete a specification for "Touchstone Plus" or similar
industry-standard definition for Touchstone-like files, to include
complex impedance references, removal of limits on the maximum number
of ports and per-port impedance references
------------------------------------------------------------------