Walter, Here are my comments. Your points #1-#6 are all true, but are not proof for needing "canned models" in the IBIS spec for AMI purposes. Based on #5 and #6, work can get done without canned models using the more general IBIS-ISS modeling approach. What is the compelling reason to add these canned models to the IBIS specification then? I want to extend this thought a little further. We don't even need IBIS-ISS to make an LTI buffer model that is equivalent to your discrete (RC) version of the "canned model". Last time I looked at that circuit, I didn't find anything in it that couldn't be done with our legacy I-V and [Ramp] based models (without even needing the [External Model] features). (Remember, a two point I-V curve is a linear buffer model...) What is the reason to need the discrete (RC) versions of the canned analog models if legacy IBIS already has the ability to describe everything they do? The only canned models I see going beyond the abilities of legacy IBIS are the Touchstone file based canned circuits, because they provide the capability to describe the frequency dependent C_comp behavior of the buffer which is not possible with legacy IBIS. But the Touchtone file S-parameter approach is available in the IBIS-ISS based proposals, so I still don't see the need for the canned circuit approach in addition to that. Since you asked, here is one bad thing that could happen with your canned model approach: Your canned model is only "invokable" for IBIS-AMI purposes. You assume that other than finding the [Algorithmic Model] keyword, the rest of the .ibs file is pretty much not needed. While that may be true from an AMI simulation perspective, think about a user who would like to do a correlation study between the AMI waveforms and a normal analog simulation. They will not be able to do that because the canned analog model is not available to the analog IBIS simulator. The IBIS-ISS approach keeps the analog model available for the analog engine of the IBIS simulator. The tool can use it for normal simulations or for generating the impulse response for the AMI models. You may say, there is not much that the user can correlate without being able to model the various taps in the analog buffer model. While that is true, the user could still correlate waveforms using the main tap only, but as we make advances with IBIS-BSS, the modeling of multi-tap drivers may become possible later. In addition to the above, we need to decide on the hierarchy of IBIS in general. So far, we have an .ibs file with a [Package] reference and a [Pin] list, which reference [Model]-s, which reference [Algorithmic Model]-s and their associated parameter (.ami) files. The canned model approach turns this somewhat upside down, as it tries to reference the canned analog models from the AMI parameter (.ami) file. So where is the "cockpit" (or command center) of our IBIS world? Is it in the .ibs file or the .ami file? Currently, pg. 139 (the introduction to the AMI section) says: | ...The "analog" portion of the channel is | characterized by means of an impulse response leveraging the pre-existing | IBIS standard for device models. So taking analog modeling out of the .ibs file and giving control over the analog device modes to the .ami file seems to be a deviation even from our existing IBIS-AMI specification. Don't take me wrong, I am not opposed to changes, I just want to have a good reason for doing it, and once we decided that we need to have a certain change, I would like to do it in a way that is consistent with the rest of the specification... Thanks, Arpad ================================================================= From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz Sent: Friday, January 20, 2012 7:06 AM To: 'IBIS-ATM' Subject: [ibis-macro] Re: Analog Buffer Modeling - A Summary All, I have not received any comments that disagree with the following statements, other than objections to having the ability to have four canned models in addition to allowing general purpose ISS Buffer subckts. I have no objection in principle to adding the canned Tstonefile proposal in BIRD 144 (we can debate some of the details). Why object to the 4 canned ISS subckts that I have proposed. In summary: 1. They satisfy the needs of all SerDes standards that have been approved, and all SerDes standards in development. 2. They accurately represent the LTI behavior of legacy IBIS models (IV and VT tables). 3. They represent circuits that EDA tools can easily and efficiently implement. 4. They make it easy for SerDes IC Vendors to accurately describe the analog behavior of their models. 5. There is nothing that prevents SerDes IC Vendors from creating custom ISS Buffer AMI subckts. 6. There is nothing that prevents IC Vendors from creating custom ISS Buffer subckts for traditional single ended and differential buffers. These are compelling arguments that IC Vendors and Users of IBIS AMI models will support. The argument that there will be a desire to add a plethora of new canned models is specious. No one has given an argument of what bad things can happen with the inclusion of these canned models in the standard. I hold these truths to be self-evident, please be prepared to voice your objections at next week's IBIS-ATM meeting and the DesignCon IBIS Summit. Walter