- Previous message: Michael McNamara: "Resend of minutes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
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.
- Next message: Michael McNamara: "Minutes of the October 20, 2003 meeting of the IEEE 1364 Working Group"
- Previous message: Michael McNamara: "Resend of minutes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
This archive was generated by hypermail 2.1.4
: Mon Oct 20 2003 - 10:20:08 PDT
and
sponsored by Boyd Technology, Inc.