[ibis-macro] Re: [ibis-interconn] Re: FW: Re: BIRD 158.3 - 2
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: Walter Katz <wkatz@xxxxxxxxxx>
- Date: Fri, 7 Jun 2013 10:05:41 -0400
100 models
How many vendors?
How many unique developers?
On Fri, Jun 7, 2013 at 9:35 AM, Walter Katz <wkatz@xxxxxxxxxx> wrote:
> 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
>
>
--
Scott McMorrow
Teraspeed Consulting Group LLC
16 Stormy Brook Road
Falmouth, ME 04105
(401) 284-1827 Business
http://www.teraspeed.com
Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC
Other related posts:
