[ibis-editorial] Re: File name concepts as used in IBIS 6.1

  • From: "Mirmak, Michael" <michael.mirmak@xxxxxxxxx>
  • To: Walter Katz <wkatz@xxxxxxxxxx>, "Arpad_Muranyi@xxxxxxxxxx" <Arpad_Muranyi@xxxxxxxxxx>, "mlabonte@xxxxxxxxxx" <mlabonte@xxxxxxxxxx>
  • Date: Mon, 24 Apr 2017 18:45:49 +0000

(resend)



Walter,



Thanks for the feedback.  The issue is not that the immediate context for each 
usage is unclear.  The problem is that the contexts conflict across the 
document.



Unfortunately, I suspect this is slightly more tricky than just an editorial 
change, but not much more.  Either we can create a separate BIRD (I was 
drafting one now) or, though I hesitate to mention it, we could modify BIRD186 
to use the preferred names.  That BIRD already touches most of the areas of 
interest.  BIRD189 would then be updated to match the BIRD186 format.



What do you think?



-          MM



From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, April 24, 2017 10:13 AM
To: Arpad_Muranyi@xxxxxxxxxx; mlabonte@xxxxxxxxxx; Mirmak, Michael 
<michael.mirmak@xxxxxxxxx>
Cc: ibis-editorial@xxxxxxxxxxxxx; IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-editorial] Re: File name concepts as used in IBIS 6.1



All,



I would like to repeat a very important point here. The “name of a file” (I use 
this to not be confused with various occurrences of “file name”,  “filename”, 
“file name”, …) is always clear in the context in which they are used. The 
[File Name] keyword always references the name of the file that this keyword is 
in. By definition, this cannot contain a path and it can only be <base 
name>.<extent>. Any other “name of a file” references a file (child file) other 
than the file this IBIS record is in (parent file). “Child files” may or may 
not include a path that is always below the directory.



The [File Name] record in an IBIS file is <base name>.ibs.  The [File Name] 
record in an EBD file is <base name>.ebd. The [File Name] record in an IMS file 
is <base name>.ims. The [File Name] record in an PKG file is <base name>.pkg.



The “name of file” record in an Interconnect Model Set record is <path>/<base 
name>.ims.



A PKG file is never referenced by name in an IBIS file (the EDA tool needs to 
read all PKG files in the directory that the IBIS file is in). So PKG files 
must always be in the directory that the IBIS file is in. It should not be a 
surprise that IBIS files are rarely if ever delivered with separate PKG files, 
PKG data seems to almost always be included in the IBIS file itself.



Since the intent is always clear in IBIS whether a “name of a file” must be 
<base name>.<ext> or can be <path name>/<base name>.<ext> I do not think a BIRD 
is necessary, but can be resolved as an Editorial Task.

Can anyone point to a “name of a file” in IBIS that this is not clear?



Walter









Walter Katz

wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>

Phone 303.449-2308

Mobile 303.335-6156

From: 
ibis-editorial-bounce@xxxxxxxxxxxxx<mailto:ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, April 24, 2017 12:16 PM
To: mlabonte@xxxxxxxxxx<mailto:mlabonte@xxxxxxxxxx>; Michael Mirmak 
<michael.mirmak@xxxxxxxxx<mailto:michael.mirmak@xxxxxxxxx>>
Cc: ibis-editorial@xxxxxxxxxxxxx<mailto:ibis-editorial@xxxxxxxxxxxxx>; IBIS-ATM 
(ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>) 
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-editorial] Re: File name concepts as used in IBIS 6.1



Just to add another twist to this conversation, in the HTML world, they

call this a URL.  A URL can practically be anything, but in the end, it

is a reference to a file, whether it is local or somewhere in the big

wide world.  Look at what they call the various components of a URL here:



https://www.w3schools.com/html/html_urlencode.asp



Can we learn something from this?



By the way, we don’t seem to be the only ones wrestling with this:



http://stackoverflow.com/questions/2235173/file-name-path-name-base-name-naming-standard-for-pieces-of-a-path



Thanks,



Arpad

==========================================================================





From: 
ibis-editorial-bounce@xxxxxxxxxxxxx<mailto:ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte
Sent: Friday, April 21, 2017 8:33 PM
To: Michael Mirmak <michael.mirmak@xxxxxxxxx<mailto:michael.mirmak@xxxxxxxxx>>
Cc: ibis-editorial@xxxxxxxxxxxxx<mailto:ibis-editorial@xxxxxxxxxxxxx>; IBIS-ATM 
(ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>) 
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-editorial] Re: File name concepts as used in IBIS 6.1



