Minutes from the 16 February ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 16 February 2021
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
Alaeddin Aydiner
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
Ming Yan
Todd Bermensolo
Rui Yang
Luminous Computing David Banas
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:
- Arpad noted Item #8 on the Agenda, PI modeling/simulation in IBIS, and said
Professor Chulsoon Huang from MS&T will present on the topic at next week's
meeting. Randy said that Chulsoon and Zhiping Yang had been working on a BIRD
draft and shared it with Randy and Bob.
-------------
Review of ARs:
- Fangyi to email his updated redriver flow BIRD draft and mention the question
about whether to update the regular flows as well.
- Done.
- Arpad and Ambrish to suggest a better name for Use_New_Flow.
- Not Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the February 9th
meeting. Randy moved to approve the minutes. Lance seconded the motion.
There were no objections.
-------------
New Discussion:
Redriver Flow Issues:
Fangyi shared his updated redriver flow BIRD draft. He noted that he had made
the changes suggested at the previous meeting including Arpad's editorial
suggestions.
Arpad said he thought the main question remaining was whether we should extend
the proposed fixes from the redriver flow to the regular flows as well. Arpad
recalled that he had been in favor of doing it all at once, but Ambrish had not
been so keen to tackle the regular flows. Ambrish said he had re-read the
existing AMI flows in IBIS 7.0, and they are complicated with many combinations
(e.g., 6a, 6b, 6c, 6d in the time-domain reference flow). He said his fear was
that if we decide to tackle the regular flows it will take a lot of time to make
sure they are all accurate. There are lots of details. Fangyi said that if we
addressed the regular flows with the new fixes, we could remove several
paragraphs regarding the cases where deconvolution might be necessary. Ambrish
agreed. Fangyi said that 6a, 6b, 6c, 6d, themselves would all be gone as well,
so this proposal would actually simplify the flow descriptions.
Walter said his group had carefully reviewed the BIRD, and they thought we were
trying to do several independent things all at once. One issue the BIRD was
trying to address was eliminating the need for deconvolution. Walter said this
would never be a problem in the first place if all models were Dual models. He
said Init-Only models get us into the trouble with the need for deconvolution,
and there's really no excuse for a model maker producing an Init-Only model.
Any Init-Only model could easily provide a GetWave that applied the same
equalization. Walter said the portion of this BIRD proposal dealing with
deconvolution could be broken off into a separate BIRD, but he might object to
that BIRD because model makers should just create GetWave in all their models.
The other issue the BIRD proposal is trying to address is the redriver flow.
However, Walter said the proposal is unnecessarily complicated. He said the two
new columns, which take the cumulative upstream IR as input and return the IR
of the equalization respectively, are unnecessary. He said BIRD166 provided a
simpler approach that fixed the redriver flow and did not require modifying the
footprint of AMI_Init. He noted that the new BIRD proposal does not change the
function signatures per se, but it does change the IR matrix data passed into
Init and would necessitate changes by EDA tools.
Fangyi said the issue he had originally noted with BIRD166 was that it did not
handle crosstalk properly. He said he had extended the approach to create this
new proposal that does address crosstalk properly. The new columns are required
additions to the original IR matrix so that the EDA tool will have the IRs of
all the possible channel sections and therefore all the possible crosstalk path
combinations. Walter said he thought the basic redriver flow could be handled
with a simpler BIRD166 type approach, and crosstalk could be addressed as a
separate BIRD. Arpad asked why we would want to separate the crosstalk flow
from the base redriver flow. He said if the EDA vendor is dealing with updating
their existing flows, then they need to consider crosstalk as well. Fangyi
agreed and said that was why he addressed both with his proposal.
Arpad again asked if we wanted to address the normal flows at this point.
Fangyi said that for him it was just a question of adding a few more paragraphs,
or we could separate the topics, finish the redriver flow first, and then come
back to the normal flow later. Arpad said he was inclined to do it all at once.
Ambrish said he was concerned that we would then be changing too many things at
once.
Randy asked if people wanted this BIRD to be considered for IBIS 7.1. Walter
said he hadn't seen a lot of interest in redriver models, and that the big thing
these days was higher speed devices like 112Gbps and 256Gbps, and the channels
were short so there were no redrivers. He said this proposal would create a lot
of work for EDA companies, and it was largely academic since crosstalk often
wasn't important in redriver simulations. He thought there was no rush for this
and said he wouldn't support putting it in 7.1.
Michael M. said they did see some requests for redrivers, typically for PCIe.
He said the speeds may not be 112Gbps, but they're getting up there. People are
often interested in backward compatible devices and reduced cost tradeoffs
between redrivers, retimers, etc. Simulation can help with tradeoff analysis.
Arpad asked how close we were to being finished with this BIRD draft if we don't
get involved with fixing the regular flows. Ambrish asked, aside from this BIRD
how many weeks did we think we had until we decided what went into 7.1? Randy
said we would be reviewing BIRD202.2 again at the next Open Forum meeting on
February 19th, and we could conceivably schedule a vote on it at the following
Open Forum meeting. He said anything introduced after Friday the 19th would
likely affect the schedule, though we could start editorial work on things that
we knew would be approved.
Radek said that if we did not make the changes to address the regular flow, then
he thought the BIRD draft was ready to go. Arpad agreed and said we could leave
it to Fangyi. Fangyi said he was ready to submit the proposal if we decided not
to address the normal flow. Arpad asked if anyone was opposed to Fangyi
submitting his current proposal to the Open Forum as an official BIRD before
Friday's Open Forum meeting. Walter said he was opposed, and he asked that his
name be removed from the list of authors. Arpad said we would leave it up to
Fangyi to decide whether or not to submit his proposal, since there's no
requirement to get approval from ATM or any other task group before a person
submits a BIRD.
- Ambrish: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 23 February 2021 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
