One thing I have to agree with your, none of us have any time left to get into this infinite loop of endless "my **** is better than your ****". As long as I am getting encrypted HSPICE from vendors today, I could care less Joe engineer thinks IBIS is all he needs. >Your assessment that IBIS can't do it at all is plain wrong. "On IBIS and SSN: many in the industry recognize that, for effects such as SSN, traditional IBIS (3.2, 4.0) today does not include enough data to provide a consistent power integrity result between tools." I didn't say the above, Michael did. And for the last time, NO ONE in Si-list response saying he/she is doing SSO analysis with IBIS today. How many tools out there really support the latest spec of IBIS 4.x anyways ? You can't dance around the encryption issue because that was one of the biggest reason IBIS exist in the first place. Call it SPICE or AMS, at the end of the day, you can't be accurate enough on your model without someone in your chain of command thinks that's too much IP and you need to encrypt the information. And do you really think all favors of Verilog-AMS, VHDL-AMS with different encryptions for different vendors will really fly ? With your busy schedule between real design work and your IBIS meetings ? Call me crazy, I've design plenty of big irons with SPICE and I never felt its slowest hinder my work, I am more worry about garbage models that lead me to incorrect results. If tomorrow you can show me an AMS model that can simulate SSO on drivers accurately, I'll take it. But so far Gary's example is no more than a two pass simulation with digital verilog simulation feeding into a SPICE level=1'ish transistor model and S-parameter. And your example is just a mix of couple of IBIS drivers pumping current out at different time. None of this address the problem with SSO noise. Unless we think that's not any issue, you haven't even start to address the problem. I can take a few standard IBIS driver models, run a digital verilog simulations and pump the different drivers at the output based on the verilog timing and I can get the same results. What's so special about it ? It doesn't address the problem of SSO noise. I think at this time you and Gary will probably say "but hey, I can modify this and that and it will do the job". Here lies the problem, if you and Gary are already the bleeding edge of AMS users and both of you still can't generate the SSO model, how long do you think the rest of the app engineer crowd can catch up the methodology ? I hope its not seven years. I am really glad Al actually make his presence in Si-list. May be he can share with us how long since he did those SSO analysis on IBM TCM modules. To see us little disciples still struggling to figure it out will probably make him laugh. But it also tells us how slow the entire industry is moving. A promising technology may be great but let's not loose sight we need to address a lot of problems today. Arpad, you should know better I can make any methodology you throw at me works. SPICE BTDT, behavioral BTDT. AMS, no problem, I am sure I can make it work also. But can you say the same about the Joe app engineer of the majority of the industry ? Why can't there be a SINGLE IBIS SSO model generated and people are using it today ? Is there no SSO problem today ? Up to this point IBIS has some reasonable strict definition, I-V curves, package parasitics etc. It may not be good enough for SSO but at least we all know where/how it comes from. If tomorrow everything becomes this magical AMS model and all users see is a bunch of equations, who is going to guarantee the accuracy or the methodology used to abstract it from SPICE (which I believe is what 100% of Si I/O designers use) to AMS ? I've ask you previously already, how do you determine what kind of abstraction is good enough for what kind of application ? Can it even be defined ? If the answer is no, who is going to guarantee the level of accuracy ? HSPICE may not be good, but at least I've never heard of any Si vendor unwilling to correlate their process with it because, like it or not, it is considered a de facto industrial standard. Can you say the same about all those AMS abstractions that will exist in the future ? I am a practical man, if tomorrow AMS is the heat it claims to be, I will be the first to jump on it. But you have to show me a single case where the average Joe app engineer can hand out an AMS model with SSO model first. Can you ? I am not talking about "I think it can be done this way", I talking about "here is the I/O with SSO model, here is a scope picture of actual measurement of SSO of the I/O and here is an AMS simulation that matches it". I will be waiting for that picture. And how long do you think the rest of the industry will show me that kind of pictures ? Please don't tell me another seven years. -----Original Message----- From: Muranyi, Arpad [mailto:arpad.muranyi@xxxxxxxxx] Sent: Thursday, March 24, 2005 2:20 PM To: Chris.Cheng@xxxxxxxxxxxx; si-list@xxxxxxxxxxxxx Subject: RE: [SI-LIST] Re: package SSN model accuracy requirements Chris, Here are my responses. When we started IBIS, our main goals were not SSO simulations, at least not the way it is done today. That's why we put only a partial and crude solution for it into the IBIS specification in the form of the [Pin Mapping] keyword. It did provide some capability for SSO, exactly with the same thinking you are saying: "at least give you a chance to predict the problem". Your assessment that IBIS can't do it at all is plain wrong. The thinking in those days was that if it becomes necessary to do something better, we will add it to the spec. This is actually happening right now in the form of BIRD95. There may be many reasons it took this long to get this far. One may be that instead of doing something about it, people just kept complaining about it. Another could be that none of us in the IBIS Open forum are "professional standards attendees", we all do this above and beyond our normal everyday work on a volunteer bases, which leaves little time for making improvements on the specification. The same goes for the receiver modeling problem. When IBIS was started, there was no need for doing that, so we didn't put it in the spec. In those days most everything was measured at the pin of the device. Later we started to move the measurement point to the inside of the package, the die pad. This was still doable with IBIS. Timing measurements at the output of the receiver are not widely done in the SI world yet. Since IBIS is mostly demand driven, this hasn't been addressed yet in the spec. However, with the *-AMS capabilities we are not going to need to change the spec any more if it becomes necessary to model the receiver. As I stated it before, in *-AMS you can model things any whichever way you want to. You can make an exact SPICE equivalent if you like, or you can write a behavioral block if that is your choice. Regarding your original question, you have already gotten two responses, so I will not go into that any further. Regarding the rest of your questions: a) I don't want to go into encryption, because that is a separate subject all together. However, regarding my company's secret in English, or Russian, or Martian, I disagree some. Think about a simple voltage divider example. You can write a Thevenin equivalent for it using one voltage source, and one resistor. The resistor's value will be the parallel combination of the original circuit's resistors, and the voltage source will have the value of the voltage division the divider gives you. If you don't know anything about the original circuit and I gave you only the Thevenin equivalent, are you going to be able to tell me what the two resistor values are in the original circuit and what voltage they are connected to? That's how behavioral equivalents can be useful to hide my company's secret. I agree, it may not be always possible to hide everything like that, and the lawyers may find that my Thevenin equivalent is IP, but that is a different story. b) Asking how AMS can handle gate modulation is equivalent to ask how the C++ language can handle your favorite software projects. By the way, the HSPICE B-element has done this for years now, try the "spu_scal" and "spd_scal" parameters of the B-element. It just hasn't been made official by the IBIS specification yet, because there was not enough demand for it up to now. However, you can look at BIRD97 and the comments Katja wrote recently how this would work and how it could potentially become part of the spec. Regarding your concerns about speed when the simulation deck is dominated by interconnects, you can actually combine all your interconnect pieces into one big S-parameter block (i.e. make a behavioral model for them), and then your simulation is going to go orders of magnitude faster. Same principle as combining the thousands of transistors into a behavioral buffer block... The equalization stuff or receiver modeling doesn't have to be done with multi dimensional lookup tables to be behavioral. This is exactly where the AMS languages provide a tremendous capability. You could write FIR filters, decision feedback loops, etc. with its digital equation capabilities, which would execute lightening fast, because they are event driven, and don't have to be evaluated at every single analog time step (iteration). c) Again, I do not want to go into the subject of encryption, it is a different story. However, when we write *-AMS or AMS, we are talking about VHDL-AMS and Verilog-AMS. Quote from the IBIS4.1 specification: | "VHDL-AMS" refers to "IEEE Standard VHDL Analog and Mixed-Signal | Extensions", approved March 18, 1999 by the IEEE-SA Standards Board and | designated IEEE Std. 1076.1-1999. | | "Verilog-AMS" refers to the Analog and Mixed-Signal Extensions to | Verilog-HDL as documented in the Verilog-AMS Language Reference, Version | 2.0. This document is maintained by Accellera (formerly Open Verilog | International), an independent organization. Verilog-AMS is a superset | that includes Verilog-A and the Verilog Hardware Description Language | IEEE 1364-2001. Sincerely, Arpad ------------------------------------------------------------------------ -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of Chris Cheng Sent: Wednesday, March 23, 2005 5:27 PM To: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: package SSN model accuracy requirements Arpad, I can give you an even simpler answer, ever since the existence of IBIS, it can't model a simple problem like SSO. If you are a customer, would you choose a method that may be error if it is done wrong but at least give you a chance to predict the problem if it is done right, or, something just can't do the analysis AT ALL ? There are many road accidents with cars, but that doesn't mean you have to walk to work. Let me repeat the question I've asked many many times, how many of the member of the Si-list who are NOT just professional standards attendee or EDA tool vendors and have real responsibility to design system are actually using a standard IBIS model to analyze SSO today ? I rest my case. Garbage in garbage out, no matter it is SPICE or IBIS. At the end, whoever give the model out has the ultimate responsibility. But ever since the existence of IBIS, it can't address the problem high performance design (SSO and receiver performance to name a few). You and I know that behavioral models can address those problems long time ago but look at how long since the first known successful attempt (if you disagree with me on that reference, ping me off-line) until the standard committee even catch up with the idea. Seven years is a very long time, people can earn sabbatical out of that. Am I supposed to wait for another sabbatical if I want to model my equalizing receivers ? I've got problems on things I need to ship tomorrow. Let's take a closer look at AMS Here are the claims : a) It abstract your I/O to protect your IP Well, Gary's reference seems to suggest every I/O design is as simple as a university paper so may be your company have no problem handing out the I/O state machine design. Is that true ? On the same reference we are led to believe a SPICE level=1'ish model is really a behavioral model, ok I dig it, but do you think your company lawyers and design managers will buy that and freely handing it out without encryption ? Like I said before, it's like asking "Can you tell me the secret of your company ?" Ans : "I can't tell you in English, but I can tell you in Martians (just not to offend my earthly friends :-D)" Is that really possible (besides the fact that there is no Martian)? b) It is accurate and fast I still haven't seen any mention of SSO or how AMS can handle power impact on the I/O, may be SSO is no longer an important issue for GB serial ports ? How does one handle such modulation by predriver and substrate feedback from multiple power sources (core power for predriver, I/O power for main driver) without resorting to those level=1'ish transistor model ? A marketing paper like what Gary present can carefully craft the example to the advantage of the simulator but in reality how many interconnect is one simple S-parameter deck ? I would bet the real customer topology will more like a mix bag of circuit elements different vendor provide such as chip package, transmission line, terminators, discrets, connector models. How the speed of AMS will do when it is overloaded with a lot more circuit elements like R,L,C, transmission lines and S-parameters by different components ? Let's focus more on this little problem like a receiver, if you have to use the output of the receiver to predict a equalization how would you use your behavioral models to predict that ? Just take a look at those typical crazy FSB ringback, over-drive specs. Try a few case of real over drive and ring back cases which depends on common, differential mode, operating point, over drive, hysteretic etc and try construct a multi-dimensional equation/table to describe it and let's see how fast you will get. Ask the friends we both know and have already make pitches in this thread what do they think ? I am a fair person, show me a real life case and data and I will be convinced. c) It is standard and everyone support it I still couldn't figure out whether AMS is VHDL-AMS or Verilog-AMS, which one we are talk about here ? Can you tell me ? Does everyone use the same encryption to protect your IP ? If every tool has a different encryption, what kind of ZBB do you think you will get for ten different kinds of encryptors from ten different vendors ? ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: http://www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List FAQ wiki page is located at: http://si-list.org/wiki/wiki.pl?Si-List_FAQ List technical documents are available at: http://www.si-list.org List archives are viewable at: http://www.freelists.org/archives/si-list or at our remote archives: http://groups.yahoo.com/group/si-list/messages Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu