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>
Cc: 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>
