Arpad, One more thing. What you presented yesterday was a flow chart for section 2.3. We should look at this section in conjunction with 2.1 and 2.2 and not a standalone section by itself. If we do that, then what you presented makes sense (with one slight correction). Thanks, Ambrish. -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Wednesday, April 21, 2010 12:37 AM To: IBIS-ATM Subject: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference That's exactly what I presented in the flow diagram I prepared for today, but we are still not in agreement. The comments we are getting from Walter indicate that the entire flow is flawed and he suggests to go back to the flow we finished in November. The comments we are getting from Kumar and Ken indicates that they would prefer to further simplify the flow, not allowing for the dual nature of LTI and non-LTI coexisting together in the same model. How shall we resolve this disagreement? Arpad ======================================================== -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma Sent: Tuesday, April 20, 2010 11:27 PM To: IBIS-ATM Subject: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference Arpad, What Kumar, Ken and I are trying to say (along with a few others, I believe) is that the flow, as described in section 2.1, 2.2 and 2.3 of chapter 10, works, and the only clarification (correction) that is needed is the Tx_Getwave issue. Adding any other flow is unnecessary and will add to more confusion. It will also go against the main goal of the ATM committee as set by you. Regards, Ambrish. -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Tuesday, April 20, 2010 11:23 PM To: IBIS-ATM Subject: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference Kumar, I heard this from you and Ken and others before, and I have already responded to it more than once that making a change of this nature is a "new feature" as far as the specification is concerned, so I am simply not going to entertain the idea, at least not with this BIRD and this discussion. Arpad ========================================================= -----Original Message----- From: ckumar [mailto:ckumar@xxxxxxxxxxx] Sent: Tuesday, April 20, 2010 8:59 PM To: Muranyi, Arpad Cc: IBIS-ATM Subject: Re: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference Sigrity is of the view models employing getwave preferabley should be using init only for parameter passing. This will greatly simplify the flow, minimize confusion and more importantly will not potentially result in the problem of the same model yielding two different results. A useful analogy is getwve vs init similar as silicon vs behavior circuit models --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: //www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: //www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: //www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: //www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe