================================================================================ IBIS EDITORIAL TASK GROUP http://www.ibis.org/editorial_wip/ Mailing list: ibis-editorial@freelists.org Archives at http://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?