Fangyi, I am sorry but I don't quite understand the second half of your 1st sentence (after the word "because") because there is some problem with English in it and I am not sure what you mean. Please clarify it. Regarding the 2nd sentence about assuming that Rx Init modifies the input, I am not sure how that makes a difference, since the convolution #2 box seems to be there to do that modification in case the Init function didn't do it. (This is also true for the Tx Init function and the convolution #1 box). The question that we didn't seem to address in the November flow is what Init will return when Init_Returns_Impulse is False. This is not shown on the drawings and I can't find anything in the current spec that says what is returned in that case. If it returns what goes into it, then this setting may be a duplicate of the Use_Init_Output = False setting, at least as section 2.3 describes that in the current spec, unless we meant to distinguish how the Init Output is passed to the GetWave functions vs. the next Init function, but this is not spelled out in the spec either as far as I can tell. Or does it mean that it should return nothing (i.e. uninitialized memory, or noise)? Or should it mean that it should return the filter only? (In that case we do not need the new Init_Returns_Filter Boolean). This must be defined because it fells like we have another loose end dangling here. Regarding de-convolution, I thought the reason we added the Init_Returns_Filter Boolean was to eliminate the need for de-convolution. As far as I can tell, according to the November flow de-convolution would only be needed with older models which do not have the ability to return filter only to the EDA tool. This would hopefully die out as new models come into existence and old models fade away. Thanks, Arpad ===================================================================== -----Original Message----- From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx] Sent: Wednesday, April 21, 2010 9:36 PM To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference Hi, Arpad; Moving the Selector to the right side does not save time-domain simulation because it makes the modified impulse returned by Rx Init based on the modified impulse returned by Tx Init and Tx Use_Init_Output is False. Moreover, you can't assume that Rx Init modifies the input impulse by convolving it with a filter. In my opinion (I pointed out last year) the November flow does not really address this issue. It works only if above assumption is true. In addition, de-convolution is still required in certain cases in the November flow. Regards, Fangyi -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Wednesday, April 21, 2010 7:08 PM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference Fangyi, Thanks for your comments. I agree with your observations. In fact this is why Walter was right when he wrote in his recent comment that the Tx Init Output Selector box on my latest drawing should be on the right side instead of the left side. That way both statistical and time domain simulations would be correct without having to sacrifice either one of them over the other. The problem is that making that change would deviate from the flow in more than just changing the order of steps 4 and 5 as described in the existing specification in section 2.3 and it would also bring us back to the issue of having to do a deconvolution for certain configurations, which is why it was suggested to me to move that selector to the left side a week ago. I am beginning to see why Walter said that the entire flow is flawed in the existing specification... The more I push and shove the blocks around in this flow diagram, the more I feel that the November flow is the right way to go. It seems that we have already figured it all out in the fall how to do this right, and no matter how hard we try to be minimalistic in fixing the spec, the best way to do it is as described in the November flow. Thanks, Arpad ==================================================================== -----Original Message----- From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx] Sent: Wednesday, April 21, 2010 8:32 PM To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference Hi, Arpad; In the current BIRD only section 2.3 defines the control of Tx Use_Init_Output on input impulse response to the Rx Init call. The excerpt quoted in Walter's email is actually for the control of input waveform to the Rx GetWave call. Your flow presented in the last meeting is consistent with section 2.3. A key difficulty arises from the condition when Tx has GetWave, Tx Use_Init_Output is False and Rx Use_Init_Output is True. If the input impulse to Rx Init is the original impulse input to Tx Init, then the time-domain bit-by-bit simulation is fine but the statistical simulation is broken. If the input impulse to Rx Init is the modified impulse returned by Tx Init, then the statistical simulation is fine but the time-domain simulation is broken. Given the fact that time-domain simulation captures more effects of nonlinear models, it seems we should give it higher priority over statistical simulation. Regards, Fangyi --------------------------------------------------------------------- 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