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