[ibis-macro] Re: [ibis-interconn] Re: FW: Re: BIRD 158.3 - 2

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: "'Kumar Keshavan'" <ckumar@xxxxxxxxxxx>, "'IBIS-Interconnect'" <ibis-interconn@xxxxxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 7 Jun 2013 09:35:44 -0400 (EDT)

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

Other related posts: