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

  • From: Mike Steinberger <msteinb@xxxxxxxxxx>
  • To: Arpad_Muranyi@xxxxxxxxxx
  • Date: Tue, 21 Oct 2008 15:54:07 -0400

Akshaye, Arpad-
Arpad's response is very good as far as it goes, but it does fail to mention one critical point which has been discussed often and at length in the IBIS ATM meetings. I suggest that this point is also central to your question, and so you need the whole story.
AMS and AMI are fundamentally different in the sense that AMS is a programming _language_ whereas AMI is a programming _interface_. Thus, they have entirely different properties, including differences in flexibility and interoperability. Furthermore, as I will demonstrate, there is a direct tradeoff between flexibility and interoperability.
Let's consider AMI first since it's the less controversial case. I happen to know that you're aware that an AMI model can be written in any language; but regardless of which language it's written in, it must offer some subset of the pre-named functions AMI_Init, AMI_GetWave, and AMI_Close; and the signature of each of those functions must match the signatures defined in IBIS 5.0.
No flexibility in function signatures is offered; and, as a standards body we have officially all agreed that these signatures are sufficiently general to support a particular type of engineering analysis: the performance analysis of a high speed serial link.
As Arpad points out several times, however, this does limit what an AMI model can represent. It can't represent anything that can't be passed through the function signatures. That's the bad news.
The good news is that because these function signatures are nailed down, any model which supports these signatures can run in any EDA tool that supports these signatures. Furthermore, models from different vendors can be combined in the same simulation and they will function correctly together. That's the benefit of an interface, and it works the same way in software as it does for standard sizes for nuts and bolts.
Now for the case of AMS. AMS is a programming language and, as a programming language, it does offer the model developer a great deal of flexibility. Up to this point, Arpad's right again. However, that flexibility comes at a cost: -->There is no guarantee that any AMS model is going to work with any other AMS model any more than there is any guarantee that one C program will work with another C program, or that any MatLab program will work with any other MatLab program.<-- Two models will only function correctly together if they support the same interfaces.
Arpad is also right that one can write an AMI model in AMS; and if for whatever reason that's the language the model developer finds most appropriate, that's their choice. Be aware, however, that the limitations of the AMI interface will still apply, and there's nothing the AMS language can do to remove those limitations.
In short, you can't have both the flexibility of a programming language and the interoperability of a standardized interface any more than you can have your cake and eat it too. 

Hope this helps.
Mike S.

Muranyi, Arpad wrote:

Akshaye,

You are raising very good (and difficult) questions.  My responses
below are my personal views.  I am not sure that there is an "official"
recommendation by the IBIS Open Forum for these questions.

1)  The IBIS Open Forum does not recommend (let alone force) one or
the other method for modeling SERDES buffers.  Both methods are
equally "official" according to the IBIS specification, and people
need to make their own choices.

2)  Theoretically a tool or vendor cannot claim full support of any
IBIS versions, unless they implement all of its content.  Otherwise
it would be false advertising, but the IBIS Open Forum is not an
organization to police these kinds of things, so vendors can say
anything they want as long as they don't cause themselves trouble
with getting their customers or competitors angry.  In practice,
I am not aware of any vendor who has full implementation of any
IBIS version after about v3.2.  EDA vendors tend to implement what
they feel is best for their business goals.  It is totally up to
them and their customer base.

3)  Theoretically I don't see any issues.  If a tool has implemented
the *-AMS extensions and also supports the new IBIS-AMI specification
in v5.0, the two types of models should work together seamlessly.  I
am almost ready to say that this could be dine in Mentor's tools,
since we have a pretty good IBIS *-AMS support, and since our IBIS-AMI
support is actually also implemented using VHDL-AMS, there should be
no issues to put these two types of models together in the same
simulation.  However, as this hasn't been done yet, I can't tell
absolutely for sure that there may be no hurdles at all.  (If you
want to continue along these lines, please contact me off line).

However, keep in mind that the IBIS-AMI specification came about
mostly because most of the EDA tools do NOT have *-AMS capabilities,
and AMI supposed to bridge that gap.  I don't mean to hurt anyone,
but in my personal opinion, everything that IBIS-AMI can do could
also be done with *-AMS plus more (since *-AMS is like a virtually
unlimited programming language).  But the reverse is not true, you
cannot describe everything in IBIS-AMI that you could potentially
do with *-AMS. Members of the IBIS-ATM committee hoped that IBIS-AMI would become available sooner and more readily in EDA tools 
than *-AMS, and by standardizing the AMI we would see more than if
we had to wait for *-AMS.

This is where interoperability comes in.  Since it is expected that
more tools would implement support for IBIS-AMI than *-AMS, you may
be better off using AMI, with the sacrifice of giving up some
modeling freedom.  Keep in mind that if AMI cannot support some
modeling needs, we will have to add to the specification before it
will be officially available.  On the contrary with *-AMS you can
do anything the language(s) let you do today, as long as you have
a tool to do it with...

I hope this answered your questions.

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

-----Original Message-----
From: Akshaye Sama [mailto:a0741311@xxxxxxxxxxxxxxxxxxx] Sent: Tuesday, October 21, 2008 10:21 AM 
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: IBIS model for SerDes IO

Arpad, others,

As a Serdes (& model) provider, we would like to provide IBIS
models to enable system level multi-vendor SI simulations. With
IBIS 5.0 adding algorithmic model to the specification, there
are at least two ways of modeling serdes IO 1) using AMS,
2)using algorithmic model(AMI).

I would like to know the view of the IBIS committee on
1- Is it expected that model developers choose a method,
   based on what suits their circuit/requirements best? Does
   IBIS recommend/force a method for modeling Serdes IO?)
2- Is it expected that any tool which supports IBIS has to
   implement support for both AMS and algorithmic models
   before it claims IBIS 5.0 support?
3- Are there fundamental issues preventing use of an IBIS-AMI
   TX with an IBIS-AMS RX(or vice versa) for a link simulation?

The reason I ask, is that, some Serdes providers can model using
IBIS-AMS and others may use IBIS-AMI. How do I make sure that
my model is inter-operable with other serdes vendor's models?

Thanks,
Akshaye Sama

Texas Instruments Ltd.

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