I agree with Arpad and Ken. We don't want a fixed topology for the analog circuit model. Moreover, we don't want the new analog model only work in AMI simulation but not in Spice simulation. For the touchtone file, as I shown in the s2p example, there is fundamental flaw in BIRD122 which violates basic circuit equations. Circuit equations for S-parameter block in spice simulations (DC, tran, HB, etc) are standardized and well established. AMI standard should not force EDA tool into a special way of simulating s4p blocks by ignoring the S(1,j) row which is valid only under specific assumptions. On the modeling side, as an industrial standard AMI should not force model vendors into a specific setting when creating s4p. Model vendors should have the freedom to decide what portion of their circuit goes into s4p. For that reason models must be able to define the impedance between Tx driver and input ports of Tx s4p and the termination of Rx s4p output ports. Regards, Fangyi -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis Sent: Tuesday, December 21, 2010 9:38 AM To: 'Muranyi, Arpad'; ibis-macro@xxxxxxxxxxxxx; 'IBIS-users'; 'IBIS' Subject: [ibis-macro] Re: [IBIS] RE: BIRD 122 Sample SPICE Deck posted Hi Arpad, Sigrity absolutely agrees with you. We have already learned from history with IBIS that hard-coded circuits will always hit limitations and tap out in applicability, as evidenced by the addition of [External Model], [External Circuit], etc. Standardizing on more hard-coded circuits make absolutely no technical sense to us whatsoever. Nor does coming up with a more limited, and redundant way of doing circuit modeling in the AMI space, rather than enhancing with IBIS-ISS. And keeping a clean delineation between circuit and algorithmic modeling was a base assumption of the original AMI spec, and is becoming dangerously blurred in some of the new cases we are seeing. Focusing on enhancing circuit modeling to make it more flexible with IBIS-ISS is the right direction in our opinion, and should much better position us all to model whatever new circuits are required for the future IO applications. Define the language and enable the model-makers to model the circuits they need, rather than define a few hard-coded circuits and shoehorn everyone into them. Thanks, Ken Willis Sigrity, Inc. 860-871-7070 kwillis@xxxxxxxxxxx -----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 --------------------------------------------------------------------- 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