====================================================================== IBIS INTERCONNECT MODELING TASK GROUP MEETING MINUTES AND AGENDA http://www.eda.org/ibis/adhoc/interconnect/ Mailing list: ibis-interconn@xxxxxxxxxxxxx ====================================================================== Next Meeting Wednesday, Sept. 1, 2010 9 AM US Pacific Time Telephone Bridge Passcode 916-356-2663 4 147-4687 (for international and alternate US numbers, contact Michael Mirmak) LiveMeeting: https://webjoin.intel.com/?passcode=1474687 Agenda: - Attendees - Call for patents - Opens - MCP Skeleton Development ====================================================================== Minutes from August 25: Attendees: ---------- (* denotes present) Agilent - Radek Biernacki*, John Moore, Ken Wong Ansoft - Denis Soldo Cadence Design Systems - Terry Jernberg, Brad Griffin Cisco Systems - Mike LaBonte Green Streak Programs - Lynne Green Hewlett-Packard - Rob Elliott IBM - Greg Edlund ICT-Lanto - Steven Wong* Intel - Michael Mirmak* Mentor Graphics Corp. - Arpad Muranyi*, John Angulo*, Vladimir Dmitriev-Zdorov Micron Technology - Randy Wolff*, Justin Butterfield Sigrity - Sam Chitwood, Raymond Y. Chen, Tao Su, Brad Brim* SiSoft - Walter Katz* Teraspeed Consulting Group - Bob Ross* ======================================================================== No patents were declared. During opens, Arpad Muranyi mentioned that he wanted several clarifications made to the minutes issued for the Interconnect team. Michael Mirmak will make the changes. Michael reviewed a list of key questions for IBIS-ISS direction, before Additional work can continue (an edited copy is enclosed). First, what is to be parsed? Just a single file? Multiple files? And are all to be considered ISS or not? Arpad suggested that a single, flattened file be evaluated, with the parser Flattening included files based on a call from the file being parsed. Brad Brim added that switches could be used, such as -R for recursive, -L for local, when parsing. Michael noted that earlier suggestions centered on a "top-level" ISS file that contained a single subcircuit definition. Includes would be allowed, but only in the context of that structure. An alternative would be to permit multiple subcircuit definitions in the top-level ISS file. Parsing for syntax would include any include file contents. Randy Wolff asked whether the parser should check files that include ISS syntax but not are not "top-level", per his warning message suggestion last time. With multiple subcircuits, where should the parser start? Arpad reminded the team that IBIS-ISS would likely be called from an IBIS file, for External Model/External Circuit, with a node list for connection and instantiation. Therefore, whatever the parser is given should be considered the top-level file, whether it contains subcircuits or not. Bob added that a search for local files may be included if the definition can't be found. Arpad responded that IBIS doesn't have an automated search hierarchy. Any definitions/includes must be found in the file itself or any local include files. Walter Katz suggested assuming an external circuit for a package. For a particular pin, we can have a filename and subcircuit name (with assumptions for MCP or node associations to ports, etc.). We may have to cope with multiple file opens/closes for the same file if multiple subcircuits are included. Why should we parse the contents? We don't for VHDL-AMS, for example. Randy asked whether this approach would assume a stand-alone parser for subcircuits. Walter responded yes. Arpad observed that we don't always have source code, as -AMS compilation is supported. The AMI file is separate, yet we parse it; PKG and EBD are also separate yet parsed. On subcircuit hierarchy, Radek Biernacki noted that any subcircuits have to be complete and the correct include statements must be present. Bob added that, for ISS, other files may be brought in but must be included Properly (the .include statement). Michael asked whether a single subckt or multiple subckts would be permitted in the top level file. Walter responded that he would like to see all subckts in one file (package.iss, for example); as an example, for pin 7, one could specify files and subckt names (say, three; one per corner). Bob suggested that no explicit limit be stated but agreed with Walter. Radek also agreed. Bob suggested that the parser trap on linked recursion in subcircuits (A calls B which calls A). Walter added that all files should include all Necessary contents below that subcircuit hierarchy level. Michael asked whether, per Randy's suggestions, we should be parsing files significantly below the top-level, if the parser were explicitly asked to do so. Walter suggested not, opting for top-level only. Radek added that the scope is local, every single file that you include must be a subcircuit definition. Randy responded that, if the parser can check every subcircuit on its own, will it flatten includes before checking? Will the parser check for subcircuit definitions if an instance of a subcircuit appears in the files? Arpad noted that SPICE allows splitting of elements across includes. ISS should follow this convention. Randy also asked whether the user must inform the parser what the top-level subckt is. Arpad replied that the parser can assume the file being checked is the top-level subckt. Bob added that flattening will help this. The team agreed that paths and directories should not be allowed and that the search assumptions should match those for IBIS files, PKG files and EBD files. On hierarchy, Arpad and Radek noted a preference for assuming local hierarchy after Michael's explanation of PARHIER operation. Bob added that this is a potential Area of conflict for cases where ISS files are brought into an existing SPICE tool. That SPICE tool's rules will obtain until the tool recognizes ISS formally (the tool could override the ISS assumption if it does not recognize ISS rules). Bob suggested documenting it the issue to ensure folks understand. Randy asked about nested subcircuits and parameter passing. The team agreed that explicit parameter passing is needed when instantiating subcircuits. The team did not agree on whether order dependencies existed in the definitions; this needs further research. Arpad suggested that, on last page of ISS, the document strongly discourage overriding the local parameter definition assumptions. Bob suggested "global hierarchy may change the results" or some similar language. The team consensus was that ISS-compliant files shall not include non-ISS files. Also, that no top-level distinction be made: files parsed by an ISS parser are either ISS-compliant or not. Includes will be automatically added to the file and the Complete text will be parsed. At least one subcircuit definition is required in the ISS file being parsed, but multiple definitions are permitted. Warning/error messages will result if a subcircuit is not present. Arpad raised a new issue: a new mechanism exists in HSPICE that allows independent scaling of elements/circuits (this is a change to an older global scaling option). This occurs at the instantiation level for subcircuits containing a particular element (e.g. capacitors). We need to know whether this should be added to ISS and, if so, we need to know what elements are affected; does it only affect .MODEL? This will be discussed/answered at the next ISS-related meeting. ARs Michael: get Synopsys HSPICE* documentation on device scaling