[ibis-macro] Re: Eye mask definition for IBIS-AMI

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: "'Muranyi, Arpad'" <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 16 Mar 2012 12:52:27 -0400 (EDT)

Arpad,

 

I do not think you understood my question. I assume your diagram is a time
domain eye, with blue indicate no "events", and defines an inner eye
contour. This inner eye contour will be a function of the number of bits
simulated, typically ~1e-6 to 1e-7. In Statistical, the center of the eye
is filled in with probabilities << 1e-7. 

 

So an eye mask only makes sense if it is defined for a specific BER, and
the BER is not a function of the model but a function of the BER
requirements for a specific channel in a specific application. Is the
target BER 1e-20, 1e-17, 1e-12, 1e-9 or 1e-5.

 

Way back when, we agreed that the "prime directive" of AMI modeling was to
assure that all EDA tools would get the same Impulse Response in
statistical and the same waveform in time domain at the slicer, and it was
up to the EDA tool on how it analyzed these results.

 

By defining an eye mask, you are now extending IBIS AMI modeling to
include how EDA tools analyze the results of simulation. I am not
objecting to this extension, but this opens up many issues that are much
more complex than just defining an eye mask.

 

Walter

 

From: Muranyi, Arpad [mailto:Arpad_Muranyi@xxxxxxxxxx] 
Sent: Friday, March 16, 2012 12:22 PM
To: Walter Katz; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Eye mask definition for IBIS-AMI

 

Walter,

 

The eye should be generated the same was as we already do.

Just draw a diamond in the middle of it, instead of two

horizontal lines.

 

In this picture I show what I think the Rx_Receiver_Sensitivity

parameter means with the two dashed lighter blue lines, and what

I think the eye mask could be with the darker blue diamond in

the middle, and optionally the horizontal lines above and below

the eye on the top and bottom:

 



 

I agree, this is probably not difficult to achieve, but it is

not in the specification.  I think it may be worth adding it.

 

Thanks,

 

Arpad

===============================================================

 

 

From: Walter Katz [mailto:wkatz@xxxxxxxxxx] 
Sent: Friday, March 16, 2012 8:23 AM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Eye mask definition for IBIS-AMI

 

Arpad,

 

Defining a format to describe an eye mask is trivial. Can you explain
exactly how the eye should be generated in both statistical and time
domain AMI simulations, and how the eye mask should be applied to it?

 

Walter

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, March 14, 2012 4:28 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Eye mask definition for IBIS-AMI

 

Greg,

 

I am not sure we are discussing the same thing (correct me if I

am missing something in your thoughts).

 

The Eye Mask I am talking about basically describes the input

characteristics of the stage that follows the Rx AMI model.

It would specify what its Vinh/Vinl and Setup/Hold times are

with respect to the clock tick that is used to latch the data.

Our current specification already has Rx_Receiver_Sensitivity,

which defines the +/- voltage value around the nominal threshold

level (or Vref, if you want to call it that).  The way I

understand this is that:

 

Vref + Rx_Receiver_Sensitivity  =  Vinh

Vref - Rx_Receiver_Sensitivity  =  Vinl

 

for the input that "reads" the output of Rx AMI.

 

What we seem to be missing in the IBIS-AMI spec is a parameter

that does the same for the timing aspect for this input.  What

is the Setup and Hold for this input to actually get the correct

logic interpretation for the waveform that it sees?

 

My point is that if we have "Rx_Receiver_Sensitivity", we should

also have a corresponding timing parameter.  If we put all these

together, we basically arrived at an eye mask definition.

 

Thanks,

 

Arpad

==================================================================

 

 

 

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Gregory R Edlund
Sent: Wednesday, March 14, 2012 1:55 PM
To: Muranyi, Arpad
Cc: ibis-macro@xxxxxxxxxxxxx; ibis-macro-bounce@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Eye mask definition for IBIS-AMI

 

Let's ask the question another way:  if jitter and noise limits are NOT
stored in the AMI model somewhere, how does the user get that information?
By calling an application engineer, probably.  And the AE may need to
check with the circuit designer.  It's easy for the information to get
stale.  The flip side is that suppliers may be unwilling to disclose
jitter and noise limits.  Then again, users often have to sign a
non-disclosure agreement to get the AMI model in the first place, so that
may not be a strong argument.

Greg Edlund
Senior Engineer
Signal Integrity and System Timing
IBM Systems & Technology Group
3605 Hwy. 52 N  Bldg 050-3
Rochester, MN 55901



Inactive hide details for "Muranyi, Arpad" ---03/14/2012 12:25:18
PM---Hello Everyone, I would like to solicit for some more co"Muranyi,
Arpad" ---03/14/2012 12:25:18 PM---Hello Everyone, I would like to solicit
for some more comments on this

From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
Date: 03/14/2012 12:25 PM
Subject: [ibis-macro] Re: Eye mask definition for IBIS-AMI
Sent by: ibis-macro-bounce@xxxxxxxxxxxxx

  _____  




Hello Everyone,

I would like to solicit for some more comments on this
question.  So far I heard one general response that it
is a good idea, and a very specific response with a
syntax suggestion, but I would like to get a few more
responses on whether it would make sense to add an eye
mask definition to the IBIS-AMI specification.  The reason
I am asking for more comments along these lines is because
last time I brought this topic up the majority of the
responses were along the lines of "not needed", "useless"
etc...

However, the more I think of this, the more it seems that
this would actually be useful, especially since we already
have vertical half of the eye mask definition present in the
Rx_Receiver_Sensitivity parameter.  Is there a reason we
shouldn't include the horizontal (timing) aspects of the
eye opening requirement in addition to what we already
have for the vertical (voltage) requirement?

Thanks,

Arpad
=============================================================

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, March 01, 2012 11:43 AM
To: colin_warwick@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Eye mask definition for IBIS-AMI

Colin,

Thanks for the suggestion.  However, before
discussing the format and syntax of the eye
mask definition, I would like to get comments
on the idea itself, such as do we all agree
that we should do this, do we agree on what
the eye mask means, etc...  Once we agree,
we could hammer out the details of the syntax.

Thanks,

Arpad
===================================================

-----Original Message-----
From: colin_warwick@xxxxxxxxxxx [mailto:colin_warwick@xxxxxxxxxxx] 
Sent: Thursday, March 01, 2012 11:29 AM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: Eye mask definition for IBIS-AMI

Hello Arpad,

Our 'scope *msk files look like this:

/* Top Polygon           */
/* Polygon Number        */  1
/* Number of vertices    */  4
    +0.0,      0.6
    +0.0,     0.5
    +1.0,     0.5
    +1.0,      0.6

/* Middle Polygon        */  2
/* Number of vertices    */  6
/* X1, Yt */    0.300   ,       0.000
/* X2, Y+ */    0.500   ,       0.073
/* 1-X2, Y+ */  0.500   ,       0.073
/* 1-X1, Yt */  0.700   ,       0.000
/* 1-X2, Y- */  0.500   ,       -0.073
/* X2, Y- */    0.500   ,       -0.073

/* Bottom Polygon        */
/* Polygon Number        */  3
/* Number of vertices    */  4
    +0.0,      -0.6
    +0.0,     -0.5
    +1.0,     -0.5
    +1.0,      -0.6


I don't know if the spec is published or not nor whether there's IP in the
spec (I'm in the EEsof division). But if this format is of interest, I can
ask my 'scopes colleagues to get involved.

-- Colin Warwick
Agilent EEsof EDA
http://signal-integrity.tm.agilent.com

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, February 29, 2012 11:43 PM
To: IBIS-ATM
Subject: [ibis-macro] Eye mask definition for IBIS-AMI

Hello everyone,

We had a few conversations on this topic in the past on this
email reflector and also in the IBIS-ATM meetings, but the
discussions didn't result in any actions as far as the
specification is concerned.  I would like to bring this
topic up again because to me it seems that we have an
incomplete "solution" for this in the IBIS specification.

Currently, we have an AMI parameter in specification called
"Rx_Receiver_Sensitivity".  Pg. 147 describes this parameter
like this:


| Rx_Receiver_Sensitivity can be of Usage Info and Out and of
| Type Float and of Data Format Value, Range and Corner.
| Rx_Receiver_Sensitivity tells the EDA platform the voltage
| needed at the receiver data decision point to ensure proper
| sampling of the equalized signal.


In other words, this is basically the Vinh and Vinl of the
core's input stage that is connected to the output of the Rx
buffer which contains all the fun stuff, the filter(s), DFE,
CDR, etc...  Since the AMI simulation's output waveform goes
into this input, the eye opening we get from the AMI simulations
better be above and below +/-Rx_Receiver_Sensitivity, otherwise
this input stage will not be able to interpret the signals
correctly.

However, there is nothing in the AMI specification which would
help us to evaluate the timing relationship requirements between
these waveforms and the clock ticks.  In other words, we have
no information about what the setup and hold times are supposed
to be around the sampling point for this input stage to recognize
the signal correctly.

To me it would make sense to define a complete eye mask which
would include a definition for the width of the eye (time) and
its time relationship to the clock ticks as well as for its
height (voltage).  I would be willing to write a BIRD for this,
but before I begin, I would like to have a little brainstorming
session to collect some ideas on how people would deal with this
and what we should put into the specification.

As a bare minimum, I would like to propose a set of parameters
which defines the shape of a diamond, laying on its side:

    *********
   *         *
  *           *
 *             *
  *           *
   *         *
    *********

For the voltages we could have a high/low level and DC offset
and for the timing we could have a left/right corner and
the beginning and end points of the horizontal lines.  This
could be achieved with seven parameters.

I could see a few additional parameters for a more elaborate
definition, but for now I will leave it at that.

Questions, comments welcome.

Thanks,

Arpad
================================================================
---------------------------------------------------------------------
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

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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

PNG image

GIF image

Other related posts: