One thing that is missing from Arpad's proposal is a defined location
for the impulse response boundary, and the port conditions required for
correct impulse response generation. This has to be explicitly spelled
out for AMI.
For example, if the die circuit is driven by a D/A converter, what is
the output impedance of the converter, and is it permissible to break
the model into frequency domain and time domain parts by removing the
connection from the D/A to the remainder of the circuit for direct
mathematical impulse response calculation. If so, what is the impedance
required at the port boundaries.
In other words, can the model be "dual use" with impulse response
calculated with either a digital time domain stimulus, or with the
linear combination of the wave-shaped pulse stream and the circuit
impulse response into a predefined port condition.
These are fundamental questions that make or break model portability
across tools and methods.
Scott
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC
On 12/21/2010 12:37 PM, Ken Willis wrote:
> Hi Arpad,
>
> Sigrity absolutely agrees with you. We have already learned from history
> with IBIS that hard-coded circuits will always hit limitations and tap out
> in applicability, as evidenced by the addition of [External Model],
> [External Circuit], etc. Standardizing on more hard-coded circuits make
> absolutely no technical sense to us whatsoever. Nor does coming up with a
> more limited, and redundant way of doing circuit modeling in the AMI space,
> rather than enhancing with IBIS-ISS. And keeping a clean delineation between
> circuit and algorithmic modeling was a base assumption of the original AMI
> spec, and is becoming dangerously blurred in some of the new cases we are
> seeing.
>
> Focusing on enhancing circuit modeling to make it more flexible with
> IBIS-ISS is the right direction in our opinion, and should much better
> position us all to model whatever new circuits are required for the future
> IO applications. Define the language and enable the model-makers to model
> the circuits they need, rather than define a few hard-coded circuits and
> shoehorn everyone into them.
>
> Thanks,
>
> Ken Willis
> Sigrity, Inc.
> 860-871-7070
> kwillis@sigrity.com
>
>
> -----Original Message-----
> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi,
> Arpad
> Sent: Monday, December 20, 2010 4:32 PM
> To: ibis-macro@freelists.org; IBIS-users; IBIS
> Subject: [IBIS] RE: [ibis-macro] BIRD 122 Sample SPICE Deck posted
>
> Hello Everyone,
>
> Now that we have seen the SPICE netlist of the analog models
> of BIRD 122 I would like to make a few comments, raise a
> few concerns and make a suggestion.
>
> The introduction section of Algorithmic Modeling in the current
> IBIS specification states the following on pg. 139:
>
> "The "analog" portion of the channel is characterized by
> means of an impulse response leveraging the pre-existing
> IBIS standard for device models."
>
> We are all aware of the shortcomings of IBIS [Model]s, so I
> am not going to reiterate them here and argue the need for
> improvements. BIRD 122 seems to suggest a solution for that,
> but the solution is targeting AMI needs only, and it is
> provided as an option: You either go with a less accurate
> IBIS [Model] or the more accurate analog parameters contained
> in the .ami file.
>
> Pg. 2 of BIRD 122 says:
>
> "Nominally, the simulation uses the traditional IBIS [Model]
> data from the .ibs file. This provides the highest level of
> model portability between EDA tools but does not always
> provide the highest level of simulation accuracy. These
> parameters define two additional levels of information
> that can be used to model the analog buffer."
>
> The problem I have with this is that the BIRD 122 proposal
> does not attempt to solve the real problem, which is the
> shortcomings of the IBIS [Model]. BIRD 122 suggests a
> solution strictly for IBIS-AMI purposes only and leaves
> IBIS modeling untouched. In addition, the suggested solution
> in BIRD 122 describes a few pre-defined "special purpose"
> circuits which are not accessible to anyone. These circuits
> are assumed, which means that they are hard coded into the
> AMI engine, they use pre-defined parameters with pre-defined
> meaning. This means that no-one can make any changes to the
> analog models without changing the specification itself.
> Considering that as soon as someone will need to model
> something that cannot be described by these hard coded models,
> it seems that the BIRD 122 proposal is only a half-baked
> temporary solution which does not provide a long term
> solution for AMI and does not address any of the fundamental
> IBIS modeling limitations at all.
>
> In addition to that, BIRD 122 seems to violate SiSoft's own
> recommendations which was posted in a public email on the
> ATM email reflector on 12/14/2010 in response to one of my
> messages. Mike Steinberger wrote:
>
> "...We need to continually remind ourselves what IBIS-AMI is in
> the first place. It's an _interface_ _definition_. That means
> that if both the model and the EDA tool comply with the
> interface definition, they can communicate with each other
> correctly. Period, the end.
>
> IBIS-AMI is not and should not be a specification of
> functionality, either for the model or the EDA tool..."
>
> To me, BIRD 122 seems to be nothing but a specification of
> functionality for both the model as well as the EDA tool...
> All of the discussions (arguments) we have on BIRD 122 in
> the ATM teleconferences are happening because we are trying
> to define functionality and we are at odds with each other
> on the details of that.
>
> The netlist we have seen from SiSoft in the last ATM meeting
> indicates that the analog models of BIRD 122 can be described
> with IBIS-ISS without any limitations or restrictions. Given
> that fact, I do not see why the analog models would have to be
> hard coded into the AMI engine and made inaccessible to IBIS.
> There is nothing in these netlists which cannot be accomplished
> with the proposals in BIRDs 116-118.
>
> In addition, I have demonstrated in BIRDs 116-118 and 125 that
> the legacy IBIS [Model] and its package model can be improved
> using the IBIS-ISS language in such ways that these improvements
> would also be available for AMI purposes. In addition, the
> analog model of BIRDs 116-118 is accessible to the model maker
> (and user) providing an open and flexible standard which will
> be usable in many unforeseen situations in the future without
> having to rewrite the specification for each new feature or
> capability needed.
>
> Also, BIRDs 116-118 do not define any functionality as far as
> I can tell. They describe the interface by which IBIS-ISS
> subcircuits can be made work together with .ami and .ibs files.
> The rest is up to the model maker. They (should) know which
> element in the S-parameter data should be zero or not, depending
> on what they put around the S-parameter (ideal source or matched
> impedance termination). If some of us feel that model makers
> need to be educated in this area, we should do that in a Cookbook,
> but not in the specification.
>
> Considering the fact that BIRD 122 needs substantial work to
> even just get the figures more understandable and match the
> SPICE netlist that we were shown in the last meeting, I would
> suggest that we should save SiSoft some time and vote BIRD 122
> down in favor of BIRDs 116-118 and 125. After all, these BIRDs
> would ensure the highest level of portability AND the highest
> level of accuracy WITHOUT having to chose from three different
> modeling options and WITHOUT the danger of having to rewrite
> the specification in a relatively short time.
>
> Sincerely,
>
> Arpad
> ===================================================================
>
>
>
> -----Original Message-----
> From: ibis-macro-bounce@freelists.org
> [mailto:ibis-macro-bounce@freelists.org] On Behalf Of Mike LaBonte
> Sent: Thursday, December 16, 2010 8:26 AM
> To: ibis-macro@freelists.org
> Subject: [ibis-macro] BIRD 122 Sample SPICE Deck posted
>
> As promised in the last ibis-atm meeting, the "BIRD 122 Sample SPICE
> Deck"
> (PDF) from Walter Katz has been posted to the ibis-atm work archive:
>
> http://tinyurl.com/2cqd4zg
>
> Or to avoid tinyurl tracking:
> http://www.eda.org/ibis/macromodel_wip/archive-date.html
>
> Mike
>
> ---------------------------------------------------------------------
> IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
> IBIS Macro reflector: http://www.freelists.org/list/ibis-macro
> To unsubscribe send an email:
> To: ibis-macro-request@freelists.org
> Subject: unsubscribe
>
>
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993Received on Tue Dec 21 14:03:07 2010
This archive was generated by hypermail 2.1.8 : Tue Dec 21 2010 - 14:03:13 PST