Time: January 6, 2009 Noon PDST ===== Audio: ====== Voice dial-in: (800) 637-5822 International: +1 (647) 723-3937 <--- (For Canada) 0201400572 <--- (For Sweden) Access Code: 685-0440 Web === Click Here to Join Live Meeting: http://tinyurl.com/yvmesj or: https://www.livemeeting.com/cc/sisoft/join?id=NKQQN3&role=attend&pw=TP8j %23-%25%7E5 Mentor Global Crossing Teleconference commands: http://www.globalcrossing.com/customer/collaboration/cust_ready_access_t ips.aspx FIRST TIME USERS: To save time before the meeting, check your system to make sure it is compatible with Microsoft Office Live Meeting. --------------------------------------------------------------------- Agenda ====== 1) Opens - Happy New Year! 2) Call for any related patent disclosures 3) Review of ARs: To All: People should bring their lists of things that need to be solved in an overhauled new IBIS specification Michael M.: - Send proposal document to Mike LaBonte for posting; - Confirm with Synopsys whether "used by permission" can be used as the official indicator on relevant documents. - in progress Old ARs: - Arpad: Write parameter passing syntax proposal (BIRD draft) for *-AMS models in IBIS that is consistent with the parameter passing syntax of the AMI models - not done - TBD: Propose a parameter passing syntax for the SPICE [External ...] also? - Arpad: Review the documentation (annotation) in the macro libraries. - deferred until a demand arises or we have nothing else to do 4) Synopsys update (Todd/Mike) 5) Continue our brain storming session on what the overhauled IBIS specification would look like. In the last meeting Walter suggested that if we fixed a few things (and he named them) IBIS would have new life for a while. I feel that with that statement we made a full circle and we are back to our fundamental question (again): Do we want to focus on a "complete overhaul" or "fix up a few things" effort. Seems like we have been there before. I would like us to decide what we really want to do... Summary from the last meeting: 1) the needs/interests of the three communities may be different - EDA vendor (least amount of change in the tool, if possible) - System designers (don't care about circuit detail) - IC designers (must have the ability to model circuit detail) 2) easy extraction vs. language freedom? - language freedom does not imply more difficult extraction - freedom in language does not imply too much complexity 3) modeling language should not get into describing how to do the extraction or modeling of the devices - IBIS does this today because of the inflexibilities (keywords) bring this as a consequence 4) our solution has to be accessible in implementation and cost - I want my cake and eat it too? 5) IP protection, executing DLL models (AMI style) - the "famous three" issues (from John Angulo) a) assigning models to the system, - a netlisting problem b) how do you simulate them - a model algorithm problem - assumed in the keyword? - defined in the model (equations, etc...)? - we need a mix of the two: - for interconnects we can stay assumed - for buffers we need more model defined algorithm capabilities - the need for a universal solution implies - either a strongly and well defined assumption - this leads to rigidity in the specification - or algorithms defined in the model capability - this provides freedom and repeatability between tools, but could make it harder on the model maker (but models would be "self validating" by definition) - table driven vs. equation based models not the same question as keyword based vs. algorithm based c) how to interpret the simulation results - a post processing problem - measurement parameters - measure statements - measurement algorithms - user defined measurements - "part level timing"? who cares what level if the timing can be user defined... (assumption vs. freedom) Summary from the meeting before that: - look at a higher level for what is needed before going into technical details; clarify assumptions of things we like about existing IBIS and what we need a new IBIS for 1) need to model buffers separately from packages and system level models that need netlists 2) table based or equation based, or both? 3) at a low level: not enough controllability (e.g. coefficients for equalization. Data is too hard to extract) 4) at a high level: three major assumptions in current spec that aren't appropriate anymore: - typ/min/max concept, with three corner format - post layout is not as strong an interest to many people - IBIS is not setup well for pre-layout simulation 5) differential buffers are inconvenient to correlating to SPICE 6) multiple power supply buffers are difficult 7) new IBIS could embrace existing IBIS applications but expand to include others 8) must be able to do batch simulations - three issues need to be addressed: 1) assigning models to the system, 2) how do you simulate them 3) how to interpret the simulation results - solution must be truly universal, work close to the same in multiple tools - language related questions: 1) invent a new language vs. turn to existing languages and perhaps modify them? - potential existing languages: IBIS, *-AMS, SPICE - VHDL-AMS difficult because it is strongly typed - Verilog-A(MS) more user friendly, but less mature - SPICE somewhat limited in behavioral capabilities - Matlab, Mathcad, C, C++, Visual Basic, etc...? - is there a familiarity problem with acceptance? - how is a transistor model turned into a behavioral equation model (whatever language is used for it)? 2) should we pick any of these and "build on it" our own language? - this would be a huge effort - EDA vendors would most likely have to build a new engine - reusing an existing language may be easier to implement and get models for it (the usual chicken and egg problem) - does any of the existing languages contain everything we need? (eye masks, pin lists, T-line, S-parameter, etc...) - and much much more... 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