Re: LRM Feedback for BTF Conference call

From: Shalom Bresticker (shalom@msil.sps.mot.com)
Date: Wed Sep 06 2000 - 08:01:30 PDT

<x-html>
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<blockquote TYPE=CITE>> Section 9.2.2 Page 128
<br>>
<br>> The paragraph after example 3 says:
<br>> When multiple non-blocking assignments are scheduled
to occur *in* the same
<br>> variable in a particular time slot, the order in which
the assignments are
<br>> evaluated in not guaranteed--the final value is indeterminate.
<br>>
<br>> Section 5.4.1 guarantees the order in which the non-blocking assignments
<br>> occur. Also note the typo.
<br>>
<br>> Perhaps you need to reword Section 9.2.2 to say:
<br>>
<br>> When multiple non-blocking assignments with timing controls
are
<br>> scheduled to occur to the same variable in a particular
time slot, the
<br>> order in which the assignments are evaluated in not guaranteed--the
<br>> final value is indeterminate.</blockquote>
We had discussions about this a short time ago.
<br>Cliff, and others, suggested a change that this paragraph would be
true only if the NBAs were in different
<br>blocks, as in example 5, but if they were in the same block, as in
example 4, the deterministic order would be
<br>kept.
<p>The last I saw about this was a detailed suggestion from Stu Sutherland,
<br>but I did not see any decision.
<br>
<blockquote TYPE=CITE>> Section 10.2.3 Page 159
<br>>
<br>> I have several issues with the reentrant task enhancement:
<br>>
<br>> 1) There are no known applications for it's
use. Further, the equivalent
<br>> functionality can be expressed
with existing constructs
<br>> (ie. instantiating a module
containing the task). Therefore, the
<br>> enhancement is not needed.</blockquote>
I'll give a real-life example.
<p>We designed an ATM controller chip.
<p>We wanted to simulate multiple ATM packets arriving simultaneously
<br>(i.e., overlapping each other in time) on different ports of the
switch.
<p>We had a task which generated packets and input them to the system.
<p>The number of ports could be dozens.
<br>The chosen port was a randomly generated parameter.
<p>It was a big headache to implement.
<br>With re-entrant tasks, it would have been a snap.
<br>
<blockquote TYPE=CITE>> Section 12.1.3
<br>>
<br>> I would like to comment broadly on the generate statement (as defined
<br>> under "Generate instantiation" in Section 12.1.3) in three parts:
<br>>
<br>> 1) Is the construct appropriate for the language?
<br>>
<br>> The proposed "generate" construct marks such
a major departure from
<br>> the rest of the Verilog language that it
is reasonable to consider
<br>> whether the construct itself is appropriate.
<br>>
<br>> It's difficult not to begin with the simple
comment that Verilog
<br>> is not VHDL.
<br>>
<br>> The fact that a construct exists within VHDL
is neither a sufficient
<br>> reason - nor even a good indication - that
it should be added
<br>> to the Verilog language.
<br>>
<br>> The two languages have their own individual
look, feel and
<br>> self-consistency. What is appropriate
in one, does not necessary
<br>> have any business whatsoever in the other.
<br>>
<br>> Much of the appeal of Verilog, much of what
has made it the
<br>> predominate hardware description language
is that it has taken
<br>> a clean minimalist approach. (Much
as C has triumphed over the
<br>> well-meaning, but overly-cluttered ADA).
<br>>
<br>> So before adding any construct to Verilog,
it is important to
<br>> determine that the construct is both necessary
and consistent
<br>> with the rest of the language; otherwise
the language as a whole
<br>> is degraded. It is difficult to accept
that the generate construct
<br>> meets these criteria.
<br>>
<br>> Moreover, one must consider the negative
impact that this construct
<br>> will have on tools supporting the Verilog
language.
<br>>
<br>> Rather than, as the rest of the language
does, describing hardware
<br>> or the behavior thereof, this construct allows
the language
<br>> to be used in a completely different way.
It allows Verilog to be
<br>> used to describe the generation of Verilog.
This is not just
<br>> a new entity within the language, it a completely
new process.
<br>>
<br>> It changes all of the rules, assumptions,
and conventions that
<br>> previously existed within the language.
The natural barrier between
<br>> simulation and elaboration has been removed.
<br>>
<br>> The consequence of this will be that commercial
tools based on the
<br>> Verilog HDL will either require massive revision
or must choose
<br>> not to support the construct. It seems
not unlikely that they will
<br>> choose the latter.</blockquote>
The lack of "generate" is universally felt to be one of the biggest
missing features
<br>of the Verilog language. VHDL has many features that people don't
request to put
<br>into Verilog.
<p>People want "generate" in Verilog because they need it and it's
not there.
<br>And it annoys them that it does not exist in Verilog.
<br>They justifiably say, "If VHDL can do it, then it's possible.
So why not in Verilog?"
<p>I too personally feel the need for it.
<p>As for commercial support, Synopsys's new Verilog compiler already supports
it.
<br>If Cadence will not support it, everyone else will do it in order to
grab Cadence's market share.
<pre>--

************************************************************************
Shalom Bresticker email: shalom@msil.sps.mot.com
Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268
P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890
<A HREF="http://www.motorola-semi.co.il/"><a href="http://www.motorola-semi.co.il/">http://www.motorola-semi.co.il/>>
************************************************************************</pre>
 </html>

</x-html>

This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:54:13 PDT and
sponsored by Boyd Technology, Inc.