DIE Information Exchange for Timing (DIET) Format

>Hi Larry
>
>We are most interested in existing and proposed industry standards and the
>DIET timing information for complex ICs sounds most interesting. I would
>appreciate any additional information you could send us about DIET and how
>it relates to Vital.
>
>Thanks
> Dave Ackley
> dackley@ichips.intel.com
>

DIET is a new format concerned with representing timing for static and
dynamic (simulation models) timing analysis of complex digital component models.
LMG, Synopsys Inc. has three different file formats for model timing
information -- each based on a different modeling technique. There
is no need for this. Mentor G has their own static timing format embedded
in their technology files.

The DIET format, along the lines of the DIE work LMG has done, is meant to make
it easy for IC manufacturers to deliver timing information in a computer
sensible format. The efforts grew out of our DIE format
work as a need identified by users and IC manufacturers.

The major difference between VITAL and DIET is that DIET is black-box oriented
and VITAL is clear-box oriented.

DIET is about describing the generic, external
timing characteristics of complex components - the timing information that
IC manufacturers deliver to users of their components. Usage specific
timing data is not included. Internal behavior and timing are not included.
Generally, some program would read DIET data along with MCM or board netlist
information and generate MCM or board specific timing information for use
by some static or dynamic timing analysis tool. There is intent to avoid
dealing with the detailed internal behavior of the part.

VITAL is about describing the usage specific, internal
timing characteristics of complex components where the gate level structure
of the model is known. Generally, some program would read VITAL data
and generate component specific timing information for use
by some static or dynamic timing analysis tool. There is intent to
deal with the detailed internal behavior of the part.

I suppose the subset of VITAL information concerned with
describing the I/O timing characteristics of a complex component could
be used as a basis for constructing a DIET description.

The only real overlap I see between the two formats is the case where some
component contains a megacell. If the internal structure and behavior of
the megacell is not known or irrelevant, then DIET may be the
way to describe the external timing characteristics of the megacell.
I'm not sure how VITAL could handle the situation.

I expect to have a Language Reference Manual and maybe an example or two
available sometime next week. This information will be available on the
VHDL.ORG machine. I will send out a notice when it is ready along with
an explanation of how to access the files.

From original announcement:

>The DIET Format is an unambiguous, EDA-tool processable, human-readable
>exchange format for specifying timing information about bare die and will
>represent data in typical IC component manufacturer provided format. It is
>initially intended for use in MCM design processes and will cover all
>aspects of bare die timing including specification and checking. It is
>intended to cover component required timing information, not instance or
>designer specific information and will provide specification of timing for
>complex, IC level components intended for MCM level use, not ASIC gate
>level components. The format is intended to replace the many ad-hoc formats
>in use today by EDA tools and MCM foundries and to provide a mechanism for
>IC manufacturers to provide important information about their products in a
>computer-sensible form.
>
>Preliminary information about the DIET Format semantics and syntax is
>available electronically.

Larry Saunders
lfs@mcimail.com or lfs@synopsys.com
408-894-0119 415-694-1837
408-894-0119 (fax) 415-962-8637 (fax)
1426 Cedarmeadow Ct 700 East Middlefield Rd, Bldg C
San Jose, CA Mountain View, CA
95131 94043-4033
Received on Tue Aug 23 11:28:06 1994