From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Feb 11 2002 - 14:35:25 PST
Precedence: bulk
An interesting thread. Time for me to chime in!
Mac has done a great job of clarifying the @* functionality.
Everyone is correct that the @* was intended to replace verbose and
error-prone combinational sensitivity lists. The @* enhancement is not only
an exceptionally nice shorthand, especially for large and complex
combinational always blocks, it is probably THE Verilog-2001 enhancement
that will fix more synthesis problems than any other enhancement that we
passed. When Mac proposed the enhancement, we all said, "why didn't we
think of this before?" As a number of us have introduced this to Verilog
and Verilog synthesis classes, the students have been overwhelmingly
excited about its introduction and have almost unanimously asked, "when can
we use it?"
When this enhancement was originally proposed, it was going to be a very
limited always @* syntax with rules that were unique to this type of always
block. At the urging of other committee members, we decided it should not
be a different type of always block but that it should be an orthogonal
addition to the language, even though we only really could conceive of the
@* being useful for combinational always blocks. We decided, that some
engineer was going to figure a clever way to use this enhancement that we
as a committee had not conceived.
With that in mind, Dennis has asked some questions and presented examples
that we did not really consider at the time the enhancement was passed. It
could be argued that the enhancement was hastily conceived and poorly
implemented. I disagree. There were those on the committee that were
hesitant to pass any enhancements because we might not get them completely
defined and right. There were others on the committee (myself included)
that wanted the enhancements, made every effort to get them right, and knew
that implementation would show corner cases that would require additional
clarification in the future.
We may have just revealed a couple of corner cases that merit further
clarification. For the corner cases, we often rely on the vendors to tell
us what is reasonable in an actual implementation.
To me, the examples shared by Dennis might also merit addition to my "do
not do" slides in my training courses. I see little value in declaring and
using local variables inside of an always block. I infrequently declare
local variables inside of an initial block inside of a testbench. This type
of usage usually comes from engineers who are still used to VHDL variables
(that typically simulate faster than a VHDL signal), or by Object Oriented
extremists. Naming all of your blocks in Verilog typically adds scope and
slightly slows down simulation. I see no good reason to be coding this way;
however, someone will try, which is why we do need to define this corner
case better.
At 02:22 PM 2/7/02 -0500, you wrote:
Precedence: bulk
>This would seem to expand to something like:
>
> always @(<events from something> or <event involving mem8x10>)
> begin : named
> reg [31:0] b;
> b = <something>;
> a = mem8x10[b];
> end
>
>But what is <event involving mem8x10>? Saying it is mem8x10[b] seems
>suspect to me since the b used to index mem8x10 is not visible from
>there.
Regardless of scoping, named.b can be modified from outside the block.
If that happens, the block needs to be re-evaluated. So you have to be
sensitive to named.b (or the equivalent of mem8x10[named.b]).
It's ugly, but that's what happens when you try to hack new features
into a language.
I prefer the word "add" over "hack."
When I worked for IBM, there used to be a sign on the wall in manufacturing
that read, "There comes a time in the life of every product where you have
got to shoot the engineer and ship the product!"
We could have worked another five years and removed another 90% or the
Verilog-2001 ambiguities, and we could have worked another five years
beyond the first five years and removed another 90% of the remaining
ambiguities. In my opinion, the Verilog-2001 enhancements, warts and all,
were worth introducing now.
It should be noted that the Verilog-2001 Standard cleared-up multiple
ambiguities that existed in the Verilog-1995 Standard, that cleared-up
multiple ambiguities that existed in the OVI (forerunner to Accellera)
Standard, that cleared-up multiple ambiguities that existed in the original
Verilog-XL donated documents.
The Verilog-200X Standard will certainly clear-up ambiguities that exist in
the Verilog-2001 Standard and introduce a whole new set with the
SystemVerilog extensions.
Steven Sharp
sharp@cadence.com
I'm encouraged to see this discussion. It shows that more than just
simulation and synthesis vendors are adding the Verilog-2001 features to
their tools. I would love to know what Dennis is working on (but then he'd
probably have to shoot me).
Regards - Cliff Cummings
//*****************************************************************//
// Cliff Cummings Phone: 503-641-8446 //
// Sunburst Design, Inc. FAX: 503-641-8486 //
// 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
// PMB 501 Web: www.sunburst-design.com //
// Beaverton, OR 97005 //
// //
// Expert Verilog, Synthesis and Verification Training //
//*****************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:35 PDT
and
sponsored by Boyd Technology, Inc.