Minutes from the 13 October ibis-atm meeting are attached.
Arpad's presentation from the 2005 IBIS Summit in Munich, which was discussed
during the meeting, can be found here:
http://www.ibis.org/summits/mar05/muranyi.pdf<https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ibis.org%2Fsummits%2Fmar05%2Fmuranyi.pdf&data=02%7C01%7Ccurtis.clark%40ansys.com%7C4a52d6cebf764e5d33b508d86fb1ea83%7C34c6ce6715b84eff80e952da8be89706%7C0%7C0%7C637382157696504199&sdata=x7aptppCXmmmgY2TcXc%2FT8csFBn1RbVBY9TFXyVaZGg%3D&reserved=0>
The VHDL-AMS model source code related to the presentation was also posted and
can be found here:
http://www.ibis.org/summits/mar05/PreDe_emphasis.vhd<https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ibis.org%2Fsummits%2Fmar05%2FPreDe_emphasis.vhd&data=02%7C01%7Ccurtis.clark%40ansys.com%7C4a52d6cebf764e5d33b508d86fb1ea83%7C34c6ce6715b84eff80e952da8be89706%7C0%7C0%7C637382157696504199&sdata=omxIlgndaodOfSUqjlFNKe0aZhT5nPW2zIfdL6hfOJo%3D&reserved=0>
IBIS Macromodel Task Group
Meeting date: 13 October 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
Google: * Zhiping Yang
Intel: * Michael Mirmak
Kinger Cai
Keysight Technologies: Fangyi Rao
Radek Biernacki
Ming Yan
* Todd Bermensolo
Rui Yang
Marvell Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SAE ITC Jose Godoy
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:
- Todd noted that DesignCon had been moved until April and asked if the IBIS
Summit had also been moved. Randy confirmed that if DesignCon is an in-person
event then the associated IBIS Summit will occur on the Monday preceding
DesignCon instead of the Friday following it. He said this change was
related to meeting room availability given the recent change in date and
venue. Arpad mentioned that there will be no IBIS Summit in the traditional
DesignCon timeframe (late January) in 2021. (See IBIS Open Forum minutes for
discussions on the DesignCon 2021 IBIS Summit and all summit planning)
- Randy asked if we might review the status of the two redriver flow BIRDs,
BIRD190 and BIRD166, which had been tabled and idle for a long time. Arpad
said items 13, 14, and 15 on the agenda were related to this topic. Randy
said he would like to revisit them, understand the issues, and decide whether
to move forward or vote them down.
-------------
Review of ARs:
- Michael to submit the [Clock Pins] proposal as an official BIRD.
- Done. Submitted as BIRD208.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the October 6th
meeting. Randy moved to approve the minutes. Lance seconded the motion.
There were no objections.
-------------
New Discussion:
GDDR6x Discussion:
Arpad opened the floor to further discussion, as we had run out of time at the
previous meeting. Walter said that IBIS currently has I-V curves for pullup
and pulldown devices. He asked if Randy was suggesting having them for the
0, 1, 2, 3 symbols. Randy said perhaps 4 I-V curves to model the way the driver
is partitioned into different impedances. Walter noted the various PAM4
transitions: 0-1, 0-2, 0-3, 1-2, etc., and asked if one might want V-T curves
for each of them. Randy agreed. Walter said these sounded like straight-
forward enhancements if we decided they were necessary, though he noted that he
and Ambrish didn't think it was necessary. Randy said that based on similar
feedback from the previous meeting he was working on gathering new simulation
data. He plans to run the existing AMI PAM4 flow on this GDDR6x interface and
compare the results to transistor level simulations to see how they match. This
should give us more to discuss later.
Arpad recalled a presentation he had given at an IBIS Summit in Munich in 2005.
(http://www.ibis.org/summits/mar05/muranyi.pdf)
He thought it could be relevant to this topic and shared the presentation,
"Pre/de-emphasis buffer modeling with IBIS". Arpad said the presentation had
been prompted by inaccuracies and issues they had observed modeling pre-emphasis
and de-emphasis buffers using the [Driver Schedule] keyword. Using main and
boost models with [Driver Schedule] had caused issues because the main and boost
drivers were separate [Model]s with their own C_comp values and C_comp
compensation routines. Consequently the capacitance of one [Model] imposed a
load on the other [Model], which resulted in inaccurate edge rates.
The proposed solution had been for the model maker to generate only one I-V
curve representing the main and boost stages both being on. Separate V-T curves
would then be generated for each of the 6 different transition types. With a
single I-V curve, the standard C_comp extraction methodology worked without fear
of double counting or how to split up C_comp. Results plots demonstrated better
edge rate agreement than standard [Driver Schedule] modeling produced. Rising
vs. falling edge rate asymmetry could also be handled by doubling up the number
of V-T curves and providing separate curves for the inverting and non-inverting
outputs.
Randy agreed that we might be able to apply similar ideas to this topic. Walter
referred to the slides comparing resulting output waveforms. He said that all
the fine details that were better reproduced were high frequency effects, and
the high frequency effects are gone before you even get out of the package
because of high frequency losses. Arpad clarified that the goal of the original
work had been to get the proper edge rate and avoid the issues with C_comp.
Walter said he thought the conclusion/solution of only using one I-V curve was
correct and also applied to this GDDR6x topic. He said the existing AMI PAM4
flow expects one I/V curve that covers the entire voltage range. He said it's
hard to make things really non-linear, and if it's too non-linear it's a big
problem for PAM4 anyway. Walter said he'd be interested to see the results of
Randy's comparison vs. transistor level SPICE models.
PI modeling/simulation in IBIS:
Zhiping said two potential BIRDs related to this topic were in progress. He
said he was in the early stages of working on a PI modeling BIRD himself. He
also reported that he had discussed the PSIJ presentation from the EMC + SIPI
summit with Professor Chulsoon Hwang from Missouri S&T. Zhiping said he would
meet with Chulsoon to talk about the process of creating a BIRD. Randy said he
had reviewed the presentation recently and looked forward to seeing what new
information they might want to include in a buffer model. Zhiping noted that
the fundamental question relates to power supply induced jitter that is defined
as a variation in the propagation delay. This delay variation is not captured
with current IBIS power-aware constructs. Zhiping said after further discussion
with Chulsoon he would likely invite him to attend an ATM meeting to discuss the
topic.
Redriver flow related BIRDs and proposals:
Randy asked if we could eventually untable these and talk about them so we can
decide if we need to do anything with them or simply vote them down. Arpad
noted that tabled topics 13, 14, 15 were all redriver flow related. Ambrish
said his BIRD190 was just a clarification and admonition to the model maker not
to assume anything that might not be there for the downstream Rx GetWave()
model. Arpad noted that Walter's BIRD166 had been an attempt to resolve some
issues with the redriver Init flow in common scenarios, but that people had come
up with combinations where the proposed fixes didn't work. In addition, Fangyi
had begun work on a more elaborate proposal, which would have become a much
bigger BIRD.
Ambrish recalled that the proposals had been tabled because there hadn't been
much urgency from tool vendors. Arpad noted that he had emailed the ATM list
and the entire SiList to solicit feedback on the redriver modeling topic, and he
had received no replies. Walter said people fell into two camps, those who
wanted dual models and those who wanted separate statistical and time-domain
models. He said it can be a complex issue, especially when it comes to
optimization, and that the original flow had pre-dated BIRD147 (back-channel
optimization). Since people in the repeater industry didn't seem to be
clamoring for a solution, it's hard to choose amongst the proposed solutions.
Michael said his group might have some feedback on this topic shortly. He said
some of the developers had strong thoughts on the ambiguities in the existing
specification, and he would try to gather the information or have them attend.
He said two fundamental questions were:
- For redrivers especially, who would want to do an Init() only model for a
redriver? A perfectly linear redriver is uninteresting and could be handled
by something like S-parameters.
- Had there been any redriver vendors who have been pushed by their customers to
deliver statistical IBIS models in the first place?
Michael said his impression was that vendors typically hadn't been devoting
many resources to developing Init only models. The non-linear effects could be
handled by GetWave() models. He said his group was very interested in
statistical mode models if they could be made accurate enough. Arpad said any
new feedback and direction would be helpful. He noted that he had recently
been hearing more from customers about redriver simulations, and he wondered if
they had encountered or were aware of any issues.
Zhiping asked if we are going to include the throughput delay of redriver in the
modeling. Michael said that a redriver is the analog-only type of repeater, as
opposed to the retimer that has a CDR and can resample. He said delay is
usually more interesting in a retimer. Zhiping said that depending on the
application, for example, two redrivers in a DDR bus, if one was on strong Si
and one was on weak Si the delay difference between the two could affect
interface timing. Walter said we're used to thinking about SERDES with
redrivers, and for SERDES you don't usually care about the delay value that
much except for wanting to minimize overall latency. Interface timing tends to
be more of an issue with parallel interfaces with separate clock and data. If
you were to have redrivers on the DQ and DQS lines of a DDR bus, that could get
ugly. However, right now we don't see that as an issue today. Arpad asked if
these delays would have to be simulated or if they'd be provided as parameters
in the model to use for post processing.
- Walter: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: None.
-------------
Next meeting: 20 October 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
