[ibis-macro] Re: IBIS-AMI Model Portability
- From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Sat, 30 Apr 2011 12:29:05 -0400 (EDT)
Mike,
I don't think you're missing anything, you're bringing up a valid point
that's been touched on before, but not explicitly discussed in this
thread.
<side point>
Before I get started, I need to comment on simulator compliance. IBIS is
a device modeling spec; it's up to EDA vendors to implement partial or
complete support, and establish that to their customer's satisfaction.
We've gone down the road of trying to establish how completely a given EDA
vendor supported IBIS in the pre-AMI days, and we didn't get anywhere. I
don't see why it would be any different now. I'm just sayin'.
</side point>
The point you're raising - will a model with "extra features" work in a
simulator that doesn't support those "extra features" - is valid, and even
central to the discussion. Specifically with regard to Out/InOut
parameters, Sigrity has consistently asserted that their current
back-channel models have a "compatibility" mode that lets them work in
simulators that don't support Sigrity's proposed back channel
implementation. This is true. We've run these models in "compatibility"
mode and they work.
SiSoft has always assumed (but has perhaps not stated clearly enough) that
Model_Specific/Info parameters would work without the need for a model
"compatibility mode". I'll take RX_Noise as an example - let's assume
that a particular "advanced model" has RX_Noise declared via a
Model_Specific/Info parameter with a value of 1mV. There are three
scenarios we see:
1. If the EDA tool understands RX_Noise, it reads it from the .ami
file and uses it. Yes, the simulation results are different than if
RX_Noise was 0, although not necessarily radically so. As Colin correctly
pointed out - if the parameter makes no difference, why bother?
2. If the EDA tool does not understand RX_Noise, but has an
equivalent simulator-specific noise feature, the model maker, EDA vendor
or user can inspect the provided .ami file and ensure the EDA tools uses
whatever simulator-specific setting is appropriate. As I've said before,
better to publish data and its meaning (even if it's not part of the
published standard) than to not publish data at all.
3. If the EDA tool does not understand RX_Noise and has no
equivalent simulator-specific noise feature, then the data is simply
ignored, and the simulator proceeds as it would have if the model had not
included a RX_Noise parameter at all. Nothing wrong with that, in our
opinion.
Back-channel models require communication between the RX and TX, which is
not provided in IBIS 5.0, so the models do require an explicit
"compatibility mode" to ensure portability. Sigrity built that into their
proposal from day one - they did the right thing for the right reasons.
The point you're making, and it's an excellent one, is that a model can be
portable and have advanced features. If I use the following scale (a
mash-up of Scott's latest proposal and some of my additions):
0 - no portability / proprietary
1 - Model uses BIRDs approved and referred from macro committee to full
forum / limited portability
2 - Model uses BIRDs approved by full forum / theoretical portability
3 - Model only uses current version of IBIS Specification / full
portability
Then the backchannel models Sigrity has proposed, and models that use
RX_Noise from proposed BIRD 123 - would both have dual ratings: 0 and 3.
That make sense?
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
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte
Sent: Friday, April 29, 2011 9:51 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: IBIS-AMI Model Portability
I think a more complete conversation about this topic would have to
include discussion of compliant simulators as well as compliant models.
This topic was triggered by a BIRD that would make some existing models
non-compliant with the IBIS spec. But unless simulators are rewritten to
suddenly refuse to use these models, which they were able to use just
before the rewrite, the "non-compliant" models will still work. Am I
missing something? Do any simulators today reject models that use
Model_specific Out parameters? And if so would those simulators be
compliant with IBIS 5.0?
I know this discussion is about expectations of compliance in general, but
it feels odd that it was triggered by models that are compliant ... so
far. We left an opening in the IBIS 5.0 spec, some models used it, and now
we are trying to close the opening. Has this been done before in IBIS?
Mike
On 4/29/11 5:44 PM, "colin_warwick@xxxxxxxxxxx"
<colin_warwick@xxxxxxxxxxx> wrote:
Understood, and I agree. So how about:
Models are either:
a) Compliant. Period.
Or
b) Non-compliant, advanced/experimental. Caveat emptor: this is a
proprietary unique solution for a unique (set of) customer(s). It is up to
that customer(s) to deal with whatever risk they wish to take with this
non-compliant model. It has the following characteristics (for the
interested reader only):
"Here is my advanced/experimental model and I claim it runs correctly in
the following (one or more) EDA tools: A, B, C, D. Here is my verification
report for Tool A. Here is my verification report for Tool B. (etc.) It
may or may not run in other tools but I haven't checked. Ask the vendor.
Or make it worth my while and I'll check it for you. By the way, you might
like to know that this model contains the following (one or more) BIRDS
and/or proprietary extension. Here is the status of each one:
Proprietary extension 1 or BIRD xyz one of:
0 - no BIRD or BIRD proposed and not yet approved by macro committee
1 - BIRD approved and referred from macro committee to full forum
2 - BIRD approved by full forum, not yet ratified, but will be in the next
release of the standard
Proprietary extension 2 or BIRD abc
Etc.
"
From: Syed Huq (huqs) [mailto:huqs@xxxxxxxxx]
Sent: Friday, April 29, 2011 4:43 PM
To: WARWICK,COLIN (A-Americas,ex1); scott@xxxxxxxxxxxxx;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: IBIS-AMI Model Portability
Hi Colin,
I like things to be simple. Either it is Compliant or it is not.
Example:
If I want to buy a DDR3 or a PCI-E device, I want *all* features of the
spec to be met by the Silicon. I don't use something that is half way
there or something that does more than the spec but has shades of grey
(unknown, uncorrelated, specs). On a system level implementation, it can
create a lot of problems.
Models should be treated the same.
If a model is not compliant to the spec then there are no more grey shades
to that model. It is a proprietary unique solution for a unique customer.
It is up to that customer to deal with whatever risk they wish to take
with this non-compliant model. A BIRD that is not approved is not a Spec.
Tks
Syed
From: colin_warwick@xxxxxxxxxxx [mailto:colin_warwick@xxxxxxxxxxx]
Sent: Friday, April 29, 2011 11:43 AM
To: Syed Huq (huqs); scott@xxxxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: IBIS-AMI Model Portability
Hi Syed,
Hmmm. you have a good point. So how about this:
Models are either:
c) Compliant. Period.
Or
d) Advanced/experimental, with the following characteristics (for the
interested reader only):
"Here is my advanced/experimental model and I claim it runs correctly in
the following (one or more) EDA tools: A, B, C, D. Here is my verification
report for Tool A. Here is my verification report for Tool B. (etc.) It
may or may not run in other tools but I haven't checked. Ask the vendor.
Or make it worth my while and I'll check it for you. By the way, you might
like to know that this model contains the following (one or more) BIRDS
and/or proprietary extension. Here is the status of each one:
Proprietary extension 1 or BIRD xyz one of:
0 - no portability: no BIRD or BIRD proposed and not yet approved by macro
committee
1 - BIRD approved and referred from macro committee to full forum
2 - BIRD approved by full forum
Proprietary extension 2 or BIRD abc
Etc.
"
For models users that absolutely positivity need portability they could
stop reading at the label "advanced/experimental." Brave souls who need
advanced features yesterday could read on into the gory details.
Thoughts?
-- Colin
From: Syed Huq (huqs) [mailto:huqs@xxxxxxxxx]
Sent: Friday, April 29, 2011 2:13 PM
To: WARWICK,COLIN (A-Americas,ex1); scott@xxxxxxxxxxxxx;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: IBIS-AMI Model Portability
This can be a night mare of a solution for the end users.
Now I have to track which model is rated what (0, 1, 2, 3) and could
*possibly*work on which tool (A, B, C, D etc).
So now I have to have all versions of EDA tool out there so I can make use
of these new rated model ?
Is that a solution ? Not at all.
-Syed
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
colin_warwick@xxxxxxxxxxx
Sent: Friday, April 29, 2011 10:39 AM
To: scott@xxxxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: IBIS-AMI Model Portability
Hi Scott,
I like this because it's crisp. We could combine the suggestions:
"Here is my model and I claim it runs correctly in the following (one or
more) EDA tools: A, B, C, D. Here is my verification report for Tool A.
Here is my verification report for Tool B. (etc.) It may or may not run in
other tools but I haven't checked. Ask the vendor. Or make it worth my
while and I'll check it for you. By the way, you might like to know that
this model contains the following (zero or more) BIRDS and/or proprietary
extension. Here is the status of each one:
Proprietary extension 1 or BIRD xyz one of:
0 - no portability: no BIRD or BIRD proposed and not yet approved by macro
committee
1 - BIRD approved and referred from macro committee to full forum
2 - BIRD approved by full forum
3 - BIRD integrated into next version of IBIS specification
Proprietary extension 2 or BIRD abc
Etc.
"
-- Colin
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Friday, April 29, 2011 11:44 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: IBIS-AMI Model Portability
Todd
I'd use the following rating
0 - no portability
1 - BIRD approved and referred from macro committee to full forum
2 - BIRD approved by full forum
3 - BIRD integrated into next version of IBIS specification
There is too much uncertainty in what happens when a BIRD proposal is
initially introduced. At that point I'd say there is no portability.
Usage of the feature is still proprietary Portability is only a
possibility when more than one EDA vendor is willing to commit software
engineering resources to add the feature. It's unlikely that this would
occur prior to macro committee approval.
Scott
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
http://www.teraspeed.com
TeraspeedR is the registered service mark of
Teraspeed Consulting Group LLC
On 4/29/2011 10:56 AM, Todd Westerhoff wrote:
Colin,
Thanks for your thoughts on the subject. I've been pondering the subject
as well and have something I'd like to propose for discussion.
Isn't the main issue here one of model portability between different EDA
tools? In particular, the ability of model makers, EDA vendors &
end-users to understand the likelihood that a particular IBIS-AMI model
will run in a particular EDA tool? It seems to be that "Compliant" is a
really broad term that can encompass everything from whether a model's
simulated output fits within a protocol's allowed jitter spec to whether
the model uses an agreed upon convention for documenting the analysis
modes the model supports. We need to care about all those things, but I'd
like to start with a way to assert whether a particular model will run in
a particular tool or not.
If I use a singular term (like Compliant or Compliant By Any Other Name),
the world is black and white - the model's either Compliant or it isn't.
That would work In a perfect world, but in practice, models come in black,
white and shades of grey. For sake of argument, I'll propose a
portability scale where 3 is the best (white), and 0 is the worst (black).
Let's assume the scale means the following:
`
0 (black) - The model has no portability. It's either completely
proprietary or uses features that haven't been publicly defined, such that
there's no chance of running it in multiple tools.
The model has limited portability. It uses features that have been
proposed for standardization, but that have not been approved yet. One or
more EDA tools may support it, but both the model and the EDA tools that
support it may need to change as the standard evolves.
The model has theoretical portability. It uses a combination of features
that are part of the published standard and features that have been
approved for inclusion in future versions of the standard. There's a
chance that those new features will get changed as they get incorporated
into an updated standard, but the risk is considered low. The model and
EDA tools that support it may need to change to support future versions of
the standard, but probably not.
3 (white) - The model is completely portable. It uses only features
that are part of the published standard, and if it doesn't work in a given
EDA tool, it's most likely the EDA vendor's problem.
Would a rating scheme like that help? It seems to me the issue we're
grappling with is not black and white compliance, but risk assessment in a
practical sense.
I'm happy to discuss any variation on this theme that we can all agree on.
What do you think?
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 <http://www.sisoft.com>
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
colin_warwick@xxxxxxxxxxx
Sent: Thursday, April 28, 2011 11:43 AM
To: Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx; ibis@xxxxxxx
Subject: [ibis-macro] Re: Minutes from the 26 Apr 2011 ibis-atm meeting
Proposed
Hi All,
It seems to me that the purpose of a standard is to promote the creation
of portable models. Why go to all the trouble of a long series of tense
committee meetings between competitors otherwise? Portability comes at a
price and that price is that it takes longer to incorporate innovation.
The definition of a portable model isn't just that it is syntactically
compliant with the standard, it must also be semantically compliant in
that it should give the same answer (within some acceptable accuracy) on
all compliant simulators.
If an model contains proprietary extensions it is, by this definition,
non-compliant because it is deliberately engineered to give a radically
different answer (when run on a simulator with the matching proprietary
capability) than a model without the extension. Why bother adding the
extension otherwise? Sure, the model might run in a simulator without the
matching proprietary capability, but clearly it will then give the wrong
answer, which is worse than not running at all.
It doesn't matter whether the proprietary extensions are documented or
undocumented by the originator, nor whether they are proposed as a BIRD or
not, nor whether they have technical flaws or not: they are still outside
of the ratified standard, therefore controlled only by the author (who
could change it at will to match their latest simulator release), and
therefore models that use it are de facto non-portable.
I have no objections to proprietary extensions. They have the advantage
that innovation can be included quickly, but the disadvantage is that
models that include them are non-portable.
So my point (and I do have one) is that models with proprietary extensions
should not be labeled "compliant." That label should be reserved for
portable models that are both syntactically and semantically compliant
with the ratified standard of the time.
My $0.02
-- Colin
This is a retitled thread, the rest of the original thread has been
removed to reduce bandwidth on the reflector .
<snip>
Other related posts:
