Akshaye-

Please note that the goal of this exercise is to produce a performance
estimate and not just a time domain waveform. Note also that the model
interface consists of  more than a transmitter high speed serial output
and a receiver high speed serial input.

Here are some questions:
1. Does the transmitter input take serial or parallel data?
2. What type of signal does the transmitter expect at its input? Analog
or digital? What signal levels?
3. What type of signal does the receiver model output?
    - Analog or digital?
    - Parallel or serial?
4. Does the signal output from the receiver model represent the signal
at the decision point? Recognize that in many receiver designs, there is
no one circuit node which is the decision point, and therefore the
receiver decision point is an abstract concept. In fact, I imagine you
could find such a design close to hand.
5. If none of the signals output from the receiver model represent the
signal at the decision point, how is the performance analysis to be
performed? For a given pair of models, what types of performance
analysis will be possible or not possible?
6. Does the receiver model output a clock? If so, where was that clock
derived from? Is there a defined phase with respect to the data signal?
Is it at the serial channel symbol rate or at some submultiple of that
(such as the parallel interface rate)?
7. How is the transmit or receive model configured? By individual
configuration pins? Through some form of bus? If it's a bus, what
protocol does it use? Are all parameters configured the same way or, for
example, are there separate switches for PVT?
8. Is the model able to output state information (such as DFE tap
values)? If so, how does it do that?

Do you expect that two model developers working independently would come
up with the same answer to all of these questions, and many more? If
these questions have different answers for different models, how would
you propose that a user use a given model? Note that manual adaptation
is not a viable option for most users.

What AMI does is to provide specific answers to these questions in such
a way that, for the average user who has a job to do, everything will
work in a predictable way without manual intervention, and they'll be
able to get their job done. That's what an interface definition does,
and that's the way AMI is working out in practice.

Note also that none of these questions is related to the programming
language.

So, in answer to your original question, if an AMS model is compliant
with the AMI interface definition, then there can be an AMS(/AMI) model
on one side of the link, an AMI model on the other side, and useful
results will be generated predictably with minimal effort. If the AMS
model is not AMI compliant, then manual adaptation will be required, and
only a small number of users will have the skills and resources needed
to produce useful results.

Hope this helps.
Mike S.

Akshaye Sama wrote:
  

Arpad, Mike,

Thanks for sharing your thoughts on this. My real
concern was interoperability between AMI and AMS
serdes models.

I seem to be ok with 1) and 2). So, IBIS forum does not
force/recommend users to model using AMS or AMI. And
also does not force participating EDA companies to
implement support for the full standard.

However, on 3), I think, IBIS should take the
responsibility of ensuring that a simulator which
implements both IBIS AMI and AMS specifications
correctly, would be able to simulate a serdes link
with AMS on one end and AMI on the other. So, the
reference analysis flow in IBIS 5.0 should not
assume AMI on both ends and should also define what
happens when the other end is non-AMI.

Mike,

I don't think there is an interoperability issue between
serdes models in AMS. It is an electrical model at the
serial interface, so if the serdes macros can be wired
up on a board, why do you think it would be a problem
to replicate this in an electrical schematic?

Of course there are (dis)advantages of each method,
but my intention is not to start an AMI vs AMS debate.
Just trying to understand if AMI/AMS addition to IBIS
does infact solve the serdes interoperability problem
that I thought was one of the main goals.

Thanks,
Akshaye

Muranyi, Arpad wrote:
    

Yup!  There are times when it makes sense to standardize
a subcircuit definition that has four fixed nodes in the
order of (in+  in-  out  power  ground), for example, to
be used for OpAmps, and there are times when it doesn't.

The advantage of the above standard is that you have a
blind "plug and play" guarantee, but then if you run across
an OpAmp which also has DC offset inputs, or a differential
output, or frequency compensation input(s), the above
standard will fall short and then you will have to wait
for someone to fix the standard (a good old IBIS phenomena).

With a general non-standard subcircuit definition I can
do all of the above, even if I have to pay a little more
attention not to mess up and accidentally connect my
inputs where the frequency compensation should have gone,
the power supplies where the DC offset should have gone, etc...

Interestingly, the non-standard subcircuit definition will
still work to describe standard OpAmps, and even if one of
my OpAmps has 4 nodes, and another has 7 nodes, I can still
connect them together appropriately and have a successful
(interoperability) simulation.

It all depends on when and where and what, and some personal
preferences...

This may be a personal choice, but I prefer the freedom
even if I have to work a little harder to enjoy it.  Of
course if I end up working so much harder that I don't
have time left to enjoy the freedom, I will end up voting
for the standardized subcircuits (interfaces).

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

-----Original Message-----
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Tuesday, October 21, 2008 4:24 PM
To: Muranyi, Arpad
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: IBIS model for SerDes IO

Arpad-

We converge. That's good.

It's certainly true that one can manually adapt between incompatible
interfaces. Similarly, I could take a bolt home from the store and
machine it to fit a nonstandard nut. (In my case I do literally have
that capability.) The point is, do we want to be doing manual adaptation
between every pair of models? I don't think so.

Mike S.
---------------------------------------------------------------------
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

    

-- 
--------------------------------------------------------------------------
Akshaye Sama

Texas Instruments Ltd

800, Pavilion Drive,
Northampton NN4 7YL
United Kingdom.

Ph +44-1604-663804
--------------------------------------------------------------------------