[ibis-macro] Re: IBIS model for SerDes IO

  • From: Mike Steinberger <msteinb@xxxxxxxxxx>
  • To: akshaye.sama@xxxxxx
  • Date: Wed, 22 Oct 2008 09:29:55 -0500

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



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

  1. Home
  2. ibis-macro
  3. Archive
  4. 10-2008