Minutes from the 06 August 2019 IBIS ATM meeting are attached.
IBIS Macromodel Task Group
Meeting date: 06 August 2019
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: Ambrish Varma
Ken Willis
Intel: Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
Ming Yan
Stephen Slater
Maziar Farahmand
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft (Mathworks): * Walter Katz
* Mike LaBonte
SPISim: Wei-hsing Huang
Teraspeed Labs: * Bob Ross
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the July 30
meeting. Walter moved to approve the minutes. Bob seconded the motion.
There were no objections.
-------------
New Discussion:
Jitter HF/LF components:
Michael Mirmak noted that the internal experts he would consult with for follow
up responses to the questions from the previous meeting had not been available
this week. He noted that he expects to have more information in the upcoming
weeks.
Other DDR5 topics: (Item #7 on the agenda)
Arpad asked Randy and Michael M. if they had any new information to report for
their AR to gather device manufacture input on these topics. Randy and Michael
M. had nothing new to discuss. Walter moved that all of item #7 be added to the
Tabled ARs: section, and he noted that we can untable it whenever we get new
information. Michael M. seconded. No one opposed. (Note: The Tabled ARs:
section already contained several distinct items for clock forwarding and
DC_Offset).
IBIS-ISS Parser discussion:
Walter reviewed the "ISS Parser" email he had originally drafted for the IBIS
Interconnect task group and had sent to ATM a few hours before the meeting. In
it he broadly defined 4 levels of IBIS-ISS parsing we could consider. He noted
up front that he thought we should only provide the simplest (Level 1) and
could document that we don't provide the other three.
Level 1 - Simply evaluate the syntax legality of each line independent of the
rest of the circuit. This involves checking each line (including the +
continuation characters) independently. The line is tokenized and checked to
ensure it starts with a legal instance type (X, R, C, L, G, etc.), comment, or
other valid token (.subckt, .include, .ends, etc.) from IBIS-ISS. Depending on
the instance type, the parser would know which tokens are nodes, etc.
Bob noted agreement but said that .param was a valid token missing from the
list in the email. Walter agreed and noted that the email did not provide an
exhaustive list but provided the broad framework.
Level 2 - The parser could check any subcircuit hierarchy, and within the scope
of .subckt/.ends it could generate a list of node names and frequency of
occurrence. It could then report any nodes (other than global reference node)
that appear only once. Walter noted that this level was an order of magnitude
more difficult than Level 1.
Level 3 - The parser could check to ensure that any filenames, subckt names, or
model names that are referenced actually exist or are defined. (Note: Walter
noted an error in his email. "Flatten all .include statements" was listed as
an item in Level 3. In fact, this flattening should happen in Level 1 prior to
the line-by-line syntax check.)
Level 4 - The parser verifies full .subckt and model scoping rules.
Walter reiterated that he thought we only need to provide Level 1. That would
be sufficient to ensure that no subcircuit is using elements that aren't legal
in IBIS-ISS. Additional checks provided by Levels 2 through 4 are nice, but
we can expect whatever SPICE simulator an EDA tool or user relies on to catch
those types of errors.
Michael M. asked Walter what "level" he considered the ibischk parser. Walter
said he would consider that at least a 4, but probably a 5 since ibischk will
even check the I/V tables and waveforms in an IBIS Model for consistency. Mike
L. noted that he agreed with Walter that Level 1 was a cost effective solution
for IBIS-ISS parsing. He noted that if you were writing a Yacc grammar to do
the parsing you could do a Level 1 parser and only write the base syntax, and it
could check the file line-by-line without even storing anything beyond the line
currently being processed. This would be low cost and provide all we need to
flag the use of any non-IBIS-ISS constructs.
Michael M. asked if checking for the presence (use) of reference nodes would
have to be done at Level 2. Walter said no, it could be done at Level 1 and is
shown in Level 1 in the email. Radek agreed that it could be done in level 1,
and he noted that it's important to check for any use of the reference node.
Bob noted that detecting use of Node 0 is okay, but it's not illegal to include
Node 0, so it shouldn't be flagged as an error.
The group discussed how an IBIS-ISS parser might be "integrated" with ibischk.
Mike L. noted that IBIS Quality task group had been considering the introduction
of two new command line options used to specify the IBIS-ISS and tschk parser
executables. The consensus was that this was a reasonable approach. Arpad
noted that it kept the ibischk, IBIS-ISS, and tschk parsers separate so they
could be updated and released independently. Mike L. noted that he had
originally envisioned a basic IBIS-ISS parser/checker embedded into ibischk, but
since the existing tschk was already a stand-alone executable it made sense to
handle the IBIS-ISS parser in a similar manner.
Walter noted that the stand-alone tschk provides a syntax check, but it does not
report on passivity, causality, etc. He suggested we might want to talk to
someone on the IEEE P370 committee, which has done a lot of work with
S-parameter metrics. They might have some checking routines we could include,
and it would be helpful to the industry in general. Michael M. asked if that
suggestion aligned with the results of the IBIS Touchstone Survey. Mike L.
noted that the survey had asked questions about quality, and that one respondent
had even mentioned IEEE P370.
Bob noted that passivity is not a requirement and some Touchstone files used
within IBIS could be active. Walter agreed that Touchstone files for on-die
S-parameters (AMI - BIRD158) could be active, but he noted that for passive
interconnect, packaging, etc. they should be passive. Walter noted that the
parser could figure out from context whether a Touchstone file should be
passive.
Radek noted that some very useful checking that went beyond Level 1 would
involve checking for the proper number of nodes in a subcircuit and ports
in a Touchstone file. For example, we would want tschk to return the number
of ports in the Touchstone file so it could be checked relative to the number
of terminals in the including subcircuit. Walter agreed with Radek, but noted
that whatever SPICE simulator was being used at simulation time could be
expected to find and report those types of errors. The only thing we couldn't
expect a general SPICE simulator to catch was whether the IBIS-ISS model used a
device type outside the subset of SPICE device types included in IBIS-ISS.
Bob noted that he had heard in the past that users really wanted a full (Level
4)
IBIS-ISS parser. Walter roughly estimated that a basic Level 1 tokenizer and
checker was on the order of weeks or a month to develop. He said anything for
Level 2 or beyond was likely many months. Bob noted that the ibischk developer
had once proposed developing a Level 4 IBIS-ISS parser by starting with the
open source Berkley SPICE code. Walter proposed a straw poll on the choices.
Arpad asked if we had concluded we wanted an IBIS-ISS parser at all. Mike L.
suggested voting on whether Level 1 and Level 4 were worth considering. He
noted that the differences in effort between 2, 3 and 4 weren't that important
relative to the big jump from Level 1 to Level 2.
Walter moved for an acclamation vote on whether ATM thought it was worthwhile to
provide a Level 1 IBIS-ISS parser. Bob seconded. There were no objections, so
it was unanimous that we should consider having a Level 1 parser developed.
Bob moved for a roll call vote on whether it was worthwhile to provide a Level 4
IBIS-ISS parser. Walter seconded. The vote was:
ANSYS - No
Intel - Yes
Keysight - Abstain
Mentor - Yes
Micron - Yes
SiSoft - No
Teraspeed Labs - Yes
Yes (4), No (2), Abstain (1).
Since a majority voted in favor, we plan to ask the ibischk developer for a
quote on a Level 4 IBIS-ISS parser.
Walter said the conclusion from the two votes was that we should get quotes for
Level 1 and Level 4 IBIS-ISS parsers. Arpad asked how this information should
be reported to the Open Forum. Walter and Randy said Arpad could simply mention
it in the ATM task group update at the Open Forum meeting. Curtis noted that
the IBIS Quality task group (Bob in particular) usually interacts with the
ibischk parser developer. Bob noted that we would start with informal quotes
from the parser developer on Level 1 and Level 4 IBIS-ISS parsers, and that he
would wait until ibischk 7.0 was complete before asking for the IBIS-ISS quotes
at all.
- Michael M.: Motion to adjourn.
- Mike L.: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 13 August 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
