Arpad, BIRD 122 clearly defines the need for IBIS to enhance analog modeling for high speed SerDes (AMI) modeling. There is a clear desire for additional capabilities for analog modeling by finishing the IBIS ISS specification, by allowing ISS External Models, and allowing AMI parameter selection to control External Models. SiSoft has no objection to this approach, as long as the proposed enhancements in BIRDs 116-119 do satisfy the minimal requirements described in BIRD 122. SiSoft will like to table any further discussions and actions on BIRD 122 until closure is achieved on IBIS ISS and BIRDs 116-119. Walter -----Original Message----- From: owner-ibis@xxxxxxx [mailto:owner-ibis@xxxxxxx] On Behalf Of Muranyi, Arpad Sent: Monday, December 20, 2010 4:32 PM To: ibis-macro@xxxxxxxxxxxxx; IBIS-users; IBIS Subject: [IBIS] RE: [ibis-macro] BIRD 122 Sample SPICE Deck posted Hello Everyone, Now that we have seen the SPICE netlist of the analog models of BIRD 122 I would like to make a few comments, raise a few concerns and make a suggestion. The introduction section of Algorithmic Modeling in the current IBIS specification states the following on pg. 139: "The "analog" portion of the channel is characterized by means of an impulse response leveraging the pre-existing IBIS standard for device models." We are all aware of the shortcomings of IBIS [Model]s, so I am not going to reiterate them here and argue the need for improvements. BIRD 122 seems to suggest a solution for that, but the solution is targeting AMI needs only, and it is provided as an option: You either go with a less accurate IBIS [Model] or the more accurate analog parameters contained in the .ami file. Pg. 2 of BIRD 122 says: "Nominally, the simulation uses the traditional IBIS [Model] data from the .ibs file. This provides the highest level of model portability between EDA tools but does not always provide the highest level of simulation accuracy. These parameters define two additional levels of information that can be used to model the analog buffer." The problem I have with this is that the BIRD 122 proposal does not attempt to solve the real problem, which is the shortcomings of the IBIS [Model]. BIRD 122 suggests a solution strictly for IBIS-AMI purposes only and leaves IBIS modeling untouched. In addition, the suggested solution in BIRD 122 describes a few pre-defined "special purpose" circuits which are not accessible to anyone. These circuits are assumed, which means that they are hard coded into the AMI engine, they use pre-defined parameters with pre-defined meaning. This means that no-one can make any changes to the analog models without changing the specification itself. Considering that as soon as someone will need to model something that cannot be described by these hard coded models, it seems that the BIRD 122 proposal is only a half-baked temporary solution which does not provide a long term solution for AMI and does not address any of the fundamental IBIS modeling limitations at all. In addition to that, BIRD 122 seems to violate SiSoft's own recommendations which was posted in a public email on the ATM email reflector on 12/14/2010 in response to one of my messages. Mike Steinberger wrote: "...We need to continually remind ourselves what IBIS-AMI is in the first place. It's an _interface_ _definition_. That means that if both the model and the EDA tool comply with the interface definition, they can communicate with each other correctly. Period, the end. IBIS-AMI is not and should not be a specification of functionality, either for the model or the EDA tool..." To me, BIRD 122 seems to be nothing but a specification of functionality for both the model as well as the EDA tool... All of the discussions (arguments) we have on BIRD 122 in the ATM teleconferences are happening because we are trying to define functionality and we are at odds with each other on the details of that. The netlist we have seen from SiSoft in the last ATM meeting indicates that the analog models of BIRD 122 can be described with IBIS-ISS without any limitations or restrictions. Given that fact, I do not see why the analog models would have to be hard coded into the AMI engine and made inaccessible to IBIS. There is nothing in these netlists which cannot be accomplished with the proposals in BIRDs 116-118. In addition, I have demonstrated in BIRDs 116-118 and 125 that the legacy IBIS [Model] and its package model can be improved using the IBIS-ISS language in such ways that these improvements would also be available for AMI purposes. In addition, the analog model of BIRDs 116-118 is accessible to the model maker (and user) providing an open and flexible standard which will be usable in many unforeseen situations in the future without having to rewrite the specification for each new feature or capability needed. Also, BIRDs 116-118 do not define any functionality as far as I can tell. They describe the interface by which IBIS-ISS subcircuits can be made work together with .ami and .ibs files. The rest is up to the model maker. They (should) know which element in the S-parameter data should be zero or not, depending on what they put around the S-parameter (ideal source or matched impedance termination). If some of us feel that model makers need to be educated in this area, we should do that in a Cookbook, but not in the specification. Considering the fact that BIRD 122 needs substantial work to even just get the figures more understandable and match the SPICE netlist that we were shown in the last meeting, I would suggest that we should save SiSoft some time and vote BIRD 122 down in favor of BIRDs 116-118 and 125. After all, these BIRDs would ensure the highest level of portability AND the highest level of accuracy WITHOUT having to chose from three different modeling options and WITHOUT the danger of having to rewrite the specification in a relatively short time. Sincerely, Arpad =================================================================== -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte Sent: Thursday, December 16, 2010 8:26 AM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] BIRD 122 Sample SPICE Deck posted As promised in the last ibis-atm meeting, the "BIRD 122 Sample SPICE Deck" (PDF) from Walter Katz has been posted to the ibis-atm work archive: http://tinyurl.com/2cqd4zg Or to avoid tinyurl tracking: http://www.eda.org/ibis/macromodel_wip/archive-date.html Mike --------------------------------------------------------------------- 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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@xxxxxxxxxxxx |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or e-mail a request to ibis-request@xxxxxxxxxxxxx | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 --------------------------------------------------------------------- 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