Fwd: Multiple Timing Formats and Ibis

-- [ From: Ron Christopher * EMC.Ver #2.10P ] --

Chris Reid,

Thank you for the feedback. I was not thinking that the physical
design data should be represented in IBIS. I was trying to preserve
the original IBIS model for the circuit, supplied and qualified by the
technology house, through all levels of packaging. This could perhaps
be done by allowing the IBIS model to be named by the package pin plus
a hierarchical internal node name which would correspond to a point
where the physical design data standard would relate. Our roadmap says
there will be a standard for physical design representation. I suspect
we need a standard for conveying a subset of the physical design which
consists of the physical connection data to connect the most external
pin of the package down through the hierarchy to the circuit. The
parasitic extraction is independent of the circuit model. We ought to
be able to use the qualified IBIS circuit model without modification.
This keeps the circuit model independent of parasitic extraction for
debug purposes as we progress up the hierarchy using different vendor
tools. Otherwise one will not be able to go back to the technology
house when the model does not work in the board environment. No one
will be able to determine what factors were put in and why.

Please guide me in my thinking.

Ron Christopher
------- FORWARD, Original message follows -------

> Date: Monday, 18-Sep-95 12:05 PM
>
> From: Chris Reid \ Internet: (chris@icx.com)
> To: Ron Christopher \ PRODIGY: (EGJJ77A)
>
> Subject: Multiple Timing Formats and Ibis
>
> Hello,
>
> It seems to me the point Ron Christopher raises about multiple dies
in one
> MCM is significant from a timing point of view, but is not
significant for
> Ibis with its current charter.
>
> From an Ibis viewpoint an MCM is just another package with a certain
set
> of driver, receiver, power, and ground pins. The particular
construction
> inside the package is not of interest except in how it affects the
package
> model (particularly with the Bird 28 changes).
>
> From a timing viewpoint it seems to me we must take a similar stand.
There
> is no hope of capturing all possible intricacies of an MCM layout in
some
> standard description language. That is the function of the layout
tool
> vendors and the associated analysis vendors. Many MCMs today are
simple,
> but there is no fundamental restriction on their structure. They
could
> become as complicated as a board.
>
> So, while Ron raises some important issues, I don't think this is the
> right forum to address those issues. Ibis should stay focused on a
package
> level description regardless of the internals of the package. From a
> timing perspective (which is off the thrust of Ibis) composite
packages
> such as MCM's will require timing models that descirbe their behavior
as a
> whole.
>
> Christopher Reid
> chris@icx.com
> 503-603-2527
>
>
>

------- FORWARD, End of original message -------
Received on Thu Sep 21 00:49:58 1995