[ibis-macro] Re: Comment on Sigrity's presentation
- From: "Dmitriev-Zdorov, Vladimir" <vladimir_dmitriev-zdorov@xxxxxxxxxx>
- To: <kwillis@xxxxxxxxxxx>, "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 31 Mar 2010 13:25:54 -0600
I think the intent was to support quick and approximate analysis
(statistical, based on filter) and at the same time, more detailed and
accurate time domain simulation, that could take longer time, not always
affordable (especially with multi-variant analysis with thousands of
parameter combination).
Quick analysis is to preliminary select evidently good/bad cases, and
those in between could undergo more accurate but slower simulation.
I do not think this approach is clean and fully justified, at least in
frame of a single model, but this is how I understand its motivation.
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis
Sent: Wednesday, March 31, 2010 11:58 AM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: [ibis-macro] Re: Comment on Sigrity's presentation
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
---------------------------------------------------------------------
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:
