Minutes from the 20 September ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
posted to the IBISCHK BUGs page.
ID#TitleRequesterDate
SubmittedSeverityPriorityStatusDate
Closed
183 IBIS-AMI Error Message Contradiction with (Usage Out)
<http://ibis.org/bugs/ibischk/bug183.txt> Michael Mirmak, Intel Corp.
September
20, 2016 [ANNOYING] [LOW] OPEN
IBIS Macromodel Task Group
Meeting date: 20 September 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
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:
- Arpad noted some modifications to the Pending BIRDs section of the weekly
agenda, including:
- Added the new BIRD 185.
- Changed the BIRD 184 entry to 184.1
-------------
Review of ARs:
- Bob Ross to post the BIRD draft discussed last week with the modifications
discussed.
- Done (BIRD 185).
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Dan: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
IBIS Interconnect SPICE Wish List: Simulator directives:
- Arpad: This item is listed at the bottom of each week's minutes. A week ago I
remembered what this item is all about.
- I remembered when I was working on an IBIS ISS subcircuit and I wanted to be
able to put in a .connect statement to connect two nodes together. But,
that is a simulator directive. It's not in the IBIS ISS spec because it's
not an element.
- I mention it here so we can consider it in the future.
- Mike L.: We could accomplish the same thing with a 0 Ohm resistor.
- The EDA tool could implement support for a 0 Ohm resistor however it wants.
- Radek: We typically use a 0V DC source for that same purpose, not a resistor.
- Adding simulation directives and getting them handled uniformly is tricky.
- We stayed away from them entirely.
- Walter: I'm fine with keeping this as a wish list item.
- I agree with Mike and Radek, but we could talk about this in IBIS ISS
discussions in the future.
Bob Ross and Radek's discussion of Editorial Task Group Issues:
- Bob: We have met twice so far.
- We have not come to firm conclusions about everything.
- We discussed most of Radek's presentation from the August 2, 2016 meeting.
- We continue to discuss that presentation and some possible revisions to it.
- We have arrived at some opinions or recommendations. People might not agree
with all of them, but they will be our recommendations.
- We prefer the phrase "simulation model" over DIA (device in action).
- We are planning to set aside the part of the discussion involving receiver
thresholds.
- Any rail can be a reference, and it need not have [* Reference] value 0.0.
- We want to insert something to the effect, "If any rails defined by
[* Reference] keywords have identical voltage values in all three corners
then they can be considered one rail."
- [Pin Reference] instead of [DUT Ref Terminal]? We haven't really begun that
discussion yet.
- We don't believe the ext_ref terminal itself should be a measurement
reference rail. That was never its intended purpose.
- We haven't gotten closure on C_comp issues. Radek is considering updates to
his presentation.
- We are going through all the emails submitted to any or all of the three
task groups (ATM, Interconnect, Editorial) related to discussing GND or
proposals for an addition to IBIS Section 3. They are all interacting.
- We plan to meet next Thursday for continued discussion.
- Radek: That is a good summary.
- Arpad: When do you expect closure?
- Is this holding up other things?
- Bob: Whenever we come to agreement. There is no "deadline."
- It's holding some things up, but in my opinion IBIS can survive without
[Pin Reference].
- Even if and when it's added it would definitely be optional. That's a
requirement for me.
- Walter: The hard part is the details, but I'm fine with everything Bob said.
- The only thing it's potentially holding up is the editorial rewrite.
- Most of the editorial issues are at least a month away from being ready, so
this isn't really holding anything up at this point.
C_comp Improvements:
- Randy: Nothing new to show this week.
- Walter: Randy and I probably need to talk more offline.
- One of the things making this BIRD complicated was dealing with I/Os.
- I think the practical application of this C_comp circuitry really applies
to DQ, which is the highest speed parallel link in the industry (3Gbps and
above).
- In most of the latest DDR IBIS files I've been seeing they always use a
[Model Selector] and just have different models for driving or receiving
mode. Even though some of those [Model]s may be I/O for some reason, any
one particular model is only used in one direction.
- Maybe there's a simplification here where you don't have to deal with some
of the subtleties of something being an I/O buffer.
- Randy: That's a good point.
- We probably want to clarify somehow that models are inputs or outputs
because we want different models for different directions.
- Walter: One of the issues I found trying to implement the new BIRD for
[Algorithmic Model] Executable_Tx and Executable_Rx is that it's hard
to find a model that's actually used for both directions.
- Bob: I understand your point, and that's one approach.
- I'd still prefer a modal solution like we have for [Add Submodel].
- If it's an I/O we really have to deal with both.
- Arpad: We have no new updates on the Redriver Flow topic.
- That brings us to the end of the agenda. Anything else to discuss?
- Michael M: I filed a new ibischk BUG last week.
- It addresses the concept of Usage Out and Value, and whether that
combination is useful as the spec is written today.
- There is some commentary in that BUG report that talks about modifying the
specification, particularly how we talk about Usage Out, so we might want to
discuss it here.
- Arpad: Can you describe the BUG?
- Bob Ross: [Sharing the BUG draft (now posted as BUG 183)]
- These rules exist in the IBIS spec:
- Format Value (or Value) and Default are mutually exclusive
- Default shall not be used with Usage Out
- Format Value (or Value) may be ignored by the EDA tool for Usage Out
- [See BUG 183 for a full description of the issue]
- Discussion: The example .ibs file causes a misleading error message to be
displayed. An Output parameter is defined with no value, and results in an
error message stating that a Value or Default should be specified. However,
since the parameter is an Output a Default is actually illegal. Michael
questioned whether the spec. should be clarified in this area and asked if
having a Value really means anything for an Output parameter. He noted that
Format might be useful for allocation purposes, but a single value was
likely of no use. He noted that in trying to think of what Format might be
meaningful for an Output parameter, he could only come up with Range as one
possibility. Radek noted that this particular bug (the misleading message)
was really a question of granularity of the error messages. He noted that
we have a bit of a mix in this case because the message intervenes for missing
Default and Output instead of just for missing Value and Output. He suggested
we could change the spec so both Value and Default were ignored for Output.
He said he was concerned that cross referencing of various fields would add
combinations and complexity. Bob said that he agreed with Radek and preferred
to keep it simple. He noted that we had sometimes avoided cross referencing
for other parameters by requiring fields where the content of the field was
meaningless but it was used as placeholders. Michael noted that he would
be happy with just making an editorial clarification BIRD. He said the only
thing he'd want to specify is whether having a Range might provide useful
information to the EDA tool. Otherwise, for an Output parameter, nothing else
is really useful. Mike LaBonte noted that Range information for an Output
could in fact be useful. For example, the Range specification might allow
the
tool to know the full scale for a plot ahead of time. Michael agreed to work
on drafting a clarification BIRD.
- Mike L.: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Michael Mirmak to draft an AMI Output parameter clarification BIRD.
-------------
Next meeting: 27 September 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
