Minutes from the 24 March ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 24 March 2020
Members (asterisk for those attending):
Achronix Semiconductor * Hansel Dsilva
ANSYS: * Curtis Clark
* Wei-hsing Huang
Cadence Design Systems: * Ambrish Varma
Ken Willis
Kumar Keshavan
Intel: * Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
Ming Yan
* Todd Bermensolo
Marvell Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft (Mathworks): * Walter Katz
Mike LaBonte
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 March 17
meeting. Michael moved to approve the minutes. Randy seconded the motion.
There were no objections.
-------------
New Discussion:
Discussion on "Gap in IBIS for sampling with statistical mode AMI models":
Hansel reported that he is progressing on an initial BIRD draft. He is folding
in some changes from various discussions. He expects to have a draft for
review in the next couple of weeks.
Hansel noted one question he wanted to submit to the group. Currently there is
no mechanism for the model to share the sampling position of the main cursor
with the EDA tool. The model has to tell the EDA tool where to sample. Hansel
said that sampling point can be with respect to a step response or a pulse
response, but not an impulse response. He asked if the group preferred to use a
step or pulse response. Arpad noted that the IBIS specification currently only
defines an impulse response input to the AMI functions. He said we can't talk
about a response that is not passed into the model, so the proposal would have
to be very careful about how these responses were defined. Ambrish asked Hansel
to capture his question in an email for ATM to consider. Hansel took an AR to
send an email detailing his question.
DDR Clock Forwarding:
A straw poll on whether Fangyi's proposal was ready to submit to the Open Forum
as a BIRD was scheduled for this meeting. Walter requested that we defer the
vote and continue discussion. He said adding a new function signature
(AMI_GetWave2()) was a big step and should be done with great thought and
consideration of any alternatives. He said he preferred to use the clock_times
vector as an input to the DQ AMI_GetWave() to accomplish the same thing. He
said he needed to understand what prevented that solution from working. Ambrish
noted that he concurred with Walter. He said his team had demonstrated that a
clock_times vector input was sufficient. He expressed the concern that this
proposal might unnecessarily complicate the flow, and he wasn't sure the need
for it had been demonstrated.
Fangyi said that only having the clock_times vector to represent forwarding the
clock will not work for the Phase Interpolator. If you don't have the actual
DQS waveform, then you can't model the behavior of the PI. The DQS waveform is
needed, and that's why they had proposed AMI_GetWave2().
Michael noted that he concurred with Walter (on deferring a vote), for a
different reason. He said that his organization had two groups that had been
independently approaching this issue. One group co-proposed Fangyi's method,
and the other team had a different perspective. Michael asked for delay of a
week or two so those teams could get in sync and potentially incorporate both
perspectives.
Arpad noted that, in terms the straw poll, just because we submit a BIRD to the
Open Forum doesn't mean that someone else couldn't submit a competing BIRD. He
asked if we needed to delay this proposal from being submitted, and if we
preferred to hash things out and come up a single BIRD. Walter agreed that
nothing prevents Fangyi from submitting his proposal. An ATM vote to confirm
that we recommend a BIRD isn't necessary, but we tend to want to come to agree-
ment in ATM before submitting a BIRD to the Open Forum. If there are any
disagreements in the Open Forum, then discussion comes back to ATM anyway.
Radek said a limited delay and discussion of any specific questions from Michael
made sense, but he said that passing additional data through strings was an
inferior solution. Ambrish asked if he could quantify how inferior.
Arpad asked about the use of clock_times as an input. He asked what the source
of the clock ticks would be. It currently comes from another .dll (the DQS Rx),
but couldn't that other .dll have the PI model so it could put its strobe output
in the clock_times vector? Fangyi said the PI is in each DQ Rx. It could be
different from DQ to DQ, so you can't generate it in the model for the DQS that
could be shared by multiple DQs. Walter said there were two ways to generate
clock ticks. The EDA tool could look at a DQS Rx input waveform and determine
crossings and figure out the clock ticks. Alternatively, the DQS input waveform
goes through the DQS model's AMI_GetWave() and the output clock_times array
contains the clock ticks.
Referring back to Fangyi's presentation on this proposal, Walter said several
slides had presented an overview of the PI, its characteristic equation, tau1
tau2, etc., but that the vin and vout weren't explicitly defined. He said we
need to understand, given the values and expected ranges of these parameters,
the magnitude of the effect we are trying to capture. We need to convince
ourselves we need a new function signature.
Fangyi reviewed the PI portion of his presentation, slide 6 in particular.
He noted that vin is defined as the DQS output waveform (the DQS signal). tau1
and tau2 are two different delay times. The input is delayed by tau1 and by
tau2, and then a weighted sum of the two is computed according to the value of
n. Fangyi noted the "Ideal input" and "Ideal output" figures on slide 6. The
Ideal output showed different waveforms you'd get by varying n. The "Real
Output" figure shows a more realistic example of how the output waveforms would
vary with n given a non-ideal input waveform. If you use the output waveform
to drive the clocking, then different values of n give you a different delay
in the crossing time.
Ambrish asked if this was delving too far into how a model is implemented.
Walter said that a PI introduced a delay of the zero crossing of the waveform.
Fangyi agreed, roughly speaking. Walter said if the model had clock ticks it
could pick a delay value based on those clock ticks to get the sampling location
right. Why would Fangyi's proposed method give a different answer than a model
adjusting based on input clock ticks? Arpad said the PI works on the DQS
waveform, which we don't have any more if using clock ticks. Walter said the PI
is a kind of CDR that works by introducing delay.
Fangyi said Walter's model would be treating the delay as continuous and
choosing the best delay. Fangyi said the discretized delay values depend on the
shape of the waveform. Curtis said he thought Fangyi was stating that the
model
couldn't even know what discrete delay variations would be available by
changing
n if it didn't know the shape of the waveform. Fangyi agreed.
Walter noted that the hardware could only sweep n and choose the best value. He
asked what the magnitude of the error bound would be for using clock ticks
instead of the actual waveform. He agreed that the value of n chosen in
simulation might not be the value hardware would choose, but what was the
magnitude of the error in actual delay value? Walter proposed a 6GHz example
with a PI with N=32. Since the UI was approx. 160ps, with N=32 you could get
160/32 = approx. 5ps resolution. Fangyi said this uniform spacing assumption
was not correct, as the spacing of the discrete steps depended on the shape of
the waveform. Walter said he was trying to get a handle on the magnitude of
the error.
Michael asked if a buffer designer would have to specify a range of n values
for which their design should work? Walter said this was a different issue.
DDR4, for example had constraints on matching the electrical lengths of the
DQs. DDR5 is less constrained in this regard. So every DQ can be trained
independently. The controller could set that skew by choosing any value of n
it wanted for each DQ. The controller can choose from the entire range of 0 to
N to best match the delay for each channel.
Fangyi referred back to the "Ideal Output" figure on slide 6.
He noted that if you drew a horizontal line through that figure
at any level, you really only had two different delays that were realizable,
even though you stepped through all N+1 values of n. There is no delay in the
middle of that range that you can realize with an ideal waveform, for example.
You don't know what discrete delay values are available without the actual DQS
waveform.
Arpad said he would summarize Fangyi's statements and the horizontal line on the
"Ideal output" example as follows: There may be plenty of values of n to sweep
through, but the actual crossing delays available might be fewer. In this case
there were only two values available and no value of delay between the two of
them was realizable. In a real case with a waveform with non-ideal finite
slopes, varying n would provide more discrete values of delay in the middle of
the range.
Fangyi noted that slicer sensitivity to slew rate is another reason to pass the
DQS waveform into the DQ Rx model. Referring to the block diagram of the
Controller DQ Rx Model (slide 5), he pointed out the Slicer block and asked how
you can model the slicer's sensitivity to slew rate without the DQS waveform?
- Bob: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 31 March 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
