Arpad,
See comments below:
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 2:25 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Response to BIRD-190
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.
TWMK> he order of convolutions do matter if any of the blocks is not LTI.
An Rx with DFE is not LTI.
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.
WMK> Not true. It, in fact, corrects the statistical flow answers. The
time domain answers are problematic when one of the models has AMI
GetWave=False, and correct that flow by generating a correct time domain
waveform by ignoring all of the AMI GetWave.
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.
WMK> I disagree with this because of my previous comments.
Thanks,
Arpad
==================================================================
From: Walter Katz [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
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
