====================================================================== IBIS INTERCONNECT TASK GROUP MEETING http://www.eda.org/ibis/interconnect_wip/ Mailing list: ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx> ====================================================================== Next meeting: Jan. 23, 2013 8 AM US Pacific Time Agenda: Attendance Call for Patents Agenda and Opens Survey Results from D. Banas Summit TG Presentation Next Meetings' Schedule/Agenda: * No meeting Jan. 30 - DesignCon * Feb. 6 * Feb. 13 For international numbers, please contact Michael Mirmak. Note: in case of issues with Lync we will use the WebEx noted at the bottom of this message ......................................................................................................................................... Join online meeting<https://meet.intel.com/michael.mirmak/QZ193W0C> https://meet.intel.com/michael.mirmak/QZ193W0C First online meeting?<http://r.office.microsoft.com/r/rlidOC10?clid=1033&p1=4&p2=1041&pc=oc&ver=4&subver=0&bld=7185&bldver=0> [!OC([1033])!] ......................................................................................................................................... <--- Reservationless Bridge - Do not edit or remove --- 916-356-2663, 8-356-2663, Bridge: 2, Passcode: 8625431 Speed dialer: inteldialer://2,8625431 -----------------------------------------------------------------> Note: in case of issues with Lync we will use the WebEx noted at the bottom of this message ====================================================================== Attendees, Jan. 16 Agilent Technologies Radek Biernacki* Altera David Banas* ANSYS Luis Armenta*, Steve Pytel Cadence Design Systems Brad Brim*, Ambrish Varma Intel Michael Mirmak* Mentor Graphics Arpad Muranyi* Micron Technology Justin Butterfield*, Randy Wolff* Qlogic Jason Zhou Signal Integrity Software Walter Katz* Teraspeed Consulting Group Bob Ross* Minutes No patents were declared. During Opens, Walter Katz suggested that the Interconnect TG provide a Summit presentation report and that the presentation be reviewed in the next meeting. Walter asked that his postings to the Interconnect mailing list be posted to the Interconnect web site as a Microsoft Word* document; the document covers how EMD and package files will interact. Brad Brim noted that the 60-day comment period continues on Si2's package proposals. David Banas reviewed the survey questions he sent to the Interconnect and ATM lists, stating that he wanted to secure less vociferous opinions (quiet but dissenting) to prevent re-working of BIRDs. In his survey on GetWave, cases D and E cover where only a single correct answer doesn't necessarily apply. Bob Ross stated that he believes GetWave is the input to the analog channel under proper termination conditions. Michael Mirmak asked whether an answer for INIT is unrelated to the answer for GetWave. David replied yes, but that the only difference may be for non-LTI processing. The problem is that the analog channel is always LTI (including buffer). We are required to do non-LTI TX processing for GetWave; we will always treat the TX driver as a linear entity. Walter stated that he agreed with Bob that the TX GetWave is the input to the analog channel under correct termination conditions; Fangyi is to submit a BIRD on this. On INIT, David's statement is correct according to Walter; the output of TX_GetWave is independent of statistical processing. A call to INIT sets up GetWave, but afterward they are independent. The problem is where the original group defined the boundary where the equalization and the analog channel is defined; this comes from the IC vendors. Michael asked whether the survey question two on the normative vs. informative nature of the IBIS-AMI flow is related to the boundary between analog and digital areas. David replied that Section 6 is likely normative; Section 10 is the only place where TX_GetWave relationship is mentioned. Walter summarized the differences between normative and informative; normative is a requirement, you must follow it as a rule. Informative is an aid to design. Radek Biernacki added that Section 10, although the title says "guide", is a part of the specification and the material is normative in that context. There is no duplication of Section 10 contents vs. other locations. The title is perhaps misleading. Walter ntoed that the reference flow indicates that it doesn't need to be followed as stated. Radek added that question one should be formulated differently to be more precise; (A) should state what the analog channel is, the analog backend of TX, the channel and the AFE of the RX. There's no disagreement in the spec between AMI_INIT and _AMI_GetWave; it's clear what is passed to the tool is at the same point; the AMI portion drives the analog channel from an ideal voltage soruce. There is pretty clear ATM agreement on this point, but it may not be stated in the specification. It's up to the model maker how that is used; that's the part that is in the DLL and that's the part that has to be properly formulated. Arpad asked whether we are talking about real silicon or the IBIS specification. Filters exist in the pre-driver stage. We don't say what the analog model input is; we say that the impulse response of the channel is convolved with the output of GetWave. Walter agreed with Radek and disagreed with Arpad. We are not talking about real circuit construction. The left side is an ideal voltage source; the right side is an analog buffer to use when generating that impulse response. For example, for a peaking filter (may not be in a TX), the model maker may put the peaking filter in an analog model or put it inside the DLL. Choice will determine how both of these are constructed. We can only do this because a peaking filter is LTI. Answer is clearly (A). Michael asked whether interoperability with RX is unaffected regardless of the survey results. Walter answered yes. Radek stated that he doesn't see where the issue is related to analog placement, except that those pieces of the analog channel have to be represented by the IBIS data. Walter replied that at least one IC vendor has released analog data in the DLL. Radek suggested that the disagreement may not be that sharp; on convolution, we use a single impulse response of a piece convolved with a single impulse response of another piece, etc. For normal cricuits, this is broken up into 2-ports, 4-ports, etc. But the impact on the circuitry is somewhat more complex. Michael asked what the next step after David's responses come in should be. David answered that, if (B), the TX convolution should be performed for GetWave just like Init; it will break the result of some tools. Arpad stated that he doesn't see how (B) can be true. Walter stated that, if 75% answer (B), and we investigate, this may turn out to be only users rather than IC vendors and EDA vendors. Walter suggests that the IC vendors assume that the answer is (A). David will report results next week. Michael asked whether a decision as to the GetWave input wave's nature should be settled in response to the survey by majority rule vs. flipping a coin. At some level, some portion of the IBIS community will be inconvenienced in that models and/or tools would have to be updated to accommodate the official interpretation. Bob stated this is a technical matter. Walter added that no other interpretation is possible other than (A). Radek stated that the inconvenience is minor. If there is a drastic difference, it will show up as different results from different tools. Bob added that Eckhard Lenski has mentioned IBIS-AMI models as giving different results from different tools. Walter replied that we do know that there's an interoperability problem between TX_INIT only and TX_GetWave only models. Radek replied that we expect answer (A) but would need to be more precise about it, to include AFE and TX back end. Bob asked whether the channel being simulated is terminated by the TX and RX, or terminated by a standard termination. Radek answered that whatever data you have in the channel for TX and RX is to be used, not the standard termination in an S-parameter, for example. Walter added a brief closing note: we owe the Summit a summary of where we are. It can be assembled by Michael or coauthors, but should review what we have been doing. Any inputs would be appreciated. Bob asked whether is this an interconnect summary or a proposal, noting that proposals should not be presented as task group outputs. ====================================================================== In case of Lync issues only, we will switch to WebEx as noted below. Meeting Number: 732 940 715 Meeting Password: IBIS ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://sisoft.webex.com/sisoft/j.php?J=732940715&PW=NNWY2NmRmZTY0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: IBIS 4. Click "Join". 5. Follow the instructions that appear on your screen. ------------------------------------------------------- Audio conference information ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:732 940 715 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.