Looking outside of IBIS for a moment, the Perl 
File::Basename<http://perldoc.perl.org/File/Basename.html> functions are:

    ($name,$path,$suffix) = fileparse($fullname,@suffixlist);
    $basename = basename($fullname,@suffixlist);
    $dirname  = dirname($fullname);

In their terminology, if $fullname = 'a/b/c.d' and @suffixlist = ('.d') then:

$name = c
$path = a/b/
$suffix = .d
$basename = c.d
$dirname = a/b



So their idea of basename is what we in some places call file name. Note that 
the use of DLL_ID as a basename is a slightly different concept. If DLL_ID is 
serdes_16544 then a DLL might write files serdes_16544_cdrout.csv and 
serdes_16544_dfeout.csv. I wonder if the term "file name fragment" might work 
better there?



I think we need to decide what we will call each entity:



a/b/c.d  file path? (not distinguishing between full and relative paths)

a/b      directory path?

c.d      file name?

c        file base name?

d        file extension?



Michael's effort to find the dominant current practice to determine a minimal 
change that results in a consistent policy is worthwhile. My suggestions above 
would not necessarily minimize the change. But Michael seems to have found that 
"file name" is currently used for both "c.d" and "c", so it seems to me some 
changes are warranted somewhere in the spec, no matter what we choose.



Mike



  _____

From: "Michael Mirmak" 
<michael.mirmak@xxxxxxxxx<mailto:michael.mirmak@xxxxxxxxx>>
To: "ibis-editorial@xxxxxxxxxxxxx<mailto:ibis-editorial@xxxxxxxxxxxxx>" 
<ibis-editorial@xxxxxxxxxxxxx<mailto:ibis-editorial@xxxxxxxxxxxxx>>, "IBIS-ATM 
(ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>)" 
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Sent: Friday, April 21, 2017 7:19:15 PM
Subject: [ibis-editorial] File name concepts as used in IBIS 6.1





Today’s discussion of BIRD189.2 focused on the concept of “file name” (and 
variants on the term), and whether it refers to a string that includes an 
extension, whether it is simply the pre-extension string, or whether it 
includes path information.  As noted by Bob Ross, the BIRD189.2 language is 
closely modeled on .pkg and .ebd language in the IBIS document.



I conducted a brief set of searches through the IBIS 6.1 specification, 
including on the phrases or words “base name”, “basename”, “file name” and 
“filename”.  My general findings are shown below, with quotations where 
appropriate.  All page numbers refer to the Adobe PDF* version of the file.



In brief, I believe Bob and Arpad were correct in their statements during the 
meeting, and that there is a long-standing inconsistency in how we refer to 
files in even pre-3.2 IBIS.  In particular, the usage on pages 9 conflict with 
the usage on 140 and 154.  The latter two use “filename”, when “basename” would 
be more consistent with usage elsewhere.



Fortunately, I believe we can very quickly make the document completely 
consistent by using the phrase “base name” for the non-extension portion of the 
string, and “file name” for the full string, appropriately and distinctly 
defined, without forcing model or tool changes.  Current BIRDs could be made 
consistent with these definitions very easily.



Comments are welcome.



-          MM



basename

--------

p. 9 – In the “GENERAL SYNTAX RULES AND GUIDELINES” section, “basename” may be 
up to 40 characters in length, followed by a period and an 
up-to-three-character extension



base name

--------

p. 213 - "The algorithmic model is responsible for using DLL_ID as the base 
name for any data files that the model creates..."



filename

--------

p. 140 - regarding .pkg, “filename” refers to base file name without extension

p. 154 - regarding .ebd, “filename” refers to base file name without extension

file name

--------

p. 9 – “basename” is 40 characters, followed by a period and an 
up-to-three-character "file name extension" (so here, file name is equivalent 
to basename)

p. 18 - for [File Name], "the file name must use the extension '.ibs', '.pkg' 
or '.ebd'.  The file name must be the actual name of the file."

p. 100ff - for [External Model], “file name” implies extension is included, but 
the phrase "file name extension" is used several times

p. 120ff - for [External Circuit], “file name” implies extension is included, 
but the phrase "file name extension" is used several times

p. 221 - for Supporting_Files, "file name" is explicitly described in contrast 
to directory names and paths





Other related posts: