====================================================================== 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 April 28 Meeting (* means attended at least using audio) ANSYS Curtis Clark Intel Corp. Michael Mirmak* Keysight Technologies Radek Biernacki*, Ming Yan Mentor Graphics Arpad Muranyi* Micron Technology Justin Butterfield, Randy Wolff* Signal Integrity Software Walter Katz*, Mike LaBonte* Teraspeed Labs Bob Ross* Michael Mirmak convened the meeting. No patents were declared. Michael noted that the April 14 meeting minutes incorrectly identified Michael Mirmak instead of Mike LaBonte as having been chair for that meeting. No other changes were suggested. Arpad Muranyi moved to approve the minutes with the correction to chair; Walter Katz seconded. The minutes were approved with no objections. In taking up BIRD186, Michael noted the need to resolve the issues with the BIRD quickly, as other BIRDs use similar concepts or affected language. Mike shared a preliminary draft 7. This draft adds text to the functional change requirements section, specifically about consistent terminology. Nomenclature recommentaions from boost.org were used as a basis for changes. The summary of proposed changes was significantly expanded. The current draft document doesn't actually make the changes in the table; a separate document is used for this. In Section 3, a new 3.1 "File Naming Definitions" section has been added. Bob Ross noted that the BIRD is defining a file name without a path, which is not the context of 99% of IBIS. A relative path in this document is a "file name" in original BIRD. These are major changes. Mike noted that there are 44 instances of "file name" in IBIS, including in [File Name]. Radek Biernacki suggested we use "file", because you can use "file" multiple times vs. the file's location. Bob responded that this would be a radical change throughout IBIS. Bob asked whether "extension" includes the period character. Mike replied that it does not, as the document is using the boost.org definition. Radek stated that we are generally not interested in root, root directory, or absolute path in general; we are only interested in relative paths. We don't "go up the [file] hierarchy." Mike replied that an absolute path is used in DLL_Path rules. This BIRD does not yet address DLL_Path. Michael asked whether we are prohibiting the use of absolute path. Walter replied that we are. Arpad stated that we need clear term definitions for paths and hierarchies. Bob mentioned Walter's earlier comment that paths are not be used in IBIS except where relative to the .ibs file location. Mike noted that the document can't use ..\ for relative paths. Bob noted that IBIS doesn't prohibit .\ Walter replied that we should be allowing .\ but it doesn't add anything in terms of path information. Bob noted that .\ is not allowed as part of a file name keyword. Arpad asked whetherwe want to allow it. Radek replied that going up the hierarchy could permit going into unknown locations. Mike added that this can be a security risk. Walter noted that adding ..\ etc. adds complexity. Radek replied that delivery of models is a separate issue from what the tool can do; Mike agreed, adding that this is for delivery of models only. Arpad noted that we still need a .\ rule; this can be grouped with ..\ but that no single \ should be allowed for absolute paths. Michael noted that the focus is just on changing Section 3. Do we point to any numbered items in Section 3 in the BIRD? Bob replied that, in many cases, we do not. For File Name and Series MOSFET, the document uses the words "paragraph" and "rule". Michael asked whether we have clarity o relatve, absolute and full paths. Radek replied that the word "name" is redundant; we are only concerned about paths. Arpad asked about "extended path". Michael asked whether someone has an example of nested paths. Walter suggested imagining having all AMI files for an AMI model in a subdirectory. With a package .ims file, one can put this file in a subdirectory below the .ibs file. One can put the circuits in the .ims file. Michael summarized this as, when specifying a file A, and referencing a file B from it, the location of B is specified relative to A. Bob replied that one should use parent directory as a term/concept. Arpad replied that, if you disallow ../, there's a problem. Bob noted that "parent" is only within the IBIS structure, not the file system. Michael asked whether the team had any issue adopting the boost.org format. Arpad made a motion to adopt the list of names as noted in the BIRD and boost.org as the format for the BIRD. Mike seconded. Arpad noted his minor concern about the phrase "file system". Radek suggested the BIRD needed a more consistent definition of relative paths, to limit "moving up" the hierarchy. Bob noted that this is a fundamental change to the look and feel of IBIS. He suggested the team "just do the work", but that now we need to scan for many more changes in IBIS. Walter replied that we are agreed on meaning and that a BIRD is not needed. A vote was taken by company, and the results were as follows (note that the participants used the word "favor" as "yes" in most cases): Intel Corp. Yes Keysight Technologies Yes Mentor Graphics Yes Micron Technology Yes Signal Integrity Software Yes Teraspeed Labs Yes The motion was therefore approved. The boost.org terminology is adopted. Bob noted that we can reference EBD files within IBIS; this means using "IBIS files" not ".ibs" in the text. Walter replied that the only time a file is not relative is when it's naming itself. Mike took the AR to upload his files to the Task Group website. Michael noted that the meetings will resume on a regular schedule. Mike moved to adjourn. Arpad seconded the motion. The meeting adjourned without objection.