[ibis-editorial] Re: FW: Queries (Set 1) V6.0 spec
- From: "Bob Ross" <bob@xxxxxxxxxxxxx>
- To: <ibis-editorial@xxxxxxxxxxxxx>
- Date: Tue, 11 Mar 2014 11:03:07 -0700
Michael:
Good points, but the Spec does not say anything about cases that are
possible from badly written tools. I do not know whether ".." by itself,
or only ".." combinations in the path specification should be prohibited.
Or we just rely on the fact that the developer will encode meaningful
path decisions.
There could be other infinite loop possibilities and also potentially
useful
possibilities with some combination of "../xyz"
Bob
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Tuesday, March 11, 2014 9:16 AM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: FW: Queries (Set 1) V6.0 spec
On (b), to clarify, is this referring to "Supporting_Files" or globally?
For "Supporting_Files", the concept that ".." is permitted needs
clarification. We are currently implying that supporting files may only
appear in directories *below* the current one containing the AMI and IBIS
files, never above. The specification also states that 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." Using ".."
alone would risk infinite loops for badly-written tools.
Should relative paths above the current directory be prohibited?
On <default_entry>, we need a more general clarification BIRD on whether the
default value is/should be unique or a repeat of another value in a List or
Range. Until then, this interpretation is fine.
Thanks for the efforts here, Bob!
- MM
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Sunday, March 02, 2014 11:59 AM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] FW: Queries (Set 1) V6.0 spec
IBIS Editorial Group
Here are questions from our parser developer and my suggested responses.
Comments?
Bob
From: Atul Prakash Agarwal [mailto:atul@xxxxxxxxxxxxxxx]
Sent: Sunday, March 02, 2014 12:03 AM
To: Bob Ross
Cc: Michael Mirmak
Subject: Queries (Set 1) V6.0 spec
Hi
Here are some queries about the spec.
a) Does the Table in Supporting_Files need to have a Labels row ? NO, NOT
REQUIRED
If so, can the label be any arbitrary string ? YES
In fact, for any Reserved Parameter, if it uses a Table, should the Labels
row be optional ? YES
If specified, should it use a standard set of labels or can it use any
labels ? ANY LABELS SINCE NO STANDARD SET IS SPECIFIED FOR ANY RESERVED
PARAMETER SUPPORTING TABLE
b) I notice the spec does not allow a dot "." in the file/directory names.
What about a dot dot ".." ? I THINK THIS IS LEGAL SINCE ANY DIRECTORY PATH
RELATIVE TO THE WHERE THE .ami FILE IS STORED IS LEGAL. SO RELATIVE PATHS
SUCH AS ".." AND "../dir_name" SHOULD ALSO BE LEGAL SINCE ".." IS NOT
PROHIBITED.
c) Can DLL_Path be an empty string ? YES, WHILE "." IS SUGGESTED, AN EMPTY
STRING "" IS NOT PROHIBITED
d) Can DLL_ID be an empty string ? YES, NOT PROHIBITED AND THE EDA TOOL
WILL RE-ASSIGN A VALUE ANYWAY
e) Can (List_Tip) occur before (Format List) ? YES, THERE IS NO ORDER
DEPENDENCY
f) Should List_Tip be supported for older versions of AMI ? ( older than 6.0
) NO
g) For determining the uniqueness of List_Tip entries, should the comparison
be case insensitive ? YES
h) The spec defines the entries in ListTip to have one to one correspondence
with the entries in List. However, the spec also has the following text.
"List_Tip <default_entry><entry><entry><entry>...<entry>"
The semantics of the <default_entry> is not defined in the spec. Please note
that any value of the List can be a default value so having the first entry
in List_Tip as a default does not make sense (while maintaining one to one
correspondence). AGREED, THE SPEC. EXAMPLE ILLUSTRATES THE PROBLEM:
(Strength (Usage In) (Type Integer) (Description "Strength of Driver")
(List 0 1 2 3 4) (Default 2)
(List_Tip "Extra Weak" "Weak" "Nominal" "Strong" "Extra
Strong"))
CONTRARY TO THE SEMANTICS, WE IMPLY BUT DO NOT STATE THAT WHEN (Default
<value>) IS USED, ITS CORRESPONDING AND UNIQUE List_Tip <entry> (NOT
<default_entry>) IS ALSO EXPECTED. THIS COULD BE A SPEC. CLARIFICATION.
Atul
Other related posts:
