Meeting called to order 8:35 October 20, 2003
Administrivia:
Next meeting is October 20th, at 8:30 Pacific Time, same number.
Meetings occur every fouth monday. Web site is
http://www.verilog.com/IEEEVerilog.html
Attendance:
Today DASC member (D yes, - no)
| |
v v
A aaaaaaaaaaaaaaa D Michael McNamara
A aaaaaaaaaaaa-aa D Steven Sharp
A aaaaaaaaaaaa-aa D Karen Pieper
A aaaaaaaaa----aa D Brad Pierce
A aaaa-aaaaaaaaa- D Shalom Bresticker
A aaaa-aaaaaaa-a- D Charles Dawson
A aaaa D Francoise Martinolle
A aaa------a--aa- D Tom Fitzpatrick
A aa-----a------- D Mehdi Mohtashemi
A a-aa-aaaaaaaaaa D James A. Markevitch
A a-aa----------- D Drew Lynch
A a-a---aaaaa-aa- D Stuart Sutherland
A -aaa D Dennis Brophy
A --aa-aaaaaaaaaa D Anders Nordstrom
A --aa-a-aaaaaaa- D Stefen Boyd
A -----aa-a---aaa - Clifford E. Cummings
A D Richard Ho (rep Curt Widdoes)
A aa D Alec Stanclulesco
A aa D Ennis Hawk
A D Atsushi
aa - Don Mills
aaa-aaaa------- D Kurt Baty
aa D Keith Gover
a--a D Karen Bartleson
-aaa D Jay Lawrence
-a-aaaaaaaaa-aa D Gordon Vreugdenhil
-a D David Smith
-a D Dave Rich
-a D Chong Guan Tan
--a--a--------- - Krishna Garlapati
---a D Steven Dovich
-----aaaaaaaaaa - Dennis Marsa
-------------aa - Erich Marchner
--------------a D Peter Flake
1) The Chair read the IEEE patent policy presentation,and refers all
to http://www.verilog.com/IEEEVerilog.html where a link to the IEEE
policy is prominent.
2) Shalom moves Stuart seconds approving minutes. None oppose, Cliff
(who is not as DASC member), Anders & Stefen abstain, minutes
approved
3) Web page: Things have been broken for the last two weeks; stopping
everything. Stefen feels this is a temporary setback, which he is
fixing as we speak.
4) Report of the 2001c Project:
Shalom: Main body editing is finished; copy sent to IEEE sans
change bars; got from Andy a draft of errata sheet, looks very
nice, orderly, readable; sent comments to Andy, also withdrew one
errata. Awaiting getting revised draft back, and update front
matter, and send it out.
5) Report on User survey
6) Report of BTF committee
7) Announcement Dennis, Mac work out details on how to collaborate.
Peter, send out a definitive message
7) The chair then reminded everyone to send in IEEE roster data at
http://www.verilog.com/IEEEverilog.html, and to verify and renew their
DASC membership, at http://www.dasc.org
8) Then the group took up the next item on the agenda, which was to
review and consider for approval the activities of the Errata and PLI
Task Forces.
Those seeking more information on these issues are directed to
http://www.boyd.com/1364_btf, where one can access these items by
issue number. As is usual practice, these matters are presented to
the VSG by one of the chairs of the task force; discussion ensues; and
only votes of those opposed or abstain are noted.
Issue : 192 Made by Shalom, Seconded by Karen
Opposed: none
Abstain: none
Motion passes
Issue : 205 Made by Shalom, Seconded by James
Opposed: none
Abstain: none
Motion passes
Issue : 225 Cliff (who is not a DASC member) proposed we return this
to ETF for proposed language; Stu seconds
Opposed: none
Abstain: none
Motion passes
Issue : 361 Made by Shalom, Seconded by Steve Sharp
Opposed: none
Abstain: none
Motion passes
Issue : 100 Made by Shalom, Seconded by Steve Sharp
Opposed: none
Abstain: none
Motion passes
Issue : 208 Made by Shalom, Seconded by Steve Sharp
Note to editor: when text is written regarding hierarchial references to
instance arrays, editor should look at restricting constant integer
expressions, as discussed in Issue 247.
Opposed: none
Abstain: none
Motion passes
Issue : 226 Made by Brad Pierce, Seconded by Shalom
Opposed: none
Abstain: none
Motion passes
Issue : 276 Made by Karen, Seconded by Steve
Opposed: Cliff Cummings (who is not a DASC member)
Abstain: none
Motion passes
Note that passing 276 makes Issue 229 moot.
Issue : 295 Made by Steve, Seconded by Brad
Opposed: Stu, James, Stefen, and Cliff (not DASC member)
In Favor: Steve, Karen, Brad, Francoise, Charles
Abstain: none
Motion passes
Issue : 317 Made by Shalom, Seconded by Brad
Opposed: none
Abstain: none
Motion passes
Issue : 337 Made by Steve, Seconded by Stefen
Opposed: Cliff (N.A.D.M.), James
Abstain: none
Motion passes
Issue : 402 Made by Brad, Seconded by Steve
Opposed: none
Abstain: none
Motion passes
10:08 Alec arrived, and started to give a report on activities of the BTF's
coordination committee. We have proposed tasks forces; still need
approval
Issue : 413 Made by Shalom, Seconded by Steve
Proposal is to delete paragraph 4 from clause 4.
Opposed: none
Abstain: none
Motion passes
Issue : 415 Made by Shalom, Seconded by Steve
Opposed: Cliff (it was noted that Cliff is not a current DASC member)nd Mutex primitives
Generic interconnect
Meeting Adjourned at 10:32.
Reminder: PLI task force today at 4:00 pm, email
for details.
Reminder: BTF meeting in five minutes, same number.
-----------------------
Here is Alec's report:
Overview of Donations to IEEE 1364 for Verilog 2005.
===================================================
This document was put together by Alec Stanculescu, and incorporates
the results of:
I1. discussions during the conference call on September 30, 2003
having in attendance: Alec Stanculescu, Ennis Hawk, Francoise
Martinole, Jay Lawrence, and Michael McNamara)
I2. feedback from Michael McNamara and Jay Lawrence via e-mail
I3. discussions during the conference call on October 3rd, 2003 having
in attendance: Alec Stanculescu, Atsushi Kasuya, Ennis Hawk,
Francoise Martinole, and Michael McNamara).
These donations and the motivations behind each one are described in
detail at www.verilog.com/1364donations.html.
This report provides a general description of each donation and
provides information that represents the basis for transforming each
donation into a candidate for introduction into the LRM for IEEE 1364.
In particular it points out areas that still need to be worked out as
well as guiding principles to consider when completing the
specification.
Each donation was declared free of any legal problems by a
representative of the respective donor company: donations 1,and 2 by Jay
Lawrence from Cadence, 3, 7, 8, and 9 by Francoise Martinole from
Cadence, 4 by Mike McNamara from Verisity, 5 by Ennis Hawk from Jeda
Technologies, and 6 by Alec Stanculescu from Fintronic USA. A copy of
the corresponding legal donation documents will have to be attach to
the final report.
1. Design Ip Encryption Extension
This donation was contributed by Cadence Design, Inc. This donation
takes advantage of public key encryption techniques and digital envelopes
to provide an encryption technique that relies solely on encryption keys
and not vendor-specific algorithms. See
http://www.rsasecurity.com/rsalabs/faq/2-2-4.html for a description of
these techniques.
Using these techniques a Verilog source file can be encrypted once with
a single key, and then the key itself is encrypted for each authorized
vendor or user who should be provided access to the IP.
This donation does not have any dependencies to other aspects of the
language. It overlaps with the 'protect/'unprotect constructs mentioned
in the Verilog LRM, but Cadence's implementation is such that
'protect/'unprotect is actually a special case of the newly donated
construct. Cadence will demonstrate that this new technique is 100%
backward compatible with existing `protect usage.
There are various scenarios where this can be used, including
(1) co-operation between parties over the Internet where each party should
have access to the source, but the files should be encrypted during
the transfer; (2) IP sent to a user of the IP that is not supposed to
have access to the source, but should be able to compile it and
simulate it, etc.
Each simulator vendor supporting this encryption should be careful not
to allow PLI or other debug tools to provide information regarding the
described circuit which was intended to be protected by the encryption.
This donation is complete and ready to be implemented.
2. Data Type Extension
This donation was contributed by Cadence Design, Inc. It provides the
basis for a true type system for Verilog. It defines (1) scalars
(2-state, 4-state, real) (2) vectors, (3) composite types (arrays of
any type, and structured types. It also provides dynamic memory
allocation based on a handle/access_type, where the deallocation is
accomplished by assigning NULL to the access_type.
All data types can be applied to both variables and nets. The resolution
of multiple drivers of a net is unchanged from Verilog-1364 in that it
is always applied as a wor, wire, or wand of the scalar elements of the
object.
A wire type Wone is defined that accepts only one driver. This is an
important extension which is in the spirit of the Verilog language.
This donation overlaps with the classes and types donated by Jeda
Technologies, as well as with constructs present in the language
developed by Accellera.
Items to be discussed by the tasks force writing the LRM are:
- enumeration type
- clear definition of scalar (e.g. something that cannot be indexed)
- clear definition of variable vs net concepts
- clear definition of vectors (known also as packed arrays)
- clear specification of deallocation in case two objects of type
access are accessing the same object.
3. VPI Extensions for data and Assertions
This donation was contributed by Cadence Design, Inc.
This donation provides the necessary VPI extensions to support the new
data structures as well as the Sugar/PSL assertions.
This donation is dependent on any new object introduced into the
language, as well as on any language extensions that allow objects to be
referenced in new places. The task force writing the necessary wording
into the LRM will have to use this donation as well as information
regarding all other pertinent extensions to Verilog.
4. Verification Extension
This donation was contributed by Verisity LTD. Verisity LTD
owns certain patents associated to the donation, however Michael
McNamara represented that Verisity has filed a statement with the
IEEE and with the DASC that states that Verisity will make free use
of its patents available to implementors of IEEE 1364 Verilog.
This donation is a subset of the capabilities provided by the e-language
and is meant to provide the user with a minimum necessary support for
verification in a syntax similar to the more extensive verification
language to be standardized under IEEE 1647.
This donation is an extension of donations 2, (Data types) by
introducing syntax that allows the user to specify data items that
should not be generated. It may overlap with donation 5, and to a
certain extent with the language being developed under Accellera.
5. Object Oriented Extension
This donation was contributed by Jeda Technologies, Inc.
This donation overlaps with donations 1 and 4, with IEEE 1647, and
with the language being developed under Accellera. It addresses
important aspects which have to be covered by Verilog 2005.
This donation provides specific constructs for:
i) Classes, Data types, and Pre-defined classes (e.g. Arrays, Hashes,
Lists, Random constraint class, etc.)
overlaps with: 2, 4, and Accellera's work
ii) Aspect programming
iii) Parallel execution, Synchronicity and Mutex primitives
iv) Cycle simulation test bench support
overlaps with 4 and Accellera's work
v) Generic interconnect
Each group of constructs mentioned above can be implemented in the LRM
by a different small task force.
6. Separate Compilation Extension
This donation was contributed by Fintronic USA Inc. This donation has
been created by Fintronic USA, Inc. using only it's own funds. It is
already implemented and shipping for over one year.
Separate Compilation is a must for a modern HDL. It can be used for
libraries of tasks, IPs, modules that do not change often.
At this time Verilog users have several options to address the
lack for separate compilation. Each major simulator vendor supports in
a non-standard way incremental compilation. The OMI standard provides
a standard way to use separately compiled designs, but introduces a
performance penalty due to an additional layer of PLI and an
additional simulation kernel for each separately compiled description.
It is time to come up with a better solution. This donation is
complementary with a donation with a similar name made by Mentor to
Accellera. The Mentor donation provides the use of packages in Verilog.
The Fintronic donation consists of a set of restrictions for both the
separately compiled Verilog and for the Verilog that uses separately
compiled descriptions. The donation describes Fintronic's implementation so
that other implementations for other simulators can be easily made.
As the constructs in this donation do not depend on other donations
already made to the IEEE, the work of writing it into the LRM can be
done by a small task force that will consider the OMI standard as well
as the work done under Accellera for packages.
7. Systemtask-based Randomization Library
This donation was contributed by Cadence Design, Inc. It extends the
randomization capabilities of Verilog by supporting the randomization
of values in any variable, in any instance/scope, with
constraints. Constraints can refer both to variables and to nets. The
new systemtasks support the enable/disable of randomizations, provide
the generation seeds, the availability of a global seed.
This donation is almost completely implemented by Cadence in NC
Verilog.
It does depend in a simple way on the available data types for
variables and nets. Currently it is specified to support all data
types existing in Verilog 2001.
It overlaps with (i) the existing $random mechanism which it extends,
(ii) donation 4 from Verisity which provides syntax for specifying
constraints and and generators as opposed to the programmatic approach
proposed by Cadence, and (iii) donation 5 from Jeda Technologies which
provides a special class for randomization.
8. Transaction Recording
This donation was contributed by Cadence Design, Inc.
It provides a set of systemtasks that can specify transaction streams to be
recorded, as well as linked based on dependency. The recording is done
in an extension of VCD.
This donation depends in a simple way on the available data types and
classes however the dependency is not significant enough to prohibit
the writing of the major LRM wording independently of any other work
on the language.
This donation does not overlap with any other donation. It affects
donation 3 dealing with VPI, in that all transaction streams shall be
accessible via VPI.
What is not clear yet is the playback extension portion of this
donation.
9. General Method for Future Extension of Verilog
This donation was contributed by Cadence Design, Inc. It constitutes a
proposal for adding a new design unit in Verilog, called package. This
design unit shall have some restrictions as compared to modules, which
will facilitate some operations (to be addressed later).
The motivation for this new design unit is to share complex data types
between modules without having to use external references, by using
the "import" construct, which could import all definitions via p.* or just
p.mytype.
One advantage seems to be that a compilation dependency between design
units could be easier specified without adding a supplementary
dependency rule on modules. This could help separate compilation.
This construct seems to overlap somewhat with the existing module
construct which currently allows generic/parameterized design units to
have multiple instantiations and provides for the sharing of objects
in one module by other modules via external references. Syntactic
sugar such as the with construct in Ada or VHDL could be added to
avoid the verbosity of external references.
The new design unit will have to include tasks as they are associated
to operations on objects of certain types. As a result the new design
unit will have to include: sub-scopes, variables, transaction
recording, assertions, initial blocks (to initialize the state of the
tasks), and perhaps always blocks in order to provide assertions of
the best quality.
The specific advantages of the new design unit need to be further
addressed.
This construct seems to overlap with the work done under Accellera
under the name of separate compilation.
Details, such as name conflict resolution, must still be addressed.
-------------------------------------------------------
Comment:
It is the opinion of the members of the CTF that several 2-3 people
task forces operating in parallel could write the LRM wording for the
various donations.
Suggested independent task forces are:
Encryption:
Data types:
Classes, and Pre-defined classes (e.g. Arrays, Hashes, Lists, etc.)
Verification and Cycle simulation test bench support
Aspect programming, Parallel execution, Synchronicity and Mutex primitives
Generic interconnect
Separate Compilation and packages:
Randomization
Transaction recording and playback
VPI :
this task force shall work after a substantial progress is made by
all the other task forces , but NOT AFTER every other task force has
finished its work.