[ibis-macro] Re: IBIS model for SerDes IO
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 21 Oct 2008 13:39:32 -0700
Mike,
Thanks for your comments, they certainly helped to paint a more complete
picture on this topic. I have only one minor comment on the statements
you made about the necessity of having a standard interface to ensure
interoperability.
While your comment is true, I think it may be a slightly bit overstated.
Take, for example, the good-old SPICE subcircuit. While it is true
that there are numerous cases when incompatible subcircuits cannot be
connected together directly (if, for example, their nodes are in the
wrong order or if they have a different number of nodes, or parameters),
this doesn't mean that the subcircuits couldn't be connected together
indirectly, or partially and still have a successful simulation.
So I am just trying to say that freedom in itself may not prohibit
interoperability, especially if direct connectivity (or communication)
between the components is not required.
In terms of IBIS-AMI, in general, I don't think that there is an absolute
need for the Tx and Rx algorithmic models to be able to communicate with
each other directly. I can easily envision an *-AMS Tx model with a totally
different interface and another *-AMS or even AMI Rx model communicating
with the tool, still be able to exchange the relevant information about
channel response, etc... I don't dispute, complications may arise if
relevant information is missing, or is formatted in an incompatible manner,
but I don't think that the situation is as prohibitive or exclusive as
it came across to me from your message.
My $ 0.02...
Arpad
=============================================================================
-----Original Message-----
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Tuesday, October 21, 2008 2:54 PM
To: Muranyi, Arpad
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: IBIS model for SerDes IO
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.
---------------------------------------------------------------------
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:
