[ibis-macro] Re: Question about cross talk with AMI models

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Sun, 27 Jun 2010 23:08:48 -0700

Walter,
 
I will answer your email paragraph by paragraph, indicated by
a letter "p" for "paragraph" (not page).
 
p1)  I know that the Rx AMI_Init function needs a modified
channel impulse response from Tx AMI_Init for its optimizer
(if it has any).  This is what the second input to Rx AMI_Init
is doing in my latest proposed flow.  It is there in the
proposed flow, it works exactly the way you want it to work.
 
p2)  Regarding analog vs. digital input, I thought the issue
was the input to Tx GetWave, not to Tx AMI_Init.  You are
now talking about Tx AMI_Init.  I hope this is only a typo...
Assuming it is a typo, my proposed flow addresses this also.
Read Section 2.4 Step 5 in the proposed BIRD (Flow_BIRD_2e.pdf).
So by fixing this and by fixing the Use_Init_Output logic
in the proposed flow, we should end up with a logical spec,
correct?
 
p3)  That is not stated anywhere in the spec or BIRD 107.
SiSoft was a co-author of both...  In this area I tend to
agree with Bob, that slapping together a specification in a
big hurry tends to result in a lower quality spec and we 
are reaping the consequences of that.  I am not saying that
I enjoy dragging out the discussions and argue over
meaningless topics, but certain things must be hammered
out and written down unambiguously in the spec.   We can't
expect people to guess what was going through the minds
of the authors years later from ambiguous text to find
out what the intent was...
 
p4)  My proposed flow does exactly that.  Please look at
slides 1-4 and 5-8 and tell me if you see any difference
in the way I drew the Rx AMI_Init box.  I might need
better glasses, but I don't see any differences, and while
my memory is not perfect at times, I don't recall drawing
them differently either...
 
p6)  I am not proposing what you say I propose.  Please
spend a little more quality time with the flow diagrams
and the draft BIRD in which I think I made it crystal clear
what I am proposing.  (In my latest flow and BIRD draft
the input of your Rx model doesn't depend on how the Rx
GetWave function is written, and there is no mention of
a Dirac-Delta function anywhere in my documentation.
I just had to stop to think to spell it right...).  But
in case I didn't succeed in getting across what was in
my mind at the time I wrote it, please point out the areas
which need better wording or drawing.
 
p7)  Both of those issues have been addressed in my latest
flow proposal and BIRD draft.  It is stated in Note #2 in the
flow diagram and also in the BIRD draft that when GW = F both
IRI and UIO must be T.  This is effectively the same as ignoring
UIO, because when you ignore it you actually act as if it was
set to TRUE.  And the input to Rx AMI_Init always gets the
modified Tx AMI_Init output in the second impulse_matrix,
regardless of whether you are in a statistical simulation or
time domain simulation or what the settings of the Boolean
switches are.
 
p8)  I don't see why you feel that you have to write another
BIRD, since you have not mentioned anything yet about my latest
flow proposal and BIRD draft that doesn't work correctly with it.
 
However, if you feel compelled to write one, you are certainly
welcome to do so.  Considering our track record, I predict that
it might take another few months to discuss it, which I expect
will get all the IC vendors even more turned off regarding what
is going on in the ATM meetings.  On the other hand, if you feel
confident about it, you may submit it to the IBIS Open Forum
directly.
 
Sincerely,
 
Arpad
=================================================================
 
 


________________________________

From: Walter Katz [mailto:wkatz@xxxxxxxxxx] 
Sent: Sunday, June 27, 2010 1:37 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Question about cross talk with AMI models


Arpad,
 
The whole logic of the existing 2.3 is flawed, period end of story. In
order for an Rx Init function to properly work, it must have the impulse
response of the channel modified by the Tx equalization, if available.
There can be no other logical explanation. How else is an Rx Init
function to optimize itself? We always new the logic in 2.3 was flawed,
and we repeatedly said so during the discussions of BIRD 107.
 
Yes the current spec is incorrect and is in error, deprecation does not
mean that there cannot be errata, and this is currently errata material.
The existing 2.3 is clearly full of errors because of the introduction
of the analog instead of digital input to Tx Init. Complicating this
fundamental error in IBIS 5.0, the logic of Use_Init_Output was put into
the flows in a totally illogical way to because analog input to Tx
GetWave was totally illogical to begin with.
 
When Use_Init_Ouput was introduced, it was only to be used when
GetWave_Exists was True. It had no meaning when GetWave_Exist was False!

 
Please remember that when Rx Init is being called, it does not know if
it is being used in a statistical flow or in a time domain flow. Since
it does not know what flow the EDA tool is attempting, it must behave
identically the same way in both cases; it must have the same inputs and
the same outputs.
 
Let me give you a simple gedankenexperiment.
 
Suppose I had a channel with an hAC(t) with significant loss and
impairments. I can easily create a Tx model that will absolutely correct
for all channel impairments, and the output of the Tx model will
generate a perfectly equalized waveform at the Rx input. (No, this will
not make me rich, I can create a Tx model in C++, but implementing this
in silicon is another story.) You propose that in some cases (depending
on how the Rx GetWave is written, and what flow I choose to make), the
input to my Rx model will either be hAC(t), or a Dirac-Delta function. 
 
So the error in IBIS 5.0 (and it is an error that needs to be
corrected), is that if GetWave_Exist is False, the EDA tool is
instructed to ignore the value of Use_Init_Output, and the input to Rx
Init must always be the channel modified by the Tx equalization (i.e.
the output of Tx Init). 
 
You leave me no other choice then to prepare an independent BIRD to deal
with this.
 
Walter
 
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com

Other related posts: