Arpad, Your comments with specific details are appreciated. During the last ATM call, I believe there was an action item (or recommendation) to create a new BIRD for this issue. I agree with you that if something like this has caused this much discussion, it is worthwhile to formally treat it with a BIRD. I'll make myself available to work with Fangyi and Radek on this one. Regards, James From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Thursday, December 20, 2012 10:26 AM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL James, Thanks for your comments and questions. I agree that it is not practical to write a BIRD for every question or comment on the specification, but if it turns out that we need to change something in the spec, either to clarify something or add a new feature, we can only do that through the BIRD process. I believe that is captured in the bylaws… As far as I can tell, Fangyi was asking for something that is not defined or possible according to the v5.1 specification, and this is why I suggested a BIRD. While I agree that there is plenty of room for improvements in the clarity of the specification, I think it is quite clear that the analog models for AMI purposes are those which are defined in Sections 6, 6A and 6B (see last sentence of the 1st paragraph on pg. 122 in the PDF version of IBIS v5.1). In addition, from Section 10.2 (pg. 158) it is quite clear that the inputs and outputs of the AMI DLL functions are combined with the Impulse Response of the channel (which was obtained by the EDA tool during a separate channel characterization step), and not the analog models themselves. I also believe that the spec is clear about the analog models not being inside the AMI DLL, since it states that the analog models are described in Sections 6, 6A and 6B, none of which talk about AMI DLL-s. If there are EDA tool vendors who implement the AMI flow in a different way, they are strictly speaking not IBIS compliant. As long as their results does not deviate from the result you would get from an IBIS compliant implementation, who cares. Let them differentiate their product that way. But if their results are different, or if their implementation requires special (non-IBIS compliant) models (analog or AMI) which only work in their tool, we have a problem. We can’t, however, solve these problems by deliberately or ignorantly misinterpreting the specification, especially in areas where it is clear what it says. I don’t mind addressing Fangyi’s request at all. I was just pointing out in my response to his email that what he was asking for is not the matter of clarifying the specification, but it is adding a new feature. As far as I can tell, in order to clarify something, the intent, feature or capability must already exist in the spec. Fangyi was asking for a definition for the analog input for the analog driver models. In the current specification there is no such thing, other than with the purely analog languages of [External Model], but even those are not available for external connections. In order to change this, we need to change the spec, hence need to write a BIRD. Thanks, Arpad ===================================================================== From: James Zhou [mailto:james.zhou@xxxxxxxxxx] Sent: Wednesday, December 19, 2012 11:49 PM To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL Arpad, I respectfully disagree with your comments below. Fangyi's comments are directly applicable to the existing 5.1 spec, page 122, section 6c, paragraph 2. It is incorrect to dismiss them as irrelevant to the existing spec. And it is neither practical nor necessary to write a new BIRD every time there is a question/comment about the spec, due to the overhead and time involved. As you have stated, "this ... would require a lot of additional detail on where this analog portion begins...", a lot of details are indeed still missing on AMI analog models. And that is the main reason, in my humble opinion, why different EDA tools generate different results using the same AMI model. If ambiguities in the spec can be arbitrarily categorized as vendor proprietary "features", then what is the purpose of writing a spec that anyone could interpret it in their own way, and produce their own results that is "better" than others? The fact of the matter is that, although certain things are governed by IBIS spec, but everything is governed by laws of electronics. We need to make sure that the former must agree with the latter, not the other way round. James From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Wednesday, December 19, 2012 7:00 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL Fangyi, While I don’t dispute that the “ Tx DLL’s output waveform ” could be “ the voltage waveform of the ideal voltage source that is connected to the Tx analog portion”, according to the AMI flow in the IBIS v5.1 specification it is not. So we can’t clarify something in the specification that wasn’t mentioned. We can write a BIRD, though, to introduce this as a new concept in the spec… but that would require a lot of additional detail on where this analog portion begins in [Model], and/or whether it applies to any kind of [Model] (I-V and V-t curve based models, or S-parameter models only, if the latter, are we talking about the input to [External Model] only, if so with which languages, etc…). But I would like to say here that we did have a discussion in the ATM meetings in the days when we were re-writing the AMI flow for v5.1 whether we should mention such alternative methods. The committee’s decision at that time was that we did not need to mention all the possible alternate ways of how EDA vendors could possibly implement the AMI flow in their tools. So my position on this now is that we should only add things like this to the specification if the information is relevant to other aspects or areas of the specification in any way. If there is another keyword or parameter that has any kind of a dependency on this information, we need to spell it out. Otherwise it is only a private or proprietary matter of an EDA vendor for their own implementation. Thanks, Arpad ================================================================ From: fangyi_rao@xxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxx> [mailto:fangyi_rao@xxxxxxxxxxx] Sent: Wednesday, December 19, 2012 8:41 PM To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL We should make it clear that Tx DLL’s output waveform is the voltage waveform of the ideal voltage source that is connected to the Tx analog portion. Fangyi From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Wednesday, December 19, 2012 5:00 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL “So, are the analog buffer and AMI block connected or not? ” In the real physical world they are, i.e. EQ, CDR, DFE, etc… are connected to the analog “front end” of the buffer, but in IBIS-AMI simulations the specification treats them as two independent animals. According to the IBIS-AMI spec, they are not connected in an electrical sense, i.e. there are no voltages and currents flowing between the analog models and the AMI DLL-s and consequently no electrical interactions are possible between the two domains. The AMI DLL only supposed to know about the analog model through the impulse response of the channel. “Is this connection point (or "isolation point" as you have been referring it as) the same as D_drive or A_signal in Table 12 (also depicted in Fig 19) of IBIS 5.1? ” It is D_drive, not A_signal. I hope this helps, Arpad ================================================================ From: James Zhou [mailto:james.zhou@xxxxxxxxxx] Sent: Wednesday, December 19, 2012 6:30 PM To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL Hi Arpad, Your comments help to clarify the spec on some issues and are appreciated. With the sole purpose of correctly interpret the spec, when putting your words together with the spec, I couldn't make sense out of them: Arpad: In IBIS v5.1 the analog buffer models were not intended to be connected to the AMI model using such electrical connections. IBIS 5.1: The transmitter equalization, receiver equalization and clock recovery circuits are assumed to have a high-impedance (electrically isolated) connection to the analog portion of the channel. So, are the analog buffer and AMI block connected or not? Is this connection point (or "isolation point" as you have been referring it as) the same as D_drive or A_signal in Table 12 (also depicted in Fig 19) of IBIS 5.1? James From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Wednesday, December 19, 2012 3:20 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL James, You caught me! … but not quite… Changing the wording of that sentence to clarify what it says might be a little different from adding a bunch of technical details that hasn’t been mentioned in the spec yet. In the framework of IBIS v5.1, that sentence seems to be sufficient in what it says. In v5.1 legacy [Model]-s are two-port blocks between the signal pad and ground and/or power, but there is no input to output relationship as in a 4-port. On the Tx side, [External Model] is kind of an exception when the external model’s language can only have analog ports (SPICE and Verilog-A) because these can have an input port as well, but note that IBIS v5.1 really doesn’t provide connection access to these inputs to the external world. The same is also true on the Rx side. An [External Model] Rx might have an output port, but again, IBIS v5.1 doesn’t provide connection access to this port for the outside world. The analog model was supposed to be used to generate the impulse response of the channel and the AMI DLL-s were supposed to be working with the impulse response of the channel, but not the analog models in the channel. I am not saying that these types of flows couldn’t be done in practice to achieve the same results. I am just explaining what IBIS v5.1 says and what is “legally” possible in IBIS v5.1. Having said all this, I don’t see why there is a need in IBIS v5.1 to spell out rigorously what the driving and loading impedances are at that isolation point. That point is not available for electrical connections for the user or the model maker as far as IBIS v5.1 goes. This is why I thought it might be “sufficient” as is within the v5.1 framework. On the other hand, I agree completely that as soon as we extend [Model] and/or [External Model] to the world of S-parameter modeling, we will need a more detailed definition for this boundary. This is why I wrote BIRD 152 (to accompany BIRD 116). So your suggestion to write BIRDs to clarify the boundary conditions has already been taken care of. The only issue that I see left is the discussion on the nature of the input port to the Tx [Model]s and the output port of the Rx [Model]s. This is a new topic that surfaced after BIRD 116 and 152 were written and submitted, so this topic is not addressed in them. I was hoping to have some discussion on that in the Interconnect meeting today, but we didn’t get to it. I hope this clarifies the apparent contradiction you found in my words. Thanks, Arpad =================================================================== From: James Zhou [mailto:james.zhou@xxxxxxxxxx] Sent: Wednesday, December 19, 2012 3:42 PM To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL Arpad, The comment of "that sentence, as it is written today in v5.1 is actually sufficient" seems to contradict with your earlier comment of "I agree, the wording could be better" It was recommended in yesterday's call to draft a new BIRD to clarify this part of the 5.1 spec. Due to the fact that the work group had spent much time debating this issue, using some simple math (which of course we had all failed terribly in school) together with word engineering might be the way to go in drafting the proposed new BIRD. James ________________________________ 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. ________________________________ 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. ________________________________ 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.