[ibis-macro] Re: Response to BIRD-190

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 19 Jun 2017 16:57:30 -0400 (EDT)

Arpad,

 

Treating Rx as LTI was for statistical analysis has always been assumed by
the SerDes community prior to IBIS AMI. During the adaptation the taps
change, but once converged DFE is LTI (and as long as the upstream
equalization and amplitude does not change in time). So DFE is LTI and I
even gave a proof - takes 5 minutes at an IBIS summit close to 8 years
ago. We have always said that in the context of SerDes modeling Rx models
with DFE the IR output of these models are suitable for statistical
analysis.

 

Walter

 

Walter Katz

 <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx

Phone 303.449-2308

Mobile 303.335-6156

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, June 19, 2017 4:44 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Response to BIRD-190

 

Walter,

 

As I was looking for the quote I just sent in my previous reply, I also
found

this quote on pg. 175:

 



 

While I don't dispute that people figured out how to model DFE in
statistical

algorithms, the above statement implies quite clearly that the Init
function

was primarily intended for initialization purposes, and as a bonus it was
also

able to support LTI signal processing algorithms, but the last thing on
the

author's mind in these statements seemed to be non-LTI algorithms, and/or

optimizations.

 

While I don't dispute that really smart people were able to figure out how
to

do all these things during the years, the point is that the original
intent in the

spec did not include support for all that.  So we seem to be having a
"mission

creep" as our fearless leader MM likes to say it, and we seem to be trying
to

retrofit the spec with the new ideas, needs, revelations as they appear.
I am

afraid that the spec can only take so much of these kinds of retrofitting,
and

eventually it will crumble under the pressure of arguments over what the

original intent really was while trying to shoehorn support for new needs 

and practices into the spec.

 

Thanks,

 

Arpad

===========================================================

 

From: Walter Katz [mailto:wkatz@xxxxxxxxxx] ;
Sent: Monday, June 19, 2017 3:03 PM
To: Ambrish Varma <ambrishv@xxxxxxxxxxx <mailto:ambrishv@xxxxxxxxxxx> >;
Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx <mailto:Arpad_Muranyi@xxxxxxxxxx>

; ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: RE: [ibis-macro] Re: Response to BIRD-190

 

Ambrish,

 

We can have a debate on whether an Rx with a DFE is LTI or not. For the
purpose of doing statistical eyes, the Impulse Response generated by an Rx
that has a DFE is valid, and is commonly used in the industry for both AMI
modeling and SerDes modeling in other tools such as MATLAB, Octave,
Python, PyBERT and PyIBIS-AMI:

 

So if we constrain ourselves to Rx AMI models with just linear
equalization (e.g. CTLE), then Fangyi's argument that BIRD 166 is not
valid, since his issue is only when Rx2 has a DFE. 

 

Your statement (edited to remove the DFE part) is "The Init was never
intended for the Rx2 to be able to optimize itself based on its input
impulse response". How does the Rx know it is used at the end of a
Redriver channel? So it cannot be an Init functionality issue but a
limitation in the Redriver Flow. I certainly always intended for the "Rx2
to be able to optimize itself based on its input impulse response".

 

Walter

 

Walter Katz

 <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx

Phone 303.449-2308

Mobile 303.335-6156

From: Ambrish Varma [mailto:ambrishv@xxxxxxxxxxx] ;
Sent: Monday, June 19, 2017 3:20 PM
To: wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx> ; Arpad_Muranyi@xxxxxxxxxx
<mailto:Arpad_Muranyi@xxxxxxxxxx> ; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: RE: [ibis-macro] Re: Response to BIRD-190

 

Walter,

We know that IBIS 6.1 (not BIRD 190) fails to give the right result  when
all models have Init_Returns_Impulse=True IF AND ONLY IF when either the
Rx2 optimizes itself based on its input impulse response and/or when Rx2
has a DFE. 

The Init was never meant to do these things.

 

We have a 'Note' in the specification that documents it. BIRD 190 merely
reminds the users of the same fact in the Redriver section of the spec.

 

This issue only appears when there is Optimization in the Init or other
non LTI behavior (for which we have Getwave). 

 

So the solution to this problem can be 1 of these 2:

a.      Implement a Getwave (Model implementation) OR 
b.      Do smart sweeping to minimize the solution space (EDA tool
implementation)

and not change the specification to accommodate each and every permutation
and combination of models and simulation capabilities out there.

 

 

Thanks,

Ambrish.

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Monday, June 19, 2017 12:38 PM
To: Arpad_Muranyi@xxxxxxxxxx <mailto:Arpad_Muranyi@xxxxxxxxxx> ;
ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-macro] Re: Response to BIRD-190

 

EXTERNAL MAIL

Arpad,

 

I have demonstrated that BIRD 190 fails to give the right result  when all
models have Init_Returns_Impulse=True.

 

 

 

If any model has Init_Returns_Impulse=False, then Init processing
requires that EDA tools generate an AMI_Init proxy using AMI_GetWave
results, and in this case BIRD 190 gives the wrong answer.

 

Ambrish and Cadence have reputably stated that AMI Models should be
Init-Only or GetWave-Only. So for the case that all of the models are
Init-Only then both IBIS 6.1 and BIRD 190 give the wrong answer. 

 

IBIS is clearly deficient for channels that do not have all Dual Models
(except for the terminal Rx).

 

BIRD 190 only re-affirms the fact that IBIS 6.1 give the wrong answer for
statistical flow in Redriver channels since it requires that the upstream
equalization is applied to the output of Rx2, not the input of Rx2.

 

Do you disagree with my proof that BIRD 190 and IBIS 6.1 gives the wrong
answer for statistical flow in this case when all of the models have
Init_Returns_Impulse=True?

 

Does anyone disagree that IBID 6.1 and BIRD 190 give the wrong answer for
statistical flow in this case when all of the models have
Init_Returns_Impulse=True?

 

Does anyone disagree that BIRD 166 gives the right answer for statistical
flow in this case when all of the models have Init_Returns_Impulse=True?

 

Does anyone disagree that we should not put into the standard any flow
that WILL give the wrong answer?

 

If we cannot get agreement on this, we should simply table BIRD 166 and
BIRD 190. I think we have clearly document the problems in IBIS 6.1, that
the IBIS 6.1 Redriver flow gives the wrong answer when either the Rx2
optimizes itself based on its input impulse response and/or when Rx2 has a
DFE.

 

Walter

 

Walter Katz

 <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx

Phone 303.449-2308

Mobile 303.335-6156

From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, June 19, 2017 11:54 AM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-macro] Re: Response to BIRD-190

 

Walter,

 

Thanks for your comments.  Regarding the last two bullets of your summary,

*       The flow in BIRD-166 does allow the Rx2 to optimize itself
correctly.
*       The flow in BIRD-166 give the right results.

These statements are only true when we have "all Init-Only or Dual models"

in the simulation, as you stated in your introductory sentence.  As you
may

recall, the discussions we had in the ATM meetings revealed that we did
not

think that imposing such requirements on model makers would be feasible.

The discussions also revealed that the proposed solution in BIRD166.x
makes

certain other model combinations worse, and as long as those combinations

are allowed, the proposal in BIRD166 is unable to address the conflicting

requirements for all model combinations.

 

This is why Ambrish ended up submitting BIRD190.  It does NOT attempt to

solve the challenges we are facing, it only documents the situation in the

redriver section of the specification so that the reader would be reminded


to the issues at hand. 

 

It seems that in order to solve these problems, we would either have to

have a "full solution" along the lines of Fangyi's proposal, or allow only

Init-only, GetWave-only or Dual models together with the proposal in

BIRD166, but the latter didn't seem to be an option based on the
discussions

we had in ATM.

 

I would very much like to make a decision on this soon, since we are
starting

to go around in circles in discussing this topic.

 

Thanks,

 

Arpad

============================================================

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Sunday, June 18, 2017 6:24 AM
To: Ambrish Varma <ambrishv@xxxxxxxxxxx <mailto:ambrishv@xxxxxxxxxxx> >;
ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-macro] Re: Response to BIRD-190

 

Ambrish,

 

Got time to review my response to BIRD 190, and would like to correct what
I wrote. Changes made in line. 

 

Walter

 

 

Ambrish,

 

Can you please comment on the following statements.

This discussion is limited to statistical simulations of Redriver channels
with Tx1, Rx1, Tx2, Rx2 all Init-Only or Dual models. 

 

1.      BIRD 190 states: 

a.      The impulse response of the Rx2 model will not include all of the
effects of the upstream equalization, and therefore the Rx2 AMI_Init will
not be able to perform an accurate equalization, and therefore to ensure
successful simulations, the user should be allowed to turn off any
automatic equalization in Rx2.

2.      As Fangyi so aptly demonstrated, the Rx2 equalization will include
two parts, one is a scaling (LTI) part from a CTLE and AGC, and the second
an additive part (non-LTI) from a DFE. 

a.      If the part of the upstream equalization that is excluded in the
input to Rx2 (as specified in IBIS 6.1 and BIRD 190) is convolved with the
output of Rx2, then both the CTLE and DFE equalization will scale this
part of the upstream equalization
b.      If this part is not excluded from the input to the Rx2 then only
the CTLE scales the effects of the upstream equalization.
c.      In case 2.a. the DFE is (incorrectly) added twice

3.      For those of us that find this argument unconvincing, then
consider the solution space that the user must explore to find a "best"
solution if automatic optimization is disabled as proposed in BIRD 190. 

a.      Let us assume that the user has set all of the upstream
co-efficient to their optimum setting, and the Rx2 automatic equalization
is turned off by the user in accordance with BIRD-190.
b.      How many simulations would the user be required to run to find the
"best" solution.

                                                               i.
Case 1

1.      Assume that the Rx2 model has the following controls (typical
PCIeG4, IEEE 802.3bj)

a.      10 CTLE settings
b.      10 AGC settings
c.      4 DFE taps each having 10 tap setting

2.      The answer is 10^6 simulations

                                                             ii.      Case
2

1.      Assume that the Rx2 model has the following controls (IEEE 802.3
400Gj)

a.      10 CTLE settings
b.      10 AGC settings
c.      14 DFE taps each having 10 tap setting

2.      The answer is 10^16 simulations

b.      It is a requirement of our customers that our tool determine the
AMI settings that give the "best" solution. Sweeping these setting in the
Rx2 as BIRD-190 requires is unacceptable.

 

In conclusion:

*       The flow in IBIS 6.1 does not allow the Rx2 to optimize itself
correctly.
*       The flow in IBIS 6.1 gives the wrong results even when Rx2
optimization is turned off.
*       The flow in BIRD-190 does not allow the Rx2 to optimize itself
correctly.
*       The flow in BIRD-190 give the wrong results even when Rx2
optimization is turned off.
*       The flow in BIRD-166 does allow the Rx2 to optimize itself
correctly.
*       The flow in BIRD-166 give the right results.

 

Walter

 

 

PNG image

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 06-2017