Arpad, The presentations I made on Compliancy at the DAC IBIS Summit made it clear that System Companies require IBIS and AMI models that are compliant with todays (and foreseeable) model and simulation requirements. It is important to them that IBIS enable IC Vendors to satisfy these requirement with IBIS and AMI models that comply with the IBIS specification. It is incontroversial that such models need to be broadband, properly support power delivery, and support the configurability of modern driver and receiver buffers. It is logical that we first focus on improving the IBIS specification so that IBIS and AMI model developers can create compliant IBIS models that satisfy the requirement that these IBIS and AMI models comply with the needs of the industry we are chartered to support. This e-mail contains an overview of what I believe we need to do to comply with current and foreseeable industry requirements. At the end of this e-mail I am proposing alternative language for the Info_Out_InOut_BIRD that clearly defines a compliant AMI model, and clearly defines how models define their compliance with the formally approved IBIS specification, and BIRDs that have been approved. It also defines how models that require features that are not compliant with either the approved specification or approved BIRDs shall document such non-compliant features. Finally, I am recommending specific procedures that the IBIS-ATM committee should proceed with to speed up the completion of IBIS 5.1 and 5.x. What we need to do to enhance IBIS so that IC Vendors can create models that are both compliant with the IBIS Specification and comply with the needs of the industry. 1. To satisfy the need to be able to generate compliant Channel Impulse Responses a. Broadband Analog Buffer Models i. There are now two proposals to use IBIS-ISS to represent AMI Buffer Models. My Compliant Analog Buffer Model DAC Summit presentation proposed one method of enhancing IBIS to do this. The presentation described the functionality required, one syntactical implementation, and examples. You have presented an alternative method by enhancements to the existing [External Model] syntax. I requested that you implement these examples using [External Model] presented with my approach. With a side by side comparison IBIS-ATM can first verify which (or both) implementations comply with the needs of the industry, and then decide which approach we should move forward on. Once a decision on the path IBIS-ATM chooses we can write the details of a BIRD in move forward on a timely basis. b. Broadband Package Models i. My Compliant Package Model DAC Summit presentation proposed an IBIS and EBD syntax, functionality required and examples. Again, I requested that you implement these examples using your proposals. With a side by side comparison IBIS-Interconnect can verify the compliance of each of these methods with the needs of the industry, decide the approach, and implement a BIRD. c. Model Configurability i. BIRD 124 defines a method to configure AMI Analog Buffer models based on the configuration of AMI parameters selected for a simulation. This is independent of either of the proposed syntaxes of Analog Buffer Models. 2. To satisfy the need to account for Jitter and Noise in AMI simulations, and to comply with standard industry methods of defining Jitter we need to move forward on the Jitter BIRD 123. 3. The Data Management BIRD 121 defines a way that AMI models can find supporting files (such as additional DLL's and data files. It also defines a standard method that DLL's can open output files with unique names to avoid corruption of data when simulations contain more than one instance of a model (e.g. crosstalk simulations) and multiple simulations in a directory. Alternative wording for the Info_Out_InOut BIRD: An AMI model that uses Model_Specific parameters of (Usage Out), (Usage InOut) or (Usage Info) that influence the EDA platform in how it prepares the input data for the algorithmic models, and/or how it processes the data returned by the algorithmic models shall be considered as non-compliant with this specification. A model may use such Model_Specific parameters that have been defined as Reserved_Parameters in BIRDs approved by the IBIS Open Forum. While not compliant with this specification, the model shall document that it complies with this specification and the specific BIRDs that have been approved by the IBIS Open Forum. Am AMI model that uses such Model_Specific parameters that have not been approved by the IBIS Open Forum is non-compliant, the model shall document these Model_Specific parameters and what the model expects the EDA Tool to use these Model_Specific parameters. The documentation of these model Model_Specific parameters shall be included in the (Description section of the AMI Reserved Parameter Version. IBIS-ATM Procedural Changes I also propose that we set up an AMI editorial committee now that will be charged with re-writing the AMI sections in IBIS incorporating the BIRDs that have been approved by the IBIS Open Forum, and those BIRDs that IBIS-ATM choose to move to the Editorial Committee for finalization. I think this will streamline the process of getting a clean IBIS AMI section in IBIS 5.1, and allow IBIS-ATM to focus on the enhancements to IBIS-AMI that will go into IBIS 5.x. Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Friday, June 10, 2011 8:47 PM To: IBIS-ATM Subject: [ibis-macro] Re: Revised Out_InOut_BIRD draft Walter, I addressed two requests in this draft. 1) I was asked to add words before "must not" to indicate that this refers to wanting to be in compliance with the spec, and is not applicable in general. So I added the words: ".in order to be compliant with this specification, Model_Specific parameters . must not." 2) You requested that I define the word "simulation". Instead of defining "simulation", I changed the text so that it does not use the word "simulation": ".to influence the EDA platform in how it prepares the input data for the algorithmic models, and/or how it processes the data returned by the algorithmic models." So in this version of the draft I made the changes that were requested of me. I wasn't asked to include anything to "reflect the issues raised in my [your] DAC IBIS Summit presentation I [you] gave on Compliant IBIS-AMI Models". There was a comment in the last ATM teleconference that we should wait with the discussion of this BIRD draft until after DAC, which is now. I made the changes, the time is here, let's review the draft and finalize it. Comments and suggestions are welcome from everyone interested in the wellbeing of the AMI specification. Thanks, Arpad =========================================================== From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Friday, June 10, 2011 7:08 PM To: Muranyi, Arpad; 'IBIS-ATM' Subject: RE: [ibis-macro] Revised Out_InOut_BIRD draft Arpad, I do not think these words reflect the issues raised in my DAC IBIS Summit presentation I gave on Compliant IBIS-AMI Models. I think that my comments should be discussed and considered in the committee. Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Friday, June 10, 2011 4:44 PM To: IBIS-ATM Subject: [ibis-macro] Revised Out_InOut_BIRD draft Hello everyone, Here is a revised version of the Out_InOut_BIRD draft. Please read it over carefully and send me your comments. I would like to discuss this in the upcoming ATM teleconference on Tuesday, and if all goes well, vote on it for submission to the Open Forum and put it to rest. Thanks, Arpad =========================================================