====================================================================== IBIS FUTURES/COOKBOOK SUBCOMMITTEE MEETING MINUTES Date: October 7, 2004 Attendees: Intel - Michael Mirmak, Arpad Muranyi Mentor Graphics - John Angulo, Ian Dodd Teraspeed Consulting - Bob Ross ====================================================================== Next Meeting: Thursday, October 21 1 PM - 3 PM US Pacific Time Telephone Bridge Passcode 916-356-2663 2 998-6947 Agenda: 1 - 1:05 PM Opens 1:05 - 2 PM Cookbook Discussion - Review of latest differential portion of Cookbook draft 2 - 3 PM Futures Discussion - Review of Cisco Power Delivery/SSO BIRD ======================================================================== COOKBOOK MINUTES Michael Mirmak summarized the latest Cookbook changes to chapter 4. He pointed out an improved diagram showing how [POWER Clamp] and [GND Clamp] tables combine the parasitic transistor behaviors of a buffer with actual ESD structures. John Angulo commented that, while this was true, the presentation might be confusing for some readers. Michael responded that the choice of audience for the Cookbook controls the level of detail. Arpad Muranyi pointed out that the improved diagram still does not show the proper connection of the bulk/substrate nodes to the power supplies involved. He also asked that a specific pad block be shown. Michael will update the document with two drawings: a simplified version to match current usage in the industry, and a more detailed version which includes the substrate connections and parasitic diodes. Bob Ross noted that NCSU might be interested in Arpad's surface technique for collection of IBIS data from differential buffers, perhaps for a future version of SPICE2IBIS. ARs --- Michael, Arpad: determine if actual ESD diodes are used separately from transistor parastics in current designs Michael : update document with both simple and detailed diagrams ======================================================================== FUTURES MINUTES John Angulo introduced the changes to BIRD91.1 over the previous version. The new version makes some stylistic and wording changes to clarify the intent and application of the BIRD. It also ensures that D_switch is mentioned specifically for both [External Model] and [External Circuit]. The key aspects are: - specifies the industry standards (IEEE, Accelera) which are required to ensure common data types are used for the port state definitions within multi-lingual models - defines the analog and digital type requirements for VHDL-AMS and Verilog-AMS ports within multi-lingual models - limits reserved digital input ports in multi-lingual models to the states 0, 1,'0' or '1', depending on the language used - limits reserved digital output ports in multi-lingual models to the states 0, 1, X, '0', '1' or 'X', depending on the language used. - permits user-defined ports under [External Circuit] to use any of the states defined under IEEE Std. 1164-1993 Bob Ross commented that much of the BIRD's language was repeated for the [External Model] and [External Circuit] sections. He asked John Angulo to investigate placing a single block with the relevant new text near the beginning of Section 6b. Ian Dodd joined and helped the team clarify the following critical questions regarding [External Circuit] and user-defined ports: **************************************** Q1) Should user-defined digital ports be permitted? If not, digital ports would be limited to D_drive, D_enable, D_receive and D_switch with defined uses. A: Yes. The consensus of the team was that users and model authors will soon need the ability to control buffer behaviors outside of the reserved port definitions. The specification should support user-defined digital ports. Bob Ross proposed, as an alternative, that digital ports could be redefined using analog signals, to essentially "SPICE-ize" digital controls in the short-term. These controls could be re-enabled in a future version of the specification. Michael Mirmak raised objections that this removed any advantage to AMS language support. Other participants suggested that the AMS languages are available now and are already supported widely. Delaying their integration with IBIS adds no value. **************************************** Q2) Should user-defined ports be identified by type (as digital or analog)? A: Yes. To avoid type mismatches and to assist netlisting (which will cluster or group these), user-defined ports should be identified as digital or analog. **************************************** Q3) Should user-defined digital ports have identified direction (in, out, bi-directional)? A: Yes. To avoid state contention, user-defined digital ports should be identified as possessing a specific direction. **************************************** Q4) Should user-defined analog ports have identified direction (in, out, bi-directional)? A: Unknown, as the meaning and value of "direction" as a concept for analog ports is unclear. Verilog-AMS appears to support analog port directionality. Ian took the AR to check with Mentor Graphics' internal AMS experts. **************************************** Q5) Should user-defined and reserved digital port connections be permitted? A: Yes. As there will be digital control capabilities in EDA tools in the short term (see above), connecting user-defined and reserved digital ports will be of use. **************************************** Q6) How should the type and directionality of user-defined ports be identified? New keyword? Naming convention? Some other means? A: Opinions varied. Arpad Muranyi suggested that a naming convention be enforced, as A_* and D_* names are already in use for [External Model]. Bob Ross favored using either a separate keyword or another identifier such as a subparameter of an existing keyword. This can be resolved separately. **************************************** Q7) Should non-electrical types (mechanical, thermal, etc.) be permitted for IBIS AMS ports? A: Not for the present. The issues noted above would be compounded for non-electrical ports. **************************************** Ian Dodd also noted that some confusion stil exists regarding the purpose of CIRCUITCALL's pin references. Michael Mirmak stated that CIRCUITCALL's reference to specific pins enables a key request of EDA tool vendors; viz., that EDA tools be informed which ports are associated with active signal pins. CIRCUITCALL explicitly identifies the pin of interest for measurements and the specific ports and nodes which contribute to activity on that signal. ARs --- Ian : Consult with VHDL-AMS and Verilog-AMS experts to determine if/why analog port directionality is required Arpad, Bob: Prepare proposals and justifications for naming conventions vs. separate keywords to identify port type and direction John : Prepare a proposal to combine BIRD 91.1's text into a single block for inclusion at the beginning of Section 6b.