Subject: [sv-ec] Simplicity, conciseness and complexity
From: Vassilios.Gerousis@Infineon.Com
Date: Fri Dec 20 2002 - 07:51:32 PST
Dear SV-EC members,
I have few thought for you to consider in your current discussion
with Join all/none/any. Please think about it and maybe it can guide some of
you to a better decision.
In the last two weeks I have seen multiple emails that are
advocating complexity of language design rather than simplicity,
intuitiveness and clean semantics. SystemVerilog provides a better language
design to describe design/verification with clean, simple and more intuitive
constructs. We are adding two large components (i.e. testbench and
assertions).
It is natural that we expect voices to help us be aware of adding
too much language constructs. This is definitely a concern, if we are just
extending Verilog with just design related constructs. The majority of
SystemVerilog 3.0 was adding many capabilities in higher abstraction that
are mostly synthesizable. The list is small, but very powerful.
Now we are adding two additional languages, that are more complex.
Vera testbench has its modeling capabilities to aid "VERIFICATION Engineers"
with capabilities to help describe testbench and verification environment in
more compact and concise manner that what exist today in Verilog. The
success of a testbench language like Vera is a testament for the growing
need of verification in the industry.
Can we describe Testbench complexity in Verilog (any version)? The
answer is yes. This adds many complexity. Examples:
1- One statement in Vera can substitute 4 or more constructs in Verilog.
2- Someone can build macros (tasks, functions, and even modules) of higher
functions. OVL is one great example of such a capability.
However this has many problems:
1- Simplicity: Provide something direct (intuitive) that a verification
engineer understand. They prefer to use simpler and powerful constructs and
semantics. If things can be described in better language, they will
immediately prefer that.
2- Complexity: One statement in Vera is worth four or more in Verilog can
aid in the following:
a- Smaller code size.
b- Faster execution.
c- Easier to debug.
3- Simplicity (better semantics) can aid in better tools:
a- Certain compilers can help in speeding up simple and concise
constructs with semantics.
b- Future automation: Easy to automatically generate Testbench.
c- etc.
OpenVera has been donated to Accellera to help accelerate
standardization of testbench language. OpenVera has multiple products in the
markets and have been proven in helping verification by verification
engineers. We have gone at least through three steps in the acceptance of
OpenVera as the testbench language extension of SystemVerilog 3.1. Both
SystemVerilog 3.1 and Vera had a portion that intersect. Of Course of those
ones, we will use SystemVerilog. For the others, Synopsys went through a
language construct re-design to make compatible with SystemVerilog.
SystemVerilog is benefiting from the wealth of experience of Vera
and the fact that Vera have been implemented in many tools and designs. It
is time for the committee to start thinking about this experience,
simplicity and conciseness that I spoke of above. It seems that some of us
have went from one extreme to another extreme.
Many things we are adding can be done as macros or functions, but I
do no believe that this is our aim. The language will grow by at least twice
the size, since we are adding large capability. we must way the following:
1- Can the number of lines be decreased by adding these new constructs. This
to me is a better question than looking at it from the other end which is I
can describe this with four lines of code in Verilog.
2- Simpler and powerful Semantics.
3- Intuitive Design / Verification language (as en example "join all" versus
join (1) ).
4- Proof and usefulness: This was implemented in Vera tools and have
provided good capabilities.
To optimize a language does not mean to reduce the number of
constructs. It is good to have smaller numbers, but do not be frugal. As I
said we are adding a completely new language for testbench.
So please examine all aspects before starting to re-design a language which
we know it is working in the industry.
Best Regards
Vassilios
----------------------------------------------------------------------------
--------------------------------------------------
Dr. Vassilios Gerousis
Chief Scientist
Infineon Technologies
DAT CS, MchB
D-81541 Munich
Germany
BalanSt. 73
Telephone: +49-89-234-21342
Fax: +49-89-234-23650
email: Vassilios.Gerousis@infineon.com
Site Map:
http://www.stadtplandienst.de/query;ORT=m;PLZ=81541;STR=Balanstr%2E;HNR=73
----------------------------------------------------------------------------
------------------------------------------------------
This archive was generated by hypermail 2b28 : Fri Dec 20 2002 - 07:52:14 PST