[ibis-macro] Re: IMPORTANT question about IBIS-AMI keywords
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 15 Dec 2009 07:35:21 -0800
Eckhard,
Correct, Model_specific is already optional, but not exactly
for the same reason. Currently it is optional because not
all models may need parameters from that section. The proposed
optionality is more along the lines of using the keyword as
a "separator" between the required and optional parameter
branches even when model specific parameters exist in the model.
We are not proposing to remove the entire content of these
branches. The parameters behind (or under) these branches
would still remain, but would be stepped up by one notch
in the hierarchy. This is kind of like flattening out a
hierarchical netlist, taking things out of two subcircuits
and putting the content of them to the top level of the
netlist without using the subcircuit statements.
Regarding your vote below, I am sensing that you may be voting
the middle ground because you feel that optionality gives us
a little more freedom of choice. In the light of what I wrote
in my answer to the first question above, I wonder if you
still hold that opinion.
For the 2nd question the issue is more of a syntax cleanup
issue. Format, as it is today is already inconsistent with
the rest of the spec, beaus it has three items inside the
parentheses, not two, and together with Default it may be
completely redundant. We would like to clean that up (i.e.
get rid of it completely), but the a vote "2b" would require
us to keep the existing syntax for the future which is what
the proposal wants to eliminate...
I can certainly relate to your general comments on the IBIS
spec. I sympathized with Mike Mirmak's proposals of having a
complete overhaul of the spec, but that is almost like starting
over from scratch. Well, not quite, because we would have a lot
of experience in spec writing, but the new spec would be like
starting over. This would be a lot of work, but would allow
us to get rid of a lot of baggage that we are carrying around
for mostly historical reasons (and backward compatibility).
A complete overhaul would be very expensive, in terms of
writing the spec as well as EDA tool implementation, and it
feels that as long as we can keep patching the old spec, we
will just keep doing that, even if it is becoming more and
more painful. I wonder some times whether IBIS will just die
a natural death for this very reason... Well, we will find
out at some point in the future. Either way, the questions
being voted on are an attempt to correct a few things in the
AMI syntax early on so that these issues wouldn't haunt us for
the rest of the life of the AMI spec...
Thanks,
Arpad
===============================================================
-----Original Message-----
From: Lenski, Eckhard (NSN - DE/Munich) [mailto:eckhard.lenski@xxxxxxx]
Sent: Tuesday, December 15, 2009 9:04 AM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: IMPORTANT question about IBIS-AMI keywords
Hello,
Some questions/remarks from my point of view:
1) concerning 1a,1b) is the section Model_specific not already optional in
the spec ?
2) concerning 1c) if we remove the branches from the spec, will the concluded
parameters appear somewhere else ?
3) general :
I do have my experiences with IBIS spec on the one side and their
implementation in the tools form the other side
E.g. [external model] and [external circuit]
- So some parameters appear in the spec, but the tool ignores them
- Some parameters are in the spec , and the tool gives me an error
- Tools have another way of using a described ibis feature
- All I got is a table, where it is stated, which parameters are supported and
which are not.
4) ibis spec :
We have introduced in the past a lot of parameters/keywords in the ibis spec,
which never ever made it inside a model delivered from Ic vendors.
So I think we don't have to remove the above mentioned parameters , may be
there should be a cook book, which explains not to use these specific
parameters.
On the other side, we made some changes in the ibis check program, e.g where we
changed the way of checking models
E.g. we changed check of non monotonic behavior from 'each curve has to be
non-monotonic' to 'the sum has to be non monotonic'
( correct me if I am wrong )
So although we did not change the spec, we might get different results from
checking the models with different parser-versions.
So coming back to the two questions
( Having in mind, that there should not be too many AMI models already
released , if we change parameters/keywords from required to not required, the
errors should be less )
Question 1 :
I support answer 1b) making them not required or optional
Question 2 :
I support answer 2b) make the Format also not required
Regards
Eckhard
Mit freundlichen Grüßen / Best regards / Cordiali saluti / ystävällisin
terveisin
Eckhard Lenski
Nokia Siemens Networks GmbH & Co. KG
COO RA GERD BTS BR PDev CAE Lib&IBIS
CAE libraries and models
Balanstr. 59
81541 München
Germany
phone : +49 89 636 79002
NEW phone : +49 89 5159 17080 NEW
fax : +49 89 636 78895
email: eckhard.lenski@xxxxxxx
http://www.nokiasiemensnetworks.com/ibis
Nokia Siemens Networks GmbH & Co. KG
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRA 88537
WEEE-Reg.-Nr.: DE 52984304
Persönlich haftende Gesellschafterin / General Partner: Nokia Siemens Networks
Management GmbH
Geschäftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke
Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kivinen
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRB 163416
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of ext Muranyi, Arpad
Sent: Monday, December 14, 2009 6:43 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: IMPORTANT question about IBIS-AMI keywords
Importance: High
This is just a friendly reminder that we would like to
have your vote on the two questions below by the next
IBIS-ATM teleconference tomorrow. If you haven't done
so yet, please send me your preferences ASAP.
Thanks,
Arpad
=======================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, December 09, 2009 11:48 AM
To: IBIS-ATM
Subject: [ibis-macro] IMPORTANT question about IBIS-AMI keywords
Importance: High
Hello everyone,
We raised a couple of important questions in the IBIS-ATM
teleconference yesterday, and we decided to post them on
this email reflector so that everyone following the IBIS-AMI
work could have their say in the decision we are about to
make. (This means we are asking for your vote on this topic).
As you may all know, we are currently in the process of
writing a BIRD for the AMI portions of the IBIS 5.0
specification to correct a few problems that slipped in.
Some of these corrections involve syntax rules regarding
the keywords in question. We have several options on how
we could deal with the cleanup effort, but not all are
equally elegant. The two opposite poles of the possible
solutions are backward compatibility vs. a clean specification.
Choosing the former may raise obstacles in the future, but
going with the latter could prevent existing models to
work under the fixed specification. The middle ground
of retaining backwards compatibility while supporting
the better solution can get ugly in the specification and
may raise lots of questions by new model makers who may
not be able to figure out why the syntax rules are so
complicated.
The rules of the two keywords which we are asking about
simply cannot be fixed cleanly without eliminating them
from the spec, but that would break compatibility.
Other options may just make the specification messy.
So we would like to get your vote on the following two
keywords. Please reply to this message with your vote
(privately or openly) before the next ATM teleconference
which will be on December 15, 2009. Feel free to ask
questions if you don't understand the problem, but
please be concise, as we have already spent significant
amounts of time in the teleconferences discussing these
topics. We need two answers, one of 1a, 1b, 1c and one
of 2a, 2b, 2c.
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?
2a) Shall Format continue to be required, as specified?
2b) Shall we retain Format but not make it required?
2c) Shall we remove Format from the AMI specification?
Thanks in advance,
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:
