Arpad,

Good questions, but probably a bit much for this forum. Tell you what -
let's take them up in today's call.

Todd.

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com
www.sisoft.com



Muranyi, Arpad wrote:
> Todd,
>
> Regarding the reasons you brought up for fixing these analog problems
> in the .ami file's specification take me out a few thousand feet to
> look at the broader picture of IBIS.
>
> For years, we have mentioned every once and a while the need to give
> the IBIS specification a complete overhaul. The reasons are quite
> obvious, there are many problems and limitations in the existing
> specification which needs to be fixed. The interaction between these
> issues is huge. The longer we wait, the worse the situation will get.
> If we don't do anything, the entire spec may collapse under its own
> weight.
>
> On the other hand, if we keep diverting everything from the original
> IBIS specification into other new specifications (such as the IBIS-ISS
> proposal, and this suggestion of describing analog buffer behaviors in
> the AMI specification), the IBIS specification could also die from
> becoming a useless empty balloon.
>
> So I would like to raise the question: Are we (consciously or
> unknowingly)
> leaving IBIS behind gradually, allowing it to die because we never have
> enough time to fix the real causes and reasons of the problems? Does
> this mean that there is no more value in having an IBIS specification?
>
> Thanks,
>
> Arpad
> ================================================== ======================
>
>
>
> ________________________________
> From: Todd Westerhoff [mailto:twesterh (AT) sisoft (DOT) com]
> Sent: Tuesday, February 09, 2010 10:32 AM
> To: Ken Willis
> Cc: Muranyi, Arpad; si-list (AT) freelists (DOT) org
> Subject: Re: [SI-LIST] Re: IBIS-AMI Vendor Support Help
>
>
> Ken,
>
> We are already talking about using the on-die S-parameter data as part
> of the analog model - in fact, we're talking about using S-parameter
> data as pretty much the entire analog model, as shown in slide 10 of the
> presentation Arpad referenced.
>
> I think confusion may come from conversations in the IBIS-ATM working
> group, where we've been talking about referencing on-die S-param data
> (used for the analog model) from the .ami file instead of the .ibs file..
>
> Walter is welcome to comment on the reasons for this, but I'll share my
> view - this is a purely pragmatic decision, designed to move SerDes
> modeling forward as fast as possible. We proposed syntax for including
> on-die S-params in the .ibs file at the Feb 2009 IBIS Summit, and the
> working group soon realized there were issues for single-ended,
> non-SerDes I/O that needed significant discussion. We've been looking
> for a way to limit scope and move forward faster - using the .ami file
> is one way to clearly indicate this is targeted for SerDes use and not
> intended as part of a broader, more general purpose solution.
>
> Todd.
>
> Todd Westerhoff
> VP, Software Products
> SiSoft
> 6 Clock Tower Place, Suite 250
> Maynard, MA 01754
> (978) 461-0449 x24
> twesterh (AT) sisoft (DOT) com
> www.sisoft.com
>
>
> Ken Willis wrote:
>
> Hi Todd,
>
> On #1, it makes sense to incorporate S-parameters into IO
> models, especially
> since some major IP suppliers have this data today. I think the
> item that
> brings some uncertainty is why this would be pushed into the
> algorithmic
> (AMI) portion of the model, especially if new syntax/API has to
> be invented
> and supported. The intent of AMI was to capture the adaptive
> filtering
> behavior of these advanced Serdes devices, which you couldn't
> really model
> well in a circuit model. If the S-parameters are largely
> parasitic data, it
> seems more straightforward to include them in the analog circuit
> part of the
> model.
>
> I understand that there is no standard "IBIS" syntax for
> S-params right now,
> but I would agree with Arpad that Touchstone is widely
> supported. Maybe we
> should be looking at [External Model] > Touchstone or something
> like that.
> But we can continue the discussion in the IBIS forum.
>
> Thanks,
>
> Ken Willis
> Sigrity, Inc.
> 860-871-7070
> kwillis (AT) sigrity (DOT) com
>
> -----Original Message-----
> From: si-list-bounce (AT) freelists (DOT) org
> [mailto:si-list-bounce (AT) freelists (DOT) org] On
> Behalf Of Todd Westerhoff
> Sent: Tuesday, February 09, 2010 9:29 AM
> To: Muranyi, Arpad
> Cc: si-list (AT) freelists (DOT) org
> Subject: [SI-LIST] Re: IBIS-AMI Vendor Support Help
>
> Arpad,
>
> Two points worthy of note:
>
> 1) I think there's a balance between adapting models to fit the
> current
> standard and extending the standard to improve the way we
> utilize vendor
> data. One of the goals we had for IBIS-AMI was to utilize model
> data
> vendors already have, S-parameter characterizations of on-die
> behavior
> being the obvious case. This should legitimately be considered
> part of
> the device model and IBIS-AMI should accommodate it as such.
> Telling
> people to include on-die S-parameters as part of the channel may
> comply
> with the current spec, but I don't think that's the way
> semiconductor
> vendors or users want to manage that data ... it just creates
> more
> opportunity for error.
>
> 2) A clear and unambiguous definition of on-die S-parameter
> syntax was
> presented at the Feb 2009 IBIS Summit, for exactly the reasons
> you
> mentioned.
>
> Thanks,
>
> Todd.
>
> Todd Westerhoff
> VP, Software Products
> SiSoft
> 6 Clock Tower Place, Suite 250
> Maynard, MA 01754
> (978) 461-0449 x24
> twesterh (AT) sisoft (DOT) com
> www.sisoft.com
>
>
>
> Muranyi, Arpad wrote:
>
>
> Sanjeev,
>
> I would recommend the following:
>
> Zero out the package related stuff in the .ibs file to
> basically turn package modeling off in it.
>
> Provide an S-parameter package file separately the same
> way as the channel's S-parameter file would be
> distributed.
> This could be documented in the .ibs file behind
> comments.
> The customer will use whatever method to include this in
> their favorite EDA tool.
>
> If there is a need for on-die interconnect parasitic
> modeling,
> it could be done the same way as the package model
> described
> in the previous paragraph. The two might even be
> combined into
> a single S-parameter file if that is more convenient or
> practical.
>
> I would NOT provide a speculated IBIS syntax or any tool
> specific syntax in the .ibs file for anything, unless a
> clear and unambiguous description is given, so that
> another
> EDA vendor could reproduce the same results with their
> products.
>
> For the rest of the buffer description I would encourage
> everyone to use existing IBIS constructs as far as
> possible.
> And again, if certain features cannot be described that
> way,
> I would encourage everyone to provide a detailed
> description
> for what needs to be modeled so that anyone could make
> their
> own model implementations using their favorite EDA tools
> based on that description.
>
> Thanks for asking the question.
>
> Arpad
>
> ================================================== =============
>
> -----Original Message-----
> From: sanjeev_gupta (AT) agilent (DOT) com
> [mailto:sanjeev_gupta (AT) agilent (DOT) com]
> Sent: Monday, February 08, 2010 5:29 PM
> To: Muranyi, Arpad; si-list (AT) freelists (DOT) org
> Cc: sanjeev_gupta (AT) agilent (DOT) com
> Subject: RE: [SI-LIST] Re: IBIS-AMI Vendor Support Help
>
> Hello Arpad,
>
> What will be your advice to companies who are ramping up
> on AMI? Should
> they include some non-AMI syntax for package modeling
> assuming that IBIS
> AMI standard will support these keywords in near future
> or provide these
> package model as a separate Touchstone file which can be
> integrated
> within simulation environment?
>
> Best regards
> Sanjeev
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the
> Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject
> field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
>
> http://www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable
> at:
> http://www.qsl.net/wb6tpu
>
>
>
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject
> field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> http://www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
>
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> http://www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request (AT) freelists (DOT) org with 'help' in the Subject field


List technical documents are available at:
http://www.si-list.net

List archives are viewable at:
http://www.freelists.org/archives/si-list

Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu