Arpad,
Treating DFE statistically is valid because the “DFE taps” multiply the
original digital stimulus and the CTLE/AGC taps multiply the original
signal. The trick works when the gain across the channel stays constant.
Allowing statistical analysis of channels with DFE was well understood by
SerDes designers well before AMI was introduced.
Walter
Walter Katz
wkatz@xxxxxxxxxx <mailto: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 2:51 PM
To: Bob Miller (APD) <bob.miller@xxxxxxxxxxxx>
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Response to BIRD-190
Bob,
Thanks for chiming in. Yes, I agree with this, and this was clear to me. I
was
responding to Walter’s statement about summation (for DFE) in the
statistical
flow (which I thought was supposed to be an LTI flow)…
Thanks,
Arpad
=============================================================
From: Bob Miller (APD) [mailto:bob.miller@xxxxxxxxxxxx]
Sent: Monday, June 19, 2017 1:47 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx
<mailto:Arpad_Muranyi@xxxxxxxxxx> >
Cc: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: Re: [ibis-macro] Re: Response to BIRD-190
Arpad>> I thought that in the statistical flow we only do convolutions (not
summations),
and being an LTI flow, the order of convolutions did not matter (other than
the changes
in the settings due to optimization results, if there are any). [emphasis
mine]
Arpad -
This issue in statistical flow is precisely the problem. A statistical-only
or dual model model in a statistical simulation cannot apply adaptive
equalization based on it's input if the input impulse does not contain all
of the upstream channel info, including upstream equalization. This is a
fatal limitation, at least in my case, completely apart from the "adapt in
init for getwave" dual model kerfuffle that brands such models as
incompletely dual-mode.
"just make the user apply the equalization manually" is an impossible
solution for reasons Walter has stated.
IBIS 6.1 is broken for statistical simulation of redriver channels.
Regards,
Bob
On Mon, Jun 19, 2017 at 12:24 PM, Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx
<mailto:Arpad_Muranyi@xxxxxxxxxx> > wrote:
Walter,
Regarding:
“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?”
At this point I can’t answer this question because I don’t fully understand
what you are
saying. I thought that in the statistical flow we only do convolutions (not
summations),
and being an LTI flow, the order of convolutions did not matter (other than
the changes
in the settings due to optimization results, if there are any). But I will
need to study this
some more…
Regarding:
“Does anyone disagree that we should not put into the standard any flow that
WILL give the wrong answer?”
I think no-one disagrees with that. And I think that is the reason for the
reluctance
towards BIRD166, since it introduces wrong answers in some cases which didn’t
have
the wrong answers before…
Sorry to repeat myself, but the fundamental problem I see here is that we
have
conflicting requirements, and BIRD166 alone can’t solve them all. As a
result, we go
around in circles trying to prove which BIRD would be more acceptable than
another
BIRD, while none of them really solve ALL of the problems. One person wants
to solve
this problem, the other person wants to solve that problem, and ultimately
the
argument becomes which problem is more important to solve. Since we can’t
seem
to agree on that, we keep going around in circles.
As I said before, BIRD190 doesn’t attempt to solve any technical problems,
it just
documents the current state of the art, raising awareness to the issues
which
exists in the spec. That’s better than leaving the reader/model maker
uninformed.
BIRD166 seems to try solving some technical problems, but it does so at the
expense
of introducing other technical problems, some of which did NOT exist before.
Is
that desirable? Also, if we are planning to address the problems with a
real solution
at a later time, we should be careful to NOT add “temporary fixes” to the
spec now
in a way that makes the full solution harder to add/support. I stated many
times in
the ATM meetings that I would only support BIRD166 if it can be an
incremental step
towards a complete solution added on later. I do not want to add something
to the
spec now that will have to be undone when we implement the full solution.
If you
can make BIRD166 a subset of Fangy’s “full solution” proposal, I would have
nothing
against it. I just don’t want it to get in our way later, or let it add
more varieties of
flows and unnecessary complexities.
Thanks,
Arpad
==================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx ;<mailto:wkatz@xxxxxxxxxx> ]
Sent: Monday, June 19, 2017 11:38 AM
To: 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
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
wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308 <tel:(303)%20449-2308>
Mobile 303.335-6156 <tel:(303)%20335-6156>
