1. Please review the latest 1076a LRM edits ASAP. I hope to submit a
package to the IEEE by the end of this month for RevCom.
ftp://vhdl.org/pub/svwg/doc/lrm-edits/latest.
2. Our next meeting is Monday, 5 April 1999 from 6-9pm at Mentor Graphics
in San Jose, CA.
The Minutes:
VASG Meeting Minutes
8 March 1999
Munich, Germany
Attendees:
Victor Berman
John Willis
John Hillawi
Francoise Martinolle
Satayam
Greg Peterson
Wolfgang Ecker
Steve Bailey
Alex Zamfirescu
-------------
1076a Status
-------------
Ballot passed
Ballot resolution completed and distributed.
1076a LRM has been updated and published on vhdl.org for review
Comments on new 1076a draft LRM are due by 20 Mar 1999
Steve will be putting together standard package for submission to the IEEE.
Goal is to have it submitted by the end of March.
Alex Zamfirescu requested a PDF version of the 1076a LRM changes that
are submitted for final IEEE/RevCom approval for the IEC. The PDF
should permit changes to the header/footer so that IEC can make pagination
changes and insert IEC header information.
------------
PLI Status
------------
Francoise Martinolle presented the PLI status.
Several issues raised and discussed.
1. Because the PLI will be balloted after 1076a and 1076-99, the
PLI group must address the changes with shared variables and VHDL-99.
The biggest issue is shared variables. John Willis performed a
past analysis in this area that included
the larger issue of supporting multi-threaded applications on either side
of the PLI. It was pointed out that the shared variables impact is a
subset and must be addressed while multi-threaded PLI support does not.
Steve Bailey suggested that the PLI should make explicit the implicit
lock/unlock of access to shared data defined in the 1076a semantics.
There is also a need to address the protected type changes. John Willis
stated the need to access an "instance" of a protected type (the shared
variable instance specifics) as well as the instance-independent
information.
He gave the analogy of record types. There was additional discussion but
general agreement.
2. Alex Zamfirescu asked if shared variables can be created through the
PLI.
Satayam replied that since signals cannot, neither should shared variables.
There was no disagreement that the PLI should not allow the creation of
shared variables.
3. Prior to the day's discussion, Francoise had planned on completing
an internal review of the PLI's technical document by 22 April 99.
Addressing shared variables and VHDL-99 may push that date out.
4. LRM editing is scheduled to take 2 months after the PLI's internal
review is completed.
5. Alex Zamfirescu raised the question of what is normative and what
is informative with the PLI. Specifically, the question of whether the
information model should be normative.
Much discussion ensued with the result consensus being that the
information model must be normative as it specifies in what contexts
specific PLI calls are permitted, among other things.
6. The normative/informative discussion spawned another issue which
was whether the PLI should have a requirement/goal that any PLI application
would be binary compatible if it is executed on the same hardware/OS
platform and the PLI server provides a compatible interface.
The PLI is to be ANSI C standard. However, ANSI C provides certain
flexibility in how types are implemented. Therefore, it was discussed
and agreed that the PLI standard should require a PLI implementation to
document, in some form, the implementation specifics in these areas of
flexibility in ANSI C. This would define whether one PLI server is
compatible with another for the same platform.
7. The PLI needs a "don't optimize" attribute to denote things in
the VHDL code which should not be optimize away. This would allow
a PLI user to force a compiler/simulator to keep dead code, dead
objects, port hierarchy, etc. that otherwise might be optimized
away. The analogy is the synthesis "keep" attributes which preserve
net names, signals, etc.
----------------
1076-99 Status
----------------
The LCS's are complete.
The VASG approved all LCSs (see previous email).
There is a request to add an LCS/LRM change that specifies
that the library STD contains only packages defined by 1076 and that
library IEEE contains only design units identified by this or other
IEEE standards as being located in that library.
LRM editing should be targeted to be complete by end of April so
that Paul is not busy editing both 1076-99 and PLI at the same
time.
IEC requested PDF format for review as soon as a draft 1076 LRM is
ready.
-----------------
VHDL 200x Status
-----------------
No progress as most volunteers busy with 1076a and/or 1076-99.
Alex Zamfirescu suggested that we may want to directly
incorporate the numeric_bit and numeric_std packages directly
into 1076. This would allow us to define a more comprehensive
and easier-to-use relationship between signed/unsigned vectors
and integers, as with Verilog.
Wolfgang Ecker has volunteered to look into updating std_logic_1164.
He should also consider the pros/cons of integrating std_logic
into 1076. Integration of numeric_std requires integration of
1164.
------------------------
1076-99 Working Session
------------------------
The remainder of the meeting reviewed the various comments
provided on LCS's from the VASG approval vote. The following
summarizes the results of this review.
LCS 3 Comments Response:
------------------------
The LCS stands. However, Paul Menchini should further review
the LCS and comment to further ensure there are no issues that
impact LRM editing. Specifically, we need to ensure that the
LCS allows a port P in entity E and a signal P in architecture
e of entity e. Which object is denoted by e.p?
LCS 5 Comments Response:
------------------------
Paul Menchini, as LCS author, should carefully review this comment
and the LCS. There is concern that the LCS may be requiring a compile
time check (hard binding) of default configurations which was not
the intent.
LCS 8 Comments Response:
------------------------
Steve Bailey, as LCS author, should carefully review this comment.
There is concern that the LCS would leave it ambiguous as to whether
or not multiple incremental bindings are permitted. It seems clear
that one incremental binding is permitted. It is believed that the
intent is to allow multiple incremental bindings.
LCS 11 Comments Response:
-------------------------
Sorry, we understand the issues, but the LCS stands -- nothing
will change in the LRM for 1999 to address the issue documented.
LCS 12 Comments Response:
-------------------------
Again, we understand the issues raised, but the LCS stands as is.
LCS 16 Comments Response:
-------------------------
The comment is a useful note to consider during LRM editing.
LCS 19 Comments Response:
-------------------------
Comment is useful to consider during LRM editing.
LCS 20 Comments Response:
-------------------------
The first half of the comment is a note for LRM editing.
The second half of the comment is in error. The proposed
language change does allow implicit signals in port
associations.
LCS 21 Comments Response:
-------------------------
The LCS stands (no change to the LRM). Changing the
semantics of postponed process initialization is not an
upward compatible change. Also, there are relatively easy
modeling ways (only need to create one delta cycle at time
0 and ensure all postponed processes know they will be
executed once prior to being executed as a postponed
process) to address the commenters' desires.
LCS 22 Comments Response:
-------------------------
Extension of the proposed LRM change to cover universal_real's
and user-defined real subtypes is too constraining on
implementations and modeling. Therefore, the LCS stands as is.
LCS 23 Comments Response:
-------------------------
Comment useful to consider during LRM editing.
LCS 24 Comments Response:
-------------------------
This LCS had 3 negative votes. The summary of the discussion
was that BUFFER ports should not be changed in VHDL '99 (agreement
with comments). Buffer ports
can be put on the list of possible language features to remove
in a future language revision.
LCS 25 Comments Response:
-------------------------
No feature was identified as not belonging on the list.
No change to LCS. All items (plus, perhaps Buffer ports)
will be kept on the list. Whether they are actually
removed from the language or not, will be decided in the
next language revision.
LCS 26 Comments Response:
-------------------------
There was a typo in the LCS. The quotes in the 2nd expression
example should not have been there (SV1 "=" SV2 should be
SV1 = SV2). The LCS stands, but John Willis and Paul Menchini
have the action item to contact the commenters to ensure that
we did not miss something important.
--------------
Next Meetings
--------------
Next meeting will be 5 April 99 from 6-9pm at Mentor Graphics
in San Jose, CA.
Possibilities:
DAC (21-25 Jun 99) probably 25-26 Jun (Fri/Sat)?
Who plans to attend?
FDL (31 Aug - 4 Sep)? Who plans to attend?
Steve Bailey
HDL Solutions Manager
Free Evaluation of VB VHDL: http://www.veribest.com/vhdl.html
VeriBest Inc.
The EDA Systems Company
6101 Lookout Rd.
Boulder, CO 80301
303-581-2467 (voice) 303-581-9143 (fax)
303-588-2001 (mobile)
mailto:sbailey@veribest.com http://www.veribest.com