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