Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!hp4nl!tuegate.tue.nl!al.ele.tue.nl!jos
From: jos@ele.tue.nl (Jos van Eijndhoven)
Newsgroups: comp.lsi.cad
Subject: questions on EDIF semantics
Keywords: EDIF semantics
Message-ID: <539@al.ele.tue.nl>
Date: 9 Aug 90 10:15:47 GMT
Sender: jos@ele.tue.nl (Jos van Eijndhoven)
Organization: Eindhoven University of Technology, The Netherlands
Lines: 106

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.nl