Time: September 16, 2008 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 2) Call for any related patent disclosures 3) Review of ARs: Don't recall any AR-s from last week. Old ARs: - David Banas: Report Xilinx position on LTI assumption for SerDes - no update - 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) Finalize the IBIS-SPICE document draft to be sent to Synopsys. Food for thought: ================= What needs are we really trying to solve with this recent effort of EMD/EBD proposals? * Hierarchy problems between .IBS, .PKG, .ICM, .EBD files? - should the .ibs file (buffer model) instantiate the package model (.pkg or .icm) or the other way around? - if .icm files were to be used for S-parameter T-line models, which file would instantiate that? Even if there was a link between .ibs and .icm files, it doesn't make sense to call a PCB T-line from the .ibs file which is the description of a component (integrated circuit)... This was discussed on 9/9/2008. Walter stated that any effort to keep ICM alive is wrong. ICM has to be put to rest. MM stated that no spec was ever dropped, but if there is anything better people will naturally switch for the better. It was also stated that ICM was to be tool-generic. Walter's reply was that the proposed IBIS-SPICE is going to be tool-generic also. For additional discussion details please see the meeting minutes. * There is a need for a netlisting syntax in IBIS simulators which can act as a top level netlist calling buffers, packages, connectors, T-lines, etc... to put all bits and pieces together. - the "best" netlisting syntax we have in the IBIS world today is the .ICM nodal path description syntax, but it was not intended to be used for PCB traces (and it has some shortcomings, limitations). - the next "best" we have is EBD, but it is severely limited * Establish a link between .IBS and .ICM files so that an IBIS buffer could have a seamless association with an .ICM package, just as it used to be with the internal or external .pkg description. - we have serious problems with the IBIS assumption of one to one pin and pad relationship which made it very hard or impossible to have branching in the package (one to many, or many to one connections between pins and pads), consequently stacked die models are not possible with IBIS package models currently. * We talked about standardizing SPICE (or a SPICE subset) on numerous occasions * Are there any other problems I am forgetting? * How much of this is solved/addressed by the current EMD/EBD proposals? 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