Hello All, I agree with Ken. I also believe that we should keep clear and defined boundaries between the various IBIS blocks. As of today those boundaries are very well defined and make sense. Those boundaries are: 1) AMI block (for algorithmic models encapsulated inside a dll to model CDR or equalization) 2) Analog I/O block (the analog I/O buffer which can be modeled using the regular VT/VI curves or using an External Model) 3) Package block (can be defined in an IBIS device or an External Circuit) The above blocks are contained and provide a lot of generality and flexibility. For example the proposed analog and broadband Tx and Rx constructs belong to block (b) above (the analog block) and should not be merged or intermixed with the AMI block (the AMI block should be kept simple and should contain algorithmic models only). Also, there is no need to introduce new constructs and keywords to model an analog or broadband Tx and Rx as such models can be easily represented using a SPICE like language (e.g., IBIS ISS). The SPICE model can then be wrapped in a subckt that can then be referenced by an External Model, which belongs to the most suitable block for such models i.e., block (b) above. So let us keep the IBIS specification simple, generic, and less cumbersome. Best regards, Feras Al-Hawari Cadence Design Systems -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis Sent: Wednesday, January 18, 2012 10:11 AM To: 'IBIS-ATM' Subject: [ibis-macro] canned circuit models Hi all, There was not a lot of air time to be had on this in the last meeting, so I wanted to follow up with email. This is just opinion of course. But I think that canned circuit models are a bad idea for IBIS and the industry. Here are some thoughts on this. - historical perspective Think back to the original IBIS spec. Basically, a canned circuit model for IOs was defined. It was very successful, and covered everything that engineers thought they wanted at the time. But technology progresses, things evolve and change, and new requirements surface. More and more keywords needed to be added, as well as more complexity, and resulted in more churn on the spec (more on this aspect later). Eventually it was decided that if we could just define a common circuit description language with External Model/Circuit, we could define any circuit that was needed, and the spec could stabilize. Finally we realize that Spice is that common language (not Fork/End Fork for example), and ISS support got added. To me, that should be pretty much it for circuit modeling. So the lesson here is that canned circuit modeling runs out of gas no matter how forward thinking you try to be. This has already been observed once. You either result in keyword explosion to try to keep up with requirements, or you define a general language you can use to describe any circuit you need to. It seems to me the smart approach now is to learn from that and just define the general language. - spec churn Going with canned circuits results in spec churn, period. You either have to add keyword after keyword, or you have to continually add new canned circuits to the spec each release. It's the same thing. The resulting churn leaves model developers, EDA suppliers, and end users constantly chasing the spec. That is bad for everybody, as it is a tremendous waste of resources. And completely redundant with a general solution. Stability of the spec is highly desirable, as end users just want to drop compliant models into compliant tools and plug-n-play as they wish to get their job done. This doesn't happen when the spec is in constant flux and everyone is chasing it on different schedules. Think of measuring the quality of the spec by the rate at which it needs to be modified. - circuit modeling not just for AMI SerDes IBIS-AMI models have 2 parts; IO circuit models and on-chip algorithmic models for EQ. The circuit model part can come from general IBIS, and I think the main focus of this sub-committee should be on the algorithmic part. There is more than enough to do there. But somewhere along the way the tail started to wag the dog, and proposals started to outline AMI-specific circuit modeling. Again, I think this is a bad direction. The algorithmic modeling needs focus, as things are changing there rapidly, and links to the associated circuit models are absolutely needed. But I don't like the direction of AMI-specific circuits. Again, a more general solution for circuit modeling will be much more efficient and serve the industry much better in the long run. So, in a nutshell, some basic ideas: - canned circuits is a bad direction in general - AMI-specific circuit models falls into that category - more general solutions where possible and less spec churn is desirable; we will create enough churn just keeping up with the algorithmic model requirements Thanks, Ken Willis Sigrity, Inc. 860-871-7070 kwillis@xxxxxxxxxxx -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Tuesday, January 17, 2012 2:23 PM To: IBIS-ATM Subject: [ibis-macro] Re: IBIS-ATM teleconference - Agenda for 1/17/2011 I prepared a couple of slides to aid our discussion today. These slides are an attempt to summarize the various arguments (pro/con) with the goal of helping our decision process at the end. I intend to keep adding more to these slides as we go with our discussions. Thanks, Arpad ================================================ --------------------------------------------------------------------- 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