Minutes from the 25 September ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 25 September 2018
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
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft: * 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:
- Note: The meeting scheduled for October 2 will not be held. People are
encouraged to use the hour to review the latest draft of v7.0 from the
Editorial task group. (see below)
- Walter noted that BIRD 195.1 had been approved by the IBIS Open Forum, so
Arpad removed it from the "Pending BIRDs awaiting discussion:" item in the
ATM agenda email.
-------------
Review of ARs:
- Walter to send a follow up email containing the discussed revisions to the
file name conventions.
- Done.
- Randy to investigate if/why/how a clock waveform input might be used.
- In progress.
- Michael M. to investigate if/why/how a clock waveform input might be used.
- In progress.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the September 18
meeting. Walter moved to approve the minutes. Michael M. seconded the motion.
There were no objections.
-------------
New Discussion:
BIRD196:
Arpad shared his BIRD196_draft_3.docx. He noted that the BIRD's only change was
to state that a filename cannot end in a period ("."). There were three
locations in 6.1 that stated that a file ending in a period was allowed. These
three statements were removed. In addition, a fourth location that did not
exist in 6.1 also received the same clarifying text. File names with only a
stem are permitted. Arpad noted that a BIRD was created to formally document
this change because it is not strictly editorial.
Walter noted that in Windows native tools you can't create a file name ending in
a period anyway, so this was a slam dunk. Bob agreed and noted that this BIRD
would close a loophole for the parser development. Bob noted that the BIRD was
written utilizing the terminology of BIRD186.4, and that the fourth location
Arpad referred to was within text added by BIRD186.4. Bob noted that the
Editorial task group could sort that out.
Walter moved to submit the BIRD to the Open Forum as BIRD196. Arpad noted that
he would "accept all changes" in the current draft and submit it. Radek
seconded. Arpad noted that at the previous Open Forum meeting they had already
scheduled this BIRD for a vote at the next meeting, with the expectation that
it would be submitted right after this ATM meeting. Mike L. noted that he would
post the BIRD and send the email notification of the vote scheduled for the Open
Forum meeting on October 12.
Vref and DDR5 improvements:
Walter shared the most recent "Summary of DDR5 issues" email. Walter noted that
the email captured the general theme of the discussions. He noted a general
agreement that we need some way to get a DC offset into Init() (an alternative
would be to provide a step response instead of an IR) and to get DC offset info
into GetWave(). He noted one issue might be whether we need a VrefDQ parameter,
or if this could be handled by model specific methods. Walter noted that he
thought the real remaining issue was clock ticks, and he suggested we wait until
model makers made recommendations on how they would utilize clock tick
information and preferred to see it implemented in the spec.
Ambrish noted previous meetings' discussions of clock_ticks and the concepts of
passing in clock_ticks or building an internal CDR into the AMI model. Ambrish
said his team had discussed it internally, and they were going to recommend a
first phase utilizing an internal CDR and properly configured jitter
impairments. He noted that this would be enough for an accurate first pass, and
it would not require a change to the AMI flow or any new parameters. Walter
noted his agreement, and suggested we could table the discussion until model
makers provide more information on what they think they need.
Ambrish said that left us with just one change, the proposed DC_Offset
parameter, to allow us to start using AMI for DDR models. Ken noted that with
the DC_Offset we could start using DDR models right away. We could add
additional details, external strobing, etc., later if it became necessary.
Walter summarized the position: If we have DC_Offset, then we still give the
AMI Init() an IR, and we give the Rx GetWave() a differential waveform. The
Rx GetWave() has the DC_Offset, so it knows how to convert the differential
waveform to single ended if it needs to. Those assumptions have been built
into models that Walter/Ambrish/Ken have produced. Ambrish agreed.
Fangyi noted they had at least one customer who would not agree with those
assumptions. Ken noted that Cadence controller IP folks and Micron DDR folks
had met to discuss the topic and felt that differential waveforms were
sufficient. Randy agreed that the assumptions seem to be working for their
models so far. Fangyi said that physically the actual waveform is single-
ended. Ambrish noted that AMI Init() (statistical simulation) capabilities,
for example, were not entirely physical either. Ken noted that there were
physical hardware implementations that process differential waveforms. Fangyi
noted that at the input to the device the waveform is single-ended. What's
happening inside the device is what's inside the model. Walter said that we
are assuming the AMI model is active at the output of the Gain Adjustment
Amplifier in the Rx. We take the DQ signal and subtract the DC_Offset (not
exactly VrefDQ, but it should be close) and that's the signal we pass into the
model. We could instead pass in a single-ended signal, but then we'd still have
to pass in VrefDQ to convert it to differential, so why do we need to do that?
If we're concerned about saturation effects at the summer, we have the DC_Offset
and can figure that out.
Walter said anyone could write a BIRD if they felt more was needed. Arpad asked
Walter and Ambrish if they were ready to go ahead with a BIRD. Walter said he
would write the DC_Offset BIRD, review it with Ambrish, then submit it to the
ATM for review. Walter/Ambrish confirmed the BIRD would be confined to
DC_Offset. Walter noted that he would include the usual background info and
would define the DC_Offset as the voltage mid-point of the step response.
Review of Topics:
Randy noted no new need for discussion of the advanced C_comp topic.
Arpad noted that we had no more immediate agenda items. Michael M. asked to
review the tabled topics list. Arpad then asked if anyone felt the need to
address the redriver flow issues that had been tabled. Walter noted that Fangyi
had proposed adding additional IR outputs to the Tx and Rx AMI Init() functions.
Having the Tx Init() output its equalization as an IR, and having the Rx output
its linear equalization and its DFE equalization as two separate IRs in addition
to the existing IR output would be useful. We should pursue it. Walter noted
that his only issue with Fangyi's original proposal was that it was limited to
the Rx. In later discussions, Fangyi had agreed that having the Tx output its
equalization as an IR would also be useful.
Fangyi noted we now have the issue of the Tx equalization's impact on a single-
ended signal's DC bias, so this is also a related topic. Arpad noted that
Fangyi had prepared his original presentation as an alternative to Walter's
BIRD166. Arpad asked if Fangyi would be willing to continue that work. Fangyi
said yes, and noted agreement with Walter's statement that he had originally
only addressed the Rx. Fangyi said that now that we have single-ended channel
applications it will be useful to extend his proposal to the Tx as well. Fangyi
noted, however, that redriver flow vs. single-ended were two very different
applications. He suggested we should address the Init() functions first, and
then we can address the redriver simulation flow.
Ambrish asked if the redriver flow issues were preventing anyone from getting
their work done. Michael M. asked if we had actually pulled in any redriver
device manufacturers to get their input on this. He noted that he could confirm
that there are people looking for one-stop shopping AMI for redriver
simulations. Arpad said he could send out an email soliciting feedback from
IC vendors who make redrivers. Arpad and Mike L. discussed the best lists for
this topic. Arpad said he would start with ATM, and if responses were
insufficient we could try si-list.
Walter suggested that until we had something pressing on the ATM agenda we might
use the time slot for editorial work on v7.0. Michael M. said he wouldn't mind
if people wanted to review the latest v7.0 draft. Arpad suggested we post the
most recent draft and ask everyone on ATM to review it. Arpad said we would
cancel the meeting on October 2 and ask that people use the hour to review
v7.0.
- Mike L.: Motion to adjourn.
- Michael M.: Second.
- Arpad: Thank you all for joining.
AR: Arpad to submit BIRD196. Mike L. to post it and send the email announcing
the vote at the October 12 Open Forum meeting.
AR: Walter to draft a BIRD introducing a DC_Offset Reserved AMI parameter.
AR: Arpad to send an email seeking input from redriver vendors on the AMI
redriver flow.
-------------
Next meeting: 09 October 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
