"always" block

[Navneet Rao]

Hi:
Has anybody seen this...

always @ ( * ) begin
......
......
......
end

Thanks
-Navneet

 

[Jim Wu]

It's one of the features introduced in Verilog-2001, which indicates
anything being read in the always block should be automatically added to
the sensitivity list.

HTH,
Jim (jimwu88NOOOSPAM@yahoo.com remve NOOOSPAM)
http://www.geocities.com/jimwu88/chips


Navneet Rao wrote:

Hi:
Has anybody seen this...

*always @ ( * ) begin*
* ......*
* ......*
* ......*
*end***

Thanks
-Navneet

 

[Allan Herriman]

On Mon, 28 Jun 2004 15:22:24 -0700, Navneet Rao <navneetr@xilinx.com>
wrote:

Hi:
Has anybody seen this...

always @ ( * ) begin
......
......
......
end

Yes, this was introduced in the 2001 language revision. Basically it
means that the sensitivity list is all signals that are used within
the block. This is much less error prone than typing a large list of
signals (which can lead to latch behaviour if you leave one out by
mistake).

BTW, it can also be written always *@ begin ... (without the
brackets).

Regards,
Allan.

 

[ABW]

"Stephen Williams" <spamtrap@icarus.com> wrote in message
news:491e2$40edb595$40695902$2628@msgid.meganewsservers.com...

I'm one of those compiler writers who had a run in with the syntax,
but unlike some other things in Verilog, it is not ambiguous. I had
to detect "(*)" in the lexical analyzer, and if matched, convert it
to a single '*' token. This prevents "(*" from being interpreted as
the start-of-attribute token. It's a little quirky, but not difficult.

Unfortunately it is ambiguous. Since it is not literally defined as a single
token it can and is treated differently by different tools.
Some tools allow @ ( * ) but complain on @ ( /*Alice has */ * /*a cat*/ )
which suggests that they treat whole sequence ( * ) including optional
whitespace as one token. Other tools can deal with whitespace, comments,
macros etc. between (, * and ) which suggests they deal with it on the
syntax level - (, * and ) are separate tokens and (* and *) attribute tokens
are treated in the grammar as a valid replacement for pairs of tokens ( with
* and * with ) accordingly.

You can stop reading here, below are just some things related to lexical
part of Verilog I always wanted to say )

In a perfect world "Lexical conventions" chapter of the LRM would not
contain any information about syntax or semantical meaning of the tokens it
defines but would have all the solid tokens listed (operators, keywords...)
and all constructible tokens defined by simple and unequivocal rules
(strings, numbers, identifiers...). Later chapters would only refer to the
defined tokens and would not define new ones. In order to do this, lexical
grammar would need to be at least context-free, unfortunately it is not the
case of Verilog.

Reality it much worse, because it's the vendors who define actual Verilog.
Even if they implement something that is wrong their custromers and backward
compatibility rule will force them to keep the unwanted features (I am
guilty myself ( but I'm not fan of backward compatibility as long as lack
of it gives something in return). One of the examples would be this
discussion:
http://www.boyd.com/1364_btf/report/full_pr/350.html
IMHO whoever allowed configurations to be part of regular Verilog source in
their implementation simply shot themselves in the foot, in particular
because lexical rules of library mapping file are in conflict with those for
regular Verilog source (see file_path_spec rule - if it was defined as
string there would be no issue, but with current rules I find it more
problematic than additional keywords conflicting with some existing
designs). Personally I don't see LRM allowing configs as part of regular
source text (although some statements in chapter 13 suggest it, but 13.2.1
should make it clear that they are allowed only in special files, and annex
A, which is normative, makes a clear distinction between library_text and
source_text). It would be nice feature to allow configs among modules but
first, rules of config body would have to be adapted to the existing rules
of regular source text.

Everyone who dealt with such "nice and useful features" of lexical grammar
of Verilog knows what I'm talking about f.e.:
based numbers being composed of three separate tokens (instead of two: size
and base+value - value can't be parsed without base),
edge_descriptor which is defined as new kind of token far outside chapter 2
and in some cases conflicts with unsized_number or identifier tokens,
similar case of level_symbols gluing even in LRM examples (8.7),
not mentioning de facto standard `uselib directive (similar problems to the
ones of file_path_spec in library mapping file but easy to workaround as
long as you don't consider Windows paths, besides `uselib does not allow
wildcards which makes it much less problematic than configs) or
real numbers in a form starting from dot (invalid according to LRM but
accepted by many tools)...
The ambiguity of (*) is just one of many in Verilog, I agree that it is one
of the easiest to deal with )

That's all for now, thank you for reading my complaints )

Regards,
ABW

 

[Chris F Clark]

I think the rant was more that other tools don't always get the @(*)
parsing right, particularly in more subtle cases, and in getting it
wrong make the feature more problematic.

While I agree that with a competent lexer and parser generator it
isn't too difficult to get the parsing mostly correct, I'm not so
certain about entirely correct. As a result, I'm not surprised that
some vendors get it subtly wrong, given that there are several almost
hacks that come close. For example, the case of code like:
`define empty
always @(*`empty)
is tricky if one does maximal munch and one wants to treat (* as a
single token when appropriate. Are you really certain, you have all
the cases where something can become syntacticly invisible between
the (* and the ). I, myself, haven't implemented that 2001 extension,
but I won't be surprised if there isn't some subtle case that I miss.

Moeover, I think the point about differing behaviors with respect to
tokenizing (* as one token or as two are correct. There are simply a
different set of tricky issues is you lex (* as two tokens and put
them together in the parser and if you remove whitespace and/or
comments in your lexer.

The sad part of this is that distinguishing the various obscure cases
of (* of how it should be parsed are probably not the best uses of
ones time in general. Most of us have more important tasks.
Unfortunately, it will be some poor user who has a piece of Verilog
that falls on different sides of the crack with two different tools
who suffers in the end.

Hope this helps,
-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

 

[Stephen Williams]

Chris F Clark wrote:

I think the rant was more that other tools don't always get the @(*)
parsing right, particularly in more subtle cases, and in getting it
wrong make the feature more problematic.

Granted.

While I agree that with a competent lexer and parser generator it
isn't too difficult to get the parsing mostly correct, I'm not so
certain about entirely correct. As a result, I'm not surprised that
some vendors get it subtly wrong, given that there are several almost
hacks that come close. For example, the case of code like:
`define empty
always @(*`empty)
is tricky if one does maximal munch and one wants to treat (* as a
single token when appropriate. Are you really certain, you have all
the cases where something can become syntacticly invisible between
the (* and the ).

You got me there. "@ (* /* comment */ )" confounds my lexor, leading
to the token stream @ (* ) and an error. The fix is rather obvious,
but I get the point.


--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

 

[Chris F Clark]

You got me there. "@ (* /* comment */ )" confounds my lexor, leading
to the token stream @ (* ) and an error. The fix is rather obvious,
but I get the point.

Sorry. I didn't mean to "get you", but I'm glad you see the point.
As the joke goes,
"You're in a maze of twisty little passages all coded in Verilog(R)."

-Chris