[ibis-macro] Re: Format and deprecation in general
- From: Ambrish Varma <ambrishv@xxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 14 Sep 2010 15:17:04 -0700
All,
Actually, we make use of the Format keyword quite a lot and our parser does not
ignore it but uses it. Somewhere in our flow, instead of looking for the
various formats (range, value, corners etc (or any other future format)) our
parser just checks for the word 'Format'. So if it is eliminated, we would have
to add it to make the current flow work - or change our flow.
Ugly as it might be - it is quite useful.
Thanks,
Ambrish.
Ambrish Varma | Member of Consulting Staff
P: 978.262.6431 www.cadence.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Walter Katz
Sent: Tuesday, September 14, 2010 5:45 PM
To: Arpad_Muranyi@xxxxxxxxxx; IBIS-ATM
Subject: [ibis-macro] Re: Format and deprecation in general
Arpad, Ken,
This is making a mountain out of a molehill. If one writes the parser to
ignore Format, which in fact the parser does today with just one exception,
then all one has to do is simply filter out the token format when processing
ami files. Thus old and new AMI files will work just fine. This is trivial
coding, and it will clean up the language definition, and the differences
between the parameter string passed to the DLL and the parameter string in
the .ami file.
Walter
Walter Katz
303.449-2308
Mobile 303.883-2120
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Muranyi, Arpad
Sent: Tuesday, September 14, 2010 5:33 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Format and deprecation in general
Ken,
Thank you for your note. I tend to agree with you on this one.
In fact I have the same thinking about some of the other
"deprecation" topics, such as Use_Init_Output, etc...
I am not sure if you were present in the meeting a few weeks ago
when we talked about deprecation for some time, and I was voicing
similar thought as you do in this message. While the discussion
was still going, one of the attendees sent me a link in a chat
window with the definition of "deprecation" in Wikipedia, which
states that deprecation is a preparation for elimination, kind
of a warning that in the future something will go away, but not an
immediate removal of that item. To me this came across as if the
person wanted to tell me that we should not eliminate things abruptly
from our specification, giving time for people to get used to the
changes.
The problem I have with this thinking is exactly what you are saying.
During the transition period, both the old and new ways have to be
supported. This makes things more complicated. In our case, when
the flow will most likely require different algorithms as well as
models, I really don't see why it is a good idea to support the
Use_Init_Output Boolean for a while, when the new flow would ignore
it anyway. You can't write a new model for the new flow and reasonably
expect that this Boolean would have any use. On the other hand,
old models which do use this Boolean would rely on the old flow,
so there is no reason to mix the new flow with the existing Boolean.
Since the changes we make in the spec will most likely require a
version number to tell the tool how to go about using the model,
to me it would make sense to abandon some of the deprecation items
right away without any overlapping between the existing and the new
specifications.
If someone can bring up a compelling reason to the contrary, I may
change my mind, but so far I don't see any reasons for doing things
piece mail.
Thanks,
Arpad
===================================================================
-----Original Message-----
From: Ken Willis [mailto:kwillis@xxxxxxxxxxx]
Sent: Tuesday, September 14, 2010 3:36 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] IBIS-ATM teleconference - Agenda for 9/14/2010
> Format
Hi Arpad,
Here is the feedback on "Format" which you requested me to send through
email.
If we were completely doing away with Format, that would be one thing.
But
the current proposal is to still support that, plus also support NOT
having
it there. It doesn't seem like we are really simplifying anything then;
instead we are adding more things that will need to be supported. I
think
that is going in the wrong direction, adding more complexity to the
spec.
The software coding purists don't like Format, but if it is there
already,
and it isn't going to go away, then adding support for Format's ABSENCE
is
more trouble than it is worth.
This is just one opinion of course, and I am curious to see if anybody
else
agrees. It seems like there are bigger fish to fry than this one.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, September 14, 2010 11:28 AM
To: IBIS-ATM
Subject: [ibis-macro] IBIS-ATM teleconference - Agenda for 9/14/2010
Time: September 14, 2010 Noon US Pacific Daylight Time
=====
Audio:
======
Voice dial-in: (800) 637-5822
International: +1 (647) 723-3937 <--- (For Canada)
0114501530 <--- (For Sweden)
0201400572 <--- (For Sweden Toll Free)
069509594672 <--- (For Germany)
08001014542 <--- (For Germany Toll free)
Access Code: 685-0440
Web
===
Click Here to Join Live Meeting:
http://tinyurl.com/yvmesj
or:
https://www.livemeeting.com/cc/sisoft/join?id=NKQQN3&role=attend&pw=TP8j
%23-%25%7E5
Mentor Global Crossing Teleconference commands:
http://www.globalcrossing.com/customer/collaboration/cust_ready_access_t
ips.aspx
FIRST TIME USERS: To save time before the meeting, check your
system to make sure it is compatible with Microsoft Office Live
Meeting.
---------------------------------------------------------------------
Agenda
======
1) Opens
2) Call for any related patent disclosures
3) Review of ARs:
Authors of the flow BIRD: Correct the text in the areas discussed
in the meeting.
Any new AR-s?
Old ARs:
- Arpad: Write parameter passing syntax proposal (BIRD draft)
for *-AMS models in IBIS that is consistent with the
parameter passing syntax of the AMI models
- not done
- TBD: Propose a parameter passing syntax for the SPICE
[External ...] also?
- Arpad: Review the documentation (annotation) in the macro libraries.
- deferred until a demand arises or we have nothing else to do
4) Quick review of the Task List (Arpad)
5) Introducing new BIRD drafts (see attachments) (Arpad)
- MinTypMax_BIRD_1
- Typos_Format_Value_Default_BIRD_1
6) Discuss Walter's three BIRD drafts:
- Format
- Labels
- Value_Default
7) Update on Walter's flow BIRD draft (Walter)
- editorial comments and questions
- dealing with the deprecation of Use_Init_Output
Thanks,
Arpad
=====================================================================
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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:
