[SI-LIST] Re: IBIS-AMI Vendor Support Help
- From: Todd Westerhoff <twesterh@xxxxxxxxxx>
- To: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- Date: Tue, 09 Feb 2010 11:10:23 -0500
Arpad,
1) Sorry - am I missing something? I thought you recommended zeroing out
thepackage parasitics in the IBIS model and including the S-parameter data
for the package explicitly in the schematic (I agree with this method, given
the current limitations of IBIS package modeling). If the package data
becomes just one more set of passive cascaded S-parameters, how is the
simulator supposed to know which S-parameters represent the package and
whichrepresent boards or connectors? If we bundle the on-die S-params into
the package, and the package is effectively part of the channel, isn't that
the same as making the on-die S-parameters part of the channel?
I realize I'm debating semantics here and don't want to. The point I was
trying to make - we need to take all the data associated with the component
and make it part of the IBIS model. The problem at the moment is that the
modeling methods IBIS supports don't always give us the fidelity we need for
the analog and package models - so, let's improve them. This is a drum
SiSoft (and Walter in particular) has been banging for a long time.
2) Here's the thing - I look at slide 10 in
http://www.vhdl.org/pub/ibis/summits/feb09/hawes.pdf[1] and it's clear to me
what the syntax is, and how the S-parameter data is being used. Of course,
I'm close to the issue and have that advantage. Making sure this is clear
toeveryone is exactly what the standardization process is all about.
The challenge here is moving the standard forward quickly and effectively.
Let's all work together and do that!
Todd.
Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250
Maynard, MA 01754 (978) 461-0449 x24 twesterh@xxxxxxxxxx[2]
www.sisoft.com[3]
Muranyi, Arpad wrote: Todd, 1) I didn't tell people "to include on-die
S-parameters as part of the channel", I only mentioned that the on-die
S-parameters could optionally be combined with the ***PACKAGE***
S-parameters"if that is more convenient or practical". In other words, I was
not saying that this was the (only) way to go, I only suggested that as an
option. 2) I would actually challenge you on your statement that the
presentation you reference has "A clear and unambiguous definition of on-die
S-parameter syntax", because I don't think anyone could sit down and write a
working simulation netlist based on the "schematics" shown on pg. 7, 8, 10
inthat presentation: http://www.vhdl.org/pub/ibis/summits/feb09/hawes.pdf[4]
This is exactly the problem I am talking about. If someone writes a .ibs
filewith unexplained syntax or a presentation that is not precise enough to
know how to build a simulation netlist, it creates confusion. Everyone can
read something of their own interpretation into it, and your mileage and
results may vary. This is why I suggested that while we are in this
situationwith the lacking .ibs capabilities, anyone using a non standard
syntax should also provide a clear and unambiguous explanation along with it
so that everyone else reading it could still make a simulation netlist for
it. If the first two primary goals of IBIS-AMI is interoperability and
transportability, this shouldn't be too much to ask for... Arpad
========================================================================
============ -----Original Message----- From: Todd Westerhoff
[mailto:twesterh@xxxxxxxxxx[5]] Sent: Tuesday, February 09, 2010 8:29 AM To:
Muranyi, Arpad Cc: si-list@xxxxxxxxxxxxx[6] Subject: Re: [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.
Thisshould 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 ...
itjust 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@xxxxxxxxxx[7] www.sisoft.com[8] 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
filefor 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
touse 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
maketheir own model implementations using their favorite EDA tools based on
that description. Thanks for asking the question. Arpad
================================================================
-----Original Message----- From: sanjeev_gupta@xxxxxxxxxxx[9]
[mailto:sanjeev_gupta@xxxxxxxxxxx[10]] Sent: Monday, February 08, 2010 5:29
PM To: Muranyi, Arpad; si-list@xxxxxxxxxxxxx[11] Cc:
sanjeev_gupta@xxxxxxxxxxx[12] 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
canbe integrated within simulation environment? Best regards Sanjeev
------------------------------------------------------------------ To
unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx[13] with
'unsubscribe' in the Subject field or to administer your membership from a
web page, go to: //www.freelists.org/webpage/si-list[14] For help:
si-list-request@xxxxxxxxxxxxx[15] with 'help' in the Subject field List
technical documents are available at: http://www.si-list.net[16] List
archives are viewable at: //www.freelists.org/archives/si-list[17] Old
(prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu[18]
------------------------------------------------------------------ To
unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx[19] with
'unsubscribe' in the Subject field or to administer your membership from a
web page, go to: //www.freelists.org/webpage/si-list[20] For help:
si-list-request@xxxxxxxxxxxxx[21] with 'help' in the Subject field List
technical documents are available at: http://www.si-list.net[22] List
archives are viewable at: //www.freelists.org/archives/si-list[23] Old
(prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu[24]
--- Links ---
1 http://www.vhdl.org/pub/ibis/summits/feb09/hawes.pdf
2 mailto:twesterh@xxxxxxxxxx
3 http://www.sisoft.com
4 http://www.vhdl.org/pub/ibis/summits/feb09/hawes.pdf
5 mailto:twesterh@xxxxxxxxxx
6 mailto:si-list@xxxxxxxxxxxxx
7 mailto:twesterh@xxxxxxxxxx
8 http://www.sisoft.com
9 mailto:sanjeev_gupta@xxxxxxxxxxx
10 mailto:sanjeev_gupta@xxxxxxxxxxx
11 mailto:si-list@xxxxxxxxxxxxx
12 mailto:sanjeev_gupta@xxxxxxxxxxx
13 mailto:si-list-request@xxxxxxxxxxxxx
14 //www.freelists.org/webpage/si-list
15 mailto:si-list-request@xxxxxxxxxxxxx
16 http://www.si-list.net
17 //www.freelists.org/archives/si-list
18 http://www.qsl.net/wb6tpu
19 mailto:si-list-request@xxxxxxxxxxxxx
20 //www.freelists.org/webpage/si-list
21 mailto:si-list-request@xxxxxxxxxxxxx
22 http://www.si-list.net
23 //www.freelists.org/archives/si-list
24 http://www.qsl.net/wb6tpu
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List technical documents are available at:
http://www.si-list.net
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
