[ibis-macro] Re: Comment on Sigrity's presentation
- From: "Ken Willis" <kwillis@xxxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 31 Mar 2010 13:57:50 -0400
Hi Arpad,
Yes, this exists in the current spec, but we feel this was ill-advised and
should be re-considered when we work on the 5.0 clean-up effort. This is
just Sigrity's opinion of course, but in a nutshell we think it should work
like this:
(a) If a particular filtering capability can be accurately represented with
Init_Returns_Impulse, then that should be the end of it. You don't need
GetWave in this case.
(b) If the filtering has some kind of advanced signal processing and complex
algorithms that require GetWave, then the model should use GetWave. That is
what it is for. If it doesn't require this added complexity and effort, see
(a).
So having both in the same model doesn't seem necessary. And cases where
multiple answers can be derived from the same model seems problematic for
both model and tool developers, and we think it will add confusion in the
user base. There is some historical precedent where users are accustomed to
using transistor-level Spice IO models for some applications, and behavioral
IBIS IO models for others. Both are useful, but users are very well aware of
which one they are using for what, and why they are doing so. We see no need
to change the existing historical mindset specifically for serial links.
Init_Returns_Filter clouds this picture even further (more different answers
from the same model), which is why we asked that it be put into its own BIRD
to be discussed separately.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, March 31, 2010 1:35 AM
To: IBIS-ATM
Subject: [ibis-macro] Comment on Sigrity's presentation
Ken,
I would like to make a comment on slide 3 of the presentation
you gave us in the ATM teleconference a week ago and the
discussion that followed.
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20100323/kenwillis/S
igrity%20AMI%20BIRD%20Feedback/Sigrity_AMI_BIRD_fback.pdf
If I understood the discussion correctly, you and Kumar are
concerned that one model could produce different results
when only its Init functions are used vs. when its GetWave
functions are also used. The discussion between you and Todd
ended in a disagreement.
However, it just occurred to me that the AMI portion of the
IBIS 5.0 specification already talks about the possibility
of having two types of analysis paths, one that only uses
the Init functions (for LTI systems), and another that also
involves the GetWave function when non-LTI effects are present.
This is found in Section 10, 2.1 and 2.2 in the specification.
Doesn't this close the discussion we had in the meeting when
you were presenting in a sense that you are challenging an
intent that is already clearly spelled out in the specification?
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
Other related posts:
