Kumar, IC Vendors are universally using this Touchstone file format for high speed (>~6GHbps) Tx and Rx buffers. There are now close to if not more than 100 models that are using Tstonefile in their .ami files. Other than simple RLC buffers that legacy IBIS deals with today, what other method are SerDes vendors using to describe the analog behavior of their devices that they use to generate the Impulse Response of their channels? Walter -----Original Message----- From: Kumar Keshavan [mailto:ckumar@xxxxxxxxxxx] Sent: Friday, June 07, 2013 9:01 AM To: wkatz@xxxxxxxxxx; 'IBIS-Interconnect'; ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: [ibis-interconn] Re: FW: Re: BIRD 158.3 - 2 it is not a question of adding 40 lines. The issue is is this the correct thing to do? viz. Freeze a specific structure while there are more flexible and universals ways to include it ________________________________________ From: ibis-macro-bounce@xxxxxxxxxxxxx [ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz [wkatz@xxxxxxxxxx] Sent: Friday, June 07, 2013 8:52 AM To: 'IBIS-Interconnect'; ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: [ibis-interconn] Re: FW: Re: BIRD 158.3 - 2 Brad, Currently, both legacy IBIS, BIRD 160, and BIRD 158 merge the actual buffer model with on-die interconnect. We are working very hard in IBIS interconnect to be able to have IBIS support for separate buffer and on-die interconnect models, which is particularly important for FPGA redistribution layers, on-die termination and C_comp compensation. I have proposed methods of doing this using EMD style model interconnect protocol, Cadence and Mentor have introduce BIRD 145 to do something similar. This partitioning is an important topic for IBIS, but in the meantime IBIS only really supports a single model that combines buffer and on-die interconnect, and BIRD 158 introduces nothing more than a shortcut that uses 2, 3, or 4 AMI parameters to replace ~40 lines of IBIS [External Model] syntax and a ~10 line wrapper IBIS-ISS file. As to keeping the analog modeling within the IBIS Component, BIRD 160 already violates that because is dependent on parameters from the .ami file. If your concern is that you do not want to update your tool to use the BIRD 158 parameters directly, simply add the 40 or so lines to the IBIS file and the additional IBIS-ISS file your library. Walter From: ibis-interconn-bounce@xxxxxxxxxxxxx [mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bradley Brim Sent: Friday, June 07, 2013 1:49 AM To: IBIS-Interconnect; ibis-macro@xxxxxxxxxxxxx Subject: [ibis-interconn] Re: FW: [ibis-macro] Re: BIRD 158.3 - 2 Hello all, Walter brings up an excellent point. One that should be considered in more detail by all before the Open Forum meeting tomorrow. In fact, it may well be the point upon which we make a decision concerning BIRD 158. Does it really "make sense to merge the [model] with the on-die interconnect" ??? Based on Walter's text it seems a statement of fact that the boundary between [Model] and on-die interconnect is presently not clear. In reality it is perfectly clear by today's specifications, including recently-approved BIRD 160, that there exists a distinct and unambiguous separation of AMI versus analog models. Some IC vendors may prefer to see this boundary removed and some EDA vendors may have even implemented proprietary, non-standard solutions for such. However, others of us believe with firm conviction that doing so is a slippery slope to complexity and special-casing that we believe must be avoided. There has been much recent discussion concerning BIRD 158: what parameters do we apply, what format/syntax does the specification text have, are common mode effects enabled, etc. All of these seem secondary issues to the highest-level binary choice that confronts us - do we include analog in AMI or not. Please do not allow the secondary details to deter your focus from the highest level decision criterion we have concerning BIRD 158. Best regards, -Brad From: ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@freelists .org> [mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz Sent: Thursday, June 06, 2013 6:13 PM To: IBIS-Interconnect Subject: [ibis-interconn] FW: [ibis-macro] Re: BIRD 158.3 - 2 All, I am sending this e-mail In case you are not on the IBIS-ATM reflector. What is relevant here is how IC Vendors are partitioning there AMI Tstonefile on-die S-Parameters, and that the boundary between [Model] and on-die interconnect models is not clear. In summary it sometimes make sense to merge the [Model] with the on-die interconnect. I will also recommend that BIRD 145.3 be tabled and discussed in the IBIS Interconnect meeting since it's examples use [Model Call] to instantiate a an on-die RDL or an on-die ODT circuit which is an alternative solution to what is currently being discussed for on-die IBIS-ISS circuits using the EMD methodology. Walter From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Wednesday, June 05, 2013 10:10 AM To: 'twesterh@xxxxxxxxxx'; 'ibis-macro@xxxxxxxxxxxxx' Subject: RE: [ibis-macro] Re: BIRD 158.3 - 2 All, I think the picture in BIRD 122 is a better representation of what is really happening. BIRD 122 Tx: [cid:image001.png@01CE635B.C6D05980] BIRD 158 Tx: [cid:image002.png@01CE635B.C6D05980] The arrow on the left side of the BIRD 122 circuit is a "Unit" step response. The actual buffer includes the triangle amplifier (gain), a resistor (Tx_R), a C_comp and an on-die interconnect. In order to build a high speed modern SerDes driver the C_comp is too large to operate properly, so an on-die interconnect circuit (e.g. T-coil) is implemented in the on-die interconnect to reduce the overall capacitance. The original on-die S parameters that we used to base BIRD 122 included the impedance of the driver (Tx_R) and the C_comp. Other IC Vendors built the on-die S parameter excluding the Tx_R but including the C_comp. This explains why Tx_R was added. The Impulse Response of the channel that is input to Tx AMI_Init includes the full Tx buffer, including the gain impedance, C_comp and on-die interconnect. In BIRD 158 the unit step response and gain were included in the circle voltage sources. In the context of the IBIS Interconnect meeting where we are planning to implement on-die interconnect in IBIS Components, the IC Vendor could choose to implement the buffer with linear pullup and pulldown curves (slope being Tx_R) and a C_comp, and the on-die S-Parameter with just the T-coil (or equivalent C_comp compensation circuit). Either for practical reasons (limitations of IC EDA tools), or to protect their IP, the IC vendors choose to include C_comp in the S parameter (or also include the Tx_R as well). So the S parameter they implement straddles part of the actual buffer and the on-die interconnect. This "straddle" might just include the capacitance (C_comp) of the buffer or the capacitance and impedance of the driving transistor. Typically they do not include the gain of the driver in the S parameter. The situation is similar for SerDes Rx buffers. Do note that the SerDes Rx buffer can introduce gain (or loss) as well. This picture is different for buffers and redistribution layers in FPGA components. These redistribution layers have a different purpose other than reducing the affective C_comp of the driver (or receiver). So for FPGA is makes sense to have the on-die interconnect separated from the actual buffer model which does include important non-linear affects . Walter From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff Sent: Wednesday, June 05, 2013 9:20 AM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: BIRD 158.3 - 2 Arpad, Well said. We're modeling a nonlinear system that's operating within a linear region, hence the need for proper biasing and Vol/Voh. Todd. Todd Westerhoff VP, Software Products Signal Integrity Software Inc. . www.sisoft.com<http://www.sisoft.com> 6 Clock Tower Place . Suite 250 . Maynard, MA 01754 (978) 461-0449 x24 . twesterh@xxxxxxxxxx<mailto:twesterh@xxxxxxxxxx> "I want to live like that" -Sidewalk Prophets From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Wednesday, June 05, 2013 12:27 AM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: BIRD 158.3 - 2 Radek, I agree that "AMI technology does not handle the common mode" but during the channel characterization simulation the models must include the appropriate common mode component if the differential response depends on what the common mode component is. As an analogy, consider the SPICE small signal .AC simulation. The DC component is irrelevant for the frequency sweep, yet the simulator will start with a DC operating point calculation because the circuit's behavior might vary quite a bit for different bias conditions. We can have the same situation in IBIS-AMI with certain types of non-linear Rx models which can still be considered linear devices for AMI purposes if the signaling range falls into their linear region. In situations like this, the channel characterization simulation will only give the correct results if the differential signal contains the correct DC "bias" or common mode component. Now that you mentioned the initial conditions, after thinking about Fangyi's statement in the ATM meeting today that in LTI systems the initial conditions do not make a difference, I tend to disagree. Let's consider a simple RC filter with (a) zero initial charge on the capacitor and (b) 1 V initial voltage across the capacitor. By applying a 1 V step, you will get exponential rise in case (a) but a flat 1 volt output in case (b). Also, in the circuit proposed in the BIRD, the voltage sources are essentially non-zero for time<0. We should state in the BIRD that: It is assumed that before transition, the circuit remains sufficiently long under inputs SRC1 = 0 and SRC2 = Tx_V, so that the steady state is achieved. After time=0, SRC1 changes to Tx_V and SRC2 to 0. We measure the voltage difference between ports 2 and 4, subtract the initial value (in steady state this difference is not zero), and divide the result by 2. This gives us the 'edge response' which starts from zero. Then, find its time difference and get "AMI Impulse response". It is important to understand that the difference voltage was non-zero before transition and at time=0 started to change to another steady state. The derivative should be taken by considering that non-zero voltage prior to zero. Otherwise, when finding the derivative (for impulse response), we'll get incorrect results. Thanks, Arpad ================================================================= From: radek_biernacki@xxxxxxxxxxx<mailto:radek_biernacki@xxxxxxxxxxx> [mailto:radek_biernacki@xxxxxxxxxxx] Sent: Tuesday, June 04, 2013 7:24 PM To: Dmitriev-Zdorov, Vladimir; bob@xxxxxxxxxxxxx<mailto:bob@xxxxxxxxxxxxx>; wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>; Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: RE: [ibis-macro] Re: BIRD 158.3 - 2 Hi Walter, I am still not convinced that specifying Vol and Voh for a specific TX AMI is of any particular value in the context of an arbitrary RX to interact with. AMI technology does not handle the common mode and we should not make an impression it does. If, in the future, handling of the common mode becomes necessary, there will be ways to enhance this methodology, and it should be done in a complete way. Second, the BIRD still needs to clarify the following three items: (a) that the "step response" of interest (to determine the impulse response) represents the response to a unit step function at the input, (b) the sources in the diagram do not represent that input, and (c) following Vladimir's comments, handling of non-zero initial conditions (if taking place) - it needs to be stated how their impact is removed. Radek From: Dmitriev-Zdorov, Vladimir [mailto:vladimir_dmitriev-zdorov@xxxxxxxxxx] Sent: Friday, May 24, 2013 12:39 PM To: BIERNACKI,RADEK (A-Sonoma,ex1); bob@xxxxxxxxxxxxx<mailto:bob@xxxxxxxxxxxxx>; wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>; Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: RE: [ibis-macro] Re: BIRD 158.3 - 2 Radek, I agree with your comments on redundancy of the input characterization: one parameter is enough since the common mode input is constant (with defined stimulus) hence no conversion of time varying common mode into differential is possible. Regarding step response, the definition in fact should be even more stringent. The step response is a response of a circuit to a certain unit size step-wise excitation, assuming no independent sources (i.e. non-autonomous circuit only) and also zero initial conditions! If we measure the response as a transition from prolonged '0' (lasted for many bits, to allow initial steady state) to '1' state, it is not a response with zero initial conditions, and for a linear circuit it gives us doubled step response. Then, EDA platform has to account for this fact by applying a factor 0.5. Another problem with 'step response' is that it is defined for one excitation only. Vladimir ________________________________ From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [ibis-macro-bounce@xxxxxxxxxxxxx] on behalf of radek_biernacki@xxxxxxxxxxx<mailto:radek_biernacki@xxxxxxxxxxx> [radek_biernacki@xxxxxxxxxxx] Sent: Friday, May 24, 2013 12:30 PM To: bob@xxxxxxxxxxxxx<mailto:bob@xxxxxxxxxxxxx>; wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>; Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: BIRD 158.3 - 2 Hi All, In my opinion the latest changes made the proposal somewhat more confusing. The common-mode input is introduced quite unnecessarily. All that is needed is the difference of Tx_Vol and Tx_Voh and the proposal asks for two numbers where just one number is needed. The one number needed could be either half of the differential voltage swing or the full differential voltage swing. (That would correspond to either Tx_Vol = -Tx_V and Tx_Voh = Tx_V, or Tx_Vol = -Tx_V/2 and Tx_Voh = Tx_V/2, and specifying just Tx_V as before.) Furthermore, the use of inherent common-mode concept associated with specifying two (could be arbitrary) numbers will be more confusing to the users of the AMI technology, and model developers in particular. Arpad: your comment about the unit excitation was quite incorrect. By definition, the step response of a circuit is the output signal (here the output differential voltage) when a unit step signal (the input differential voltage) is applied to the input. The circuit inside must not have independent sources in it. The framework in which this BIRD is written does not follow this convention, and suggests independent sources being part of the circuit. In fact these sources should properly be described as voltage-controlled voltage sources that are controlled by an input signal that is not shown. A unit excitation (Dirac delta, or unit step function) must be applied to that input to determine the impulse response needed for AMI simulation. In the context of the picture in the BIRD that unit excitation will result in the voltages of the sources as described. Those voltages are poorly termed in the BIRD as "step response stimulus". In fact the picture does not reflect an input-output model of the actual circuit, but shows a schematic for impulse response calculation - that should be explicitly stated. Radek From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross Sent: Friday, May 24, 2013 8:44 AM To: wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>; Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>; 'IBIS-ATM' Subject: [ibis-macro] Re: BIRD 158.3 - 2 All: Looks good enough to me for submission. Bob From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz Sent: Friday, May 24, 2013 7:43 AM To: Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>; 'IBIS-ATM' Subject: [ibis-macro] Re: BIRD 158.3 - 2 All, I have made the changes requested by Bob and Arpad (enclosed). Any additional comments before I send the formal version to Michael this afternoon would be appreciated. Walter From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Friday, May 24, 2013 10:03 AM To: IBIS-ATM Subject: [ibis-macro] Re: BIRD 158.3 Walter, Here are my comments on this BIRD draft. What does "differential transmission" mean in this sentence: "This Impulse Response characterizes the differential transmission of the Tx analog buffer model,"? Could you make this clearer with better wording? In the following sentence you are talking about the "die side of the package": "For a Tx buffer, the Transmitter Circuit defines the analog buffer model between the zero impedance stimulus input voltage source and the die side of the package model. For an Rx buffer, the Receiver Circuit defines the analog buffer model between the die side of the package model and a high impedance probe at the input to the Rx Algorithmic model." However, it is not clear whether this means that the buffer model described by the data in the Touchstone file can/should also include the on-die interconnect or not. I think this should be clearly stated otherwise different people will make different assumptions to model on-die interconnects. This sentence: "Note that this Touchstone analog model only represent the on-die model between the die pad and buffer interface to the algorithmic model" is somewhat misleading, because it can be interpreted as if the Touchstone model is **the** on-die interconnect model between the pad and the buffer's terminals ("buffer interface"). You use the words "unit excitation". This sentence: "This BIRD defines what that unit excitation is when the Tsonefile parameter is present." really doesn't make sense, because by definition a unit = 1, i.e. the "unit excitation" would have to have a fixed and predefined magnitude of 1 volt, yet in this BIRD you define Tx_Voh and Tx_Vol, which is not "unit" anymore. Also, please correct the spelling of "Tsonefile" in this sentence (missing "t"). You mention in the discussion of the Impulse Response generation that the Tstonefile parameter is a Reserved Parameter, but you don't say anywhere in the document whether the rest of the parameters in this BIRD are Reserved or Model_Specific. Please specify what you want them to be. I would also like to request to put a "0" before and after each decimal point for properness. For example, instead of "(Range 1. .5 1.)" please write "(Range 1.0 0.5 1.0)", it is much more readable that way. Thanks, Arpad ====================================================================== From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz Sent: Thursday, May 23, 2013 9:04 PM To: IBIS-ATM Subject: [ibis-macro] BIRD 158.3 All, Please review version 158.3 (Tstonefile AMI models) before I send the final version to Michael tomorrow afternoon. The major change is that there are now two Tx voltage levels (Tx_Vol and Tx_Voh) that determine the differential step response stimulus that is assumed for generating the Impulse Response of the channel. This make BIRD158 Tstonefile models directly convertible to BIRD 160 external models, and gives the model maker the ability to determine the common mode voltage when generating the Impulse Response of a channel. Walter Walter Katz wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx> Phone 303.449-2308 Mobile 303.335-6156 --------------------------------------------------------------------- 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