[ibis-macro] Re: IMPORTANT question about IBIS-AMI keywords
- From: Bob Ross <bob@xxxxxxxxxxxxx>
- To: Arpad_Muranyi@xxxxxxxxxx
- Date: Wed, 09 Dec 2009 21:02:54 -0800
Arpad:
In response to your questions, here are some bullet point
considerations on the choices.
Most would also apply to Question 2, and I may add some specific
points on it later.
Overall I favor 1a) and 2a) for cost, resource, schedule, performance,
quality, efficiency, potential clarity, minimum risk, fastest industrial
adoption, least industrial disruption, and minimal customer
support reasons along with some possible direct benefits with
this syntax.
Other people can add more Pro/Con points for any of the choices.
Bob
---------
Question:
1a) Shall we retain Model_Specific and Reserved_Parameter
branches as required?
1b) Shall we retain Model_Specific and Reserved_Parameter
branches but not make them required?
1c) Shall we remove Model_Specific and Reserved_Parameter
branches from the AMI specification?
----------
Pro 1a)
1. In Place Now: Currently required and documented per committee
agreement and long processes
2. In Place Now: Currently ibischk5 parser code and in related test
cases now publicly available and also paid for and shipped
to developers, some of whom will now schedule adding it to a product
3. Minimum Time and Priorities: Committee can focus now on some higher
priority issues now instead of some details related to this issue
4. Industrial Adoption: Developers who implement ibischk5 parser can
proceed with the code as delivered without risking a forced degradation
at an uncertain future date
5. Trivial Incovenience: Two extra text required parameters is minimal
overhead
6. Clarity: Visual grouping of reserved and model specific parameters
helpful for teaching and understanding the AMI specification
7. Better Syntax Checking: Clear separation of officially standardized syntax
helpful for explicit syntax checking, versus not detecting (for example)
a spelling error producing an unintended but legally compliant
Model_specific parameter
8. New Standard Syntax Clarity: Clear Separation of reserved parameters
helpful for identifying new standardized parameter syntax as AMI
revolves
9 . In Place Separation Useful: Structure in place if another separation
parameter is considered as an excellent solution to some future issue
10. Fix Existing Problems: Tools and experience and understanding in place
to fix existing Current Spec problems as a priority
11. Promote Industrial Adoption Now: Can move forward now to promote clean
industrial adoption versus maintaining the current situation with numerous
private arrangements supporting several unique vendor-specific syntaxes
Con 1a)
1. Migration from Model_Specific to Reserve_parameter: No rule or process
yet on how to do this
Pro 1b)
1. Helps Industrial Migration: Two choices retained forever eliminates
some industrial migration issues
2. Avoids Incompatibilies: Allows industry adoption now without any future tool
support, model support or customer support forced incompatibilty
3. Still Simple: Only two extra parameters and still simple rules
4. More Graceful IBIS Committee Migration: In place code and test cases, all
with the required parameters still used for all test cases
5. Maintains Full Documentation: Does not require looking at different
versions of Specification for details on historically legal syntax
Con 1b)
1. Wasteful: No technical benefit for providing functionally equivalent
syntax choices
2. Slight complication: Rule could be both or none, but it could
also allow only one of Reserved_parameter and Model_specific -
a slight specification complication and discussion
Pro 1c)
1. Clean syntax: Start fresh now with one choice and avoid carrying legacy
syntax
Con 1c)
1. Early Adoption Forces Duplicate Syntax Anyway: Resolution
to practical graceful EDA Version upgrade for customer support
(when the 1c option is available and implemented) requires in
practice and privately option 1b anyway to continue supporting
exisitng [IBIS Ver] 5.0 and new 5.X models
2. Setback to Industry: Nothing is in place now, and it will take
year(s) to get to our current state today (BIRD development, approval,
Version 5.X approval, new parser project start and completion)
3. Setback to Industry: This requirement is part of a large set
of proposals (now ~23 pages) with some possibly contentious
issues - no schedule committment due to complexity
and new very detailed considerations
4. Risk of Other Serious Problems: New features as part of when this
requirement could introduce new, unanticipated serious problems
that further delay actual adoption by industry
5. Creates Large Time Window for Future Industrial Incompatibily:
Upgrade (or purposeful delayed upgrades) by EDA Vendor, Model
providers and Customers are always out of sync and based
on individual priorities, concerns, and resources - creating
a large time window of models and tool incompatibiliies
6. No Financial or Business Benefit: No business gain or financial
benefit for this change when parameters required today
are made illegal
7. Practical Support Issues: Most vendors will have migration support
issues/costs with the abrupt change (large list of topics)
8. Barrier to Sales or Upgrades: Customer libraries and compatibiliy
issues
9. Divides Industry: Create Reasons for some to move one
direction ahead of time and others to go with the existing Spec.
10 Contrary to an exiting cornerstone requirement of IBIS for
being downward compatible (that contributes to IBIS success)
11 Continued Private Solutions: A planned deprecation in the
the unpredicted future with unspecified new features encourages
existing private solutions and existing private arrangements
(including promoting this unofficial feature and undercutting
current IBIS)
12 EDA Vendor Documentation: Both alternatives should always be
supported by most vendors - another wasteful overhead
13 Model Providers Supply Two Versions: Broad tool support may
require two equivalent versions (same problem for company Model
Librarians)
--
Bob Ross
Teraspeed Consulting Group LLC Teraspeed Labs
121 North River Drive 13610 SW Harness Lane
Narragansett, RI 02882 Beaverton, OR 97008
401-284-1827 503-430-1065
http://www.teraspeed.com 503-246-8048 Direct
bob@xxxxxxxxxxxxx
Teraspeed is a registered service mark of Teraspeed Consulting Group LLC
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
