Scott, Thanks for your response. If you're saying that we should be sure customers know these parameters are proposed in BIRDs and not part of the published IBIS 5.0 specification, consider that a given. That's what the comment in the .ami header | Data management, simulation control, jitter & analog model parameters using BIRD 121-124 Parameters was meant to convey. Each section of the .ami file has a header that indicates its purpose, i.e. | analog model using S-parameter data . that associates with the comment in the header. We can make the callout more explicit on a parameter by parameter basis, for example, changing | 3 corner receiver latch noise (Rx_Noise (Usage Info)(Range 0.0020 0.0015 0.0030)(Type Float) (Description "RX amplitude noise expressed in V.") ) | 4 corner receiver latch noise (Rx_Noise_Table (Dependency (Parameter (List "Rx_Corner In" "Rx_Noise Sel" ) (Usage Info) (Type String)) (Row (List "NC" "0.0020" ) (Usage Info) (Type String)) (Row (List "WC" "0.0025" ) (Usage Info) (Type String)) (Row (List "BC" "0.0015" ) (Usage Info) (Type String)) (Row (List "EC" "0.0030" ) (Usage Info) (Type String)) ) ) to | 3 corner receiver latch noise using BIRD 123 (Rx_Noise (Usage Info)(Range 0.0020 0.0015 0.0030)(Type Float) (Description "RX amplitude noise expressed in V.") ) | 4 corner receiver latch noise using BIRD 124 (Rx_Noise_Table (Dependency (Parameter (List "Rx_Corner In" "Rx_Noise Sel" ) (Usage Info) (Type String)) (Row (List "NC" "0.0020" ) (Usage Info) (Type String)) (Row (List "WC" "0.0025" ) (Usage Info) (Type String)) (Row (List "BC" "0.0015" ) (Usage Info) (Type String)) (Row (List "EC" "0.0030" ) (Usage Info) (Type String)) ) ) Anyone have a better idea? Thanks, 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 From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow Sent: Thursday, April 28, 2011 12:30 AM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: IBIS-AMI RX model Todd What I think Arpad means is that this standards has a long way to go. I can do production work with a K&E Slide Rule (at least if I could remember how to use one again), but it's not pretty. Right now AMI is in the "it's getting there" stage, where we need to start making sure that all needs are met, and not just specific customers, or silicon vendors. Trust me, the methodology that some of them have is not that great, and can be greatly improved upon. As for your model problem, I suggest that you tell your customers that you will provide this functionality for them in your tool, and that the IBIS committee is definitely considering your approaches, but that they may very well require model changes by the time that a specification is available. If they were my customer, I would have told them up front that anything that we do that is outside the specification may very be SiSoft specific and may need to be changed in the future, but to support you, and early introduction of these methodologies, we would help them to release modified models in the future at the least possible expense. Regards, Scott Scott McMorrow Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 (401) 284-1827 Business (401) 284-1840 Fax http://www.teraspeed.com TeraspeedR is the registered service mark of Teraspeed Consulting Group LLC On 4/27/2011 10:43 PM, Todd Westerhoff wrote: Arpad, I'm not looking to argue - I'm asking for guidance. I have a real problem to solve and I'm trying to do it in a way that creates the least controversy. When you say that AMI "is in its infancy and barely able to walk on crutches", are you suggesting that AMI models and simulators aren't ready for production work? I hope not, for everyone's sake. "Innovation" is admittedly an abstract term, and the Tuesday group didn't seem to like it. I thought about it, and decided that it would be helpful to make the problem to be solved more tangible. So I did. The problem is - we have a model to ship in the next few days that needs functionality described in BIRDs 121-124 to meet the customer's demand for functionality and the vendor's demand for a single set of model files. The question remains - what do you suggest we do? Thanks, 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 From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Wednesday, April 27, 2011 8:09 PM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: IBIS-AMI RX model Todd, The more we argue over this topic, the more I am starting to get the impression that you want to use a specification that is in its infancy, barely able to walk on crutches, as if it was a healthy and mature race runner. Certain things just can't be done. Whether the parser flags things or not is irrelevant. You can go to the doctor for a checkup and he can let you go telling you that you are healthy and at the same time you can have an undetected serious disease. It all depends on what they are testing for whether they will find it or not. I would like to suggest that instead of discussing whether we are for or against innovation or unfair competition, we should admit that we have fundamental issues with the specification. We should focus on finding solutions to fixing those problems so we can eliminate the issues of slow progress etc. in the future. Unfortunately this will take a little more work up front. We can't just throw together a few keywords and expect that band aid solution to fix big, fundamental problems. I hear you that customers are banging on the doors for solutions. We may have to provide temporary solutions for them while we are working on the real solution, but we shouldn't pretend that a quick fix band aid solved our real problems and expect the whole world to follow it. Arpad ====================================================================== From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff Sent: Wednesday, April 27, 2011 4:45 PM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] IBIS-AMI RX model All, I have a practical question for this group, that demonstrates (hopefully) the point we've been trying to make about innovation. Let's say I have a RX model that I need to release this week, which has the following characteristics: 5 Tap DFE that supports both Linear Approximation (Init/Statistical) and Adaptive (Getwave/Time-Domain) analysis modes DFE mode control - allows user to shut DFE off, fix DFE taps at a defined value, or let model auto-adjust DFE tap settings output during Time-Domain simulation (Getwave) to enable plotting and analysis of tap settling time / pattern-based tap drift 4 corner support - model data provided for Nominal (NC), Worst (WC), Best (BC) and Extreme (EC) conditions Budget data for random jitter on the RX recovered clock due to non-correlated on-die switching noise Budget data for Gaussian noise on the RX sampling latch due to non-correlated on-die switching noise Broadband model for the RX termination (analog) network, provided in S-parameter format The .s4p files associated with item 6 are to be copied into the user's project automatically along with the IBIS-AMI model Items 1 and 2 are supported by IBIS 5.0. No issue there. Item 3 is debatable, I think. It's supported by the IBIS 5.0 spec as it currently stands, although some in the Tuesday meeting didn't understand that until recently. I hear Fangyi saying this should be OK, but I don't hear general agreement. SiSoft considers this OK, if that wasn't evident. Item 4 is not supported by IBIS 5.0 and leverages Dependency Tables as defined in BIRD 124. Items 5 and 6 are not supported by IBIS 5.0 and leverage jitter/noise parameters as defined in BIRD 123. Item 7 is not supported by IBIS 5.0 and leverages analog model parameters as defined in BIRD 122. Item 8 is not supported by IBIS 5.0 and leverages data management parameters as defined in BIRD 121. The end-user and the semiconductor manufacturer have their own requirements for this model: The end-user requires that the model support 4 corner operation, and that any data that affects the simulation result (jitter budgets, analog models, etc.) be supplied as part of the model. To be specific, they don't want to have to fill-in dialogs in the simulator for jitter and noise budgets based on the model being used, and they don't want to have to edit the model in any way to use it. The semiconductor vendor wants a single model that can be supplied to anyone using any EDA tool, with portability between different EDA tools to the maximum extent possible. In practice, that means the model should make best use of IBIS 5.0 syntax, and where the model needs to specify advanced functionality not part of IBIS 5.0, that data should not interfere with the operation of the model in another EDA tool. Both the end-user and the semiconductor vendor understand that another tool may not make use of the advanced data, or that data may need to be coded in some other simulator-specific way for use in another tool. But, the reasoning goes, having the data published in a public way is better than having strictly proprietary data or no data at all. As I type this, we have every reason the believe the .dll associated with this model is known to run in multiple commercial EDA tools. I maintain that because: The specific .dll to be released has been demonstrated to run in both the SiSoft and Cadence public AMI test benches Multiple .dll's built from the same modeling toolset have been demonstrated to run in multiple commercial EDA tools So ... the question is, how should we code items 2-7 in the model's .ibs and .ami files? For all of the discussion this week on the potential hazards of publicly defined model-specific parameters, I've heard no proposals on how to approach this issue. I heard lots of discussion on what we shouldn't do, but nothing on what we should do, that the IBIS-ATM Tuesday group would find acceptable. Once upon a time, we probably would have put this data in the .ibs or .ami file as a comment, using the |SiSoft syntax. That clearly delineated functionality as non-IBIS 5.0, but was denounced as being unfair and proprietary. So, we devised a method of defining these things as parameters in the .ami file, consistent with the IBIS 5 parser, wrote everything down, called it Opal. We created a public use license to guarantee that we couldn't pull the rug out from everyone by changing our minds and declaring all this stuff was restricted. That was 10 months ago. Opal AMI parameters were denounced as being proprietary (I still don't quite get that one) and unfair because the document wasn't open to uncontrolled edits (and therefore, was protected from unintentional or deliberate corruption). So, we took the parameter definitions from Opal, split the parameter definitions up into groups of related items, and submitted BIRDS 121-124 to the IBIS Open Forum for deliberation. Those BIRDs are 6 months old now. The attached .ami file contains everything from items 1-8 using the parameters defined in BIRDS 121-124 and checks clean with the latest IBIS parser. I'll add that all of these parameters were publicly defined at least 10 months ago. Not exactly ancient, but not blindsiding people, either. For anyone who wants to follow the values through the attached example, the values being specified in the model are: NC WC BC EC Rx_Receiver_Sensitivity (V) 0.0030 0.0040 0.0020 0.0050 Analog .s4p model file NC.s4p WC.s4p BC.s4p EC.s4p Rx clock random jitter (1 sigma, S) 0.5e-12 0.6e-12 0.4e-12 0.7e-12 Rx Gaussian latch noise (1 sigma, V) 0.0020 0.0025 0.0015 0.0030 To the Tuesday group: if you don't like BIRDs 121-124, how would you like to see this functionality coded and released? That's not a loaded question - the core model is utterly and completely IBIS 5.0 compliant and portable, and there's advanced functionality that we're willing to publicly define in any mutually agreed, reasonable manner. Limiting the functionality of the model is not an option, and waiting until the committee achieves consensus is, unfortunately not an option either. What would you like us to do? The clock is ticking, and we can't afford to jitter around. 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