Minutes from the 25 October ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 25 October 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:
- None.
-------------
Review of ARs:
- Walter to send out a proposal for modification of the existing rules for file
names. (IBIS 6.1, Section 3, item 3)
- Done.
- Michael Mirmak to draft a clarification BIRD for AMI Output parameters.
- In progress. Michael said he expects to have something soon.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Michael M.: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Bob Ross and Radek's discussion of Editorial Task Group Issues:
- Bob: Summary of the most recent meeting:
- Radek prepared draft language for the new [Local Reference] keyword.
- Discussion is still ongoing.
- Should [External Reference] be included in the "node collapse" rule?
- Probably yes.
- We discussed pseudo-differential applications and whether [Local Reference]
applies.
- Starting point for further discussions.
- No meeting this week.
Relaxation of IBIS filename restrictions:
- Walter: [sharing Section 3, item 3., which defines filename requirements]
- [sharing his emailed proposal to modify it]
- Modifications:
- Added capital letters, ".", and "/" to the original character set.
- Added a special note with respect to Windows filenames being case
insensitive but case preserving.
- Added a special note with respect to Linux filenames being case sensitive.
- "/" is added for use indicating subdirectories in a file name.
- "//", "..", are not allowed.
- "/" cannot appear as the first or last character in a file name.
- The EDA tool is responsible for converting "/" to "\" if necessary.
- This sentence may not be required.
- Arpad: You only want to allow subdirectories?
- Walter: Yes, I think that's sufficient.
- Additional proposal:
- I think an eighty character file name is still too constraining.
- Should we change it to 256?
- We would have to increase line length to 512 in that case.
- Bob: That is a separate item.
- Is 80 really too constraining for a file name?
- Walter: I'm not sure. It might be.
- Arpad: Are there any OS restrictions?
- Mike L: I believe it's 260 characters on Windows for a network path.
- 260 is the limit for the entire path, not just the file name.
- Walter: The last paragraph explains that this relaxes almost all file name
rules.
- Space character " " remains illegal in a filename.
- Absolute paths are not permitted.
- This statement might be redundant.
- Michael M: I think this would address the current IBISCHK BUG 182.
- AMI models have relative paths in a file name. (parser doesn't flag this)
- Only subdirectories would be allowed.
- Bob R: As IBIS exists today, BUG 182 is relevant and not an enhancement.
- If this change to file names gets adopted, then we can revisit the parser
issues at that time.
- As it stands now, certain combinations of "/" in filenames can cause the
parser to crash. We don't want to fix that issue yet.
- We are very sloppy in IBIS with respect to "file name".
- The original statement specified a 40 character basename, a ".", and a three
character extension, for a total of 44 character max length.
- A search of the IBIS document reveals usage of "file", "file name", and
"filename". (.pkg format sections uses "filename").
- This proposal would help with that cleanup.
- We should also note that we have reserved extensions for .pkg, .ami, .ibs
.ebd, and a pending .ims for the interconnect modeling. Those extensions
are preserved, and we should mention it.
- The contents of the [File Name] keyword, which exists in IBIS files except
.ami, should not be affected by this change to allow relative paths.
[File Name] keyword contains a single file name and no path.
- IBIS has been sloppy and has a mixture of rules.
- In Multi-lingual we make no requirements of file names.
- We don't actually require ".dll" and ".so" extensions, though the latest
parser might complain if it doesn't see them.
- So, the scope of this BIRD could involve a major editorial cleanup of
the entire document.
- Mike L.: With regard to Windows filenames, I would say that file name
resolution is case insensitive, but filename storage is case
preserving.
- In any event, I don't think IBIS should worry about that issue.
- Bob R.: I would be careful with the new verbiage about "Windows file names".
- We are introducing a new problem here. There would now be nothing wrong
with generating an entire set of Linux models that uses file name case
for uniqueness. Placing such a set of models on Windows would could fail.
The model maker has to be careful.
- Michael M.: We've seen that problem before with .zip or .tar archives
expanded on Windows.
- Mike L.: That's not unique to IBIS.
- Bob: The problem was solved by IBIS strongly suggesting using lower case.
- Mike L.: We've run into distributions where every other type of file for a
given part used mixed case, but the IBIS files had to avoid it.
- Walter: On page 99, [External Model] section, we already allow upper case
and recommend caution.
- Bob: We have different rules for different formats, and suggestions but not
requirements for some.
- There are also inconsistencies with DLL_ID and BCI_ID, which allow only
"alphanumeric" characters.
- This will be a big editorial change.
- Michael M.: There will be some overlap and editorial cleanup required.
- It's not that different than the [Pin], terminal, etc., wording changes in
the interconnect draft.
- Walter: [making changes to his proposal based on the discussion]
- Added a URL to a wiki page about case_preservation.
- Added specific reserved file name extensions.
- Noted that filename extensions are case sensitive.
- Arpad/Bob R: By "case sensitive" you mean file name extensions should be
lower case.
- Walter: I don't see any far reaching changes that need to be made elsewhere
in the document.
- We would have to scrub the document, 500+ plus instances of "file" to
review.
- Bob: I think that because we were sloppy earlier, this will interact with
many areas of the document.
- I would suggest this for IBIS 7.0.
- Walter: I certainly agree with Bob that this would not be for IBIS 6.2.
- Do people agree with this change?
- Arpad: The length of file names and line length seemed controversial.
- I think file name length factored into line length decisions.
- Why do we need a line length limit at all?
- Bob: We could have total relaxation and say there are no column length
requirements anywhere, but the entire keyword line must fit in the
line length limit.
- Arpad: Should we consider going to unlimited line length?
- What would it require?
- Some keywords would have to have "begin" and "end" pairs.
- Would it be worth the effort to review all this?
- Syntax would define the limits of things instead of hard coded line
length limits.
- You would need a more rigorous syntax to do it.
- It would be more general, instead of having to redo the line length limits
every time we want to increase the size of things.
- Walter: Making my original change would require very little.
- Relaxing length requirements for all keywords might be a big deal for
people who do their own parsing.
- Going to unlimited would be a big change. People often tend to read things
into fixed size buffers.
- Increasing a line length from 120 to 256 is probably trivial for the
official IBIS parser and other parsers. Going to unlimited is not.
- I'd prefer to do the simple thing rather than solve a hard problem that is
not a problem.
- Bob R.: Going to unlimited, we might as well do a brand new spec. altogether.
- That would be way too much.
- Walter: I agree with Bob. That would be like making a whole new spec like
Touchstone v2, and no one would use it because it's too big a change.
- Should I put this proposed file name change into an official BIRD format?
- It's not going into 6.2, so there's no rush.
- Bob R.: Yes, go ahead and put it in BIRD format.
- There might be a substantial review, and it might spawn other BIRDs.
- Walter: I don't anticipate that.
- I will scrub the document and look for whatever changes need to go into a
BIRD.
- Walter: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Walter to scrub the IBIS spec and prepare a BIRD for the proposed relaxation
of file name rules.
-------------
Next meeting: 01 November 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
