Minutes from the 20 November ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 20 November 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
* Maziar Farahmand
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:
- Arpad noted that the only ATM meetings we expect to cancel in the upcoming
weeks are those on December 25th and January 1st.
-------------
Review of ARs:
- Randy to investigate if/why/how a clock waveform input might be used.
- In progress. Arpad noted that Randy had said he was unable to attend today
and next week, but that he expected to have some slides on this topic when
he returns.
- Michael M. to investigate if/why/how a clock waveform input might be used.
- In progress. Michael M. noted that he also expected to have some feedback
in a few weeks.
- Arpad to send an email to si-list seeking input from redriver vendors on the
AMI redriver flow.
- Done. No replies received thus far.
- Walter to send draft2 of the DC_Offset BIRD to ATM. Mike L. to post it.
- Done. Walter sent a draft3 in response to some comments from Mike L. on
draft2. Mike L. posted draft3.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the November 13
meeting. Walter moved to approve the minutes. Bob seconded the motion.
There were no objections.
-------------
New Discussion:
DC_Offset BIRD Draft:
Walter noted that he had nothing new to share, and that draft3 was published
and awaiting comments and corrections.
Fangyi noted the previous meeting's discussion about whether this parameter
applied to Tx. He said a related question was whether or not the Tx
equalization could affect the bias (DC_Offset). He noted that the current
standard left open this possibility, though it is not an issue for differential
signals. However, for single-ended signals we might want to clarify things.
Walter said DC_Offset is currently an In parameter. If someone thinks it's
useful to be able to modify it, then we could make it InOut or Out. Walter said
he wasn't sure what it means for the Tx to change the DC_Offset or what the EDA
tool would do with the value.
Fangyi noted that he was not requesting that it be an Out. He was simply asking
what we would do about a situation in which the Tx equalization were allowed to
change the DC_Offset. Fangyi noted an arbitrary amplifier in the Tx could
affect the Tx swing and the DC_Offset. However, he said he did not think this
would be a realistic equalization model for a Tx. Fangyi said that he expected
that Tx equalization should not affect the amplitude or the DC_Offset. Ambrish
asked Fangyi if he was suggesting that DC_Offset shouldn't be needed for the Tx.
Fangyi agreed.
Ambrish noted that he would check with experts in his IP group for their
thoughts. He could get info on whether they thought DC_Offset was needed for
the Tx, why it was needed, and if it could be affected by Tx equalization.
Michael M. noted that he would check with his colleagues as well.
Fangyi said this would be good. Fangyi again noted that he didn't think Tx
equalization should affect the swing or the DC_Offset, but if it changed one it
would change both. Once we get confirmation from others, we might want to add
clarification to the BIRD to avoid arbitrary and ambiguous Tx models.
Ambrish noted that one reason the Tx might need the DC_Offset was to let it
choose the right pre-emphasis option, but it may not need to report the value
back. Fangyi noted that the Tx output is limited by Vcc and Vss, regardless
of the Tx implementation. Since Vcc and Vss are characterized in the analog
channel, the Tx .dll should not change the swing or the IR amplitude.
Bob noted two editorial issues with draft3. The first sentence of the
Definition section still mentioned InOut. This was an oversight, as all Usages
other than In were removed at the last meeting (draft2). Bob also noted that
the meaning of "this" in "then this should be the same..." in the final sentence
of that paragraph was unclear. Walter and Arpad noted that "this" should be
replaced with the parameter name itself "DC_Offset".
Michael M. asked if this all still assumed an IR was input to the .dll. Walter
confirmed this was true. Michael noted that we wouldn't need DC_Offset if we
had a step response or pulse response instead. Walter agreed and noted that
there were many ways to solve the problem. We could instead have a BIRD to
change the arguments to AMI_Init(), or add a new Reserved parameter to indicate
that a step or pulse response were being passed instead, for example.
Arpad asked how this would work with BIRD158 style models. Walter noted that
BIRD158 models implied a differential Tx and Rx. Arpad said this raised another
question, will we have to extend BIRD158 to handle single-ended cases? Walter
joked that we might need it for DDR7. Walter noted that DDR5 is only 4 to 5
Gig, and on-die S-parameters as found in BIRD158 are typically used for higher
frequency applications. Walter noted that right now DDR5 model makers are using
classic IBIS [Model]s and don't need BIRD158. There may be a need to extend
BIRD158 in the future, but no IC vendor is asking for it now.
Walter noted the comments in today's meeting, but said he would hold off on
creating another draft until we got more feedback, including that from Ambrish
and Michael after they consult with their co-workers.
IBIS-AMI Improvements - Summary of DDR5 issues:
Ambrish and Walter said they thought the topic could be removed from the agenda.
They noted that the DC_Offset BIRD addressed part of it. The clock-forwarding
issue was waiting for feedback from Randy, Michael M., and others. Walter noted
that he is working on a paper for the DesignCon IBIS Summit that discusses the
rise/fall asymmetry issue and how to address it.
Michael M. asked if the asymmetry wouldn't also be addressed if we had the
option of a pulse response, or step response, or multiple step responses as
opposed to the IR.
Walter noted two primary issues:
1. What to do with Init(): We could give Init() two IRs or two step
responses (rising/falling), which would require a BIRD, or we could call
Init() twice and process the results after the fact, or we could provide a
"melded" IR. There are various ways of generating the melded IR.
2. What to do with GetWave(): This is the more critical issue, because it's up
to the EDA tool to generate the waveform input to Rx. The method described
in IBIS 6.1 is clearly invalid because it only uses one IR and there
are really two IRs for the channel (rising/falling). Do we need to change
the standard? SiSoft is instead choosing to publish how we do it. Then
people can choose to add that approach to the standard or propose a better
way instead. No change to the function calls. Even if you changed what you
do with Init() to handle two IRs, it's still up the EDA tool to generate the
waveform input to the Rx.
Fangyi noted that it was important to keep statistical simulation in mind.
Walter noted that he inferred from Cadence's DesignCon presentation that they
too were using a "melded" IR. They have a PRBS method for generating the melded
IR. Walter said SiSoft had several methods of generating the melded IR that do
better than using a rising or falling IR. He noted that there are fundamental
limitations for statistical simulation with this technique, but it does well if
a 10mV error is acceptable.
Fangyi asked about an Rx with DFE. If your Rx has DFE then in a statistical
flow the Rx will need to add the DFE spikes to the IR. If you only have one IR
it's almost impossible to recover the DFE spike information and apply it to
other IRs. Ambrish said he thought statistical flow simulation of DFE was
already far removed from what's going on in the hardware. Michael M. said that
depends. Walter noted that they had done a lot of work with DDR5 DFEs and
gotten valid and useful results from statistical simulation. It wasn't as
accurate as time domain but was good enough for engineers to make decisions
about their channels and margins. Fangyi said some engineers might tolerate a
5 percent difference relative to SPICE, and some might find it a significant
error.
Arpad returned to the clock-forwarding issue and asked if we needed to do
anything in the spec. Walter said what is critical is determining the phase
between DQS and DQ. That is determined by the controller as part of a training
process. If we add DQS as in input to the Rx model, it has to be trained by
the Tx to get the right phase. How would the EDA tool know how to generate the
skew? Only the Tx AMI model can do that, presumably using a back-channel type
scheme. Fangyi noted that we are talking about the write-cycle in DDR5.
Fangyi noted that this issue was related to the fact that at some level we are
really trying to model the controller. We generally talk about modeling things
at the buffer level, but to address the skew issue we should be talking about
the component level. The controller doesn't adjust the individual skew for
every I/O. It is actually handled one level above. You might have 64 DQs, but
not every one has its own skew. Walter said this was true for DDR3 and DDR4
in particular, but many DDR5 controllers control skew at the individual bit
level (not the byte, nibble, lane, etc. like DDR3). Fangyi noted that we also
have control and clock and command address lines. We have skew issues for those
lines too, and they are not controlled on the individual bit level. Walter
agreed that the controller would adjust all those skews to maximize performance.
Fangyi noted that they are not adjusted by each command address line model, it's
handled "one level above". Walter agreed.
Fangyi said it comes back to whether we want to model it at the I/O buffer level
or at the component level. Many issues are more naturally modeled at the
component level. Walter agreed and said that when we do timing analysis we have
to know all the clock to outs, and skews between clocks and data, and they're
all part of the timing model. The EDA tool can run the analysis and determine
what settings the silicon would come up with if it did train. Fangyi said the
EDA tool is acting like the controller, but it's not necessarily doing what the
controller would do. Walter said the EDA tool, presumably with an accurate
timing model, is figuring out at the component level what all the skews need to
be. It may not match exactly what the controller is doing, but presumably you
have a timing model that accurately represents what the controller is doing.
If we wanted AMI to more strictly emulate the controller's behavior, then you'd
need BIRD147 style communication between all the models to try to emulate what
the hardware is doing. Fangyi said another alternative was to develop a
component level model, which Randy had said would be complicated. Walter
agreed.
Walter noted that he was involved early on in 802.3. He said that he gave a
presentation on IBIS-AMI, and people there rejected anything that involved
simulation. Their goal was a standard, you write your Rx according to a certain
compliance test, and your channel satisfies it, etc. They don't want their
customers to have to simulate anything. They want rules. That's why they came
up with things like the Chanel Operating Margin (COM) metric. It's a bit like
AMI, and one can create AMI models that satisfy the COM requirements, but
simulation is a dirty word to them.
Arpad noted the component-level vs buffer-level discussion and asked what we
want IBIS to be in the larger context. He noted that we have a few [Component]
level things (Pin, Pin_Mapping, etc.). Do we want to refine that component
level to do what Fangyi was suggesting?
Michael M. noted that even what Arpad had mentioned was at the physical level,
and that this was talk of moving up into an architectural level. If we want to
move up to architectural level, then we have to be careful to decide what
protocol level stuff we need to include as well. We need to be careful or we
could end up with mission creep and never get a new version of IBIS done.
Walter noted that they had done timing models based on MOTIVE (View Logic)
static timing analysis (clock to out, clock skew, set-up and hold times, etc.).
The timing model defines what clock to use for setup and hold for these inputs,
etc. If IBIS decides we want to develop a standard timing model, he would have
no problem putting what they'd done in the public domain, though maybe there
would be some issues since it's an enhanced version of a MOTIVE type model. If
we decide to do that, then Walter suggested a timing model would be related to a
[Component], and it could be included kind of like a [Package Model] is.
Arpad asked if we needed to go in that direction, and noted that the clock-
forwarding issue touches on the question. Walter noted that we all have timing
models. Do EDA companies want a unified way of defining a timing model? Fangyi
noted that if we have a component level model, then the timing model and other
things can be implemented inside the .dll.
- Walter: Motion to adjourn.
- Michael M.: Second.
- Arpad: Thank you all for joining.
AR: Ambrish to check with IP experts on whether DC_Offset is useful for Tx.
AR: Michael M. to check with IP experts on whether DC_Offset is useful for Tx.
-------------
Next meeting: 27 November 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
