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