[ibis-macro] Re: IBIS-AMI Model Portability
- From: Mike LaBonte <milabont@xxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 29 Apr 2011 21:51:00 -0400
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
>
> Teraspeed® 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:
