[ibis-macro] Minutes from the 06 April ibis-atm meeting

  • From: Curtis Clark <Curtis.Clark@xxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 12 Apr 2021 19:14:13 +0000

Minutes from the 06 April ibis-atm meeting are attached.



The documents discussed during the meeting 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=04%7C01%7Ccurtis.clark%40ansys.com%7Ca8cb7b0d3e6043897ada08d8f86b8fba%7C34c6ce6715b84eff80e952da8be89706%7C0%7C0%7C637532488764137761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=tzpLerIAQrONVz%2BWu2%2Fj1QfAqQ1EcG7DTKOYB4FbQKU%3D&reserved=0>

IBIS Macromodel Task Group

Meeting date: 06 April 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
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
Siemens EDA (Mentor):       * Arpad Muranyi
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:
  
- None.

-------------
Review of ARs:

- Curtis to send out amended minutes from the March 23rd meeting.
  - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the March 30th
meeting.  Walter moved to approve the minutes.  Michael seconded the motion.
There were no objections.

-------------
New Discussion:

Clarification of PAM4 Thresholds:
Hansel introduced a BIRD draft he had prepared to address the possibility of
confusion when the PAM4 threshold parameters interact with the DC_Offset
parameter introduced in BIRD197.7.  He noted Randy's presentation on a single-
ended PAM4 technology, GDDR6x.  Hansel's draft augments the Usage Rules for the
thresholds by adding the qualifier "zero voltage-centered":

    "... when the zero voltage-centered signal is sampled:"
    
Walter said this became an issue when DC_Offset was introduced.  We're looking
at the input to a differential receiver, so the waveform is more or less
centered at 0V, and to convert to single-ended you add back in the DC_Offset
value.  What's meant here in Hansel's change is to make it clear that the
thresholds apply to that "differential" waveform without the DC_Offset.

Michael said that as an editorial issue it might be helpful for us to develop
some boilerplate language for dealing with DC_Offset and single-ended vs.
differential waveforms in AMI, as he suspected there would be other places
where DC_Offset interacted with existing language in the specification.

Walter said he thought we all agreed on the intent of Hansel's language change.
There were no objections.  Bob said he thought the proposal, as shown, included
too much of the existing specification.  He and Arpad said the BIRD could be
reduced to quoting the page number in IBIS 7.0 and listing the Usage Rules:
introductory sentence before and after this change (the addition of "zero
voltage-centered").  Walter agreed and said the existing proposal contains the
proper explanation of the justification for the change, and that should stay.
Walter moved to recommend that Hansel submit this BIRD, with the noted changes,
to the Open Forum for potential inclusion in IBIS 7.1.  Bob seconded.  There
were no objections.

BIRD210 and BIRD211:
Walter shared a new "BIRDs_210_211" presentation.  He noted that it was what he
had shared at the previous Friday's Open From meeting, except that he had added
three new slides.

slide 12: BIRD210 Flow
Walter had added some additional notations to Fangyi's BIRD210 Flow slide.
  Note: Nomenclature used in these minutes
    column 1 - legacy column 1, first white boxes in the slide
    column 2 - legacy aggressor(s), second white boxes in the slide
    column 3 - first new column proposed in BIRD210, first blue boxes
    column 4 - second new column proposed in BIRD210, second blue boxes.

Walter said he'd added the "Latch" box at the Rx2 column 3 output, and Fangyi
agreed this was the latch.  Walter observed that the Rx2 column 1 output was
not used, and Fangyi said it provides the response of the nearest upstream
channel section and can be used by the EDA tool to construct crosstalk paths.
Fangyi said the two "X" boxes Walter had added (legacy column 1 outputs of Rx1
and Rx2) represent the impulse response of each section of the channel, so the
EDA tool can use them to construct all crosstalk paths.  Walter asked to defer
crosstalk discussions until later.  Walter then observed that for Rx1 the output
in columns 1 and 3 are identical.  Fangyi agreed.

Walter noted the "Ch1" box he had added after the output of Tx1 column 3.  He
asked the rhetorical question: whether the column 3 input to Rx1 was the Tx1
column 1 output or the Tx1 column 3 output convolved with Ch1.  Fangyi agreed
that the two options were identical, and the EDA tool could choose.  Walter then
acknowledged that he had proposed using the unit impulse response as a crosstalk
column as a "trick" to eliminate the need for column 4.  However, he said he
agreed that the column 4 information (filter response) is necessary for certain
crosstalk applications and for avoiding deconvolution when using Init Only
models in time domain.  Fangyi agreed and said he had made this a formal column
in his BIRD210.

slide 13 - Compromise flow
Walter then discussed some changes to BIRD210 that would result in a BIRD he
would support.  First, he suggested that column 4 (filter response) be made
optional and its use indicated by a new Init_Returns_Equalization parameter.  If
this parameter is true then the column is added.  It has nothing to do with
redriver flow or any special case, and it's useful for any Init Only model.

Second, Walter said that once you have the (optional) filter response column
information, all the "X" outputs noted on slide 12 could be computed by the EDA
tool using existing information and the filter response(s).  So, there's no
need to preserve the legacy flow information in column 1.  Fangyi agreed.
Walter then suggested that there is no need for the information flow in the
legacy column 1, and that the information flow in column 1 should be replaced
by that in column 3 (i.e., column 1 would then contain the cumulative upstream
response information that is in the first new column of BIRD210).

Walter said this new flow would work for every model except for a Tx that wants
to optimize based on its downstream channel.  So, he proposed that we only add
the additional "downstream" response column for Tx models, and that it be
optional and controlled by a new Tx_Requires_Downstream_Channel parameter.  He
said only Tx models that want to optimize based on the downstream channel would
need this optional column.  He said it's useful for some models for optical
devices.

Ambrish noted that Walter's proposal to change the information in the legacy
column 1 was changing the flow for everything, not just redriver simulations.
Walter agreed there was a change to the input to the primary Tx (Tx1).  He said
that whether you pass in the downstream channel (legacy), or pass in a unit
impulse response and convolve the output with the downstream channel, you get
the same answer unless the Tx optimizes itself.  Fangyi said that if we adopt
this approach, we should be certain we know how many existing Tx models optimize
based on the downstream channel.  Walter said he was only aware of one existing
Tx model that had ever tried to optimize based on its downstream channel, and he
said that feature of the model had failed to work properly.  It typically over-
equalized the channel and messed up the Rx's DFE.  Fangyi was aware of the
model Walter described, and he said the group that produced it is now part of a
different company.  He suggested we reach out to them to see if they are still
producing models like this.  Walter agreed to investigate.  He said only such
legacy models would be a problem and need to be rewritten.  He said the new
optical device models that are being developed could specify the new parameter
and use the extra downstream column.  Only these models need to be burdened
with the new parameter and new column.  He noted that models for these devices
would not work at all with the existing flow because they'd have access to the
downstream information but not the upstream information.

Radek said this still seemed to be an incomplete solution and sort of a hack.
He disliked the "if" conditionals.  "If the Tx model outputs its equalization
then the EDA tool can construct other quantities with convolution...", and the
problem is the "if".  Fangyi restated Radek's concern by noting that column 4
in BIRD210 is not optional.  It's mandatory, especially if you cascade redrivers
and need to reconstruct sectional responses.  Walter said the tool has other
options if the optional Init_Returns_Equalization parameter were not provided.
It could pass in the unit IR as a crosstalk column, and the model is obligated
to return its filter response.  He said that trick only causes a problem if the
model is using crosstalk to determine its equalization.  So, to run into any
trouble you'd need a model that is optimizing based on crosstalk, that is Init
Only, that doesn't provide the new optional column, and doesn't automatically
exclude a unit IR crosstalk term when it's optimizing.  The model should not do
all of those things.

Walter summarized his issue with the existing BIRD210.  He said if a Tx2 needs
to know its downstream response, then BIRD210 requires the primary Tx and
terminal Rx also be rewritten to support the new flow.  He said the Tx1 and Rx2
don't care about the extra information.

Walter summarized his proposed changes.  The information in column 3 is moved to
column 1.  We only add an optional new downstream IR column to Tx models that
want it.  We add a new optional extra column for the model to use to return its
filter response.  The use of the new optional columns is controlled by two
independent new parameters.  With this people can write models that handle all
the new features but can still work well with legacy models.

Arpad asked how much mixing there would really be between new models requiring
the new features and legacy models.  Walter said that if the flow doesn't
support legacy models then we shouldn't bother.  He said it would be a bad idea
to force perfectly good legacy models for the initial Tx and terminal Rx to
change to support a redriver flow.  Arpad said he understood, so he asked Fangyi
if he thought it was possible to revise the BIRD210 flow such that only redriver
(Rx1 and Tx2) models' Init functions needed changes relative to legacy models.
Fangyi said the terminal (primary) Tx doesn't need the additional columns, but
he had to think more about whether the terminal Rx does.

Radek expressed concern that if we try to define the Rx1 and Tx2 as behaving
differently and having different information in their IR matrices than the
terminal Tx1 and Rx2, then we are creating entirely new types of Tx and Rx
models, and this may not be a good idea.  Walter said he agreed, and he noted
that his proposed changes were symmetric, so Tx1 and Tx2 had the same options
and Rx1 and Rx2 had the same options.  Arpad said it would still be nice if
we could come up with something where only the problematic redriver models
in the middle are altered.

- Walter: Motion to adjourn.
- Michael: Second.
- Arpad: Thank you all for joining.

AR: Walter to investigate whether any model vendors are generating legacy Tx
    models that optimize based on their downstream channel.
AR: Walter to send out his new BIRD210 vs BIRD211 compromise presentation.

-------------
Next meeting: 13 April 2021 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 06 April ibis-atm meeting - Curtis Clark