1 / 6

Update, Restart, or Fork? Exploring the Future of IBIS for Complex Package Models

This document by Michael Mirmak discusses the challenges of adapting IBIS (Input/Output Buffer Information Specification) to support increasingly complex package models, including on-die interconnects. It raises critical questions about the sufficiency of IBIS 5.x/6.x in modeling these packages and whether a fresh approach or modifications to existing keywords are needed. Key considerations include the number of existing models, the relevance of old IBIS files, and necessary references within package data. The paper evaluates the pros and cons of modifying existing structures versus starting anew with a clean slate.

ianthe
Télécharger la présentation

Update, Restart, or Fork? Exploring the Future of IBIS for Complex Package Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Update, Restart or Fork? Michael Mirmak Oct. 3, 2012

  2. The Question… • Are useful package models so complex that traditional IBIS cannot be modified to support them? • “Package” here includes on-die interconnect In other words, to support packages, must we… • only add/change keywords in IBIS 5.x/6.x • invalidate existing keywords/relationships • … or start with a completely fresh approach?

  3. Clarifying Questions • How many models are generated today using the original package/pin/buffer intent of IBIS? • How many models use & tools support keywords outside of [Model] scope, such as [Pin Mapping] and [External Model]? • How many existing “old” IBIS files are likely to be updated with new format package data but without buffer model changes? • Assume “old” means IBIS 4.0 and below • Does including IBIS 4.2 and below make a difference? Rating the importance of existing structures & keywords is key to deciding next steps for IBIS

  4. What Do We Need • References to pins • References to die pads (I/O) • References to buffer power connections (may involve multiple die pad connections) • Many-to-one pad-pin connections • One-to-many pad-in connections • Simple, easy-to-understand syntax • Minimal IBIS community costs/burdens See previous IBIS-ATM meeting proposals and lists; Strong agreement here

  5. Pros/Cons Working List • Modify existing IBIS: Add keywords but preserving structure • Examples: [Pin], [Model], [Component], [Pin Mapping], [Node Declarations] stand, add [Package Circuit] • Fork: Deprecate keywords and assumptions, while adding others • Example: Remove one-to-one [Pin]/[Model] assumption, deprecate [Pin Mapping], add [Die Pads]… • “Blank Sheet of Paper”: no relationship to IBIS 5.1 assumed • Examples: LISP-like tree hierarchy, separate model, package, component files

More Related