Minutes from the 18 October ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 18 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:
- Walter noted that he was interested in talking about allowing the use of
relative paths in locating supporting files for an IBIS file.
-------------
Review of ARs:
- Bob Ross to send out an updated BIRD 147.2 proposal containing the changes
discussed.
- Done. A further updated version, BIRD 147.3, was sent out after a
post-meeting email discussion amongst several attendees.
- Mike LaBonte to submit BIRD 147.3 to the Open Forum.
- Done.
- Michael Mirmak to draft a clarification BIRD for AMI Output parameters.
- In progress.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Radek: Motion to approve the minutes.
- Walter: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
- Arpad: Anything else to discuss on BIRD 147.2 or 147.3?
- Bob R.: BIRD 147.3, as submitted to the Open Forum, is all set.
- Mike L.: I think technically it is now out of this committee.
- There was no real controversy over it when it was introduced at the Open
Forum last Friday.
- I think it can be off the ATM agenda for now, unless the Open Forum asks
for some more input.
- Bob: There is one bigger picture issue that came up, which might be taken
care of in another BIRD.
- The BCI_ID definition contains the language "alphanumeric identifier",
similar to the language for the AMI Reserved parameter DLL_ID.
- That's an issue for the future, as we might want to relax the "alphanumeric"
requirement and allow the full character set allowed for filenames
[See Section 3, item 3. of the IBIS spec.].
- Walter: BCI_ID contains a unique name created by the EDA tool.
- It's not created by the model maker (maker of the .ami file).
- I agree that it might be over-constrained, but I don't think it's a problem.
- We can relax it in the future if we want to, but it's not causing any
trouble.
- Bob: We might flag a legal file name character as an error in the parser?
- Walter/Ambrish: No the parser doesn't see this value, it's set at runtime by
the EDA tool.
- Bob: What about the default value in the .ami file?
- Would "no_name" as a default value be flagged? I'm not sure.
- Radek: The values in the .ami file for BCI_ID and DLL_ID are just place-
holders that can be completely ignored.
- Bob: Okay, the bottom line is that BIRD147.3 is okay as is.
- In the future, we may want to look at whether we should relax that
statement that the values of those parameters have to be alphanumeric.
Bob Ross and Radek's discussion of Editorial Task Group Issues:
- Bob: We reviewed what we agreed upon.
- These have been stated before:
- We have the "node collapse" rule where if all the corner values for
two [* Reference] keywords are the same, then their corresponding
terminals are considered the same (shorted).
- We prefer "simulation model" vs. DIA (device in action).
- We recommend [Local Reference] as another reference keyword.
- Its primary function is to provide the node for the default C_comp or
Package connections.
- We discussed a [DUT Reference] and its node, which provides the reference
for extraction of IBIS model information.
- We discussed a notion of a simulation reference, which is where the
[Local Reference] is connected.
- We agreed that with [Local Reference] we would not change the I-V tables.
But we could measure I/O buffer outputs with respect to a simulation
reference.
- Next steps are to document what we agreed upon.
- Somehow insert the "node collapse" rule into the spec.
- It could be part of an expanded version of BIRD 181.1, or it could be
in a BIRD related to the [* Reference] voltages.
- I've added an expanded draft of touchstone vs. IBIS-ISS.
- Touchstone files in general leave the circuit topology ambiguous.
- If you assume an n+1 reference node, the topology becomes more fixed.
- IBIS-ISS you nail down the topology with the available nodes right away.
- We've tentatively planned our next meeting for Wednesday afternoon.
Relaxation of IBIS filename restrictions:
- Walter: [sharing Section 3, item 3., which defines filename requirements]
- Primary items: lower case, 40 character max, 3 character extensions.
- This was quite good 20 years ago, and it made sense because it made it
simpler to move amongst UNIX/Windows/DOS.
- I'd like to extend these now.
- Why not have more than 40 characters?
- Why limit ourselves to lower case?
- Why limit ourselves to 3 character extensions?
- For example, if I had an xyz.s10p S parameter filename, that's a four
character extension.
- Arpad: That's a good point.
- In IBIS-ISS we allow touchstone filenames, do these rules apply to IBIS-ISS
touchstone filenames as well?
- Walter: I'm not sure.
- Bob: We haven't changed the rules, and it's ambiguously stated, but they are
technically limited to the IBIS defined file types themselves (.ami,
.ebd, .ibs, .pkg). We actually define those 3 character extensions.
- Walter: It says [in Section 3, item 3.], "file names used in a .ibs file".
- So we have .iss files, touchstone files, etc.
- Bob: I think it's ambiguous.
- Walter: I just think we should consider relaxing these requirements.
- Moving further, should we allow filenames like "base/file.xyz"?
- In the future we may have a large number of files that go along with a
.ibs file, or go along with a .pkg or interconnect model set.
- It would be nice to put them all in a directory. For example, one sub-
directory to hold all the S parameter models called by an interconnect
model set, etc.
- I think we should consider allowing relative paths.
- Bob: I understand and agree that we could do something like this with a BIRD.
- But there's a difference between what we say in the spec and what an EDA
vendor might do moving the files around.
- The issue is, if the EDA tool uses the official parser, can we even check
the set of files if they get moved around to different locations?
- Mike L.: That's irrelevant.
- We only need to specify how the files are delivered by the model maker.
- The parser only needs to parse things based on the IBIS rules we describe.
After delivery, it's not the parser's problem. If the EDA tool rearranges
things after that, it's up to the EDA tool to get it right.
- Walter: Today all the files have to be in the same directory.
- I think it would be a major improvement to allow files to be in
subdirectories.
- If an EDA tool wants to move all the files off into some different
structure, then they may need to modify the official parser.
- Or we could change the official parser and let it go off and find any files
it needs in the subdirectories of the one containing the .ibs file.
- Arpad: Subdirectories make sense in some cases.
- But in other cases the parent directory might also make sense, for example,
if you want to have a bunch of common files that are used by many different
models or different versions of the same model.
- Walter: That would be fine.
- If the IBIS file calls out a certain location for something, say a
.dll in a subdirectory, then if the tool moves that .dll somewhere it
could potentially modify the .ibs file if it wanted to keep the parser
happy.
- I would just like people to think about it and see if you can think of
anything bad that would happen if we allow an IBIS file to be delivered with
its support files in subdirectories of the IBIS file.
- Arpad: That's not a bad idea for organization.
- If we say that all these rules matter only for initial delivery purposes,
and the tool can then do whatever it wants, then is this that big a deal?
- Walter: I don't think it's that big a deal.
- What could happen is if the tool moves things around it could break other
dependencies, but as long as it knows what to move around it should be okay.
- Mike L: We have that pretty well covered.
- How and what to move around is pretty well covered by the AMI Reserved
parameter Supporting_Files.
- Walter: Okay, think about this idea of allowing subdirectories. It may not
be as general as everyone might like, but can anyone think of any
bad things that would happen?
- Bob: That's a good suggestion, and we could vet it through the BIRD process.
- This is where I brought up the expanded character set earlier. We currently
don't allow "/", for example, which would be the directory separator in some
operating systems. We could deal with that in the BIRD, too.
- What about the case sensitivity? I understand it for Linux, but it could
create a filename collision for Windows, which doesn't recognize case
differences in file names.
- Mike L.: But having that provision in IBIS amounts to what a lawyer would call
prior restraint.
- If a model maker is making any files that will ever land on a Windows system
then they know they would run into this problem.
- That's a standing issue with Windows.
- I don't think IBIS needed to take it upon itself to protect people from
themselves.
- Bob: The parser only checks the [File Name] keyword for lower case only.
- The actual file could differ by having some upper case letters and the
parser would not complain about that.
- Arpad: I personally like to use capitalization to indicate word boundaries
instead of underscore or something like that.
- So I would like to have capital letters, even though I'm not using them
to represent unique filenames vs. lowercase.
- Walter: Also, would we like to have a filename like this: xyz.def.jklm ?
- "." is not in our current character set, but I think this filename should
be valid.
- Walter: I don't think anyone here objects to the idea.
- I would like to take a cut at rewriting this paragraph.
- If we can then come to agreement on it, then we can draft a BIRD.
- Ambrish: What's the rationale for having the [File Name] keyword inside the
IBIS file that has to match the actual file name?
- Arpad: It was just for sanity checking.
- Mike L.: It actually comes out of the early days of email.
- In the days before email attachments were common, the entire IBIS file was
in the contents of the email. The [File Name] field gave you the actual
name of the file.
- Walter: We could make it optional in some future release.
- Bob: Or we could add a similar keyword for AMI files.
- Ambrish: I'd like to just get rid of it.
- Bob: It doesn't hurt anything.
- Ambrish: It does, if I change the name of a file without adjusting that
[File Name] then the parser complains.
- Arpad: In a case where one IBIS file refers to another, then if someone
changes a file name the parser might not be able to find it. I guess
then this keyword might be useful for finding out the real file name?
- Walter: I sense everyone here is okay with improving this to make file names
more readable and more general.
- I will take a cut at rewriting this section.
- Radek: Good. If we consider an extension to allow "/" to be used for
subdirectories then we can discuss that, too.
- Ambrish: Motion to adjourn.
- Radek: Second.
- Arpad: Thank you all for joining.
AR: Walter to draft an updated version of IBIS file name rules.
-------------
Next meeting: 25 October 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
