OK, you've really got my attention now <grin>...
The distinction in use between DLL_ID and BCI_ID is that DLL_ID defines a
namespace for *exclusive* use by an algorithmic model while BCI_ID defines
a namespace *shared* between two (or possibly more) models. There is no
guarantee that in every EDA tool the Tx and Rx models share the same
working directory. (Indeed I know one where they do not.) In this case
BCI_ID needs to provide a path in the namespace for the two models to meet
up.
It seems possible, even likely, that if the Tx and Rx do NOT share the same
working directory they reside in parallel directories under the same
EDA-managed directory tree. This is why the example in BIRD147 contained a
"../" in the BCI_ID path. Hence my earlier caveat: I'm OK with prohibiting
".." in a file name if (and only if) EDA vendors do not object. But as not
every EDA vendor is listening to this conversation, are we possibly "fixing
someone's wagon" by being too restrictive?
Regards,
Bob
On Mon, Nov 14, 2016 at 6:20 PM, Mike LaBonte <mlabonte@xxxxxxxxxx> wrote:
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@
freelists.org <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:* ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@
freelists.org] *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:* ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@
freelists.org] *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
