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] On Behalf Of Mike LaBonte
Sent: Friday, October 14, 2016 2:21 PM
To: IBIS-ATM <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: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
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
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
