Minutes from the 31 October 2018 IBIS Editorial Task Group meeting are attached.
Regards,
Justin
================================================================================
IBIS EDITORIAL TASK GROUP
http://www.ibis.org/editorial_wip/ ;
Mailing list: ibis-editorial@xxxxxxxxxxxxx
Archives at //www.freelists.org/archive/ibis-editorial/
================================================================================
Attendees from October 31, 2018 Meeting (* means attended at least using audio)
ANSYS Curtis Clark
Cadence Design Systems Bradley Brim
Intel Corp. Michael Mirmak*
Keysight Technologies Radek Biernacki
Mentor, A Siemens Business Arpad Muranyi*
Micron Technology Justin Butterfield*, Randy Wolff
SiSoft Walter Katz, Mike LaBonte*
Teraspeed Labs Bob Ross*
Michael Mirmak convened the meeting. No patents were declared.
Justin Butterfield took minutes.
Review of minutes from the October 30 meeting:
Arpad Muranyi moved to approve. Mike LaBonte seconded. Minutes were approved
without objection.
Review of ARs:
- Michael to remove the historical section numbering in Section 1.
- Michael reported this is done, and we will review it today.
- Michael to copy the conditionally required parameter changes to the other
appropriate tables.
- Michael reported this has been done, but we need to decide on the language
for the meaning of the double dash in the default column.
Opens:
- None.
Editorial review of ver7_0_181031.docx and the task checklist:
Michael showed Section 1 now has the parentheticals with the historical
numbering removed. He noted cross references for the section numbers have been
added and should automatically update. He also added a paragraph about the new
features in IBIS 7.0. Arpad asked if the section numbers reflect the new IBIS
7.0 sections. Michael replied the section references are from IBIS 7.0. Arpad
asked about the sentences which say "section" and if these should say "the
content in section" if the section numbers have been changed. Michael agreed
we should use this phrase. Bob Ross asked about the cases where we have only
moved text. Michael noted the intent of the Section 1 is a high level
introduction to the evolution of the document. Bob thought we could use the
section titles rather than the section numbers. Arpad agreed it could be more
convenient for the reader to mention the title of the section. Bob commented
the title should be indicative of the new feature. Michael proposed to make
some offline edits to Section 1. Arpad noted we also have some information
about the list of BIRDs for each versions. Michael agreed this a different way
of stating the same thing, but the BIRD titles can be cryptic.
Michael noted the next item on the checklist is the Default column issue in the
Reserved Parameter summary tables. He noted the values in the Default column
need to be resolved. Arpad suggested to add footnotes for the meanings of the
defaults. Michael stated we started this discussion last time. Arpad thought
that the double dash ("--") should mean undefined. Bob stated one use of
double dash is where there is no default, since it is a required parameter.
Arpad commented, if there is a parameter missing, it means the model does not
use it or generate it, but this does not mean the EDA tool or the User cannot
add a value. If the parameter is defined with a value of zero, the tool should
not add a value, but the system can add Jitter for instance. Bob commented
that the tool can override the parameter whether it is defined or not, but
there is no way to transmit the parameter to the DLL if it does not exist.
Arpad asked how we want to proceed with this Default issue. Michael asked if
the definitions in the footnotes are sufficient. Arpad asked about
Tx_Sj_Frequecny which has a default of Undefined. Michael replied that this
was the original default when the parameter was introduced. Bob suggested for
the double dash to correspond to required parameters and if missing no default
is permitted. Michael suggested a footnote for double dash stating it means
that an entry must be provided if the parameter is present, and no default is
assumed or permitted. Arpad thought we could use "Error" rather than double
dash. Michael stated we could also use "Illegal".
After some discussion about the purpose of the Default column, Michael stated
the intent of the table is to summarize the rules, and he noted we do not need
to spell out all the rules. Bob commented the double dash makes the table look
cleaner. Bob suggested to add the phrase "conditionally required" to the
double dash footnote. Michael asked about the Ts4file parameter which has a
double dash for the default but is not required. Arpad replied, if it is not
used, we do not provide a default. He commented that the footnote should apply
to the not required parameters as well. Arpad suggested to say if the
parameter is present an entry must included. Michael asked if the footnote he
added covers this. Arpad thought it does. Michael asked if the
Supporting_Files parameter should have double dash for the default. Michael
asked about the Jitter parameters which have a default of 0. Mike noted that
model makers have expected that the defaults of jitters are zero and suggested
to leave these entries as 0. Michael asked about Tx_Jitter which has a default
of None. Mike noted there are multiple formats for Tx_Jitter. Bob thought
"None Defined" is appropriate, since we do not know the format. Arpad
suggested to have 0 for the Tx_Jitter default.
Michael proposed to send this topic to the ATM reflector asking how to handle
the Default column. He asked if Default column has value. Bob suggested to
not discuss deleting the default column, and he proposed we should resolve the
issues with the Default column. Mike agreed noting there is value in many of
the default listings such as the PAM4 values.
Michael will send out the latest draft and checklist [AR].
Mike moved to adjourn. Arpad seconded. The meeting adjourned without
objection.
The next meeting will take place Tuesday, November 6, at 12 PM Pacific.
Open Technical Questions:
1. BIRD182: POWER and GND [Pin] signal_name as [Pin Mapping] bus_label
a. Is a bus_label created even if we don't have [Pin Mapping], [Bus Label],
or [Die Supply Pads] through the [Pin]?
b. Is a bus_label short created for legacy package models based on the
second column of [Pin] when we do not have a [Pin Mapping] entry?
