Taranjit, One of the main reasons for BIRD120 to "take away the flexibility by isolating init and getwave" is because passing the IR to Tx_Getwave does not work for non-linear drivers. This practice had been deprecated in BIRD120. The differences between the two reference flows (IBIS 5.0 vs. BIRD120) have been analyzed in the IBIS Quality presentations dated 17-AUG-2011 and 06-SEP-2011, archived at http://www.eda.org/ibis/quality_wip/archive-date.html The diagram in your original email does not comply with either IBIS 5.0 or IBIS120. "IR" should not be convolved with TX_Getwave output. In order to achieve what you need to do, the chip-RDL-routing IR should be incorporated into the analog channel IR (aka hAC(t)) and, the rest of the reference flow as specified in BIRDF120 should work fine without problem. The existing specification (BIRD120 to be adopted by IBIS5.1) has already achieved what you asked for in the last two paragraphs of your original email, which had been explained in detail in above presentations. James Zhou From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Taranjit Kukal Sent: Thursday, June 14, 2012 8:56 AM To: 'twesterh@xxxxxxxxxx'; 'ibis-macro@xxxxxxxxxxxxx' Subject: [ibis-macro] Re: AMI-init should pass modified IR to getwave.... Hi Todd, That is why RDL IR is to be convoluted with channel to get overall IR. And I would have loved to pass this to EDA tool that provides me resultant wave in getwave for further processing (as against doing my own sampling and convolution in getwave) Somehow, it is not very convincing that we take away the flexibility by isolating init and getwave. The only reason I see for deprecating “Use_Init_Output” was to allow statistical flow to work independently ...was there any other reason that I am missing? If not, then we should have had two IR outputs to EDA tool from Init - one for statistical and one for further getwave processing (at the same time allowing IBIS5 compatibity) Rgds From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx] Sent: Thursday, June 14, 2012 08:13 PM To: Taranjit Kukal; ibis-macro@xxxxxxxxxxxxx <ibis-macro@xxxxxxxxxxxxx> Subject: RE: [ibis-macro] Re: AMI-init should pass modified IR to getwave.... Tananjit, This therefore violates the basic assumption of AMI … that the channel is fully described in the impulse response passed to TX_Init. Attempting to model the RDL after the fact in the algorithmic model will eliminate any of the reflections / ISI caused by the interaction of the RDL with the channel. The RDL needs to be part of the channel model used to generate the impulse response. Todd. Todd Westerhoff VP, Software Products Signal Integrity Software Inc. • www.sisoft.com<http://www.sisoft.com/> 6 Clock Tower Place • Suite 250 • Maynard, MA 01754 (978) 461-0449 x24 • twesterh@xxxxxxxxxx<mailto:twesterh@xxxxxxxxxx> “I want to live like that ” -Sidewalk Prophets From: Taranjit Kukal [mailto:kukal@xxxxxxxxxxx] Sent: Thursday, June 14, 2012 10:37 AM To: 'twesterh@xxxxxxxxxx'; 'ibis-macro@xxxxxxxxxxxxx' Subject: Re: [ibis-macro] Re: AMI-init should pass modified IR to getwave.... Hi Todd, Your description of RDL is correct. Rx is at the buffer i/p so RDL essentially becomes additional channel. Rgds From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx]<mailto:[mailto:twesterh@xxxxxxxxxx]> Sent: Thursday, June 14, 2012 07:09 PM To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>> Subject: [ibis-macro] Re: AMI-init should pass modified IR to getwave.... Taranjit, When you say “On chip RDL”, are you specifically talking about the interconnect between the die pad and the buffer itself? Where is the receiver termination physically taking place? Todd. Todd Westerhoff VP, Software Products Signal Integrity Software Inc. • www.sisoft.com<http://www.sisoft.com/> 6 Clock Tower Place • Suite 250 • Maynard, MA 01754 (978) 461-0449 x24 • twesterh@xxxxxxxxxx<mailto:twesterh@xxxxxxxxxx> “I want to live like that ” -Sidewalk Prophets From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]> On Behalf Of Taranjit Kukal Sent: Thursday, June 14, 2012 2:04 AM To: 'IBIS-ATM' Subject: [ibis-macro] AMI-init should pass modified IR to getwave.... Hi All, When I was implementing AMI model, I found a situation where it was important that Rx ami_init needed to pass modified-IR to getwave function. Reason was that Chip-RDL-routing was available as Impulse-Responses. Removal for “Use_Init_Output” to make Statistical-flow independent of Transient-flow, is going to break the original intent where init and getwave were supposed to work in conjunction with each other handling linear and non-linear filtering portions respectively (as shown below) [cid:image002.png@01CD4A17.64816FC0] I would go back to Arpad’s suggestion (year 2010) for having two Impulse-responses coming out of ami_init - One that goes to EDA tool for statistical flow - One that gets passed to getwave to allow splitting of modeling-effort across init and getwave and make things easy for linear filters. BIRD120 was brought up that deprecates use of “use_init_output” with a view to keep statistical and time-domain simulations independent. But as I think more, we need to allow both capabilities. It absolutely does not make sense to implement simple linear filters within getwave when we can convolute the filter-IR with channel-IR. We should take all steps to make modeling easy and ensure enough flexibility. This way, we cover both the scenarios – those who want to leverage init as complement to getwave and those who want to keep statistical-flow purely independent. Since this does not bring any disadvantage, I strongly feel that we all re-consider outputting two modified-IRs out of init function – one for statistical-flow and another one to complement getwave filtering. Rgds ..kukal ________________________________ This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.