Feras, You're certainly entitled to your opinion. I just don't see it as a technical justification. BTW, who said anything about PCIe? Todd. -- Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@xxxxxxxxxx <http://www.sisoft.com/> www.sisoft.com "It doesn't matter what you've heard Impossible is not a word It's just a reason For someone not to try" -Kutless From: Feras Al-Hawari [mailto:feras@xxxxxxxxxxx] Sent: Wednesday, February 08, 2012 5:09 PM To: Todd Westerhoff; 'IBIS-ATM' Subject: Tx and Rx templates, why not? Todd, I explained my opinion regarding that many times before, you can review the previous threads to learn more about that. Here are some reasons: - IBIS ISS allows us to develop such models and many other models in a general manner that leaves all the dirty details to the model developer. For example, till this point Walter is still considering whether to keep or not the unity gain elements in the templates. He was also asked to consider adding series resistors to the template. Such templates won't last long as people will always need to modify/add something to them. So why should we keep running after these details and then keep changing the spec based on that, especially when we can save time and effort by putting all of that work in the plate of the model developer based on the general IBIS-ISS approach. - Introducing two PCIe-related templates will also open the door to the introduction of many other templates for all different technologies (DDR3, USB, etc). - As technology moves forward, these templates will need to be updated or even nullified. Best regards, Feras From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx] Sent: Wednesday, February 08, 2012 4:48 PM To: Feras Al-Hawari; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: IBIS Summit Feras, And what would your technical reasoning for that be? "Cumbersome" is an opinion, not a justification. Todd. -- Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@xxxxxxxxxx www.sisoft.com <http://www.sisoft.com/> "It doesn't matter what you've heard Impossible is not a word It's just a reason For someone not to try" -Kutless From: Feras Al-Hawari [mailto:feras@xxxxxxxxxxx] Sent: Wednesday, February 08, 2012 4:38 PM To: twesterh@xxxxxxxxxx; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: IBIS Summit Todd, We only support including the [External Model]s for the thevenin and broadband Tx and Rx as EXAMPLES. Including them as predefined templates and names would be cumbersome. Feras From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff Sent: Wednesday, February 08, 2012 1:28 PM To: 'IBIS-ATM' Subject: [ibis-macro] Re: IBIS Summit Ken, It seems to me you're failing to distinguish between an approach that allows pre-defined templates only and an approach that allows a general sub-circuit but pre-defines common examples for the sake of convenience and automation. So the question remains - if we go forward with BIRDs 116-118, are you saying we shouldn't pre-define templates that have proven useful as part of that effort? Todd. -- Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@xxxxxxxxxx www.sisoft.com <http://www.sisoft.com/> "It doesn't matter what you've heard Impossible is not a word It's just a reason For someone not to try" -Kutless From: Ken Willis [mailto:kwillis@xxxxxxxxxxx] Sent: Wednesday, February 08, 2012 11:42 AM To: twesterh@xxxxxxxxxx; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: IBIS Summit An excerpt from my Jan 18th post on this is below: - 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 _____ From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff Sent: Wednesday, February 08, 2012 8:21 AM To: 'IBIS-ATM' Subject: [ibis-macro] Re: IBIS Summit Ken, What's your reasoning here? The conclusion seems to be "pre-defined templates are bad", but I don't understand the reasoning behind it. I can explain why we're advocating for pre-defined templates - if we can agree on a few cases that address most I/O circuits, we can create tools that automate the extraction and generation of data for those sub-circuits. In our experience, automation breeds consistency breeds quality, because we eliminate manual steps. Computers don't get tired or distracted. So I ask, what's wrong with that? We're not suggesting limiting the ability to create new sub-circuits in any way, we're just advocating that we start with a few that have proven useful in practice. Todd. -- Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@xxxxxxxxxx www.sisoft.com <http://www.sisoft.com/> "It doesn't matter what you've heard Impossible is not a word It's just a reason For someone not to try" -Kutless From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis Sent: Tuesday, February 07, 2012 10:13 PM To: wkatz@xxxxxxxxxx; 'IBIS-ATM' Subject: [ibis-macro] Re: IBIS Summit Hi Walter, Unfortunately, I had to drop off the call today after about 45 minutes, right when you were getting to the end of the presentation. I was with you until slide 19: - SiSoft would like BIRDs 116 and 118 to include a shortcut syntax for these four models "Shortcut syntax" brings us right back to "canned circuit models", which I still don't agree with. Putting these models into the spec as examples in standard syntax makes perfect sense to me. I think we should move forward with that. Thanks, Ken Willis Sigrity, Inc. 860-871-7070 kwillis@xxxxxxxxxxx _____ From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] <mailto:%5bmailto:ibis-macro-bounce@xxxxxxxxxxxxx%5d> On Behalf Of Walter Katz Sent: Monday, February 06, 2012 12:11 PM To: IBIS-ATM Subject: [ibis-macro] IBIS Summit All, Here are my take-aways as it affects the IBIS-ATM committee. A Tale of Two Parsers, Bob Ross (Teraspeed) The IBIS 5.1 .ami parser will only check IBIS 5.1 rules (with some special code for AMI_Version, and Use_Init_Output). The IBIS 5.1 .ibs parser will only check IBIS 5.1 rules. To me, this means that if a .ibs file is Version 3.2, it will not generate any warnings or errors for IBIS 5.1 keywords. A System Developer's Perspective on AMI, Greg Edlund (IBM) This presentation, and the DesignCon Tutorial (8-MP2 AMI Models: How to tell a Peach form a Lemon) will be an excellent resource for the IBIS Quality Committee. Using Function Programming Languages to IBIS AMI Modeling, David Banas (Altera) If you close your eyes, you do not have to imagine any changes to the IBIS Specification to reflect AMI DLLs written in Haskell. Case Study: IBM 15 Gb IBIS-AMI Model using Dependency Tables, Adge Hawes (IBM), Walter Katz (SiSoft) An excellent example of the significance of BIRD 150 (Dependency BIRD) to AMI Model developers. Efficient End-to-end Simulations of 25G Optical Links, Sanjeev Gupta (Avago), Fangyi Rao (Agilent) The AMI optical link model used Repeaters as described in BIRD 131, with some possible extensions. SiSoft requested that Fangyi describe any enhancement that are required to BIRD 131 in order for SiSoft to run these models. How did we get here, and how should we go on?, Arpad Muranyi (Mentor) An excellent presentation that accurately describes the status of BIRDs 122, 116, 117, 118, 129, 144 and 145. Based on discussions I had earlier in the week with Fangyi, Vladimir, Ambrish and Kumar, I re-affirmed that SiSoft is is full support of BIRD 117 and 118, with details in my following presentation. Ad Hoc Discussion: BIRD116 and "Intrinsic Models", Walter Katz (SiSoft) I verbally gave the enclosed presentation, which describes the four BIRD 122 Analog models converted to BIRDs 116 and aa8 [External Models]. In summary, when IBIS 5.2 (BIRDs 116 and 118) is approved, SiSoft will produce AMI models using this [External Model] format. I believe the only controversial issue regarding these four BIRD 122 Analog models is the requirement of a termination resistor for the AMI_Touchstone_Rx. I have added termination resistors with a value RTref (default 50), which satisfy the needs for Channel Analog simulators that use S-Parameter arithmetic or a SPICE step response simulation to generate the Channel Impulse Response. When BIRDs 116 and 118 are approved by the Open Forum, SiSoft will publish to IBIS these four [External Model]s. Walter Walter Katz wkatz@xxxxxxxxxx Phone 303.449-2308 Mobile 720.333-1107