================================================================================ IBIS EDITORIAL TASK GROUP http://www.ibis.org/editorial_wip/ Mailing list: ibis-editorial@freelists.org Archives at http://www.freelists.org/archive/ibis-interconn/ ================================================================================ Attendees from September 19, 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 September 14 meeting: Bob Ross noted a typo in Michael's name which is misspelled on line 78. Mike LaBonte moved to approve with this change. Arpad Muranyi seconded. Minutes were approved without objection. Review of ARs: - Quality Group to check the last row of characters in the Syntax Rules section rule #3. - Mike reported he sent out an email about this. - Arpad to add the file names discussion to the ATM agenda. - Arpad reported this was done. - Michael to send out the latest IBIS 7.0 draft and checklist to the group. - Michael reported this was done. Opens: - None. Editorial review of ver7_0_180919.docx and the task checklist: Michael noted we are continuing with BIRD186.4 regarding the File Naming Rules. There were some changes suggested over email. He suggested to use the IBIS 7.0 draft as the basis for these new changes. Bob noted there were some issues with this BIRD that need to be closed. There are 3 items that relate to BIRD186.4. The first issue is the period as part of an extension. We never meant for a period to be part of the extension, and we can resolve this as part of a clarification note. The second issue is that we never state that a stem must have at least one character, but we should state this. Bob noted this is illegal in windows, but he doesn't think this change requires a BIRD. Arpad stated that the discussion in ATM indicated that we should write a BIRD for this. He asked what would that BIRD need to address. Bob stated the third issue is that the sequence of period period ("..") should be illegal. If we want to add this new rule, then we need a BIRD for this restriction. Although, Bob thought this restriction is not necessary. If we add this rule, it needs to be vetted. Arpad thought that the reason for excluding double dots was to prevent having double dot as the file name. Michael stated the concern Radek raised was that we do not want to traverse the directory structure. He asked if there is another issue that restricting repeated double dots is required to prevent. Mike thought there is not. Arpad suggested to add "../" as a sequence that is not permitted. Mike noted if you cannot have "./" you cannot have "../". Arpad stated we should make it clear what we mean. Bob stated if we have the case of ".../" it might not be clear that this is also not permitted. Arpad asked what ".../" would do. Bob stated that we do preclude this, but his point was it is not necessary to state "../" is excluded. Michael noted we have two different audiences: model makers as human readers and those trying to write computer code to read these files. Michael suggested to add a parenthetical about sequences including "../". Michael asked about the other issue of period not being part of the extension. He added a parenthetical to clarify this. Bob agreed with this. Arpad suggested we need to work on the wording, since we have contradictory statements. He suggested to make an exception rather than a parenthetical note about period being excluded from the the extension. Bob noted we later state the extension is after the last period. Arpad stated that we are now consistent with this. Bob noted that the last period is now not part of the stem nor the extension. Arpad asked if the file can end with a period. Michael replied there was new text to say a file name cannot begin or end with a period. Arpad asked if this change requires a new BIRD. Bob thought this would require a new BIRD, as it is not a necessary clarification change. Michael asked if this rule is to go above the operating system requirements or to align with operating system rules. Bob stated we do allow files to end with a period. Arpad asked if the operating system cares if there is a dot at the end of the file. Mike noted in Unix and Linux there is no restriction on this. Michael noted Walter's concern was that the extension cannot contain a dot. Arpad commented that the last dot is the file name delimiter. Michael stated we do not define what the last period is called. Arpad commented that we have two uses for periods. The last period is the delimiter, and the other periods are part of the stem. Bob suggested to not have the new rule. Arpad asked if the last period is a delimiter to nothing when there is no extension. Mike asked if we need to have a special case to handle the delimiter. Arpad stated his concern is we do not know how the period without an extension will be handled by the operating system. He prefers to have the rule to prevent this case. Mike commented that this change would require a new BIRD. He suggested to take up the discussion in ATM. Bob stated he did some experiments in windows and notepad does not allow you to have "a." for a file name, as it forces the file name to "a". Arpad asked if this is an OS rule or a notepad rule. He suggested for Bob to do the same experiment in DOS. Mike stated the goal of the file name rules is to make files work consistently between operating systems. Bob stated DOS also does not allow "a." as a file name. Arpad stated he will write a simple BIRD to prevent file names ending with a period [AR]. Bob noted there are three places in IBIS 6.1 where this is mentioned including examples of file names as "xyz.". Arpad asked if Bob can provide the locations needing the changes. Bob also clarified this is a BIRD on 6.1. Arpad suggested to change the second sentence of rule #3 to say "file name (stem and extension)". Michael made this change. Mike noted in the list of characters that the single quote in the list of characters is the non-ASCII quote character. He suggested to change it to the ASCII single quote which is ASCII decimal number 39. Michael made this change. Mike asked if we should add the ASCII code for this single quote. Michael added a note saying labelling the "apostrophe" and "grave accent" and noted the corresponding hexadecimal codes. Michael will send out the latest draft and checklist [AR]. He noted there are some provisional changes that still need to be reviewed. Arpad asked if we should undo these changes. Mike suggested to add a line item to the checklist to review these changes. Mike moved to adjourn. Arpad seconded. The meeting adjourned without objection. The next meeting will take place Wednesday, September 26. 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?