BIRD100: A Series of Package Choices

1. BIRD100:A Series of Package Choices Michael Mirmak Intel Corp. Chair, EIA IBIS Open Forum

2. Status • Creation of BIRD100 has hit a wall • Intended to define IBIS-ICM link syntax • What the draft BIRD100 includes today • “instance_name” -- a subparameter of [Pin] • Permits multiple [Model]s on one pin, and multiple pins tied to a single [Model] instance • “Pad” – a subparameter of [Pin Numbers] • Permits traditional [Package Model] constructs to connect to multiple [Model]s • Notes on ICM Naming Convention • A set of instructions on properly naming ICM nodes to map to [Model] and [External Model] connection points

3. The Problem • IBIS ambiguities force choices for ICM linking • Need definitive statements on the application of and relationships between several keywords • [Pin Mapping] and package models • POWER and GND [Pin]s and package models • Package models and [Pin]s / [Model]s • Additionally… • For what IBIS constructs should ICM be available? • For what IBIS constructs should traditional packages be available? • Interactions to check • IBIS buffer construct (native, [E. Model], [E. Circuit]) • Pin modeling of power/ground ([Pin] uses POWER or not?) • [Pin Mapping] (used or not?) • Package model type ([Package], [Package Model], ICM, R_pin, etc.) • BIRD100 constructs (instance_name used or not?) • 96 different combinations in all

4. Key Questions • BIRD100 as written is incomplete • Not all IBIS 4.1 Fig. 12 cases addressed • The following slides ask key questions which must be answered to complete BIRD100 • Answers to these questions will impact how BIRD95, AMS are implemented • These may also affect tools currently implementing [Pin Mapping] and other package keywords • Keep in mind potential EMI and non-PC applications (JEITA requests)

5. Figure 12 (top)

6. Figure 12 (bottom)

7. Q1: [Pin Mapping] • [Pin Mapping] • What is the relationship between [Pin Mapping] and package models ([Package], [Package Model], R_pin)? • Where are [Pin Mapping] connections made? • At the buffer rail? (option a below) • If so, packages “sit” between [Pin Mapping] busses and pins • At the pin, with ideal shorts? (option b below) • If so, packages “sit” between [Pin Mapping] busses and individual buffer rails • R_pin makes less sense in this version • May we assume [Circuit Call] prohibits [Pin Mapping]? • For just the affected pins? • For the entire component? • Will instance_name work with [Pin Mapping]? We cannot avoid a choice here

8. (a) [Pin Mapping] as On-die • Package model associated with pins • [Pin Mapping] is between packages and buffers [Package], [Pin] [Pin Mapping] [Package Model] A2 (POWER) pullup_ref Digital Port A1 pulldown_ref A3 (GND)

9. (b) [Pin Mapping] as Pin Shorts Digital Port • [Pin Mapping] shorts pins together Pkg A2 (POWER) pullup_ref Pkg A1 A5 (POWER) Pkg A3 (GND) Pkg pulldown_ref Digital Port Pkg A4 A6 (GND) Pkg

10. Q2: Traditional Packages • Traditional Package Models • [Package], [Package Model] and R_pin, etc. • How do these relate to power/ground connections? • Example • Pin A1 is defined POWER. It has R_pin, L_pin, C_pin associated with it (this is not prohibited) • Is the package model connected to this pin? • If so, where is “the other end” of the package? • If not, is pin A1 a direct short (and if so, to where)? • Same question applies to [Package Model] • “Endpoint” is assumed the die pad; which one? • Currently, only [Pin Mapping] resolves this situation • Without 4.1 port definitions (A_puref) or [Pin Mapping], package details on power are meaningless

11. Q3: IBIS 4.1 Ports • IBIS 4.1 creates standard ports (A_puref) for [E. Model] • Same port names can be applied to [E. Circuit] • Should we allow use of A_puref, etc. ports for package definitions, [Pin Mapping], etc.? • Example: Pin A1 (POWER) connects to A_puref for I/O pin A2 • If not, [External Model] cannot connect to packages without ICM • See Fig. 12 in IBIS 4.1; where do these ports go? • How do [Pin Mapping] and [Package Model] connect to A_puref? • Option 1: assume A_puref = pullup_ref • Shorts all [External Model] supplies • This prohibits multiple buffer instances now in BIRD100 • Option 2: allow “A_puref” in [Pin Mapping] syntax • Option 3: allow “instance_name.A_puref” in [Pin Mapping] • Also allows [Package Model] to use ports & multiple instances

12. Q4: IBIS 4.1 Ports for [Model] • IBIS 4.1 suggests ports apply to native [Model]s • “Native” [Model]: [Model] without [External Model] • Do we allow A_puref to be used with native [Model]s? • Should instance_name be permitted alongside these constructs? • If so, [External Model] just got expanded to work with multiple instantiations (not necessarily bad)

13. Proposals • Prohibit [Pin Mapping] and [External Circuit] • Prohibit [Pin Mapping] and [External Model] • Document [Pin Mapping] as connecting packages to buffers (packages connect to pins) • Permit use of ports with traditional IBIS • Example, A_puref for [Model] without [E. Model] • Permit use of [Package Model] with [E. Model] • Allow dot notation “Pad” subparameter in [Package Model] • Example: Pad=myinstance.A_puref, wheremyinstanceis a specific instance_name under [Pin] • Permit ICM for ALL flavors of IBIS (native, multi-lingual) • [Model], [External Model] links must use the die node syntaxinstance_name.port_name • Integrate ICM parser into IBIS parser • Raise total IBIS parser fee to $3000 • Permits checking of ICM as [Package Model] file • Permit ICM code within an IBIS model