Minutes from the 01 November ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 01 November 2016
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Broadcom (Avago): Xingdong Dai
Bob Miller
Cadence Design Systems: Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
Cisco: Seungyong (Brian) Baek
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
IBM Luis Armenta
Trevor Timpane
Intel: * Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp.: James Zhou
Andy Joy
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- Mike LaBonte noted that he will be unable to attend the next two ATM meetings
because he will be at the IBIS summits in Asia.
-------------
Review of ARs:
- Walter to scrub the IBIS spec and prepare a BIRD for the proposed relaxation
of file name rules.
- Done. An email with proposed language was sent to ATM on Wednesday,
October 26th.
- Michael Mirmak to draft a clarification BIRD for AMI Output parameters.
- Done. An email was sent to ATM on November 1st.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Michael M.: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Relaxation of IBIS filename restrictions:
- Walter: [sharing the most recent proposal email]
- Modifications to original version (some based on the last meeting's
discussions):
- File name length was originally bumped from 40 to 80.
- Added a TBD item, should we bump it to 128 or 256?
- A corresponding increase in the line length would be required.
- Added a link to a wiki page on case preservation, to illustrate the well
defined notion of "case preserving."
- Reduced the character sequences that are not permitted to "//" and "..".
- Arpad/Radek: Why exclude "//"?
- Radek: It is normally simply treated as "/".
- Walter: I left it out because it sometimes implies an absolute path.
- We can think about and discuss that one.
- New statement: "As a result of this change, 'file' shall mean the file name,
including the full path relative to the directory containing the parent
file."
- Arpad: I think "full" is confusing in that context (may be confused with
absolute).
- Walter: [removed full from the sentence, based on Arpad's comment]
- Examples: [reviewing examples provided in the email]
- [Algorithmic Model] example:
- .ami and .dll file names containing paths relative to the directory
containing the .ibs file.
- [Interconnect Model Set Selector] example:
- Entries in the selector contain .ims files with paths relative to the
directory containing the .ibs file.
- The .ims files themselves contain File_TS entries that include paths
relative to the directory containing the .ims file.
- Discussion: Radek noted that Walter's examples showed the file name entries
in each particular file as relative to that file's directory. Radek said he
would prefer that the file name entries were always relative to the directory
containing the top level .ibs file. Walter said he preferred the
hierarchical approach where file name entries in each file were relative to
the directory containing the file. He said this would make it easier to have
self-contained subdirectories that could be moved around independently and
used with multiple top level files (for example, a self-contained set of
of Interconnect Models in a subdirectory). Walter said he and Radek could
think about this and discuss it further. Bob noted that he wanted the
[File Name] keyword entries themselves to remain file name only (no path
information). He noted that the .pkg format specification said that .pkg
files had to be in the same directory as the .ibs file. Walter said this
proposal would not alter that section. Bob noted that a .ebd file in the
top level directory containing the .ibs file could itself refer to a .ibs
file which would be in a subdirectory. He noted that we have to be careful
about situations this proposal might allow, but that he thought it was a good
proposal in general. Bob asked that the wiki link entry be removed, and the
definition of case preserving be provided in the spec. Walter agreed. Walter
took the AR to draft this proposal into a formal BIRD syntax for further
review in ATM.
Format and Usage Out Clarifications BIRD:
- Michael M.: [Sharing initial Draft of the BIRD]
- BIRD constructed in response to ibischk BUG 182, which I filed regarding the
the relationship between Format and Usage Out.
- In IBIS Section 10.3, most of the Format text is written in the context of
Usage In. In some cases, In and InOut are explicitly mentioned, but in most
cases In is implied.
- That caused confusion for me when working with models that had parameters
declared as Usage Out, but the nature of Format requires a Value or some
additional argument.
- Rather than propose changing requirements or making things optional, I
opted to instead try to clarify what is expected when a parameter has Usage
Out and certain Format settings.
- There are a few changes that are non-editorial, in which I've tried to
clarify what would happen when an EDA tool sees a model that has Usage Out
and Format. This seems ambiguous enough now that different EDA tools
behave differently.
- About half the changes here are simply editorial or adding explanatory text
to make complete sentences.
- The opening lines, which attempted to clarify some technical assumptions,
may be incorrect based on email feedback I've seen.
- The intent of this was not to change anything technical about the parser or
the specification, but we may need to review some assumptions.
- Discussion: The proposed initial sentence of the Format section:
"Format defines the context or arrangement of the data being passed to the
executable model file by the EDA tool."
and the fifth sentence:
"Unless otherwise noted, specific Usage Out arguments or data provided as
Format are effectively ignored and will be simply passed by the EDA tool
to the executable model file."
were both considered unacceptable. Radek pointed out that the Format info
might be useful to the EDA tool for an Out parameter, or even necessary in the
case of Format Table, but that it is not passed to the model. Walter
pointed out that passing an Out parameter to the executable model is actually
forbidden (in page 202 of IBIS 6.1, language explicitly restricts the content
of the input parameters string to In and InOut only). It was noted that
Format Range might provide useful information to the tool. Michael M. asked
if there was anything about the contents of Value for an Output parameter that
would be useful for the EDA tool or the model. Walter and Radek agreed that
if Usage is Out, the contents of Value is totally ignored by both the EDA
tool and the executable. (note: Default was also included in the discussion,
but Default is expressly forbidden for Usage Out by the spec.)
- Michael M.: If I take out mention of the data or content as being "passed to"
the executable model for Usage Out, and restrict this to the
statements about Format being used by the EDA tool to determine
how to display Out parameter data to the user, would that be
sufficient?
- Walter: Yes.
- Michael M.: For Usage In or InOut, I think there's an implication that the
parser could do some consistency checking.
- For Usage Out, the parser can't check anything (can't check values returned
by the model at run time). However, there is an implication that the EDA
tool could check returned values (vs. a Format Range, for example).
- Radek: Yes, the parser can't test Out parameters.
- If the executable model is not following its own rules from the .ami file
(for example violating the Range specified in the .ami), I don't think we
need to require the EDA tool to report it.
- Arpad: I agree that we shouldn't require it, but we could suggest it.
- Curtis: Motion to adjourn.
- Radek: Second.
- Arpad: Thank you all for joining.
AR: Walter to put the file name relaxation proposal into a BIRD format.
AR: Michael M. to update his BIRD draft based on the discussion.
-------------
Next meeting: 08 November 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
