Ken, In summary, it will be legal to have a channel with the Tx and Rx being independently either Init only, GetWave only, or dual (9 cases). With Dual models the user/EDA tool can determine whether to use simple flows or value added flows. The basic principles for "Model Writers" is as follows: Tx Init expects as its input the impulse response of the channel. Tx Init will return the impulse response of the channel modified by the Tx Equalization if Init_Modifies_Impulse is True. If Tx Getwave exists: Tx Getwave expects as its input a digital stimulus waveform. Tx Getwave will return the stimulus waveform modified by the Tx Equalization (which may not necessarily be LTI). Rx Init expects as its input the impulse response of the channel modified by the Tx Equalization (output of Tx Init) Rx Init will return its input (output of Tx Init) modified by the Rx Equalization if Init_Modifies_Impulse is True. If Rx Getwave exists Rx Getwave expects as its input the output of Tx GetWave modified by the impulse response of the channel. Rx Getwave will return its input modified by the Rx Equalization (and optionally clock ticks) The documentation of the Rx model should indicate what the Rx Init function will do if it just receives as its input the impulse response of the channel that does not include the equalization of the Tx. Walter Walter Katz 303.449-2308 Mobile 303.883-2120 wkatz@xxxxxxxxxx www.sisoft.com -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Ken Willis Sent: Wednesday, September 15, 2010 11:12 AM To: IBIS-ATM Subject: [ibis-macro] Tx (dual) > Rx (init only) combo for time domain Hi everyone, Having been shouted down 2 weeks in a row on this, here is my (final) attempt to express an opinion on this particular problematic combination. I am concerned the current path we are on will lead to confusion amongst model developers and users for a long time. Here is my proposal, with some background first: There are multiple time domain combinations that include "Rx (init only)": Tx (init only) > Rx (init only) ---------------------------------------- This is well-defined, so no problem. Tx (getwave only) > Rx (init only) ----------------------------------------------- This is also well-defined. Tx (getwave) modifies the bit stream, Rx (init only) modifies the channel's impulse response, and the 2 get convolved together, per Arpad's flow charts. In this combination, if the Rx doesn't optimize its own settings, then this flow works fine, and is a good reference flow. No problem here either. But what if Rx does have optimization capabilities? You can't give it the channel's impulse response modified by the Tx, because the Tx doesn't have that functionality. So the only reasonable thing to do in this case is turn off the Rx optimization in the model (typically available, and should be recommended in the spec) and set whatever programmable settings the Rx has interactively, or through sweeps or something. So this scenario WILL require some special handling by the user, no matter what. But note that there is only 1 flow here for this combination, and is easily understandable / explainable. This has significant value in and of itself. Tx (dual) > Rx (init only) ----------------------------------- Since the Tx is a dual model in this case, either of the first 2 combinations could be utilized by the user. If the Rx performs optimization, the first one is appropriate to use. If Rx doesn't perform optimization, the second one can be used. Who decides if the Rx does optimization or not? At this point, for the sake of simplicity and keeping this a "clarification" BIRD, my suggestion is that we leave it to the user at this point, and avoid new Booleans. I think that is reasonable. The user should know what models they are using and what their capabilities are. Yes, we will lose some accuracy by using the Tx init functionality vs. Tx getwave. But seeing that we are still using a simple init-only Rx, this trade-off is acceptable to me to avoid the added complexity of a special flow. True, this doesn't use Tx getwave and have your Rx do optimization at the same time. But this is no different than the boat you are in with the second combination above, so NOTHING new here. What I am against is making up a special flow for this one specific case (time domain/dual Tx/init-only Rx/Rx does optimization). I think that is the wrong thing to do in a specification for a reference flow. I think the reference flow for this problematic combination should be the same as one of the first 2 well-defined combinations. If a particular EDA tool wants to go above and beyond and offer a more advanced value-added flow, that of course should be allowed. But it should an option to do so, and NOT mandated in the reference flow. Remember, we got rid of "split" models because they were more complicated than they were worth. "Dual" models were intended (by me anyway) to mean you use either the model's getwave or init, but not both together. The flow currently being considered for this combination violates that idea, and is overly complicated. Summary of Proposal -------------------------------- - No special flows for special cases in the reference flow! - With a "dual" Tx, user can legally pick either of its 2 functionalities based on the Rx's functionality - EDA tools can add their own value-added flow for specific combinations if they want to Thanks, Ken Willis Sigrity, Inc. 860-871-7070 kwillis@xxxxxxxxxxx <mailto:kwillis@xxxxxxxxxxx>