Fwd: [OVI/DC-TSC/WG-arch-No.22] Multiple Standards in Timing Verification

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

In the teleconference call Friday 9/15/95, I was asked to put the text
from the referenced file here on the reflector without the picture for
those who cannot retrieve either the .mif or .ps file available on
cfi.org/incoming.

The text only of the referenced file follows:

I believe ASIC vendor timing tools are used both on the chip and above
the chip. This hierarchical processing will move from above the chip
boundary down inside the chip itself. There is good standardization
work going on for the chip itself but what about the interactions above
the chip? Many of the problems currently occurring above the chip in
timing will be moving down inside the chip as chip design complexity
increases in the next three years.

Figure 1 shows two chips connected together on an MCM. Wire X is the
connection and associated wire on chip 1 connecting a driver and a
receiver circuit and the chip pad. Wire Y does the same on chip 2.
Net D is the connection on the MCM connecting the two chip pads
together.

Assume that chip 1 represents a component where the designer provided
timing data in the DIET form. The second designer used the CFI/OVI
methodology for ASIC chip using the DCL delay language. The second
designer for chip 2 ran delay abstraction which creates a special
abstracted form which can only be used by the ASIC designer's timing
verifier tool when processing the higher level package.

Delay calculation on the MCM requires SPICE like analysis of the module
net D which requires IBIS models. Now, should the designer of chip 1
have to construct a single IBIS model for the driver and the receiver
together with the chip wire effects, or should there be a standard
which allows the system to use the IBIS model of the driver and the
IBIS model of the receiver and the wire segments of just the net which
connects to the chip pad so no further manual derivation is required as
processing proceeds up the hierarchy from the chip analysis to the MCM
analysis, and to the board analysis.

If one want to extend this methodology down to hierarchical processing
on chips, the DIET format does not contain sufficient information to
handle rise time dependent delays on unbuffered drivers.

What is the architecture for this higher level delay calculation and
timing verification? Is wire X and wire Y counted in the chip
processing? Must it be included in the Net D analysis? There must be
a standard methodology for handling this. Is DCL used at the higher
level to call a SPICE analysis?

------- FORWARD, Original message follows -------

> Date: Monday, 11-Sep-95 12:26 AM
>
> From: Ronald J Christoph \ Internet: (egjj77a@prodigy.com)
> To: Ron Christopher \ PRODIGY: (EGJJ77A)
>
> Subject: Fwd: [OVI/DC-TSC/WG-arch-No.22] Multiple Standards in Timing
> Verification
>
> I should have addressed these concerns/questions to the IBIS forum as
> well. In hierarchical processing involving ASIC chips, I recommend
there
> be an IBIS model for each driver circuit and for each receiver
circuit and
> a standard representation for the physical parasitics. If this is
where
> we are going, then associating a single IBIS model with a component
MCM
> pin (if I understand IBIS) seems questionable for the future?? My
> questions are illustrated in the referenced file.
>
> Ron Christopher
> ------- FORWARD, Original message follows -------
>
> > Date: Wednesday, 06-Sep-95 02:17 AM
> >
> > From: Ronald J Christoph \ Internet: (egjj77a@prodigy.com)
> > To: Ron Christopher \ PRODIGY: (EGJJ77A)
> >
> > Subject: [OVI/DC-TSC/WG-arch-No.22] Multiple Standards in Timing
> > Verification
> >
> > I have put some timing verification methodology and standards
concerns on
> > the relationships between the DCL delay calculation language, IBIS,
> and DIET into a framemaker .mif file. The file is timever.mif at
> > ftp.cfi.org/incoming.
> >
> > I am sure it requires further explanation, or maybe someone has it
all
> > resolved.
> >
> > Ron Christopher
> >
> >
> >
>
> ------- FORWARD, End of original message -------
>
>
>

------- FORWARD, End of original message -------
Received on Sun Sep 17 21:41:14 1995