[SI-LIST] Re: IBIS-AMI Vendor Support Help
- From: Todd Westerhoff <twesterh@xxxxxxxxxx>
- To: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- Date: Tue, 09 Feb 2010 13:33:44 -0500
Arpad,
I agree - let's take this one back into IBIS-ATM and get it sorted out.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
Muranyi, Arpad wrote:
> Todd,
>
> 1) I think this discussion is spiraling into a rat hole because of some
> terminology differences. I don't think it is worth our time to go
> deeper
> into it... But to answer the questions you raise, yes, your summary of
> my recommendation is correct. I suggested to take the package (and
> possibly
> the on-die interconnect) model(s) out of the .ibs file context and put
> it
> (them) into the schematic editor of the tool. I used the word "channel"
> for anything that is between the package models of the Tx and Rx,
> regardless
> of where and how these package models are modeled. You seem to use the
> same
> word for anything that is in the schematic editor, regardless of what
> they
> represent. (I may add, someone else might use the word to describe
> anything
> that is between the Tx and Rx buffer models on the die). But I think
> this
> is all irrelevant. The point was that we were discussing the
> limitations of
> .ibs and I made a recommendation for how we could get around it while we
> wait for .ibs to get improved. It sounds like you are in agreement with
> that recommendation, so let's put this topic to rest...
>
> You raise the question, how does the tool know which S-parameter block
> is what. Does the simulator really have to know that?
>
> 2) Sorry, but that drawing on slide 10 drives me nuts. Why are there
> two
> voltage sources there back to back without anything connected to the
> node that is between them? Is that node assumed to be GND? Is the
> entire
> circuit really floating as it is drawn? Etc...
>
> Thanks,
>
> Arpad
> ========================================================================
> ===
>
>
>
> ________________________________
>
> From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx]
> Sent: Tuesday, February 09, 2010 10:10 AM
> To: Muranyi, Arpad
> Cc: si-list@xxxxxxxxxxxxx
> Subject: Re: [SI-LIST] Re: IBIS-AMI Vendor Support Help
>
>
> Arpad,
>
> 1) Sorry - am I missing something? I thought you recommended zeroing
> out the package 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 which represent 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
>
> 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 to everyone 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
> www.sisoft.com
>
>
> 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 in that
> presentation:
> http://www.vhdl.org/pub/ibis/summits/feb09/hawes.pdf
>
> This is exactly the problem I am talking about. If someone
> writes a
> .ibs file
> with 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
> situation
> with
> 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
>
> ========================================================================
>
>
> ------------------------------------------------------------------
> 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
>
>
>
------------------------------------------------------------------
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:
