Regarding "Each item would be a directory path relative to the directory the
.ibs is in",
I am not sure if we should make those paths relative and only
relative.
There are times when relative paths are useful, but there are times
when full paths are more desirable.
For example, if you want to be able to move around a file structure,
relative paths are better, but if you want to have a "central" location
for a library which is always in the same place, regardless where the
rest of the files are which reference it, a full path is better.
If we do something about this in the IBIS spec, I would suggest to
let the model maker (or even user) decide whether they want to use
relative or full paths.
Thanks,
Arpad
==========================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] ;
On Behalf Of Walter Katz
Sent: Friday, October 14, 2016 1:35 PM
To: mlabonte@xxxxxxxxxx; IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Why not hierarchical path names to supporting files
Mike,
You are correct, we would need a BIRD to specifically allow files to be defined
with a path below the directory containing the IBIS file. I think we should
consider such a BIRD just because the number of files associated with an IBIS
file can be very large.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte
Sent: Friday, October 14, 2016 2:21 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-macro] Re: Why not hierarchical path names to supporting files
Supporting_Files allows forward slashes to denote directory paths, but note the
parenthetical on IBIS 6.1 page 211 below:
Parameter: Supporting_Files
Required: No, and illegal before AMI_Version 6.0
Direction: Rx, Tx
Descriptors:
Usage: Info
Type: String
Format: Table
Default: (Illegal)
Description: <string>
Definition: Supporting_Files contains strings of file names and/or directory
names to point to files and/or directories which are used by the AMI executable
model directly or by the EDA tool (for example to generate the channel impulse
response) to function properly. Supporting_Files is organized as a table
containing a single column and one or more rows, in which each file name or
directory name entry must be placed into a separate row. The file names or
directory names may be written with or without a path, but in either case, they
must be expressed relative to the location of the .ami file in which the
Supporting_Files parameter is found. (The AMI executable models and the AMI
parameter definition files are all required to be in the same directory as the
.ibs file in which they are declared). Path separators in the entries of
Supporting_Files must be forward slashes "/". Back slashes "\" are not allowed.
The EDA tool is responsible for making any operating system-specific
adjustments (for example, replacing forward slashes "/" with backslashes "\")
if necessary. The last character of this string shall not be a forward slash
"/". A Supporting_Files entry may not be an empty string "", or a string
containing a period alone ".".
And on page 171 of IBIS 6.1 we have:
The File_Name provides the name of the executable model file. The executable
model file should be in the same directory as the.ibs file.
The Parameter_File entry provides the name of the AMI parameter definition
file, which shall have an extension of .ami. This must be an external file and
should reside in the same directory as the .ibs file and the executable model
file. See Section 10.3 for details.
So there seems to be a conflict over the strength of the "same directory"
requirement. Furthermore, one would think that for consistency parameter files
for [External Model] and [External Circuit] would follow similar rules. But
IBIS 6.1 page 98 has this:
The Converter_Parameters subparameter must contain one parameter name per line,
which must be followed by an equal sign and a constant numeric literal or a
reference to a parameter name which is located in a parameter tree. The
reference must begin with a file name, followed by an open parentheses and a
the tree root name, a new open parentheses for any branch names (including the
Reserved_Parameters or Model_Specific branch names if present in the tree) and
the parameter name, and a matching set of closing parentheses. Spaces are
allowed in the reference following the file name. The file reference may point
to any file which contains one or more parameter trees. The files referenced
must be located in the same directory as the .ibs file containing the
reference. The file names of parameter definition files must follow the rules
for file names given in Section 3,
A comprehensive and consistent approach might be to define a new top keyword to
be used near the beginning of an IBIS file:
[File Search Paths]
ibis_files/Interconnect
ibis_files/AMI
ibis_files/external
[End File Search Paths]
Each item would be a directory path relative to the directory the .ibs is in.
Tools would search those in order to find ANY and ALL files referenced in a
.ibs file, which would all be named without a path. We could debate whether the
paths would propagate such that they would apply to Supporting_files in a .ami
file loaded by the .ibs file. Having a single search path list for everything
would require having no duplicate file names.
Mike
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, October 14, 2016 1:19 PM
To: IBIS-ATM
Subject: [ibis-macro] Why not hierarchical path names to supporting files
All,
I expect some of us have seen AMI models with a large number of supporting
files. In the future, package models may have 500 IBIS-ISS interconnect
subckts, or 500 S-Parameter files. It would be very convenient for module
makers to encapsulate all of the files for an .ibs file or an AMI in a
dedicated sub-directory of the IBIS file directory. This can also go a long way
toward minimizing collisions between multiple IBIS files and all of their
supporting files.
There are not too many places where a file name is specified in IBIS. We simply
say that the executable model file name can have one or more than one
subdirectory levels. The "/" shall be used for the sub-directory delimiter both
Linux or Windows. ("\" is problematic for Linux because "\" is an escape
character in many Linux applications).
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
