Doug, Even though your message is addressed to Scott, I feel I have to respond to it because you made several comments about (I assume the ATM) committee, its chairman's responsibilities (me) and our motivations. I wonder what is the basis of the claims you are making with such great authority when I could count on one hand how many times you have attended the ATM meetings in the last several years. You simply have no clue on what is going on in the meetings and it seems that the information you are getting from your colleagues who do attend the meetings is heavily filtered and biased. The number of constructive feedback given to your company's or anyone else's proposals is countless and come in written or verbal, public or private forms. Your claim that we are "Just saying I don't understand or I disagree ..." is simply not true. Also, your claim that "...the committee focuses on trying to eliminate that possible use as its number one crusade..." and "the reason the committee chose to focus on this instead of the functionality is, in my opinion, politically motivated" is dead wrong. The committee's number one priority currently is to clean up the errors and inconsistencies in the existing specification. The issues with Model_Specific (Usage Out/InOut/Info) are simple logical problems in the specification that need to be addressed. The rules in the current specification simply do not make logical sense. There is nothing political about this, it is a plain logic problem. I am very sorry to hear that you are unable to comprehend that. Unfortunately this is just one of the many logical nonsenses in the specification. But now that you reminded me to what my responsibility as the chairman of the committee is "It is the responsibility of the committee members to look past the individual and address the topic and it is the responsibility of the Chairman to ensure that that happens." I am getting very close to sending a request to our postmaster to remove you from the ATM email reflector, in order to make sure that we can make progress in our work without individuals like yourself hindering us with useless, false and inflammatory accusations. Sincerely, Arpad ======================================================================= From: owner-ibis@xxxxxxx [mailto:owner-ibis@xxxxxxx] On Behalf Of Doug Burns Sent: Friday, April 29, 2011 12:46 PM To: scott@xxxxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx; ibis@xxxxxxx Subject: [IBIS] RE: [ibis-macro] Re: Minutes from the 26 Apr 2011 ibis-atm meeting Proposed Scott, Let me address your comments one by one: 1. I have never stated that OPAL is the final word on every topic and if additional clarifications or capabilities are needed, I for one would be glad to have the discussion. However, the issue is not OPAL since at IBIS we only deal with BIRDS before the committee. 2. Your statement: "Your assumption that network analysis stops with 2 ports at the die is just silly" is your assumption, not ours. 3. That statement continued as: It's a good first approximation, but not something that I want to take into the future, where I will be modeling power, ground, termination networks and multiple serdes channels simultaneously". We agree about the issues in the future, but we are not in the future. There are specific issues that need to be addressed today and addressed quickly. I will also say that we should try to make sure that what we do implement today has capability for expansion toward these other topics, but waiting for resolution of these futures impedes the present. 4. You express concerns about the clarity of the submitted BIRDS in various parts of your email. I take this seriously and will work to ensure that they are clear and concise. We have no agenda to frustrate the committee, but I require clear, concise, constructive feedback. Just saying I don't understand or I disagree doesn't cut it. I need specifics as to what or why as well as alternatives that you may suggest. You may constructively criticize what I propose only if you are willing to provide real feedback and examples of what you require. 5. As far as the committee trying to slow us down. Scott, as they say, the proof is in the pudding. Let's look at history. a. When we proposed new features and included them as |SiSoft parameters, all hell broke loose from our esteemed colleagues about "Non-Standard Models". There was no discussion about what was were needed, it was purely attack mode. b. We then modified our approach and used the model specific parameters to convey information. Now instead of addressing the needs of the extensions, the committee focuses on trying to eliminate that possible use as its number one crusade. When asked for a solution, the response is "Make non compliant models". What do you think will be the response if we go down that road? There is a saying here Scott, "I may have been born at night, but it was not last night!" c. We have asked the committee for a way such that advanced features don't get attacked and so far we have made little progress. 6. As for "Lump me together with that thought one more time in a public forum and I'll come up there and we'll have words". I have this to say, Please do not threaten me either publicly or privately. Personally, that sort of comment is improper and is beneath the type of individual that I think you are. I expressed my opinion and I stand by what I said. I want to move forward and would gladly be willing to work with you in a constructive way to advance our goals concerning IBIS-AMI modeling. 7. We all understand that a committee is a democratic process. We also need to understand that each individual involved brings along certain baggage that needs to be worked with (That include you, me, Walter, and the rest of the crew). It is the responsibility of the committee members to look past the individual and address the topic and it is the responsibility of the Chairman to ensure that that happens. 8. Let's talk about Model Specific IN/OUT. a. "The reason we're arguing about Model specific Outputs and In/Outs, is because there are a plethora of models out there that meet the spec, but don't run in all tools, unless time is spent to reverse engineer what was actually done. This bothers customers. An example that I've observed is that the brilliant S-parameter analog model methodology provides two different results if driven by a 50 ohm driver or a pure voltage source. This bothers me, since the requirement is an isolation boundary between the algorithmic and the analog domain. Had the interface been thought out more carefully, this need have been the case, which is why I am against the approach that you advocate." The issue here appears to be more a matter that the assumptions of what was a valid construct are not clear and that such clarification is needed. This example surely does not rise to the level as a reason to outlaw the use of the IN/Out parameters. I'll also note here that how you punctuated your comments was meant to insult or inflame. We all need to refrain from this behavior if we expect civil discourse. b. "I think it's absolutely fine to have Model Specific outputs that provide information that can be stored, plotted, tabulated, or displayed in any way that any one desires. This is not at issue. The issue is with non-standard parameters that are designed to alter simulation flow or results. This cannot be acceptable in an industry specification, since it requires knowledge that exists only with the model maker and simulation vendor that the model was targeted for. Yet you guys have spent the last month arguing against that perfectly rational position, which is why it has taken up so much committee time. Just capitulate and go on. Accept that you will not get a consensus that agrees with your position." The issue here is with the new parameter not with the actual Model Specific IN/OUT. The REAL concern is that this allows a proposed parameter to pass the parser and get advertised as compliant. We do understand the issue, but as stated before, the behavior of the committee and their associated companies when new features are introduced is to start throwing FUD into the air. This argument would not be needed if the committee was working to address the current shortcomings in functionality. I am sorry, but the reason the committee chose to focus on this instead of the functionality is, in my opinion, politically motivated. Give me a way to build models the industry needs now without always being attacked and then I will be willing to rethink my position. c. Todd is going to make a proposal that try's to meet the needs of both developers and EDA suppliers. 9. As for the rest, we are in agreement that discussion is needed on many fronts. You mentioned many topics and I await the proposals. Best regards, Doug