Minutes from the 11 January ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 11 January 2022
Members (asterisk for those attending):
Achronix Semiconductor: Hansel Dsilva
Amazon: John Yan
ANSYS: * Curtis Clark
* Wei-hsing Huang
Cadence Design Systems: * Ambrish Varma
Jared James
Google: Zhiping Yang
Intel: * Michael Mirmak
Kinger Cai
Alaeddin Aydiner
Keysight Technologies: Fangyi Rao
* Majid Ahadi Dolatsara
* Ming Yan
Radek Biernacki
Rui Yang
Todd Bermensolo
Luminous Computing David Banas
Marvell Steve Parker
Mathworks (SiSoft): Walter Katz
Mike LaBonte
Micron Technology: * Randy Wolff
* Justin Butterfield
Missouri S&T Chulsoon Hwang
Siemens EDA (Mentor): * Arpad Muranyi
Teraspeed Labs: * Bob Ross
Zuken USA: * Lance Wang
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the January 4th
meeting. Randy moved to approve the minutes. Michael seconded the motion.
There were no objections.
-------------
New Discussion:
Agenda item #8: New BIRD drafts
Issue 1 - Cleanup of A_gnd language with respect to File_IBIS-ISS.
At the previous meeting, Arpad had said that the following sentence, which
appears on pgs. 339 & 379 of IBIS 7.1 is grammatically incorrect:
"If present under File_IBIS-ISS, Terminal_type A_gnd may be used any number
of times on any of the terminal lines."
At the previous meeting, the group had decided to remove the phrase "any number
of times", since it is what mistakenly implied that A_gnd could be used multiple
times for the same terminal. Arpad had created a BIRD for this change, but he
noted that we had decided at the last meeting that the change could be handled
by the Editorial task group and didn't need a BIRD. Bob suggested we submit it
as a BIRD since Arpad had already drafted it. Randy said there was a lot of
administrative overhead in handling such a simple change with a BIRD. Bob
agreed that we could handle it with the IBIS 7.1 known issues document for now
and submit a BIRD later if it were necessary.
Arpad moved to add this issue to the IBIS 7.1 known issues document. Bob
seconded. There were no objections. Randy took an AR to update the known
issues document.
Issue 2 - Alphanumeric [Pin] names BIRD draft 2:
Arpad reviewed the proposed changes. The BIRD adds a 16th item to the Syntax
Rules in Section 3.2. The item defines "alphanumeric" to mean the characters
0-9, a-z, A-Z. The BIRD adds the alphanumeric qualifier to the [Pin] names,
which the group had agreed was the original intent.
Arpad noted one new change. In the [Series Pin Mapping] keyword section, pg.
55 of IBIS 7.1, the text says that the function_table_group Sub-param "contains
an alphanumeric designator string". Arpad thought this language was problematic
given the new explicit definition of "alphanumeric". Randy had suggested that
"alphanumeric designator string" be replaced simply by "name", which would be
more consistent with the language used in other keyword definitions. Bob said
he was concerned about possible backward compatibility issues with this change.
Curtis said the change might be required now that this BIRD strictly defines the
meaning of "alphanumeric", depending on what the ibischk parser had previously
allowed for function_table_group names. Arpad asked if we should test the
current parser to confirm its behavior. Bob took an AR to test what characters
the current parser allows in function_table_group. Bob suggested we hold off
on deciding what to do with this BIRD pending his test results.
Issue 3 - [Designator Pin List] Relaxation BIRD draft 2.
Arpad summarized the issue. He noted that IBIS 7.1 requires every pin in any
referenced IBIS [Components] to be included in the EMD [Designator Pin List].
This BIRD would relax that requirement and allow the model maker to list only
the subset of pins required for their [EMD Model]s (and any additional pins
the model maker chose to include).
Randy asked if the language of the proposed change was unnecessarily complex.
He
asked, in particular, if the final part of the sentence was necessary:
"...[EMD Set] keywords that are referenced by the [EMD Group] keyword of the
[EMD Model] that contains the [Designator Pin List] keyword."
Arpad said he wanted to make it clear that we have to be careful about how the
necessary list of pins is defined. He said the [Designator Pin List] is a top
level keyword similar to [Component]. [Designator Pin List] and [EMD Group]
appear in the [Begin EMD]/[End EMD] block, but the [EMD Set] and [EMD Model]
keywords appear outside of it. So, we can't simply say that all reference
designator pin names mentioned in all [EMD Model]s should be included in the
[Designator Pin List] keyword. We have to limit it to the designator pin names
in [EMD Model]s that are referenced by [EMD Set]s included in the [EMD Group]
that is in the same [Begin EMD]/[End EMD] block as the [Designator Pin List].
Bob said he thought that signal_name and bus_label weren't relevant to this
discussion, and we were only concerned with pin names. Arpad said his original
draft hadn't mentioned signal_name and bus_label, but he had added them based on
Walter's feedback. He said the problem was that in terminal line entries in the
[EMD Model] you could refer to pins by their signal_name or bus_label. If a
terminal line referred to a signal_name, for example, the [Designator Pin List]
would have to include all pins in the referenced IBIS [Component] that use that
signal_name. Bob said we could instead say that at least one pin must be stated
for each distinct signal_name or bus_label.
Bob said he was concerned because the original requirement to list all pins in
referenced IBIS [Components] had been the product of a long process of review.
He said relaxing the requirement would allow model makers to mistakenly provide
incomplete routing in the EMD model, and the parser would no longer be able to
check for it.
Randy asked if this BIRD was also a good place to add the 'NC' signal_type for
unconnected pins in the EMD model. Arpad said that initially it seemed the two
topics could be kept independent and voted on separately. However, if we relax
the requirement that all pins be listed in [Designator Pin List] but allow the
model maker to list unused designator pins at their discretion, then the 'NC'
topic becomes dependent on the [Designator Pin List] changes. In that case, we
might want to add 'NC' to this BIRD. Bob said he thought we should start with
separate BIRDs and combine them later if it made sense. Michael asked if this
discussion should be moved to the Interconnect task group instead. Randy agreed
that EMD modeling had come out of the Interconnect task group. Michael moved
to transfer discussion of the [Designator Pin List] BIRD and possible 'NC' BIRD
to the Interconnect task group. Randy seconded. There were no objections.
Issue 4 - Requiring clock-forwarded AMI data Rx models to return clock times
Arpad reviewed draft 2 of the proposed BIRD. He said that it simply doesn't
make sense to expect that the EDA tool could figure out the clock times based on
the data waveform or the output of the Rx clock executable model. The group
reviewed Arpad's changes, which also moved one existing sentence to better fit
the overall flow of the discussion. Bob suggested that the paragraph Arpad had
modified could be broken into two paragraphs. Arpad made this change, which
split the existing paragraph into two without any changes to order or wording
of the sentences. Arpad suggested we could review the draft again at the next
meeting and decide if it was ready to submit to the Open Forum.
- Michael: Motion to adjourn.
- Randy: Second.
- Arpad: Thank you all for joining.
AR: Randy to update the IBIS 7.1 known issues list document with Arpad's A_gnd
change.
AR: Bob to test the existing ibischk7.1 parser to see what characters it allows
in the function_table_group entries.
-------------
Next meeting: 18 January 2022 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
