Looking at the definition of DLL_ID I think Bob is right:
Definition: The EDA tool is responsible for recognizing this parameter name
and replacing the value declared in the .ami file with a string that
contains a unique alphanumeric identifier. The algorithmic model is
responsible for using DLL_ID as the base name for any data files that the
model creates, either for use as temporary storage or for recording output
data. The use of DLL_ID helps guarantee that multiple instances of the same
model (or different models from the same vendor) do not mix up data as a
result of collisions between temporary or permanent file names.
It mentions the use of DLL_ID as part of file names, while saying nothing
about where those files would reside. Maybe BCI_ID should do likewise, and
therefore consist of a short string of unique characters, not a file path of
any kind. If anything we might add a AMI parameter giving a directory for
temporary files, but I think models current assume the working directory,
and tools arrange for that to be a good place. That seems good enough.
Mike
From: Bob Miller (APD) [mailto:bob.miller@xxxxxxxxxxxx]
Sent: Monday, November 14, 2016 11:23 AM
To: Mike LaBonte
Cc: IBIS-ATM
Subject: Re: [ibis-macro] Re: Draft1 of BIRD147.4 - RE: File naming BIRD
Draft 4.
Hi Mike-
BCI_ID was modelled after DLL_ID and serves a similar purpose (providing a
unique space for the model to create/find//modify/delete working files).
Either could in practice function as intended if they consist of only a
directory as you propose. On the other hand, I believe they already can be
merely a directory, especially when understood in the context of Walter's
file naming BIRD.
I wouldn't change BCI_ID unless it is seen as important enough to also
change DLL_ID.
Regards,
Bob
On Sat, Nov 12, 2016 at 12:44 AM, Mike LaBonte <mlabonte@xxxxxxxxxx> wrote:
BCI_ID is described here as a file path, yet you would never guess that from
its name. And it combines the identification of a directory to use for
message files with only a prescribed portion of the file name. The protocols
have little flexibility, they can only append more characters to form a
message file path.
Could BCI_ID be just a unique ID string like “1”? The protocols could place
that anywhere they want in a file path, including using the BCI_ID to create
a directory that contains message files with fixed names (the BCI_ID must
not have slashes). And could message files be created in the working
directory by default, unless a c parameter is present? The same value for
was actually just a unique ID string like “1” would be passed to all models.
I think with these two changes the parameter names would be more intuitive
and protocols would have greater flexibility.
Alternatively, we could simply drop BCI_ID and require tools to pass a
BCI_Message_Directory giving a unique an existing directory that contains no
files, for the models to use. These would have to be created for each
interconnected model group, but there would be no chance of file collision.
Should any files in this thread by posted somewhere?
Mike
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Miller ;(Redacted
sender "bob.miller" for DMARC)
Sent: Friday, November 11, 2016 11:48 AM
To: Bob Ross
Cc: dmarc-noreply@xxxxxxxxxxxxx; IBIS-ATM
Subject: [ibis-macro] Re: Draft1 of BIRD147.4 - RE: File naming BIRD Draft
4.
Comments on BobR's questions:
----
In BIRD147.4, what is the “absolute” path versus relative path in this
statement?
The contents of the “path string” concatenated into BCI_ID can either be an
absolute path, or a path relative to the current working directory of the
process running the executable model.
The File naming BIRD states:
Absolute files names (e.g. that begin with // or C:) are not permitted.
I think the statement in 147.4 can be deleted. This makes the EDA tool's
choice of BCI_ID more restrictive, but if the EDA vendors are OK with it, I
as a model maker don't care.
----
In the File naming BIRD there is a statement:
A “file name” may also be a directory.
In general this should not true and would lead to ambiguity regarding which
file in the directory to use.
The only place I know that this is relevant and legal is under the
parameter Supporting_Files where some of the “file names” can be
directories.
Perhaps we need to look at the general statement closer.
Agreed. This is consistent with my earlier comment about the use of "file
names" in places where the broad definition of "file name" as proposed is
not appropriate for the specific use context.
----
The example shows in the file name ID the sequence: “ ..”
(BCI_ID (Usage In) (Type String) (Value "../dll_scratch_dir/channel1")
The File Naming BIRD states:
The character sequence “..” is not permitted
The example should be changed, provided everyone can live with the more
restrictive usage. Question: why should ".." be disallowed if the EDA tool
knows that ".." is part of a legal path within it's sphere?
Regards,
Bob
On Thu, Nov 10, 2016 at 5:22 PM, Bob Ross <bob@xxxxxxxxxxxxxxxxx> wrote:
Bob M, etc.
Attached is BIRD147.4, draft2. Changes are described at the bottom.
Because the file name can include the path, the path discussion (now part of
the file name) seems ok.
Here are some more questions regarding possible contradictions:
----
In BIRD147.4, what is the “absolute” path versus relative path in this
statement?
The contents of the “path string” concatenated into BCI_ID can either be an
absolute path, or a path relative to the current working directory of the
process running the executable model.
The File naming BIRD states:
Absolute files names (e.g. that begin with // or C:) are not permitted.
----
In the File naming BIRD there is a statement:
A “file name” may also be a directory.
In general this should not true and would lead to ambiguity regarding which
file in the directory to use.
The only place I know that this is relevant and legal is under the
parameter Supporting_Files where some of the “file names” can be
directories.
Perhaps we need to look at the general statement closer.
----
The example shows in the file name ID the sequence: “ ..”
(BCI_ID (Usage In) (Type String) (Value "../dll_scratch_dir/channel1")
The File Naming BIRD states:
The character sequence “..” is not permitted
----
Bob
From: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx [mailto: ;
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> ibis-macro-bounce@xxxxxxxxxxxxx] On
Behalf Of Bob Miller (Redacted sender "bob.miller" for DMARC)
Sent: Wednesday, November 9, 2016 9:09 AM
To: Bob Ross
Cc: Walter Katz; IBIS-ATM
Subject: [ibis-macro] Re: Draft1 of BIRD147.4 - RE: File naming BIRD Draft
4.
Bob, et. al -
"optionally pre-pended with a “path string” in BIRD 147.x now seems
superfluous. (This was originally my language.) It seems like any "file
name" created under Walter's file naming BIRD "section 3" implicitly may
also include the path, which in BIRD147.x is intended.
We could ask whether all present and future "file names" will function as
intended with a path. If not, it is likely important to distinguish the file
naming rules for file names which may and which may not include a path.
Regards,
Bob Miller
Broadcom, Ltd.
On Tue, Nov 8, 2016 at 3:02 PM, Bob Ross <bob@xxxxxxxxxxxxxxxxx> wrote:
All,
Attached is draft1 of a BIRD147.4 change related to the File naming
proposal. The change is described at the bottom.
Does the clause “optionally pre-pended with a “path string”.” apply here
when the expanded file name rules can include a path?
Comments?
Bob
From: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx [mailto: ;
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> ibis-macro-bounce@xxxxxxxxxxxxx] On
Behalf Of Walter Katz
Sent: Tuesday, November 8, 2016 12:50 PM
To: IBIS-ATM
Subject: [ibis-macro] File naming BIRD Draft 4.
Mike,
Please post this on the IBIS-ATM working area.
Walter
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
