I just realized that I mistakenly attached an incomplete rough draft to the
original email. The minutes attached to this email are largely the same, but
contain some formatting and editorial fixes.
Thanks,
Curtis
Minutes from the 05 May ibis-atm meeting are attached.
Documents discussed during the meeting were sent to the ATM list and will be
uploaded here:
http://ibis.org/atm_wip/archive-date.html<https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fibis.org%2Fatm_wip%2Farchive-date.html&data=02%7C01%7Ccurtis.clark%40ansys.com%7C064e5fa3ba35485bb18a08d7f221c061%7C34c6ce6715b84eff80e952da8be89706%7C0%7C0%7C637244099569595870&sdata=2m18eBhUyc2FQZcD2d%2BD90ai%2BE8XmIL%2FdvYmb5Ifuaw%3D&reserved=0>
IBIS Macromodel Task Group
Meeting date: 05 May 2020
Members (asterisk for those attending):
Achronix Semiconductor * Hansel Dsilva
ANSYS: * Curtis Clark
* Wei-hsing Huang
Cadence Design Systems: * Ambrish Varma
Ken Willis
* Jared James
Intel: * Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
Ming Yan
* Todd Bermensolo
Stephen Slater
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
Zuken USA: * Lance Wang
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- Randy noted that we had received a new BIRD198.1 from the authors in Japan.
He said he had reviewed it and created a new draft with some editorial
changes. He asked that time be allocated to review it at an upcoming meeting.
Arpad agreed to add it to the agenda.
-------------
Review of ARs:
- AR: Radek to send BIRD201 clarification suggestions to Walter.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the April 28
meeting. Michael moved to approve the minutes. Randy seconded the motion.
There were no objections.
-------------
New Discussion:
Gap in IBIS for sampling with statistical mode AMI Models:
Hansel shared his presentation about a new BIRD draft, and discussion continued
where it left off last meeting. Hansel reviewed open questions.
slide 13: Clarifying the description of Rx_Decision_Time
Hansel again noted Ambrish's "returned by the model" language and said this
leaves the ball in the model developer's court. If the model maker does
anything to introduce extra delay, for example, this has to be reflected in the
output value of Rx_Decision_Time. Michael said his suggestion had been to
adjust the text for clarity in defining exactly what Rx_Decision_Time is.
Walter said you know it when you see it, but it might not be easy to define in
text. He said in reality we have an IR available, and from that we can create a
pulse response. EDA tools look at that pulse response and decide where to put
the clock. For some it might be the high point of the pulse response, some
might use a hula-hoop algorithm, etc., but you can mark a location on the pulse
response plot and say that's where the sampling will occur. Then you can look
at all the UI increments to the left and right to formulate eyes, contours, etc.
Now, we want to replace that process. Now you take the IR, convolve it
with a pulse, and the Rx_Decision_Time tells you where to sample. You have an
IR that starts at time zero, a pulse response that starts at time zero, and the
Rx_Decision_Time is the time where you want to sample the pulse response.
Arpad noted Michael's comment last week about the text's use of "decision
point", which in IBIS typically implies a physical location corresponding to the
output waveform of Rx GetWave(), where the core logic begins. He suggested
that
we change "decision point" to "decision time" in this proposal. Walter, Radek
and Hansel agreed. Hansel changed all instances to "decision time", and also
made the change from mean or median sample time to "ideal sample time" as
discussed the previous week. Michael said these changes resolved his question.
slide 14: Should we provide any guidance on generation of the pulse response?
This question from Ambrish was added at last week's meeting. Ambrish said that
we might want to be explicit, for the sake of the model makers and EDA tool
vendors, and explain what Walter had described. We might state that one way to
generate the pulse response is to convolve the IR with a pulse that starts at
t=0. Arpad said he didn't think this was necessary. He said IBIS 7.0 doesn't
say that you take the derivative of a step response to get the impulse response,
so why would we mention this? Radek noted that this had been discussed during
deliberations over BIRD194, and that text had been removed. So, IBIS 7.0 does
not discuss it. Arpad noted that BIRD158 type AMI models can use Touchstone
files instead of legacy IBIS constructs, so you could conceivably stay in the
frequency domain and never have to construct step or pulse responses at all.
Walter said if the EDA tool did what we had just described and convolved the
output IR with a pulse starting at t=0, then the value of Rx_Decision_Time
returned by the model tells the EDA tool where to sample that pulse. He said
we all agree on that, and the question is whether we need to put it in the
spec.
Ambrish said that if someone convolves with a pulse not starting at t=0 then
they get a different answer, so we might want to state it explicitly. Since the
tool has to know how to apply this value, we need to make sure it's understood
the same way by model makers and tool vendors. Walter referred to the
Description string in the Example section of the Rx_Decision_Time definition:
"The time value in seconds, which is the receiver decision time of the
symbol that the threshold crossing started with respect to time zero of
the impulse response."
He said this description makes the intent clear. It's just talking about the
rising transition, and we don't even need to mention the difference between step
or pulse responses.
Radek said that, to be precise, we are talking about a pulse with a rising edge
at t=0 and a width equal to the UI. An IR is by definition the response to a
delta at t=0. So we can talk about a pulse response instead of an impulse
response.
Arpad asked how Ambrish could be worrying about different delays being
introduced. He said if you take the IR returned by the model and integrate it
to get the step response, where can different delays be introduced? Curtis
clarified that Ambrish was talking about generating the pulse response directly
by convolving the IR with a pulse, and he was concerned about someone using a
pulse that didn't start at t=0 and introducing artificial "delay" in the pulse
response. Ambrish agreed.
Walter said you can do two different convolutions with the IR. One with a step
and one with a pulse. If you overlay them, the leading edge of the pulse
response will be almost identical to the leading edge of the step response.
The only time they wouldn't agree is if there are causality issues (long tail
to the left of the IR). The leading edge of the pulse response should be
identical to the leading edge of a step response that started at the same time.
Radek agreed and said the delay is built into the impulse response.
Ambrish said that if everyone thought it was clear that the steps and or pulses
started at t=0, then he would drop the issue. However, if there was any room
for confusion then we should be explicit. Ambrish briefly searched IBIS 7.0
and said that he didn't find any discussion about how the modified IR is to
be returned. So, he said if this has always been understood that the step
or pulse would start at t=0, then we could drop his suggestion to explicitly
state it.
slide 15: Guidance on CDR and PD, or should clock ticks and/or Rx_Decision_Time
be mandatory?
This question from Arpad was added at the previous meeting. Arpad said that he
had made the observation that the GetWave() flow had the same decision time
issue if the GetWave() did not return clock ticks. He had asked if we should
consider making clock ticks mandatory, so we didn't have to worry about EDA
tools implementing their own differing CDRs. Similarly, he had asked if we
should consider making Rx_Decision_Time mandatory so EDA tools don't have to
decide for themselves.
Walter said that as a tool developer he would be happy if the model maker always
provided this information, but he didn't think model makers would like it being
mandatory. Walter said that if your model only has a ctle, agc, and ffe, and no
dfe, then there is no decision time and no need to provide clock ticks. Arpad
said the eye diagram still has to be built based on something, even if the model
has no dfe. Walter said a redriver model is just taking an analog waveform in
and passing an analog waveform out and would not need any clock ticks
information. Arpad agreed that a redriver model was a good counter example, but
he said it was an exception. Walter said it's another case of whether we want
to define or enforce what a "good" model's behavior is.
Radek said he thought Arpad had been proposing that this new Rx_Decision_Time
parameter could be used in the GetWave() flow if clock ticks were not returned
by GetWave(). He thought this was a reasonable suggestion. Arpad said that he
had not intended to suggest this at all. He had merely made the observation
that an analogous hole existed in the GetWave() flow if the model didn't return
clock ticks. Ambrish said the difference was that the GetWave() flow already
provided a way for the model to return clock ticks if it wanted to. This
Rx_Decision_Time parameter was adding a way for AMI_Init() to return the
information if it wanted to.
Arpad said that he had merely made the suggestion based on his observation
about clock ticks being analogous to Rx_Decision_Time. He didn't want to pursue
the topic if others disagreed or didn't think it was important enough to change
the spec. Randy said this might be a topic for a different BIRD, or better yet
a cookbook topic on what a good model does.
Hansel briefly reviewed the BIRD itself. He noted the change to allow type UI
as well as Float, which was discussed at the previous meeting. He also noted
the description of "ideal" sampling time in the Solution requirements section.
He reviewed one new point that had been added: Rx_Decision_Time takes precedence
over Rx_Clock_Recovery_Mean for statistical processing.
Arpad asked Hansel to incorporate the comments from the meeting and send the
presentation and the BIRD draft to the ATM list. Hansel agreed.
BIRD201 - Addressing Radek's comments:
Radek reviewed his recent email regarding BIRD201 flow clarifications. He said
that up to step five everything is clear. He said step 6 was vague, and he
thought it could be removed. Radek suggested we explain scenarios involving the
different combinations of the simulation type (statistical or time domain) and
the BCI_Training_Mode value. For example, even if BCI_Training_Mode is "Dual",
if the user is running a statistical simulation it stops after step 5 and does
not continue on to time domain. If the user is doing a time domain simulation,
but BCI_Training_Mode is "Impulse", then training is over after step 5. What
should the tool do if a time domain simulation is being run and BCI_State
returns error or fail at the end of Impulse training? We need to explain the
expected behavior in all scenarios. Walter said he would work on an updated
version to address Radek's concerns.
- Walter: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Arpad to add BIRD198.1 discussion to the agenda.
AR: Hansel to email his updated BIRD draft and presentation to the ATM list.
AR: Arpad to ask Steve to upload Hansel's documents to the ATM work archives.
AR: Walter to work on a BIRD201.1 draft to address Radek's feedback.
-------------
Next meeting: 12 May 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
