On page 211 of IBIS 6.1:
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.
…
When directory names are used in this parameter, it is implied that all of
the files and subdirectories in that directory are needed by the AMI model.
Your wish has been granted J
Mike
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Miller ;(Redacted
sender "bob.miller" for DMARC)
Sent: Tuesday, October 25, 2016 4:50 PM
To: Walter Katz
Cc: Muranyi, Arpad; IBIS-ATM
Subject: [ibis-macro] Re: Why not hierarchical path names to supporting
files
I think we may want/need to revisit the AMI Reserved_Parameter
"Supporting_Files" to be consistent. In particular, I would like to see it
possible to reference a directory instead of a potentially long list of
files in Supporting_Files and the so-named directory tree is sucked up by
the EDA tool and made available to the model in a location the model expects
to find them (i. e. via DLL_Path). If supporting files are delivered in the
.ibs file directory in a tree of subdirectories, they should be presented to
the executable model in the same tree.
Regards,
Bob
On Fri, Oct 14, 2016 at 5:17 PM, Walter Katz <wkatz@xxxxxxxxxx> wrote:
Arpad,
I think the IBIS file and supporting files should be delivered in a single
directory with all files either in the top directory or in subdirectories
below the top directory. When this IBIS file is imported into the library
structure of a company or an EDA tool, the files could be put into other
structures as you suggest.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, October 14, 2016 6:57 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Why not hierarchical path names to supporting
files
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] 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
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
