I sent this to Mike over the weekend, somehow managing to not send it to the list.
I'm not sure that the BIRD makes any existing models not-compliant at all. That remains to be seen. Do you personally know of any models out there that use Out or InOut parameters to alter *flow *or *results*? If they do not, they are still compliant. I don't know the specifics of the Gennum Backchannel model, but we can all agree that that model is using mechanisms that alter flow or results, and that currently that functionality is non-compliant, or using Todd's better word, *non-portable*. The model would still load into other EDA tools and be capable of use in a "standard functionality" mode, where the backchannel functionality is disabled. But the full intended functionality of the model would not be achieved in any but the original target simulator. The standard functionality mode is compliant (or portable). The enhanced proprietary functionality mode is not compliant (or not portable).
If we agree that IBIS as a portability specification, then a desired function of the specification is to encourage modelers to use portable constructs whenever possible, and highlight instances when they are using non-portable constructs. It is also a desired function that the specification encourage modelers to submit non-portable constructs for standardization through the BIRD process. Finally it is a desired function of the IBIS committees involved to guide the BIRD process to standardization of generalized constructs that cover specific current needs and future needs, to avoid a "hodgepodge" of keywords, parameters, ... etc, that have only one specific usage. These have always been the goals of IBIS specifications.
There are plenty of enhancements that were introduced by EDA vendors or model makers that were approved nearly as-is, with little modification, and plenty of enhancements that were introduced that were approved with significant modifications, requiring the original submitter to change their models to meet the specification and write code to use the new format in EDA tools. There are also plenty of parties who have ignored the specification process altogether, and used comment line keywords to allow users to add proprietary functionality into distributed and existing models, in order to support proprietary simulator features. It is well-known that these features are non-portable. Usually, however, these proprietary features were added into models by the user, who could edit the ASCII text files.
In the early days of IBIS portability issues came up all the time. There was IBIS, and there was Quad Design. Quad Designs model format was proprietary and different from IBIS. It's models were not portable to IBIS simulators. There were two solutions to this problem. First, features unique to Quad models were often standardized in IBIS with an IBIS-specific format. Second, IBIS simulator vendors created Quad To IBIS translators. This solved both the specification problem and the portability problem, since there was a 1-to-1 mapping from one format to the other. Yet other simulator vendors, like Cadence, had their own internal proprietary format, DML. A translator from IBIS to DML, and I believe Quad to DML were used to solve that portability issue. Eventually the IBIS to DML translation was integrated and for all purposes the tool was an enhanced IBIS simulator, with many additional features under the covers. There was a point when IBIS became the accepted standard for I/O modeling, and even Quad had to create an IBIS to Quad translator, as Intel no longer supported the Quad format.
Unfortunately, the model is no longer in the clear. A substantial portion of the model is in the hard-coded DLL, and cannot be modified by a translation script. Portability questions then arise in several ways:
* When the model maker creates proprietary models with parameter
names and formats to support new functionality, and the committee
agrees to include those parameters in the spec at some future
date, with minor or major alterations.
o In this case, we can say that the original model is
proprietary, and document that fact so that end-users and
other EDA vendors are not surprised by the new functionality.
+ It is then each vendors' responsibility to determine
whether it is in their best interest to incorporate
those proprietary parameters, or wait until an IBIS
specification is approved.
o We can agree that once a specification for the functionality
has been approved, that new models going forward should
incorporate the specified syntax. We cannot dictate whether
they do.
+ As in past IBIS modeling efforts, vendors may choose
to provide a mapping mechanism to allow proprietary
models to run in their systems, in order to support
their customers.
# A good example of this would be EDA vendor
support for HAL 9000 IBIS-AMI models that use
features that are proprietary and therefore
not-portable. Each EDA vendor then chooses (or
does not choose) to provide a custom portability
design kit.
* When the model maker creates proprietary models with parameter
names and formats to support new flow or result altering
functionality. That new functionality is inherently
non-portable. Translation or mapping cannot necessarily be used
to provide the necessary functions.
o In this case, we can say that the original model is
proprietary, and document that fact so that end-users and
other EDA vendors are not surprised by the functionality,
and are informed that the functionality will only perform as
expected in specific tools.
o Because these flow/result altering model functions have deep
architectural implications at the EDA and model making
levels, it should be strongly encouraged that the model
makers come to the IBIS committee as soon as possible, to
work towards an agreed upon specification.
+ If a specification is agreed upon, it makes sense for
the original model makers to revise their models to
meet the final form of the specification, and all
future models using these functions to code to the
specification.
o It is exactly this class of proprietary model problem that
the Out/InOut Bird seeks to highlight and avoid as much as
is possible.
If we all can agree on several points, I believe the committee process
will become smoother and faster:
* Portability
o across platforms is good, as it allows for rapid market
acceptance.
* Generality
o of constructs is good, as it allows for rapid portable
feature enhancement.
* Collaboration
o on specification allows for a result that is greater than
the sum of it's parts.
Peace out
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 9:51 PM, Mike LaBonte wrote:
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?MikeOn 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>
