jos@ele.tue.nl (Jos van Eijndhoven) (08/09/90)
To the 'comp.lsi.cad' News reading society,
the EDIF technical query contact Hilary Kahn.
With this message I hope to receive answers on 4 questions
regarding the semantics of EDIF.
=BACKGROUND=
To support an EDIF interface to design tools in our group,
I wrote a program that accepts as its input a full EDIF level 2,
keyword level 3 description. The (default) action of the program is
to perform the keyword level 3 macro expansion, and 'execute'
the EDIF level 1 and 2 constructs for one design hierarchy in the EDIF text,
thus producing a clean EDIF level 0 output text.
The program will provide accurate and detailed error messages on
all kinds of syntactical and semantical errors in its input.
Optionally, it can strip graphical, simulation, or userdata information.
Thus actual EDIF interfaces are shielded from the EDIF level 2 complexity,
and are allowed a simpler error reporting.
Another purpose of the program is checking locally generated EDIF files.
The program is now in its first testing and debugging phase.
A paper on this program, some remarks of me on the EDIF standard,
and hints to other implementors, is accepted (in abstract form)
for the European EDIF conference, October 1990.
Samples of EDIF level 1 and 2 descriptions are welcome to further test
the program.
=THE MANUAL=
For implementing this, my almost solitary source of information
was the EDIF 2.0.0 reference manual, EIA standard No. 44, dated may 1987.
All page numbers in the sequel refer to this book.
During the implementation considerable respect was built for the
originators of this manual. Almost all foreseen implementation problems
were correctly solved by small remarks in the supporting text.
However a few questions remained, which I would like to address in this
mailing.
=THE QUESTIONS=
1. The EDIF value type (miNoMax seems almost useless within the restrictions
imposed by the manual. These values can be created with the (mnm
construct, and then be copied between variables with the (assign
and (parameterAssign forms. However nothing else can be done with
them. They cannot be referenced in any other expression to use
their values in (numberValue contexts, opening up real use.
It seems that -either- a statement is required that says that a
'valueNameRef' to a miNoMax type variable is allowed in a 'numberValue'
context returning its nominal value (now forbidden: page 2-253),
-and/or- new constructs (forms) are needed to extract the individual
min, nom, max fields from these variables for further use.
I understood this correctly?
2. Suppose I have a miNoMax type parameter [variable] 'A' with a value of
-lets say- (mnm 0 1 9).
Now if I assign a new value to this parameter [variable] by means of a
(parameterAssign [(assign] construct, I suppose that all three fields of
the original variable are overwritten, no matter whether the new value
originates from a 'valueNameRef', (mnm, or otherwise.
Basically there is just no reason to assume otherwise. This would mean that
it is allowed to do a (parameterAssign A (miNoMax -1)).
The '-1' is first silently upgraded to (mnm (undefined) -1 (undefined)) and
then copied to A. Thus the original [0 9] boundaries do NOT prevent the
assignment of the -1 value!
A (parameterAssign A (number -1)) would give a fatal type clash (pp. 2-275).
I understood this correctly?
3. The (parameter (unit declaration is to be able to use convenient
parameter values, scaled with respect to the 'real world' SI values.
The (scale forms are required to pass these values out to other libraries.
If such a value is passed to another library, the value local to
the receiving library is obtained by multiplying the originally assigned
value with the ratio of the two (scales of this (unit in both libraries.
For (integer values this seems a problem, since multiplying with this
ratio could easily lead to fractions.
It seems natural to EDIF to have the new value type upgraded to a
numberValue, as the (divide does (page 2-86).
This silent and implicit type upgrading (integer->number->mnm)
is normal to EDIF expressions, and is determined by the TYPE of the
operands and the respective operation, NOT by the actual VALUE of
the operands. This would mean that a (parameterAssign size (integer 6))
to a (parameter size (integer) (unit distance)) in another library
will be ALWAYS type upgraded to a numberValue -irrespective of
the actual (scale values- and hence cause a fatal type clash
with the declared integer parameter. (A silent implicit type downgrading
form number to integer is never done in EDIF expressions).
This would mean that (unit declarations can never work for (integer
parameters (although such examples are given on page 2-381).
Where is my mistake ??
ps: I silently assumed that (unit would not work for the types (boolean
and (string. Type (pt is questionable to me. A statement on
this would be nice.
4. If I would only be interested in basic netlist connectivity information,
can I than simply eliminate (discard) subnet '(net (net' and
'(net (instance' constructs without affecting the network structure
information? i.e. fully relying on the single line:
"It (The net construct) must contain a single joined statement which
determines its effect on connectivity" (page 2-229)
Any reactions are highly appreciated,
Jos van Eijndhoven
Eindhoven University of Technology
The Netherlands
jos@es.ele.tue.nlwbaker@comet.Berkeley.EDU (Wendell Craig Baker) (08/10/90)
The following are some answers to your questions regarding EDIF 2 0 0.
They are based on the experience of writing a toolkit for building
EDIF 2 0 0 translators; a description of this system and its
availability are described below.
1. Re: miNoMax
Yes, there is no way to reference the minimum, nominal or maximum
values from within the framework of EDIF 2 0 0; these values may be
stored in variables (constants, parameters, variables), but there is
no way to reference their member values (as there is for pointValues
via xCoord and yCoord).
2. Re: parameter valueNames and the use of assign
It is my understanding that the valueName defined by a parameter
is readonly, as is the valueName defined by a constant. The only
valueName which can be used in a destructive assignment operation are
the valueNames defined with a variable. Yes, the assignment of
(parameterAssign A
(miNoMax -1))
equivalent to the following:
(parameterAssign A
(miNoMax (mnm (undefined) -1 (undefined)))
3. Re: scaling
Yes, scaling between libraries is not consistent and can cause integer
values to become floating-point values. The same occurs with points
which must fall on the integer grid, and after scaling them may not
necessarily do so. Currently my view is that this is an inconsistency
in the EDIF 2 0 0 specificiation, and thus it is the user's call
(opinion) as to whether the values are (a) truncated to the nearest
integer coordinate, (b) the values are promoted to floating-point
wherever possible or (c) the operation is invalid in the first place.
Unit of course, does not affect boolean or string types; it does
affect pt types because they are implicitly DISTANCE units.
4. Re: nets and subnets
Yes, the subnets can be discarded because they only refine the
connectivity definition that has been established in the net's single
joined construct. The subnets are typically used to represent
routing and as such connect between the ports referenced in the joined
statement and the TIE instances that may be instantiated in the net
body.
I hope this helps a bit; if its useful, you may want to check out
edifLint on the toolkit distribution
You may also find that it is useful to obtain certain of the EDIF
committee's publication regarding netlist and schematics
representation in EDIF 2 0 0. I do not recall the exact titles at
this point. The User's group address is as follows:
EDIF User's Group
P.O. Box 25542
Tempe AZ 85285-5542
In addition Prof Hilary Kahn runs a question-and-answer service for
authoritative answers to such questions. The service can be reached
at edif-support@ux.cs.man.ac.uk
Wendell C. Baker
Berkeley CAD Group
U. C. Berkeley
Berkeley CA 94720
wbaker@comet.berkeley.edu
Ordering Info:
-----------------------------------------------------------------------
You can get the tape from the Industrial Liason Program Office
for $250.00 shipping and handling at the following address:
Industrial Liason Program Office
479 Cory Hall
Electronics Research Laboratory,
University of California, Berkeley
Berkeley CA, 94720
ATTN: Cindy Manly
If you have access to ftp, then the tape is free (you just get to suck
it over by yourself) and you hae to remember to print out the docs
yourself too. The usual anonymous ftp rules:
Name: comet.berkeley.edu
Address: 128.32.132.34
/EDIFWorld89.ps
|-Release_7.5-f14-hlnk-nexc.tar.Z (Release 7.5 for SysV/HPUX etc)
|-Release_7.6-notes-reversed.ps
|-Release_7.6-notes.ps
|-Release_7.6.tar.Z (Release 7.6 for others)
edif-|-agreement-reversed.ps
|-agreement.ps
|-agreement.tex
|-assurance-reversed.ps
|-assurance.ps
|-assurance.tex
|-blurb
\blurb+ftp <------- this file
Other Ports
--------------------------------------------------------------------
I have ports of the system for SysV and Apollo machines as well
The file Release_7.5-f14-hlnk-nexc.tar.Z in the ftp directory is
the port of Release_7.6.tar.Z suitable for use on SysV/HPUX/AIX.
The system has been ported to other Non-Unix machines such as VMS
and various mainframe architectures; these latter being a nontrivial
effort on the part of the individuals involved, but it was accomplished.
The ILP blurb
--------------------------------------------------------------
EDIF 2 0 0
Release 7.6
-----------
The major feature of this new release of the Berkeley EDIF 2 0 0
Software is the implementation of the CAD Framework Initiative (CFI)
Scalar Netlist Interface for 1990 as was demonstrated at the 27th
Design Automation Conference in Orlando Florida. Through the use of
this interface it is possible to make any CFI-compliant program read
EDIF 2 0 0 as input with no modification to the program. That is, any
program, using the CFI-defined interface can directly read data from
an edifFile through the use of this new package. In addition to this
new feature, there are numerous bug fixes and portability enhancements
that have been contributed by users of the toolkit.
The Berkeley EDIF 2 0 0 Software is an environment for managing EDIF
2 0 0. The system is a translator-building toolkit that provides all
facilities necessary for building a translator to or from EDIF 2 0 0.
Using the toolkit, it is possible to construct any translator; the
translator-writer should only have to provide access to the source or
target data format.
The toolkit uses an efficient in-core data structure specifically
designed to store the EDIF syntax. This data structure is called
the EDIF Heap. The EDIF Heap supports the storage of the EDIF syntax
as well as providing a compiler-like symbol-table data structure.
Lisp memory management systems have been extensively investigated.
Because there are many similarities between Lisp and EDIF, the results
from this work has been used to advantage of in the implementation of the
EDIF Heap. For example the scheme known as ``typed pages'' is used in
the EDIF Heap to simulate a tagged architecture. Further, the Lisp
symbol-table data structure, called the ``environment'' has been extended
for use in the EDIF Heap. In Lisp, the environment need only support
two name spaces; in EDIF 2 0 0, there are seventeen name spaces.
The toolkit consists of a storage manager for the EDIF Heap which provides
automatic allocation and garbage-collection services. Also provided are
routines converting the EDIF Heap structures to and from their printed form.
These routines perform reading and printing of the EDIF syntax.
Other routines provide the services of macro-expansion, expression-evaluation
and statement-execution. The goal of the EDIF 2 0 0 software is to provide
an environment that will support the manipulation of EDIF in a straightforward
manner and also to provide a system with which it is easy to build translators.
translators to and from EDIF.
In addition to the new CFI Scalar Netlist Interface, Release 7.6 also
contains EDIF-manipulating programs such as the ``edb'', the EDIF
debugger, and ``edifdiff'' which compares two edifFiles independent of
how they were formatted.
In addition, Release 7.6 supports all edifLevels and all keywordLevels. The
set of tools in the EDIF 2 0 0 tools are translators to and from CIF, OCT,
an ``linter'' for syntax and semantics checking, an ``EDIF debugger''
which has much of the flavor of a C source-code debugger, a PostScript plotter,
and two EDIF manipulation programs designed to perform such operations
as macro expansion, parameterized-design instantiation and a host of other
operations.
The toolkit provides a simple programming paradigm and users are encouraged
to use the system to build translators to and from their own databases.
Hardware/Operating System Requirements:
DEC VAX and DECstation running Ultrix 2.2, 2.4, 3.0, 3.1, and 4.0;
4.2BSD and 4.3BSD UNIX; Sun OS 3.2, 3.5, 4.0, and 4.1; Sony NeWS;
4.3BSD Utah for the HP; and Apollo 10.1 and 10.2, Sequent DYNIX as
well as many others. The system has been ported to SystemV, HPUX 5.5
and 6.5, Apollo 9.7 and 10.0.1, the MacIntosh and VMS. The authors
should be contacted directly for concerning the availability for these
systems.
Versions Available: UNIX only
Distribution Media: 9-track, 1600 BPI, 2400-ft. magnetic tape
Source Code: Yes
Object Code: No
Programming Language:
The system is written in the C language and is compatible
with both ANSI C and the Portable C Compilermike@edif.sps.mot.com (Mike Waters) (08/11/90)
wbaker@comet.Berkeley.EDU (Wendell Craig Baker) writes: > The following are some answers to your questions regarding EDIF 2 0 0. > They are based on the experience of writing a toolkit for building > EDIF 2 0 0 translators; a description of this system and its > availability are described below. Wendel's answers appear to be correct to me, but you must be very careful in accepting "unoficial" interpretations since there are often subtleties which are only spotted after careful review. As a result you run the risk of receiving different answers from different people (or by asking at different times!). The only answers that should be depended on are the ones received via Hilary Kahn You should always send your questions to Hilary for a reviewed response, including correlation with the questions that have already been asked. There are currently four volumes of "EDIF Questions and Answers" available from the University of Manchester. Write to Ms. H.J. Kahn, Department of Computer Science, University of Manchester, Oxford Road, Manchester, M13 9PL, England for more information. You can send the questions by ordinary mail, FAX or E-mail. The e-mail address is edif-support@ux.cs.man.ac.uk Alternatively you can forward your mail via the EDIF BBS 602-897-5478 E-mail address edif-support@edif.sps.mot.com I have forwarded your post to this address to be sure that it is not missed! > You may also find that it is useful to obtain certain of the EDIF > committee's publication regarding netlist and schematics > representation in EDIF 2 0 0. I do not recall the exact titles at > this point. The User's group address is as follows: > > EDIF User's Group > P.O. Box 25542 > Tempe AZ 85285-5542 The USA EDIF User Group no longer publishes the EDIF User Guides nor the EDIF Technical Notes. They are still the source for past issues of the EDIF World Workshop proceedings. For copies of the Standard (now ANSI/EIA Standard 548 BTW), User Guides, or Technical Notes contact: Electronic Industries Association, 2001 Eye Street, N.W., Washington, D.C. 20006. Phone (202) 457-4962 They also have European and Asian distributors, but I don't have their addresses here.