NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/vhdl/430

Text File | 1992-08-27 | 4.5 KB | 108 lines

Newsgroups: comp.lang.vhdl
Path: sparky!uunet!clsi!shankha
From: [e-mail] (Shankha Mitra)
Subject: Re: VHDL 92 question
Message-ID: <[e-mail]>
Originator: shankha@clsi
Sender: [e-mail]
Organization: CAD Language Systems, Inc.
References:  <[e-mail]>
Date: Thu, 27 Aug 92 15:55:43 GMT
Lines: 95


The following is being posted on behalf of Paul Menchini:

--------------------------------------

In article <[e-mail]>,
[e-mail] (Thomas Dettmer) writes:
>
> Questions to the people involved in the restandardization process:
>
> 1. What is the actual status or when will we see a new valid version of the
> LRM?

As of this writing, the actual status is as follows:  The LRM has been
integrated with all approved IRs and LCSs.  This complete draft has been
reviewed once in North America (on 10-11 August), and will be reviewed
immediately after EuroDAC on 11 September.  Feedback received from the North
American review will definitely be incorporated into the balloting version; I
suspect that the same is true for the comments received at EuroDAC.

The second part of the question: "... when will we see a new *valid* version
..." [emphasis mine] depends on what you mean by "valid."  Strictly speaking,
the LRM will not be fixed (as in approved and therefore not subject to
short-term change) only after successful balloting and approval by the IEEE
RevCom committee, which probably will not occur until March 1993.  Between now
and then, the LRM can change in a variety of ways:

The pre-balloting reviews may cause changes to language features as well as
editorial changes to the LRM language, but are not going to cause wholesale
addition or deletion of features (e.g., "global variables").

During balloting (and, in particular, the response to balloting process) it is
possible for anything to change, although I expect that few language features
will be either added or deleted.

I suspect that once the Ballot Recirculation Document is sent the LRM will be
extremely stable in terms of both major features and their details, whether or
not the ballot is successful.

Once the LRM is successfully balloted, only minor editorial changes may be made
prior to RevCom approval and publication.  Hence, the LRM will be quite stable
at this point.

> 2. (more specific) Will the foreign language interface be part of the new
> standard? Or possibly I should say, will there be more standard than to
> declare functions in packages without a package body?

I can only speak with respect to the current draft, since my crystal ball is in
the shop....

There are "improved" provisions for providing subprogram bodies and
architectures that are not written in VHDL.  The mechanism is as follows:  A
new attribute, FOREIGN, has been declared in package STANDARD.  Any subprogram
body or architecture that contains an attribute specification annotating the
name of the subprogram or architecture (as appropriate) with this attribute is
a *foreign body*).  The value of the FOREIGN attribute is a string, whose
interpretation is implementation-defined.  A foreign body is subject to
special, implementation-defined elaboration rules (which presumably have the
effect of linking the body identified by the string into the model)--in
particular, any VHDL declarations or statements in the foreign body are *not*
elaborated according to the rules of Chapter 12.

I don't know if this "is more standard than [the 1987 approach]," but there it
is....


       Paul Menchini
       Chair, VHDL'92 Documentation Team

       Vice President of Marketing
       CLSI Solutions

Address: CLSI Solutions            Voice:       [phone]
     2 Davis Drive            VoiceMail: [phone], x307
     P.O. Box 13036            Fax:       [phone]
     Research Triangle Park, NC    Internet:  [e-mail]
        27709-3036        uucp:       ...!uunet!clsi!mench
     USA

"If an undetectable error occurs, the processor continues as if no error had
 occurred."    -- IBM System/360 Principles of Operation

"The base type of a type mark is, by definition, the base type of the type or
 subtype denoted by the type mark."    -- IEEE Std 1076-1987

"In particular, a type is closely related to itself."
    -- IEEE Std 1076-1992/A

"Elaboration of a private type declaration creates a private type."
    -- IEEE Std 1076-1992/A
--

-------------------------------------------------------------------------------
Shankha S. Mitra                                               [e-mail]
CAD Language Systems, Inc.                 uunet!clsi.com!shankha