Minutes from the 09 April ibis-atm meeting are attached.
The following documents were discussed during the meeting and can be found at
the ibis.org website:
ibischk bug 203<http://ibis.org/bugs/ibischk/>
BIRD197.2<http://ibis.org/birds/>
IBIS Macromodel Task Group
Meeting date: 09 April 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:
- Bob noted that list of attendee names was due for periodic maintenance and
removal of those who had not participated recently. Randy noted that it's
typical to remove the names of people who have not actively participated in
over a year. Curtis took the AR to cull the list and have Bob review the
changes. (done - reflected in the Members list above).
- Arpad noted that a vote on the DC_Offset BIRD (BIRD197) had been postponed at
the last Open Forum meeting. The Open Forum recommended that ATM review it in
light of some feedback including grammatical changes. Arpad noted that he had
forgotten to add it to the agenda email, but we could discuss it.
-------------
Review of ARs:
- Mike L. and Bob to produce a revised draft response to the BIRD198 authors.
- In progress. Arpad noted that the reason for this AR was that no update had
been sent that fully reflected the comments and suggestions from the March
26th meeting.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the April 02
meeting. Mike L. moved to approve the minutes. Radek seconded the motion.
There were no objections.
-------------
New Discussion:
BIRD197.2 (DC_Offset)
Arpad shared BIRD197.2 and noted several grammatical changes he and others had
reported. He reviewed corrections with the group and made the changes in a
new draft:
- 4 instances of "singled ended" ---> "single ended". (Arpad)
- 1 instance of "single-ended" ---> "single ended" for consistency. (Randy)
- In the Definition of the Issue: section,
"The forces all AMI..." ---> "This forces all AMI..." (Arpad)
Bob noted that he thought there had also been technical comments. Radek noted
that Michael M. had also mentioned that "step response" was used for the first
time in the following sentence and not defined in the spec.:
"If the impulse response was generated by differentiating the step response..."
But Radek noted that he thought the sentence was okay. Arpad said he had
responded to Michael's original email because he hadn't understood Michael's
comment. Michael's comment had asked about step response being a legal input
to the AMI model now, but this particular sentence did not imply that. Curtis
said he thought the people from whom Michael had gathered feedback may have
been confused and thought the model was now going to generate the IR from the
step response. The group agreed that no change was required for this sentence
at this time.
Ambrish asked to confirm that "shall" means "must" in the following sentence:
"The waveform output of the Rx AMI_GetWave shall be adjusted so that the EDA
tool can add DC_Offset..."
Arpad and the group agreed it does (it does in IBIS in general).
Radek objected to the use of "single ended voltage..." and said voltage is
voltage. Randy suggested we discuss improvements to the language now so as not
to further delay the BIRD. Arpad said the section in question is attempting to
define DC_Offset. Radek said DC_Offset is an offset to move the waveform from a
single ended port to something that can be handled with differential
infrastructure.
Radek proposed that the following sentence in the Definition of the Issue:
"This forces all AMI simulations to be centered around the mid-level of the
single ended signal."
be changed to:
"This forces all AMI simulations to be centered around the mid-level of the
signal of a single ended port."
Similar changes were made in several locations.
Bob noted that we should add an entry to the Background Information section
stating the reason for creating BIRD197.3. Arpad did.
Arpad took the AR to send this draft_1 of BIRD197.3 to the ATM list for further
review.
C_comp related ibischk bug #203:
Bob shared the bug report for bug #203 and noted that the parser does not
complain if C_comp_pullup or C_comp_pulldown are specified for an Input model.
He noted that it was being considered as an enhancement to add a warning, or
caution or note.
Arpad noted that there had also been discussion of a possible technical issue
to address in the spec. Bob said the broader technical issue is that the spec
allows any of the C_comp_pullup, C_comp_pulldown, C_comp_power_clamp and
C_comp_gnd_clamp to be specified for an Input model. He noted that the spec
also contains this sentence:
"For this reason, the EDA tool should generate a circuit netlist so that, if
defined, each of the C_comp_* capacitors are connected in parallel with their
corresponding I-V tables, whether or not the I-V table exists."
Bob said the discussion can turn to "which rail does it connect to." Arpad
asked why any of this was a problem.
Walter posed a question to try to clarify the discussion. If one has an Input
model with Power Clamp and Ground Clamp I/V tables and only [Voltage Range]
specified, and all 4 C_comp_xxx values are specified as 1pF, how much
capacitance should be in the simulation? Should the simulation have 1pF between
signal and gnd, and 1pF between signal and the positive rail, or should it have
2pF between signal and gnd, and 2pF between signal and the positive rail?
Bob said you should have a total of 4pF, 2pF between signal and gnd and 2pF
between signal and the positive rail.
Arpad noted the example of an FPGA, for which the user could configure a
standard I/O cell into an Input. They would tie-off the pullup and pulldown
transistors so they don't drive the circuit, but the devices are still there and
you would still want to consider their capacitances. So, he saw no issue with
providing all 4 C_comp_xxx values even though the buffer is an Input. He noted
there could be an issue figuring out where to connect them if only [Voltage
Range] were specified.
Arpad posed another question. In the context of BIRD189 we have the buffer
terminals defined in the syntax. What if the BIRD189 package model used all
four rail terminal names (Pullup_reference, etc.), but the [Model] for that
buffer only has [Voltage Range], what do you do then? Bob said you collapse
them into the same node (pullup and power clamp terminals are the same, and
pulldown and ground clamp terminals are the same). He said the way [Voltage
Range] is intended to work is that it defines the value if any or all of the 4
*_reference keywords are missing. He noted that in practice terminal
connections to real buffers rarely have separate terminals for pullup and
power clamp (or pulldown and ground clamp).
Walter noted that his interpretation was that an Input doesn't have 4 terminals,
so he still didn't know how to connect capacitances in his example. He said he
thought C_comp_pullup or C_comp_pulldown on an Input should generate a parser
warning stating that those capacitances would be ignored. Arpad disagreed and
referred to his FPGA example. Walter then said we need to clarify the spec
because it's unclear.
Radek suggested it would be better to clearly state that C_comp_pullup and
C_comp_pulldown are considered even for an Input model. Otherwise he said we
could get into trouble with I/O buffers depending on their state. Bob agreed
and said that we never intended for an I/O buffer to ever switch off any of the
C_comp_xxx paths. So, we expect them there regardless of the state of the
buffer.
Arpad asked what the immediate need is with respect to bug #203. Bob said the
immediate goal was to classify the bug and decide if it requires a warning, or
a caution, or a note. Walter said that if the interpretation is that they are
always being used, then there shouldn't be any warning/caution/note at all. Bob
said that we needed to clarify this in the spec and mention that all 4
C_comp_xxx values are always considered. Walter said that would be fine, and
then this bug would be resolved as "no plans to fix." Arpad noted that he felt
#203 was not a bug at all. Even with the current language in the spec there's
nothing that says it's illegal to have C_comp_pullup or C_comp_pulldown in an
Input model.
- Walter: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Arpad to send draft_1 of BIRD197.3 to the ATM list.
-------------
Next meeting: 16 April 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
