Minutes from the 20 August 2019 IBIS ATM meeting are attached.
IBIS Macromodel Task Group
Meeting date: 20 August 2019
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: * Ambrish Varma
Ken Willis
* Kumar Keshavan
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:
- None.
-------------
Review of ARs:
- Walter to draft an email listing proposed clarification language related to
Interconnect Models.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the August 13
meeting. Walter moved to approve the minutes. Bob seconded the motion.
There were no objections.
-------------
New Discussion:
BIRD 197.4 discussion:
Walter summarized the state of the issue. He noted that after reviewing
BIRD197.4 carefully there were certain details he didn't like. He and Ambrish
had each sent out alternative proposals. Walter noted that the two were quite
similar, with the biggest difference being that Ambrish's removed NRZ_Threshold
altogether. Walter noted that he liked the idea of removing NRZ_Threshold.
He said that if a model maker wants the reference voltage to be 0.5V instead
of 0.0V, they could simply subtract 0.5V from the waveform before GetWave()
returns it. So, there would be no loss in functionality if we didn't have an
NRZ_Threshold parameter and the EDA tool always used 0.0V as the threshold value
when detecting the logic levels in the GetWave() output waveform.
Ambrish noted that NRZ_Threshold was not the primary issue with his proposal,
and that he had proposed separating DC_Offset and NRZ_Threshold into separate
BIRDS. NRZ_Threshold could be applicable to all AMI simulations, but DC_Offset
was for single-ended applications. Ambrish said the primary reason for his
proposal was that his group thought BIRD197.4 was unclear and had ambiguities
about what is done by the model and what is done by the EDA tool. Kumar said
the flow had to be clear about who does what, and that he was confused by
BIRD197.4. He said keeping it simple was better, and DDR4 and DDR5 could
be handled with simpler approaches. He said that DDR6 users would be
comfortable looking at differential waveforms anyway.
Fangyi asked what was complex about BIRD197.4. He reviewed the primary point:
Complete waveform = Rx GetWave() output + output value of DC_Offset
and noted that the text makes it clear that the EDA tool adds the DC_Offset to
the GetWave() output. Ambrish said it wasn't a question of understanding the
text itself, it was a question of clearly dividing who does what. Ambrish noted
that in BIRD197.4, if DC_Offset were an In parameter then the model had to do
all the shifting (because the default "output" value of DC_Offset is 0V if
DC_Offset is an In parameter), but if DC_Offset were an InOut then the EDA tool
does the shifting (when it adds the value of DC_Offset to the waveform).
Fangyi said the only difference between their proposals was that Ambrish
wanted the default output value of DC_Offset to be the input value, while
BIRD197.4 specifies the default output value as 0V. Fangyi said that with DDR5
the output waveform would usually be centered about zero, and that's why the
output value of DC_Offset defaults to zero in BIRD197.4. Fangyi said it
didn't make sense to have the output value of DC_Offset default to the input
value, because the input and output waveforms are at two different nodes.
Walter noted that he thought Fangyi's BIRD197.4 documented the process clearly,
but that he didn't want to implement that process in his tool. He asked what
Fangyi's proposal added relative to the simpler approach he, Ambrish and Kumar
wanted. He suggested all the complications of the new parameters could instead
be handled by having the model shift the waveforms so they are compared to a
0V reference. Fangyi said the benefit of the output value of DC_Offset was for
the statistical flow. It allows a statistical simulation to produce an eye
centered at DC_Offset. Walter said this was simply a visual aid to reference
the eye to some different reference point. All that really matters is the
waveform relative to the latch. The DC_Offset would just allow the final eye
to correspond to a hypothetical lab measurement.
Ambrish said his IP folks didn't want to follow BIRD197.4 and didn't want to
output a value of DC_Offset from their models. They wanted their models to use
the input value and leave the waveform the way they got it. Walter said he
thought the "default" output value wasn't meaningful. If the model defines
the parameter as an In, then the model is saying the "output" value is
meaningless, and the waveform returned by GetWave() will be based on a 0V
threshold. Kumar said the output value couldn't be determined properly at
Init() time anyway, and the output value wasn't a fundamentally important
quantity. Ambrish agreed that the input quantity was the important one. Walter
asked why the EDA tool should add the output value to the waveform at all. He
said that's only meaningful to make it comparable to the NRZ_Threshold value.
Walter noted that his proposal and Ambrish's were similar, except Ambrish's
removed NRZ_Threshold altogether. Walter's proposal had changed NRZ_Threshold
to state that it was compared to the output of Rx GetWave(), not the "complete"
waveform as in BIRD197.4. Walter shared his draft. Radek noted that the
language shown went back to the ambiguous "can be added" statements, which left
it unclear exactly what was added to what and by whom. Ambrish asked that
people review his version and said that his clearly spelled out the division of
labor. Walter made a motion to vote at the next ATM meeting on whether to
introduce Ambrish's proposal as a BIRD197.5 to supersede BIRD197.4. Ambrish
seconded. There were no objections to scheduling the vote.
Interconnect Model syntax - questions about Aggressor_Only:
Bob noted some contradictory language in the spec that had been revealed when
the parser developer literally interpreted several statements. The parser
developer had properly interpreted several statements, but the end result was
not the intent of the spec. On page 33 of IBIS 7.0, the following statement is
not literally true:
No I/O pin_name in a component may appear as a Pin_I/O terminal without the
Aggressor_Only column in more than one Interconnect Model in the Interconnect
Model Group.
This statement conflicts with the fact that a connection path only has to be
tagged as Aggressor_Only at one interface, and it will be considered
Aggressor_Only for the entire path. Walter noted that when an interface is
tagged Aggressor_Only, it's really the connection between the interfaces that
is Aggressor_Only. Bob agreed. So, only one Interconnect Model in the Model
Group (or a combination of two models in the pin-to-pad and pad-to-buffer
Models case) can specify the Pin's entire path without the Aggressor_Only tag
appearing. But it is not necessary to have the Pin_I/O terminal itself tagged
as Aggressor_Only in all the other models. They might have the Buffer_I/O
terminal tagged as Aggressor_Only instead, for example. Walter and Bob agreed
that the entire path is considered Aggressor_Only if any one of the *_I/O
terminals is tagged Aggressor_Only (stated on page 32). Bob noted that he was
going to propose a cleanup BIRD to address these issues.
Bob also noted that you can't apply these rules directly to Interconnect Model
Sets, because you can't check the possibilities until you know all the Sets in
the Group. As an example, he noted that you might bring in Aggressor_Only tags
in a Model that's part of another Set. Walter agreed this was a subtle and
interesting point. Bob said he planned to finalize all the information for the
parser developer in the next few days.
- Walter: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 27 August 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
