Minutes from the 04 January ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 04 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 November 16th
meeting. Radek moved to approve the minutes. Ambrish seconded the motion.
There were no objections.
-------------
New Discussion:
Updated Agenda:
Arpad noted that he had updated the Agenda in the ATM teleconference email:
item 6 - List of topics for which we are awaiting updates
item 7 - List of potential new topics suggested at previous meetings
item 8 - List of issues from the Known Issues document for IBIS 7.1 that we
may want to address
item 9 - New potential issue with AMI clock forwarded models.
BIRD213.1 draft 9:
Walter moved to untable BIRD213.1. He noted that we had previously decided to
table it until IBIS 7.1 was approved. Since IBIS 7.1 had been approved at the
last Open Forum meeting, he had produced a draft 9 of BIRD213.1 that was written
relative to IBIS 7.1. Bob seconded the motion. There were no objections.
Walter reviewed draft 9. He said there were no substantive changes to the
document. Change descriptions had been updated to reflect IBIS 7.1 page
numbers. Changes that were redundant now that bit_time had been renamed
symbol_time in IBIS 7.1 (BIRD214) were removed. Walter removed one additional
change listed for page 229 that was redundant because of the symbol_time changes
introduced in 7.1. Walter saved the resulting document as draft 10.
Agenda item 9 - Possible issue with clock-forwarded AMI models:
Arpad described the issue. He said for conventional SERDES models we allow the
possibility that the Rx model will not return clock times. The EDA tool can
apply its own CDR model to the signal, although even in this case it is not
clear that the EDA tool's CDR model would behave the same way as the actual
device. In the case of the new-to-IBIS-7.1 clock-forwarded Rx AMI data models,
however, it really doesn't make sense to expect the EDA tool to derive clock
times from the output data signal if the data model doesn't return clock times.
In addition, the EDA tool may not be able to use the clock input to the Rx data
model (which was output by the Rx clock model) because the Rx data model might
be processing and modifying the clock times internally. Arpad suggested that we
might want to require the Rx data model to return clock times.
Walter agreed with Arpad's suggestion. He said any device being modeled this
way probably has a clock tree and lots of other stuff in the path between the
clock and the latch, and we only care about the clock at the latch. He said he
had no objection to making the return of clock times mandatory for an Rx data
executable model. He said that the model maker may simply return the input
clock times if their model doesn't need to modify them.
Arpad then asked if we should consider requiring all Rx models to return clock
times. He said even for SERDES he never thought it was a great idea to make it
optional. The EDA tool's CDR model might not be what the real CDR would do.
Walter and Radek said such a change would violate the long-standing IBIS
principle of older models being forward compatible (you can increase the version
number on an older model and it should still work). Walter said it mirrored
what had recently been done for statistical analysis, where the time to sample
the latch is an optional Reserved Parameter Rx_Decision_Time (BIRD 205). Walter
said he would not object to adding new language suggesting that model makers
were "discouraged" from not returning clock times. Ambrish said similar
language would need to be added for Rx_Decision_Time if we added it for
clock_times.
Agenda item 8 - IBIS 7.1 known issues:
Issue 1 - Arpad 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."
He said the sentence implies that A_gnd may be used multiple times on the same
terminal line. Walter agreed and suggested:
"If present under File_IBIS-ISS, Terminal_type A_gnd may be used on any
number of terminal lines."
Bob agreed, and Bob, Walter and Arpad agreed this was a purely editorial fix
that could simply be added to the IBIS 7.1 known issues document.
Issue 2 - The [Pin] keyword does not include the "alphanumeric" restriction,
which should be added for consistency with other pin name keywords. Arpad said
that we should also explicitly define what we mean by "alphanumeric", and a
strict definition would only include 0-9, a-z, A-Z. He noted that some new
keywords that include the "alphanumeric" qualifier can themselves include [Pin]
names, so [Pin] names could now implicitly have to be alphanumeric. Bob had
tested the existing parser, and it did allow non-alphanumeric characters in
[Pin] names while rejecting them in other pin name keywords (correct behavior
according to the current specification).
Walter said he wouldn't object to a definition of alphanumeric that included
some special characters like '_' (underscore). Arpad agreed in principle, but
said since pin names are limited to 5 characters the usefulness of a delimiter
character like '_' is limited. He also noted Bob's argument that the original
intent had been to support data book pin names, and the strict definition of
alphanumeric was intended.
Bob said if we assume the strict definition of alphanumeric, then this could
just be an editorial change, as the original intent was for [Pin] names to be
alphanumeric. Arpad said he thought he should draft a BIRD for this. Walter
said he would not object to limiting [Pin] names to strict alphanumeric. He
quickly searched and confirmed that all existing occurrences of "alphanumeric"
in the specification are related to pin names and would be compatible with the
strict definition. Bob agreed with this. Arpad took an AR to draft a BIRD.
Issue 3 - The EMD [Designator Pin List] does not allow signal_type 'NC', and
it requires all pin names from referenced IBIS Components to be listed.
Arpad said he thought the requirement that [Designator Pin List] include all
pins of the referenced IBIS Component should be relaxed. He explained that if,
for example, the same IBIS Component were included five times, then all pins
would be included five times. Since we currently don't allow 'NC', the model
maker would have to invent fictitious and unique signal_names for each of the
pins that wasn't actually connected/supported in the EMD model. Arpad said his
interpretation of what 'NC' would mean in a [Designator Pin List] is that the
EMD model has nothing connecting to that IBIS Pin. So, if we relax the
requirement that all pins need to be listed, then 'NC' wouldn't be needed.
Walter said he would like to adopt both of Arpad's suggested changes. Arpad
asked whether we should have two BIRDs, one for relaxing the requirement that
all IBIS Pins are listed in [Designator Pin List], and one for allowing 'NC'.
Arpad said they could be independent BIRDs. Radek said they are interdependent.
If you decide not to allow 'NC', then you would not just relax the requirement
that all pins be listed, you might instead require that only pins connected
to the EMD model are listed.
Walter moved that we draft BIRDs to relax the requirement that all pins be
listed and allow 'NC' in EMD [Designator Pin List]. Radek seconded. There were
no objections. Arpad took an AR to draft the BIRDs.
Bob noted that the current scheme, which requires all pins to be listed, allows
the parser to crosscheck the EMD model against the referenced IBIS [Components].
- Walter: Motion to adjourn.
- Jared: Second.
- Arpad: Thank you all for joining.
AR: Arpad to draft a BIRD clarifying "alphanumeric" in [Pin] names.
AR: Arpad to draft a BIRD relaxing the requirement that all pins be listed in
the EMD [Designator Pin List].
AR: Arpad to draft a BIRD allowing 'NC' signal_type in [Designator Pin List].
-------------
Next meeting: 11 January 2022 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives