Walter, I think the disagreement we have comes from two different things we were talking about. Now I understand that you were talking about pointing to an industry spec, but not for the purpose of parsing and reading the document to extract the numbers from it, but so that the EDA vendor can pre-program the simulator with the numbers found in those specs, and when the IBIS file points to a spec like that, the tool could identify which pre-programmed number set to use for the purpose they are there for. What I was thinking about was different. I was thinking that the [Specification] keyword would point to a "data file" that the user or model maker writes to tell the simulator through the IBIS file's [Specification] pointer how to do certain things, such as define an eye opening spec, for example. So we disagreed because we were talking about two different things. Thanks, and sorry for the confusion. Arpad ===================================================================== ________________________________ From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Friday, December 05, 2008 10:43 AM To: Muranyi, Arpad; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: Making IBIS responsive to the modeling needs of the industry ... new keyword [Specification] Arpad, I cannot disagree with you more. The external specifications I am pointing to are Industry Standards (E.G. JEDEC, USB, and yes Hspice!). When JEDEC specs DDR2 or DDR3, they are defining a set of measurement rules that parts must comply with in order to have the JEDEC stamp of approval. When a systems house designs a board using DDR2 or DDR3 components, and if their simulations satisfy the JEDEC rules for DDR2/DDR3, then they can be assured that their board will work with any qualified DDR2/DDR3 component. So Having an IBIS part that has a model that is DDR2 or DDR3 qualified means that that part will work as long as the simulation satisfy the JEDEC DDR2/DDR3 rules. What customers want are IBIS models that they can use in EDA tools that will tell them if the simulations satisfy those JEDEC requirements. There is no way of putting these JEDEC requirements into IBIS files today. Derating is one example of a JEDEC rule, but there are others relating to AC, DC levels, slew rates, how slew rates are measured, how long signals need to stay above AC levels, ... All I was saying is that IBIS needs to adapt these Industry Standard Rules in a timely fashion either by aggressively adding measurement parameters and keywords to IBIS, or by at least having a standard way of pointing to Industry Standards. IBIS has several functions, one as a pin list and assignment of models to pins, one as an analog description of how drivers and receivers interact with a channel, and one as a method of analyzing the signal at a receiver to determine timing information. There are two philosophies of determining timing information, one is to replicate the timing path inside an Rx as accurately as possible, the second is to replicate the timing rules that standards committees set on the requirements of chip manufactures to meet timing steps for that standards committee's specifications. You missed my entire point with your comment "your tool is still not going to be able to use my eye opening description and my tool is not going to be able to use yours.". What I said is that the [Specification] would point to an Industry Standard Rule, not mine and not yours. I then said that each EDA tool can implement this Industry Standard Rule in its own way. The external file I described was just a way of describing the details of the Industry Standard Rule. This file gets read by a human who decides on an implementation of that rule for his EDA tool. I think that you will find that many IBIS enhancement requests for new keywords are simply desires to add the ability to specify industry standard rules in IBIS. Walter