Minutes from the 02 April ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 02 April 2019
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC: David Banas
GlobalFoundries: Steve Parker
IBM Luis Armenta
Trevor Timpane
Intel: * Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
* Ming Yan
Stephen Slater
Maziar Farahmand
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft (Mathworks): * Walter Katz
* Mike LaBonte
SPISim: * Wei-hsing Huang
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Walter to send out the modified draft response for further review by those in
attendance.
- Done (to be reviewed in this meeting).
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the March 26
meeting. Bob moved to approve the minutes. Mike L. seconded the motion.
There were no objections.
-------------
New Discussion:
Draft response to the authors of BIRD198:
Mike L. shared the modified draft response email. Arpad, Bob and Mike L. noted
that some of the simplifications and deletions discussed in the previous meeting
meeting were not reflected in the email. Bob noted that many of the issues he
raised in his response would have been addressed already by the previous
meeting's changes. Mike L. and Bob took the AR to go over the previous week's
minutes and fully revise the original draft according to those discussions.
Arpad suggested we wait until the next meeting to continue discussions. There
were no objections.
Arpad noted that we had no new updates on the remaining agenda items: Enhanced
C_comp and DDR5 issues.
Michael M. asked to discuss an issue he had raised in an email "Technical
questions on BIRD197.2" sent to ATM on March 27, 2019.
Question about DC_Offset:
Michael noted that he had gotten some feedback from model makers on BIRD197.2.
He said there was some confusion about the fact that DC_Offset was a parameter
of Usage In, but the value provided in the .ami file is a throw-away place-
holder and the value comes from the tool not the user. He asked if we should
add a diagram or additional explanation.
Arpad said he thought the confusion might stem from that fact that we have so
many possible directions for AMI parameters. Some parameters are provided for
the tool (Info), some go into the model (In), some come back from the model
(Out), and there is also information passed around between the tool and the AMI
DLL through the AMI function arguments. The sticky point might be that we
didn't define a crisp way of conveying the direction information.
Radek noted that the issue is related to the function signatures in the model
(.dll). If a model doesn't have the AMI_Resolve() function, then everything has
to go through the AMI parameters, Reserved or Model Specific. He noted that we
already have some Reserved parameters that are placeholders in the AMI file.
Arpad noted that DLL_Path is analogous. Mike L. agreed and noted that the tool,
not the user, typically provides the value for DLL_Path as is the case for
DC_Offset. Mike L. noted DLL_ID as well. So, the concepts applied to DC_Offset
are not new. Mike L. noted that we have some AMI parameters for which the
values
are provided by the user and some for which the value comes from the tool.
Michael asked if we could add an editorial clarification (diagram, table, etc.)
that captured what Mike L. had said.
Arpad asked if there was anything in the Definition:, Usage Rules:, etc., for
DC_Offset that left it unclear? Michael M. noted that it can be tough to expect
model makers to review the entire spec. Arpad asked if adding any editorial
clarification would help. If we add a new table, are people going to read it?
Michael M. agreed to work on drafting a BIRD to propose the type of
clarification
he felt would be helpful. He noted that it would not happen quickly.
Parsing IBIS-ISS files:
Mike L. brought up an issue from the Quality Task Group. He noted that there
have been occasional discussions in the past about whether we should develop an
official parser for the IBIS-ISS. Typical questions are:
- Would it be a separate program or part of ibischk?
- Would it parse such that it created structs in memory and could be used as a
front end (for source code purchasers)?
- Would it check for connectivity and other issues or just basic syntax?
Mike noted that the Quality Task Group largely consists of Mike, Bob and Lance.
Therefore, it doesn't have a representative set of opinions.
Arpad asked how important an issue this was and noted that every tool has some
sort of SPICE engine. So, the model maker would not be left without any
information about any problems in the IBIS-ISS model. Randy asked if, for a
given tool, you can be sure you're really checking for what's allowed in IBIS-
ISS, or are you accepting a broader set of functionality? Arpad agreed that
most
tools would allow a superset of IBIS-ISS capabilities.
Michael M. noted a strong belief that we need a generic IBIS-ISS parser. He
noted that:
- We can't assume everyone has access to a compatible tool.
- Not all tools are equal and would include the same features.
- The value of the IBIS parser is that it's the official arbiter of what is
valid.
- It provides a single standard reference.
- We want to allow model makers to be sure they've produced a minimally
compliant model.
Randy noted that Justin had produced some examples of IBIS 7.0 compliant models
using different interconnect models aligned with BIRD197. However, they really
have no idea whether their IBIS-ISS files are compliant. From their perspective
a parser would be very helpful.
Mike L. noted that making sure the IBIS-ISS file only contained the proper
subset
of SPICE components would be the primary value of a parser. Mike also noted
that
we now have Touchstone files used in IBIS. We have a separate tschk2 for
checking those files, but it's a separate program and ibischk does not
automatically check Touchstone files. He felt that ideally ibischk would check
as much as possible. Arpad noted that checking Touchstone files would be nice,
but since they can become huge it could be a performance bottleneck. We would
probably want a command line option to enable or disable checking Touchstone
files.
Arpad asked if Bob would discuss an IBIS-ISS parser with the ibischk parser
developer. Bob said Michael M. or someone who wants the parser would have to
provide some sort of spec. Arpad asked if the IBIS-ISS spec itself isn't the
parser spec.? Bob said you need to define what you want that parser to do.
Walter said it's a question of syntax checking vs. context checking. A basic
syntax check could look at element by element syntax. Context checking would
be at another level and might include, floating nodes, proper subcircuit node
count, illegal values, etc. Arpad said that if the purpose is to ensure
the model stays within the IBIS-ISS subset, then basic syntax checking should be
enough. It doesn't guarantee a functional model, but would it be enough to
start
with syntax checking and evolve over time if necessary? Randy noted that
ibischk
itself evolved that way.
Mike L. noted that ibischk source code purchasers just about fund the cost of
the
parser development. However, he noted that an IBIS-ISS check would involve
separate cost and the overhead of separate contracts, regression tests, etc. He
noted that he expected the number of purchasers of the IBIS-ISS parser source
code would be small, and he doubted source code sales would fund its
development. He noted one way to fund it might be to increase the cost of the
ibischk source code.
Arpad noted that we could continue this discussion next week. Michael M. noted
that this was a bin list topic for Interconnect, but that it could be taken up
in ATM instead. Mike L. said the discussion had been helpful.
- Mike L.: Motion to adjourn.
- Radek: Second.
- Arpad: Thank you all for joining.
AR: Mike L. and Bob to produce a revised draft response to the BIRD198 authors.
-------------
Next meeting: 09 April 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
